Костыль в программировании что это

Костыль

Костыль — средство добавления недостающей функциональности или исправления серьёзных дыр без должного редизайна системы. Каждый костыль затрудняет дальнейшее развитие. В тех случаях, когда костыль уничтожает незапланированную функциональность, называется заплаткой.

В этом мире много т. н. «костылей». Четкого определения нету, но, в общем, костыль — это нечто, что навешивается на что-то для решения какой-либо возникшей проблемы (и/или добавления функциональности), вместо того, чтобы это «что-то» переработать (возможно, с нуля). Яркие примеры костылей — ipsec, smtp auth, pppoe, и прочее.

Содержание

Суть [ править ]

Костыли могут создаваться в силу неспособности разработчика создать более фундаментальное решение, либо в случае необходимости быстро устранить некий критичный баг, исправление которого более элегантным методом в предоставленные сроки невозможно. Такие костыли называют «временным решением», но, как говорится, «нет ничего более постоянного, чем временное (решение)». Маленький костыль называют «грязный хак» или сопля. Как и костыли, сопли могут создавать проблемы в дальнейшем. Есть мнение, что в этом вашем программировании есть три основных парадигмы: костылирование, инкостыляция и поликостылизм.

Синонимом кода, состоящего из костылей чуть более, чем полностью, является индусский код.

Окостылил говнокод?
Ляг, поспи и все пройдет.
Встал, покодил, все-равно
Получается говно.

Как не патчил много лет,
Как не фиксил баги,
Все-равно велосипед
На костыльной тяге.

Что б совсем без костылей,
Великов и багов
Нанимайте, говорю,

Способы борьбы с костылями [ править ]

• Переписать всё начисто.
• Взять и уебать Убедить автора, что так писатьнехорошо, и переписать начисто.
• Убить нахер Убедить ПМа, что быстро только мухи рождаются, и пересмотреть сроки.
• Добавить ещё один костыль.
• Объявить фичей и построить вокруг ровное приложение.

Пример [ править ]

При написании программ для Microsoft Windows некоторые программисты полагались на баги WinAPI. Позднее, при создании свободной реализации WinAPI Wine, эмуляцию соответствующих багов пришлось добавить специально, чтобы обеспечить совместимость этих программ с Wine. Некоторый лулз состоит в том, что в MS при разработке новых версий софта занимаются тем же самым ради совместимости с предыдущими версиями.

Я впервые услышал об этом от одного из разработчиков популярной игры SimCity, который поведал мне о критической ошибке в их программе: она использовала память сразу после ее освобождения. Главное табу, нарушение которого прощалось в DOS, но карается в Windows, где освобожденную память тут же стащит другое работающее приложение. Тестеры в команде разработки Windows протестировали множество популярных приложений, чтобы убедиться, что все работает без сбоев, но SimCity зависала. Они сообщили это разработчикам Windows, которые дизассемблировали SimCity, шаг за шагом в дебаггере найдя ошибку, и добавили специальный код, проверяющий наличие SimCity в памяти и запускающий распределитель памяти в специальном режиме, в котором SimCity разрешается использовать память после ее освобождения.

