Костыль в программировании что это
Костыль в программировании что это
В коде живого проекта соотношение времени работы над проектом и количества костылей выглядит как пила, у которой каждый зубчик — итерация.
Цикл итераций выглядит примерно так:
Если вы работаете на молодой развивающийся проект — создавайте набор точечных и специфичных утилит. Такой вариант разработки долгое время будет эффективен, поскольку:
Стройная и красивая архитектура возможна только в случае, когда вы сразу видите полный объём решаемых задач. Для эволюционирующего бизнеса это условие практически невыполнимое. Поэтому очередной рефакторинг стоит проводить, когда вы заново качественно переосмыслили, как должна работать определённая часть проекта.
Костыль усложняет и восприятие кода — код, напичканный обработчиками частных случаев, очень сложно поддерживать. И в какой-то момент такой код становится невозможно развивать.
Если ваш костыль живёт в коде достаточно долго, а тем более если он обрастает братьями и сёстрами, — следует запланировать рефакторинг в одной из ближайших итераций.
Такие частные решения всё-таки находят свое применение:
Как правильно использовать костыли в разработке и не наплодить ошибок
В любом серьёзном проекте разработки найдутся костыли. Это естественный элемент пейзажа и процесса. Рассказываю, как ставить их правильно.
Костыльное программирование — это, мягко говоря, не идеальное решение. Костыль чаще всего не оптимизирован с точки зрения эффективности и производительности. И всё-таки иногда они нужны. Причин, по которым костыли появляются в коде, великое множество. Чаще всего их используют для быстрого и простого исправления ошибки, чтобы не переписывать половину модуля. Но бывают и другие случаи.
Костыляем правильно
Виртуальный график количества костылей ко времени в коде живого проекта напоминает пилу, у которой каждый зубчик — итерация. Цикл итераций выглядит примерно так:
Помните, что рефакторинг — достаточно затратный процесс, так как на этом этапе нужно понять статус и общую картину, расписать текущий алгоритм, проверить все точки соединения с другими частями проекта и с внешними ресурсами, провести миграцию существующих данных.
Тестирование отрефакторенного проекта — это отдельная задача неочевидной на первый взгляд сложности. Следует проверить, не потеряли ли мы что-нибудь нужное в процессе отработки наших костылей.
Когда вы работаете на молодой развивающийся проект, создавайте набор точечных и специфичных утилит — такой вариант разработки долгое время будет одним из наиболее эффективных:
В проекте, где бизнес-процессы неустойчивы, сложное целостное программное решение продержится до первой непредугаданной «хотелки» заказчика. А она прилетит очень скоро.
Архитектура кода не может быть стройнее и сложнее архитектуры бизнеса.
Стройная и красивая архитектура возможна только в случае, когда вы сразу видите полный объём решаемых задач. Для эволюционирующего бизнеса это условие практически невыполнимое. Поэтому очередной рефакторинг стоит проводить тогда, когда вы заново качественно переосмыслили, как должна работать определённая часть проекта.
Костыль усложняет и восприятие кода — код, напичканный обработчиками частных случаев, очень сложно поддерживать. И в какой-то момент такой код становится невозможно развивать.
Если ваш костыль живёт в коде достаточно долго, а тем более если он обрастает братьями и сёстрами, — следует запланировать рефакторинг в одной из ближайших итераций.
Когда пригодятся костыли
Такие частные решения всё-таки находят свое применение:
Так мы можем «быстро накостылять, а потом, если идея сработает, выпилить костыль и написать код с нуля как следует» — это хорошее решение для лёгких быстрых проектов. Но если речь идёт о высоконагруженных проектах, то неоптимизированный и не доведённый до ума код может поставить под угрозу работу всей системы.
И помните, что даже костыль нужно писать аккуратно, грамотно, соблюдая стилистику и максимально подробно описывая причину, по которой он создавался. Это нужно, чтобы, вернувшись к своему же коду год-два спустя, вы не испытывали неловкость, найдя ответ на вопрос «Кто писал этот бред?».
Костыльный программист
Статья посвящена оверинженирингу и тем, кто предпочитает старые костыльные решения лишь потому, что они очень просты. Перевод под катом.
Джейми Завински – из тех, кого я называю «костыльными программистами». И я произношу эту фразу с изрядной долей уважения. Он из той породы программистов, которые упорно работают, создавая будущее и разрабатывая всевозможные полезные штуки. Т.е. они умеют делать рабочие продукты.
Это именно тот человек, который вам нужен, если ваша команда занимается созданием велосипедов, потому что два его излюбленных инструмента – костыли и WD-40. И он элегантно владеет ими, даже когда ваш велосипед мчится с холма со скоростью миля в минуту. А тем временем другие программисты всё ещё застряли у старта, споря, что лучше: титан или уникальный композитный материал космической эры, который Боинг использовала в своём 787.
Когда вы закончите, у вас получится неряшливый велосипед, но вы можете быть абсолютно уверены, что он взлетит.
Я просто прочёл интервью Джейми в книге Coders at Work Питера Сейбела. Это колоссальный набор интервью с великими программистами, в том числе Питером Норвигом, Гаем Стилом и Дональдом Кнутом. Книга настолько интересна, что я вчера провёл на диване целых 60 минут вместо обычных 30, т.к. просто читал и не мог остановиться. Как я уже говорил, идите и прочтите её.
Примеч. Перев.: Coders at Work – сборник интервью. Известные программисты отвечают на один и тот же список вопросов. Одно интервью – одна глава. Всего 15 глав.
Это то, за что я люблю костыльных программистов. А теперь представьте: вы работаете в команде. Вы страшно заняты, лихорадочно набрасывая код. И тут к вашему столу подходит некто с кружкой кофе в руке и начинает трескотню: мол, вы можете увеличить крутость вашего приложения на целых 34%, если воспользуетесь многопоточными подразделениями COM. И это даже не так уж сложно, поскольку он наваял пачку темплейтов, и всё, что вам нужно сделать – воспользоваться множественным наследованием, унаследовавшись всего от 17 темплейтов, каждый из которых принимает в среднем четыре аргумента, а дальше вам останется только написать тело функции. Вам покажут просто гигантский список множественного наследования кучи классов и, кхм, многопоточных подразделений COM. И ваше сознание уплывает, и вы перестаёте понимать, о чём, чёрт возьми, болтает этот хмырь. Но он просто не хочет уходить, и даже если уйдёт, то лишь затем, чтобы, вернувшись в свой офис, написать ещё больше умных классов, полностью основанных на множественном наследовании без единой реализации. И когда вся конструкция с треском рухнет, именно вас посреди ночи попросят прийти и разобраться, потому что он уже будет на какой-нибудь долбанной конференции по паттернам проектирования.
А костыльный программист не побоится сказать: «Множественное наследование – отстой. Выкинь его. Просто выкинь».
Как видите, все остальные слишком боятся показаться идиотами, признав, что просто не способны одновременно удерживать в голове достаточно фактов, чтобы заставить работать множественное наследование, или темплейты, или многопоточность, или COM, или ещё что-нибудь из этих вещей. Поэтому они боязливо соглашаются с любым модным программистским безумием Архитектурных Астронавтов, которые выступают на конференциях, пишут статьи и книги, и настолько продвинутее, чем мы, что даже не осознают, что продвигаемые ими штуковины слишком сложны для нас.
А вот что говорит Завински о Netscape: «Выпустить продукт в срок нам позволили решения вроде не использовать C++ и многопоточность».
Позже он писал email-клиент в Netscape, но команда, ответственная за непосредственно отображение сообщений на экране, так никогда и не выпустила свой компонент. «От них требовался большой пустой прямоугольник в центре окна, где мы могли бы просто отображать текст. Но они подошли к проекту слишком теоретизированно, попытавшись взглянуть на вещи со стороны DOM/DTD. “Хм, ну… нам нужно всего лишь ввести дополнительный слой абстракции, и делегировать делегата делегата, после чего символ наконец появится на экране”».
— Похоже, оверинжениринг сильно вас раздражает, — заметил Питер. 
— Да, — ответил Завински. – В конце дня просто выпустите грёбаный продукт! Конечно, переписывать код, делая его чище – это круто, и с третьего раза он действительно станет красивее. Но цель-то не в этом. Вы здесь не для того, чтобы писать код, а для того, чтобы выпускать продукты!
Завински не заморачивается кучей юнит-тестов. Они «выглядят замечательно… в теории. Если вы избрали неторопливый темп разработки – это ваш путь. Но, взглянув на “необходимо полностью создать с нуля за шесть недель”, ну… я понимаю, что это нереально без какой-нибудь урезки. И выбрасывать я собираюсь то, что не слишком важно. И юнит-тесты не критичны. Если их не будет, пользователю даже в голову не придёт жаловаться на их отсутствие».
Прежде чем возмущаться, вспомните, что Завински был в Netscape, когда они изменяли мир. Они думали, что у них есть всего несколько месяцев, прежде чем кто-то другой снимет все сливки. Много важного кода написано в таком стиле.
Костыльные программисты – прагматики. Завински популяризовал наставление Ричарда Габриэля «Чем хуже, тем лучше». На 50% идеальное решение, которое уже есть у людей, решит больше проблем и дольше проживёт, чем 99% идеал, которого нет ни у кого, потому что он валяется в вашей лаборатории, где вы до бесконечности полируете чёртову штуковину. Выпуск – это фича. По-настоящему важная фича. Она обязана быть у вашего продукта.
Принцип, который хорошо известен всякому костыльному программисту: любая кодерская технология, которая всего лишь чуточку переусложнена, похоронит ваш проект. Костыльные программисты стремятся избегать C++, темплейтов, множественного наследования, многопоточности, COM, CORBA и уймы прочих технологий, чьё применение выглядит оправданным, если думать об этом много и долго, но которые чуток сложноваты для человеческих мозгов.
Конечно же, формально нет ничего плохого в том, чтобы попытаться написать на C++ многопоточный код в Windows, используя COM. Но это трахотня с катастрофическими багами, многие виды которых возникают только при определённых временных сценариях, и всё потому, что наши мозги, действительно, не слишком хороши для работы с таким кодом. Посредственные программисты занимают оборонительную позицию, не желая признавать, что они не способны писать такой сверхусложнённый код. И они позволяют хвастунам из своей команды перепахивать проект унылой темплейт-архитектурой C++, потому как иначе им придётся признать, что они недостаточно продвинуты для использования того, что сам Спок признал бы идеальной программерской техникой.
Костыльным же программистам насрать, что вы о них думаете. Они – приверженцы простых и лёгких в использовании инструментов, которые позволяют высвободить дополнительные мозговые мощности, направив их на создание новых фич для пользователей.
Но есть одна загвоздка, на которую стоит обратить внимание: костыльные программисты – это IT-эквивалент симпатичных парней. Да-да, тех восхитительно выглядящих щёголей, которые могут выйти из дома непричёсанными, с нечищеными зубами, во вчерашней грязной одежде — и всё равно выглядеть блестяще по самой своей природе. Вы, мой друг, не можете показаться на людях с растрёпанными волосами, иначе распугаете всю округу.
Потому что вы не симпатичный парень.
У костыльнных программистов достаточно таланта, чтобы справиться со всей этой хренью. Они достаточно хороши, чтобы выпускать продукт, и мы простим, если они не напишут юнит-тестов или даже поксорят указатели “Prev” и “Next” в связанном списке, дабы высвободить дополнительно 32 бита памяти. Потому что они достаточно хороши, чтобы с этим справиться.
Заметки о костылях
Все же есть в этом мире порой некоторые вещи, которые можно обсуждать бесконечно.
И что самое замечательное, каждый раз такое обсуждение может закончиться совершенно непредсказуемым результатом, как для автора, так и для читателей.
Любому разработчику известно для чего нужды костыли, велосипеды и грабли. И наверняка у каждого уже есть парочка в гараже, а так же бубен на стенке для особых случаев. Если у вас еще их пока нет, вы либо совсем недавно присоединились к нам (Возможно, только вчера открыли «PHP для чайников» и через пару дней у вас они тоже будут. Костыли будут конечно же свои, не многие из нас открывают свои чуланы чужим.) или ставите задачи для вашей армии раз***в (пусть тут будет слово близкое вам сегодня), когда очередное недоразумение уронит вам сервер, выведет кривой отчет или просто откажется запускаться программа. Оставлю тихую надежду, что остальные, те кто пользуется плодами этого совместного творчества сюда не зайдут.
Начнем с определения.
«Костыль — приспособление для поддержания веса тела пациента при стоянии и ходьбе» (с) Вики
То есть «костыль» не такое уж и плохое решение, как может показаться. Думаю, не один здравомыслящий человек не будет отказывать от возможности ходить, когда этого лишён, но он точно не захочет опираться на клюку когда все в порядке.
Определение есть, теперь немного о предмете (пациенте)
Считается что приложение (решение, система…) пишется с первого раза, без ошибок и не требует не только поддержки, но и развития. О процессе утилизации — переходе от одного решения к другому (вы надеюсь не верите в зубных фей и в вечно работающие сервера, базы данных, платформы, технологии) промолчим, как и об оценке каждого их этих этапов.
Вообще все ещё немного страшнее, существует целые направления в науке занимающие оценкой проектов, анализу рисков и остальной околоразработческой деятельности.
Назовем эту простую стратегию – «Стратегия святого Грааля разработки». Никто никогда не видел быстро-качественно-дешево, но все уже хотят еще вчера, и что самое интересное все знают, что это такое — «сделайте мне красиво».
Результат очевиден.
В итоге, в погоне за великой целью гибнут многие из нас, кто в странных технологиях: гибкая разработка, автоматизированное тестирование, парное программирование и т.д., и т.п.; кто в темных углах различных средств и языков, начиная от C++, Java, Pyton, PHP, JS; кто на подобных форумах ^_^
А давайте предположим, что пациент изначально больной (в надежде что не головой, бывают и такие варианты). Что, если единственно, что ему надо — не научиться бегать (конечно бегать, ведь ходить или ползать неинтересно, где вы встречали вменяемые сроки отведенные на разработку), а получить представление о беге, почувствовать ветер и скорость, пусть это будет просто вентилятор и человек бегающий с кустом в руках вокруг. И тогда все становиться гораздо проще.
Тогда достаточно используя различные костыли создать нечто способное ковылять и по мере развития, если конечно оно последует (реальный бизнес такая не предсказуемая вещь), мы потихоньку будет сначала убирать, то один, то другой, при условии полной или частичной «реабилитации» «пациента».
В итоге каждый получит что хотел: клиент получить возможность бегать и не надорвётся в попытках взять стометровку на олимпийских спринтах, да и разработчики не будут судорожно подбирать очередную клюку в надежде, что вот как раз теперь она нужного размера.
Резюмируя.
Исходя из нашего предположения, вы как разработчик всегда должны проектировать две системы (а иногда и больше, гораздо больше): первая это то, что можно сделать прямо сейчас, и «идеальная» — включающая идеальное представление о том, какой она должна быть (вдруг и правда, нужно будет выиграть олимпиаду).
Вы должны уметь в уме создавать решения способные изменять любую имеющуюся систему на набор костылей и наоборот.
И главное, в следующий раз, когда будет решать ну прямо очень сложную задачу, попробуйте для начала вот ту палку в углу, которую поставили пару дней назад, возможно, что и не заработает, но поковыляет.
Что такое костыль в программировании
Primary tabs
Forums:
Костыли — это неудобные, но работающие решения той или иной проблемы в коде программы.
Неудобные обычно в смысле трудности дальнейшего развития системы и относящиеся к плохому стилю.
Работают они как-то так:
Примечание: иногда (не так часто) делать костыли приходится вынуждено из-за чисто технических ограничений, например, существования разных браузеров, которые при этом и работают сильно по-разному.
Часто костыль делают именно как быстрое решение — когда лень (+ отсутствие времени и/или навыков) не позволяет сделать что-то более продуманное и осмысленное.
Костыли обычно чужие — не свои
Как говорит один уважаемый человек: костыли — относительное и субъективное понятие, и обычно их замечают только в чужом коде (почему-то 😉
В своём же коде программист под воздействием таинственных сил часто ничего плохого не видит!
Этот феномен не разгадан до сих пор.
А что у нас в реальности
Большинство реальных программистов так или иначе, хотя бы раз в жизни «костыляли» свои программы — то есть использовали быстрые, но неизящные решения, в связи с чем их (костыли) и отобразили на знаменитом гербе программистов.
Более того, некоторые программисты следуют только стилю костылей, практически не производя иных продуктов))
Как сервировать костыль — и подавать в «правильном» освещении
Если хочется приподнести быстрое решение проблемы в положительном смысле — назовите его хаком 😉
Спросила меня недавно одна знакомая о том что такое костыли в программировании. Тут я задумался, какую аналогию можно провести чтобы человек далекий от программирования понял что такое костыли. Недолго думая я кое-что придумал.
«В общем представь себе калеку. Безногого. Ходить он не может по определению. Но ты суешь ему костыли. Один за другим надеясь на чудо. Но чудо никак не происходит. Но тут, в конце-концов происходит какая-то магия, и он встает. Не идет конечно, но он уже стоит. Мы на радостях аккуратно, чтобы он не дай бог не упал, в одной руке держим бубен, а второй аккуратно даем костыли дальше. А дальше два варианта развития событий. Или происходит черная магия и калека начинает идти на этих костылях, или же он снова падает, и нам придется забрать у него все костыли, доделать их, и начать давать ему их снова, пока он наконец не пойдет. Так вот. Калека – это код. Ну а это те самые костыли на которых он держится.»
Дубликаты не найдены
no. Костыли – это когда вместо шины/гипса/фиксирующей повязки, ты тупо вручаешь костыли человеку с травмой ноги(не обязательно с травмой, он почему то не может ходить, а тебе некогда разбираться). И о чудо – он пошел. Нормальный код- это когда ты сделал рентген, убедился что там перелом, совместил кости и наложил гипс.
А просто сказать: «тоже самое, что и у калеки» нельзя было, или настолько привык, что без костылей даже в объяснении не обойтись?
У нас есть калека ты даешь ему костыль он не идет. Ты надеваешь ему кастрюлю на голову и о чудо он идет. Такое сравнение мне нравится больше.
Смотреть что такое «Workaround» в других словарях:
workaround — (n.) by 1987, from WORK (Cf. work) (v.) + AROUND (Cf. around) … Etymology dictionary
Workaround — A workaround is a bypass of a recognized problem in a system. A workaround is typically a temporary fix that implies that a genuine solution to the problem is needed. Frequently workarounds are as creative as true solutions, involving outs >Wikipedia
Workaround — Unter einem Workaround (englisch für: [um etwas] herum arbeiten bzw. in etwa Abhilfe) versteht man die Umgehung eines bekannten Problems innerhalb eines technischen Systems durch eine Hilfskonstruktion. Es ist eine provisorische Lösung, die die… … Deutsch Wikipedia
Workaround — Un workaround ou work around (avec un trait d’union), anglicisme signifiant littéralement « travail autour », parfois traduit en solution de rechange ou de contournement[1], est, notamment en informatique, le contournement d’un bug ou… … Wikipédia en Français
Workaround — Notbehelf; Behelfslösung; Umgehungslösung * * * Workaround [dt. »ein Problem angehen«], das Überarbeiten von fehlerhafter Hard oder Software, bei der aber der Fehler nicht beseitigt, sondern nur ein Lösungsweg angegeben wird, den Fehler zu… … Universal-Lexikon
workaround — An ingenious, undocumented way to solve a problem. ► “One workaround is to print a business letter on plain stock and then photocopy it onto the letterhead.” (MacWorld, Dec. 1994, p.135) … American business jargon
workaround — noun /ˈwɜː(ɹ)k.əɹaʊnd/ a) A means of overcoming some obstacle, especially an obstacle consisting of laws, regulations, or constraints. b) A procedure or a temporary fix that bypasses a problem and allows the user to continue working until a… … Wiktionary
workaround — n. manner of bypassing a problem caused by a bug without correcting the bug itself (Computers) … English contemporary dictionary
workaround — noun Computing a method for overcoming a problem or limitation in a program or system … English new terms dictionary
workaround — /ˈwɜkəraʊnd/ (say werkuhrownd) noun Chiefly Computers Colloquial a temporary means of bypassing or avo >Australian English dictionary