костыли в коде мем
Костыльный программист
Статья посвящена оверинженирингу и тем, кто предпочитает старые костыльные решения лишь потому, что они очень просты. Перевод под катом.
Джейми Завински – из тех, кого я называю «костыльными программистами». И я произношу эту фразу с изрядной долей уважения. Он из той породы программистов, которые упорно работают, создавая будущее и разрабатывая всевозможные полезные штуки. Т.е. они умеют делать рабочие продукты.
Это именно тот человек, который вам нужен, если ваша команда занимается созданием велосипедов, потому что два его излюбленных инструмента – костыли и 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 бита памяти. Потому что они достаточно хороши, чтобы с этим справиться.
Как правильно использовать костыли в разработке и не наплодить ошибок
В любом серьёзном проекте разработки найдутся костыли. Это естественный элемент пейзажа и процесса. Рассказываю, как ставить их правильно.
Костыльное программирование — это, мягко говоря, не идеальное решение. Костыль чаще всего не оптимизирован с точки зрения эффективности и производительности. И всё-таки иногда они нужны. Причин, по которым костыли появляются в коде, великое множество. Чаще всего их используют для быстрого и простого исправления ошибки, чтобы не переписывать половину модуля. Но бывают и другие случаи.
Костыляем правильно
Виртуальный график количества костылей ко времени в коде живого проекта напоминает пилу, у которой каждый зубчик — итерация. Цикл итераций выглядит примерно так:
Помните, что рефакторинг — достаточно затратный процесс, так как на этом этапе нужно понять статус и общую картину, расписать текущий алгоритм, проверить все точки соединения с другими частями проекта и с внешними ресурсами, провести миграцию существующих данных.
Тестирование отрефакторенного проекта — это отдельная задача неочевидной на первый взгляд сложности. Следует проверить, не потеряли ли мы что-нибудь нужное в процессе отработки наших костылей.
Когда вы работаете на молодой развивающийся проект, создавайте набор точечных и специфичных утилит — такой вариант разработки долгое время будет одним из наиболее эффективных:
В проекте, где бизнес-процессы неустойчивы, сложное целостное программное решение продержится до первой непредугаданной «хотелки» заказчика. А она прилетит очень скоро.
Архитектура кода не может быть стройнее и сложнее архитектуры бизнеса.
Стройная и красивая архитектура возможна только в случае, когда вы сразу видите полный объём решаемых задач. Для эволюционирующего бизнеса это условие практически невыполнимое. Поэтому очередной рефакторинг стоит проводить тогда, когда вы заново качественно переосмыслили, как должна работать определённая часть проекта.
Костыль усложняет и восприятие кода — код, напичканный обработчиками частных случаев, очень сложно поддерживать. И в какой-то момент такой код становится невозможно развивать.
Если ваш костыль живёт в коде достаточно долго, а тем более если он обрастает братьями и сёстрами, — следует запланировать рефакторинг в одной из ближайших итераций.
Когда пригодятся костыли
Такие частные решения всё-таки находят свое применение:
Так мы можем «быстро накостылять, а потом, если идея сработает, выпилить костыль и написать код с нуля как следует» — это хорошее решение для лёгких быстрых проектов. Но если речь идёт о высоконагруженных проектах, то неоптимизированный и не доведённый до ума код может поставить под угрозу работу всей системы.
И помните, что даже костыль нужно писать аккуратно, грамотно, соблюдая стилистику и максимально подробно описывая причину, по которой он создавался. Это нужно, чтобы, вернувшись к своему же коду год-два спустя, вы не испытывали неловкость, найдя ответ на вопрос «Кто писал этот бред?».
Профессия Fullstack-разработчик
Вы с нуля научитесь верстать, программировать сайты и создавать веб-приложения «под ключ» на PHP, Python или JavaScript. Сможете начать карьеру fullstack-специалиста в IT-студии или на фрилансе. Выйдете на новый уровень в веб-разработке.
Как правильно помечать костыли в коде?
Зачастую при любой разработке возникает необходимость написать код, про который известно заранее что он:
Потом по коду выискать просто, но помощи IDE в обозрении костылей в таком случае нет.
3 ответа 3
хотелось бы представлять костыли и TODO отдельно друг от друга
но помощи IDE в обозрении костылей в таком случае нет
Во-вторых, все приличные IDE 🙂 умеют добавлять пользовательские таск-теги.
PhpStorm (и любые другие джетбрейновские):
Eclipse (можно кастомизировать даже для каждого языка/проекта):
CLion:
Eclipse:
Ахахах. Нет ничего более постоянного, чем временное решение
Если Вы не можете писать лаконичный и гибкий код для определенной задачи, то у вас проблемы с проектированием архитектуры и стоит подтянуть свои скилы, такие проблемы у начинающих разработчиков из-за недостатка опыта. Помните, что один костыль требует нагромождения новых костылей, расширение системы и ее функционала, а также внесение изменений будет затруднено.
Вы немного неправы про отсутствие костыля в английском языке, оно часто называется kludge or workaround
Куски кода которые требуется исправить часто отмечают с помощью FIXME, которую поддерживают многие редакторы и PHPSTORM тоже, оно отмечается в TODO. FIXME ставиться непосредственно перед проблемным участно и может содержать описание в каких строках код содержит проблемы и что за проблемы, которые нужно исправить, ограничителя нет.
Могу сказать, что я и коллеги, мы редко помечаем костыли. Часто они сразу переписываются без пометок в момент новой задачи или поиска ошибки (класс уже несколько раз стрельнул, даже после исправления), потому что все эти пометки с недостатком времени превращаются в постоянные. Переписываются естественно костыли без фанатизма, в целях экономии средств бизнеса на дальнейшую разработку и поддержку продукта.
Если в команде поддерживается стремление к высокому уровню абстракции и соблюдению правил количества строк в классе, рефакторинг какого-то кривого кода не занимает много времени, но если достался в наследство, то нужно определять уровень рефакторинга в зависимости от предоставленного времени на задачу.
P.S Избегайте лишних парадигм: костылирование, инкостыляция и поликостылизм, пишите красивый код приложив к нему хотя бы минутку проектирования.
Заметки о костылях
Все же есть в этом мире порой некоторые вещи, которые можно обсуждать бесконечно.
И что самое замечательное, каждый раз такое обсуждение может закончиться совершенно непредсказуемым результатом, как для автора, так и для читателей.
Любому разработчику известно для чего нужды костыли, велосипеды и грабли. И наверняка у каждого уже есть парочка в гараже, а так же бубен на стенке для особых случаев. Если у вас еще их пока нет, вы либо совсем недавно присоединились к нам (Возможно, только вчера открыли «PHP для чайников» и через пару дней у вас они тоже будут. Костыли будут конечно же свои, не многие из нас открывают свои чуланы чужим.) или ставите задачи для вашей армии раз***в (пусть тут будет слово близкое вам сегодня), когда очередное недоразумение уронит вам сервер, выведет кривой отчет или просто откажется запускаться программа. Оставлю тихую надежду, что остальные, те кто пользуется плодами этого совместного творчества сюда не зайдут.
Начнем с определения.
«Костыль — приспособление для поддержания веса тела пациента при стоянии и ходьбе» (с) Вики
То есть «костыль» не такое уж и плохое решение, как может показаться. Думаю, не один здравомыслящий человек не будет отказывать от возможности ходить, когда этого лишён, но он точно не захочет опираться на клюку когда все в порядке.
Определение есть, теперь немного о предмете (пациенте)
Считается что приложение (решение, система…) пишется с первого раза, без ошибок и не требует не только поддержки, но и развития. О процессе утилизации — переходе от одного решения к другому (вы надеюсь не верите в зубных фей и в вечно работающие сервера, базы данных, платформы, технологии) промолчим, как и об оценке каждого их этих этапов.
Вообще все ещё немного страшнее, существует целые направления в науке занимающие оценкой проектов, анализу рисков и остальной околоразработческой деятельности.
Назовем эту простую стратегию – «Стратегия святого Грааля разработки». Никто никогда не видел быстро-качественно-дешево, но все уже хотят еще вчера, и что самое интересное все знают, что это такое — «сделайте мне красиво».
Результат очевиден.
В итоге, в погоне за великой целью гибнут многие из нас, кто в странных технологиях: гибкая разработка, автоматизированное тестирование, парное программирование и т.д., и т.п.; кто в темных углах различных средств и языков, начиная от C++, Java, Pyton, PHP, JS; кто на подобных форумах ^_^
А давайте предположим, что пациент изначально больной (в надежде что не головой, бывают и такие варианты). Что, если единственно, что ему надо — не научиться бегать (конечно бегать, ведь ходить или ползать неинтересно, где вы встречали вменяемые сроки отведенные на разработку), а получить представление о беге, почувствовать ветер и скорость, пусть это будет просто вентилятор и человек бегающий с кустом в руках вокруг. И тогда все становиться гораздо проще.
Тогда достаточно используя различные костыли создать нечто способное ковылять и по мере развития, если конечно оно последует (реальный бизнес такая не предсказуемая вещь), мы потихоньку будет сначала убирать, то один, то другой, при условии полной или частичной «реабилитации» «пациента».
В итоге каждый получит что хотел: клиент получить возможность бегать и не надорвётся в попытках взять стометровку на олимпийских спринтах, да и разработчики не будут судорожно подбирать очередную клюку в надежде, что вот как раз теперь она нужного размера.
Резюмируя.
Исходя из нашего предположения, вы как разработчик всегда должны проектировать две системы (а иногда и больше, гораздо больше): первая это то, что можно сделать прямо сейчас, и «идеальная» — включающая идеальное представление о том, какой она должна быть (вдруг и правда, нужно будет выиграть олимпиаду).
Вы должны уметь в уме создавать решения способные изменять любую имеющуюся систему на набор костылей и наоборот.
И главное, в следующий раз, когда будет решать ну прямо очень сложную задачу, попробуйте для начала вот ту палку в углу, которую поставили пару дней назад, возможно, что и не заработает, но поковыляет.
Всегда ли наличие костылей в коде это плохо?
Вы когда-нибудь серьезно задумывались над вопросом «всегда ли наличие костылей в коде это плохо?». А быть может существуют ситуации, где костыли серьезно экономят время? И быть может фраза «нет ничего более постоянного, чем временное» не всегда применима и ее стоит рассматривать не как постулат? Как бы то ни было, каждый видит за этими вопросами свои ответы. Однако, в рамках данной статьи я рассмотрю несколько аспектов, которые часто остаются за бортом и возможно покажутся вам познавательными.
Примечание: Момент рисков не рассматривается в рамках данной статьи, так как иначе она сильно разрастется и превратится в перечисление массы факторов, а суть статьи не в этом.
Ситуация 1. Вам нужно написать небольшой скрипт. Вы точно знаете, что скрипт будет написан один раз и вы его не будете повторно использовать или же наполнять функционалом. К примеру, вам необходимо убедится в какой-то технологии или же проверить js скрипт из консоли браузера. Имеет ли смысл в таком случае писать идеальный и красивый код, снабжая его подробными комментариями? С одной стороны, если задача набить руку, то имеет смысл. С другой стороны, если вам нужно проверить десяток мест, то такая задача становится обременительной и немного бессмысленной, так как потраченное время и силы вы бы могли пустить на что-то более полезное.
Ситуация 2. Вас могут попросить подправить чужой код с костылями. Вы знаете, что в дальнейшем код не будет переделываться, другими словами так и будет кочевать. Человек, который попросил вас подправить код, не рассматривает вариант переделки скрипта/программы, сколько бы вы не убеждали его в необходимости. Не видит человек за этим смысла. Тут важно понимать, что может он и не собирается в дальнейшем поддерживать этот продукт, а просто когда для него ситуация станет лучше, то будет написана программа «с нуля». Другими словами, переписка кода зависит чисто от вашего желания, никто вам за это не скажет спасибо. С одной стороны, вы можете написать этот костыль и свое время направить на что-то другое. С другой стороны, вы можете подправить часть критичных ошибок, не особо увлекаясь полной переделкой, чтобы самому не писать костыль. С третьей стороны, вы можете полностью переписать скрипт. Вот тут важно честно себе ответить на вопрос, а что если у вас времени только на первый вариант?
Ситуация 3. В жизни бывают ситуации, когда ошибки нужно исправлять в срочном порядке. И не всегда бывает время на «качественное» исправление. К примеру, ошибка в системах реального времени. Чтобы немного упростить ситуацию, допустим вы знаете, что в последствии время на переписку этой части с ошибкой будет. С одной стороны, вы можете настоять на своем (или скрыть, что вы не делаете костыль) и тем самым затянуть время исправления. С другой стороны, вы можете спокойно сделать костыль, а уже после этого заняться обдумыванием нормального кода. Какой вариант будет предпочтительнее для вас? А какой вариант был бы оптимальнее для всех сторон?
Ситуация 4. У вас достаточно много времени и поэтому вы постоянно пишите только «качественный» код. Как вы думаете, если возникнет ситуация, где без костыля никак не обойтись, то вы сможете написать нормальный костыль, который в последствии можно будет легко переделать? Или же в спешке вы напишите такой код, что его переделка займет весьма существенное время, так как вы неправильно сэкономили время и действительно важные части были написаны криво? К примеру, поддавшись фразе «все равно пишу костыль» сделали некорректный формат хранения данных, переформирование которого в последствии обойдется весьма существенным временем и силами. Помните, чтобы уметь писать «продуманные» костыли, у вас должен быть опыт написания последних.
Ситуация 5. Представьте себе, что вам нужно написать некоторый функционал. Однако, неизвестно будет ли он полезен или быть может вам придется его вырезать в будущем. Вы знаете, что разница во времени написания существенна. К примеру, на «относительно продуманный» костыль у вас уйдет 1 час, а на нормальное решение уйдет 10. Имеет ли смысл писать нормальное решение в таком случае, особенно, если вы знаете, что если функционал окажется полезным, то времени на него сможете выделить достаточно много?
Существуют и другие ситуации, но даже этих вполне достаточно, чтобы задуматься над вопросом «всегда ли наличие костылей в коде это плохо». Свои мысли по этому поводу можете смело оставлять в комментариях.