То есть даже когда они были лицом к пользователю, лицо всё равно было как жопа. Вкурочить! Костыль! Для КОНКРЕТНОЙ программы! Вместо того, чтобы просто галочку в свойства совместимости добавить — «удерживать за приложением высвобожденную память до следующей аллокации»! А если так уж хочется полной автоматики, пусть по умолчанию для СС она там стоит. Вот бы тогда бы уже понять, что M$ надо руки отпиливать по самую жопу :(

Или вот такой костыль для IE — добавляет для элементов LI, вложенных в элемент свойство hover. Здорово нужен при написании разномастных выпадающих меню.

Костыли IRL [ править ]

При проектировании самолета конструкторы постоянно сталкивались с самыми разнообразными, ранее никогда не встречавшимися проблемами. Например, у компоновки самолета, выигравшего конкурс, шасси не вписывалось в предназначенный для него отсек. Для выхода из ситуации предлагались довольно экзотические решения – воздухозаборники выносились на «спину», а после выхода на заданный курс самолет должен был переворачиваться кабиной вниз и так совершать полет. При посадке бомбардировщик должен был снова переворачиваться в исходное состояние.

• В Петербургском метро в 99-м году обрушился козырёк над входом на станцию «Сенная площадь». После под каждый похожий козырёк подставили подпорки, которые портят вид станции и мешают пассажирам. К концу нулевых большинство из них либо перестроили (как, например, наркоманского вида Горьковская), либо под козырьки запихали ларьки, либо козырёк убран вообще. Дольше всех подпорки продержались на Василеостровской.
• В самарском метро в 2002 году открыли станцию «Московская», а оборотный тупик (или съезд) зажали. В результате, до конца 2007 года, когда открыли станцию «Российская», поезд сначала приезжал со станции «Спортивная» на один путь станции «Гагаринская», разворачивался в тупике, подходил ко второму пути этой же станции и дальше уже ехал до станции «Московская».

Также костылём водилы называют малоразмерное запасное колесо («докатку»). Вот такое, например.

Workaround

Обходной приём, или Workaround — обходное решение проблемы, выявленной в системе (в простонародии «костыль»). Обходной приём обычно является временным исправлением, подразумевающим, что требуется подлинное решение проблемы. Очень часто обходные приёмы так же креативны, как истинные решения, и требуют нестандартного мышления.

Обычно они рассматриваются как неустойчивые варианты, не отвечающие в полной мере будущим требованиям, выходящим за рамки изначального дизайна системы. При реализации обходных приёмов важно пометить изменение так, чтобы в будущем разработать подходящее решение.

Обходные решения применяются в разных областях человеческой деятельности, не только в программировании.

Реализация обходного приёма может стать причиной отказа системы в будущем [1] . К примеру, в компьютерном программировании обходные приёмы часто используются, чтобы обратиться к проблемному месту в библиотеке, такому как некорректное возвращаемое значение. Когда библиотека наконец-то будет исправлена, обходной приём может стать проблемой для функционирования всей программы, поскольку он ожидает от библиотеки старого, неправильного, поведения.

Содержание

Причины применения обходных решений

• Высокая стоимость подлинных решений
• Отсутствие в нужный момент ресурсов, требуемых для реализации подлинного решения
• Подлинное решение требует большого времени для разработки
• Пока неясно, как реализовать подлинное решение, и что оно будет из себя представлять
• Внедрение подлинного решения приведёт к потере совместимости с большим количеством существующих систем. Переоборудование же всех систем — дорогостоящее и долговременное занятие

Примеры широко известных обходных решений

В программировании

• Функция __doPostBack в ASP.NET. Существует потому, что у браузеров изначально не было возможности инициировать отправку страницы на сервер с помощью клиентского сценария (фактор — совместимость)
• Спецификация XHTML 1.0 Transitional. Существует по причине наличия у населения огромного количества браузеров, поддерживающих старые спецификации HTML [2][3] (фактор — совместимость)

В технике

• «Жучок» вместо предохранителя в электрощитке. Позволяет немедленно восстановить электроснабжение при отсутствии под рукой предохранителей, но может привести к пожару в случае перегрузки или короткого замыкания [4] . (фактор — ресурсы, иногда — время)
• Выход в интернет или связь нескольких компьютеров и прочих цифровых устройств через модем, подключённый к телефонной (Dial-up, ADSL) или телевизионной (Кабельные модемы) линии, вместо подключения по более дорогому цифровому каналу связи, специально предназначенному для этого (витая пара, оптоволокно) [5] . (фактор — стоимость, иногда — время)
• Системы кодирования цвета в аналоговом телевидении: PAL, [6] . (фактор — совместимость)

В медицине

• Временная пломба на зубе, применяемая при лечении глубокого кариеса (первое посещение), лечении пульпита биологическим методом, после заполнения корневого канала. (фактор — время)
• Костыли — пока не срастётся перелом и больной будет в состоянии ходить без поддержки. (фактор — время)

Примечания

1. ↑ASP Net — Firefox doPostBack (LinkButton) not working
2. ↑Переход к XHTML
3. ↑Сага о DOCTYPE
4. ↑«Жучки», буржуйки и иконы
5. ↑FastEthernet против ADSL
6. ↑Как устроен телевизионный сигнал. Теория цифровой обработки видеоизображения.

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое «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 outside the … 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 avoiding a particular problem without addressing its cause …

Костыли в программировании — что это?

В этой статье разберем, что означает слово костыли в области программирования.

Время чтения — 1 минута

Поделитесь статьей в социальных сетях

В этой статье разберем, что означает слово костыли в области программирования.

Костыли — это не очень удобные, но по каким-то причинам работающие решения, которые присуще той или иной программе при разработке.

Стоит знать, что иногда костыли приходится создавать искусственно и по вынужденным мерам. Это может происходить из-за каких-то технических ограничений.

Но нередко среди разработчиков бывает и такое, что костыли делают в качестве какого-то быстрого решения проблемы, допустим когда у разработчика остается очень мало времени до сдачи проекта, ему приходится прибегать к таким мерам.

Как показывает практика, большинство программистов хоть раз, но пользовались данным «механизмом», другими словами, делали быстро по времени, но не очень качественно и изящно, что, конечно, в последствии это сказывалось на работе той или иной программы.

что значит костыль в программировании

В коде живого проекта соотношение времени работы над проектом и количества костылей выглядит как пила, у которой каждый зубчик — итерация.
Цикл итераций выглядит примерно так:

Если вы работаете на молодой развивающийся проект — создавайте набор точечных и специфичных утилит. Такой вариант разработки долгое время будет эффективен, поскольку:

Стройная и красивая архитектура возможна только в случае, когда вы сразу видите полный объём решаемых задач. Для эволюционирующего бизнеса это условие практически невыполнимое. Поэтому очередной рефакторинг стоит проводить, когда вы заново качественно переосмыслили, как должна работать определённая часть проекта.

Костыль усложняет и восприятие кода — код, напичканный обработчиками частных случаев, очень сложно поддерживать. И в какой-то момент такой код становится невозможно развивать.

Если ваш костыль живёт в коде достаточно долго, а тем более если он обрастает братьями и сёстрами, — следует запланировать рефакторинг в одной из ближайших итераций.

Такие частные решения всё-таки находят свое применение:

Как правильно использовать костыли в разработке и не наплодить ошибок

В любом серьёзном проекте разработки найдутся костыли. Это естественный элемент пейзажа и процесса. Рассказываю, как ставить их правильно.

Костыльное программирование — это, мягко говоря, не идеальное решение. Костыль чаще всего не оптимизирован с точки зрения эффективности и производительности. И всё-таки иногда они нужны. Причин, по которым костыли появляются в коде, великое множество. Чаще всего их используют для быстрого и простого исправления ошибки, чтобы не переписывать половину модуля. Но бывают и другие случаи.

Костыляем правильно

Виртуальный график количества костылей ко времени в коде живого проекта напоминает пилу, у которой каждый зубчик — итерация. Цикл итераций выглядит примерно так:

Помните, что рефакторинг — достаточно затратный процесс, так как на этом этапе нужно понять статус и общую картину, расписать текущий алгоритм, проверить все точки соединения с другими частями проекта и с внешними ресурсами, провести миграцию существующих данных.

Тестирование отрефакторенного проекта — это отдельная задача неочевидной на первый взгляд сложности. Следует проверить, не потеряли ли мы что-нибудь нужное в процессе отработки наших костылей.

Когда вы работаете на молодой развивающийся проект, создавайте набор точечных и специфичных утилит — такой вариант разработки долгое время будет одним из наиболее эффективных:

В проекте, где бизнес-процессы неустойчивы, сложное целостное программное решение продержится до первой непредугаданной «хотелки» заказчика. А она прилетит очень скоро.

Архитектура кода не может быть стройнее и сложнее архитектуры бизнеса.

Стройная и красивая архитектура возможна только в случае, когда вы сразу видите полный объём решаемых задач. Для эволюционирующего бизнеса это условие практически невыполнимое. Поэтому очередной рефакторинг стоит проводить тогда, когда вы заново качественно переосмыслили, как должна работать определённая часть проекта.

Костыль усложняет и восприятие кода — код, напичканный обработчиками частных случаев, очень сложно поддерживать. И в какой-то момент такой код становится невозможно развивать.

Если ваш костыль живёт в коде достаточно долго, а тем более если он обрастает братьями и сёстрами, — следует запланировать рефакторинг в одной из ближайших итераций.

Когда пригодятся костыли

Такие частные решения всё-таки находят свое применение:

Так мы можем «быстро накостылять, а потом, если идея сработает, выпилить костыль и написать код с нуля как следует» — это хорошее решение для лёгких быстрых проектов. Но если речь идёт о высоконагруженных проектах, то неоптимизированный и не доведённый до ума код может поставить под угрозу работу всей системы.

И помните, что даже костыль нужно писать аккуратно, грамотно, соблюдая стилистику и максимально подробно описывая причину, по которой он создавался. Это нужно, чтобы, вернувшись к своему же коду год-два спустя, вы не испытывали неловкость, найдя ответ на вопрос «Кто писал этот бред?».

Профессия Fullstack-разработчик

Вы с нуля научитесь верстать, программировать сайты и создавать веб-приложения «под ключ» на PHP, Python или JavaScript. Сможете начать карьеру fullstack-специалиста в IT-студии или на фрилансе. Выйдете на новый уровень в веб-разработке.

Что такое костыль в программировании

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

Костыльный программист

Статья посвящена оверинженирингу и тем, кто предпочитает старые костыльные решения лишь потому, что они очень просты. Перевод под катом.

Джейми Завински – из тех, кого я называю «костыльными программистами». И я произношу эту фразу с изрядной долей уважения. Он из той породы программистов, которые упорно работают, создавая будущее и разрабатывая всевозможные полезные штуки. Т.е. они умеют делать рабочие продукты.
Это именно тот человек, который вам нужен, если ваша команда занимается созданием велосипедов, потому что два его излюбленных инструмента – костыли и 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; кто на подобных форумах ^_^

А давайте предположим, что пациент изначально больной (в надежде что не головой, бывают и такие варианты). Что, если единственно, что ему надо — не научиться бегать (конечно бегать, ведь ходить или ползать неинтересно, где вы встречали вменяемые сроки отведенные на разработку), а получить представление о беге, почувствовать ветер и скорость, пусть это будет просто вентилятор и человек бегающий с кустом в руках вокруг. И тогда все становиться гораздо проще.
Тогда достаточно используя различные костыли создать нечто способное ковылять и по мере развития, если конечно оно последует (реальный бизнес такая не предсказуемая вещь), мы потихоньку будет сначала убирать, то один, то другой, при условии полной или частичной «реабилитации» «пациента».
В итоге каждый получит что хотел: клиент получить возможность бегать и не надорвётся в попытках взять стометровку на олимпийских спринтах, да и разработчики не будут судорожно подбирать очередную клюку в надежде, что вот как раз теперь она нужного размера.

Резюмируя.
Исходя из нашего предположения, вы как разработчик всегда должны проектировать две системы (а иногда и больше, гораздо больше): первая это то, что можно сделать прямо сейчас, и «идеальная» — включающая идеальное представление о том, какой она должна быть (вдруг и правда, нужно будет выиграть олимпиаду).

Вы должны уметь в уме создавать решения способные изменять любую имеющуюся систему на набор костылей и наоборот.
И главное, в следующий раз, когда будет решать ну прямо очень сложную задачу, попробуйте для начала вот ту палку в углу, которую поставили пару дней назад, возможно, что и не заработает, но поковыляет.