Костыльный программист
Статья посвящена оверинженирингу и тем, кто предпочитает старые костыльные решения лишь потому, что они очень просты. Перевод под катом.
Джейми Завински – из тех, кого я называю «костыльными программистами». И я произношу эту фразу с изрядной долей уважения. Он из той породы программистов, которые упорно работают, создавая будущее и разрабатывая всевозможные полезные штуки. Т.е. они умеют делать рабочие продукты.
Это именно тот человек, который вам нужен, если ваша команда занимается созданием велосипедов, потому что два его излюбленных инструмента – костыли и 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 бита памяти. Потому что они достаточно хороши, чтобы с этим справиться.
Костыль в программировании что это
В коде живого проекта соотношение времени работы над проектом и количества костылей выглядит как пила, у которой каждый зубчик — итерация.
Цикл итераций выглядит примерно так:
- Внедрили костыли.
- Накопили в определённой части проекта некую критическую массу костылей.
- Провели рефакторинг и встроили костыли в логику, переписав часть кода.
Если вы работаете на молодой развивающийся проект — создавайте набор точечных и специфичных утилит. Такой вариант разработки долгое время будет эффективен, поскольку:
- Вы достаточно оперативно получаете рабочие инструменты, которыми бизнес может пользоваться.
- Вы копите данные в нашей базе.
- Вы получаете фидбек от бизнеса.
- Бизнес адаптирует свои процессы под созданные инструменты и уточняет ТЗ на будущую разработку до того, как вы всё сделали по-своему.
Стройная и красивая архитектура возможна только в случае, когда вы сразу видите полный объём решаемых задач. Для эволюционирующего бизнеса это условие практически невыполнимое. Поэтому очередной рефакторинг стоит проводить, когда вы заново качественно переосмыслили, как должна работать определённая часть проекта.
Костыль усложняет и восприятие кода — код, напичканный обработчиками частных случаев, очень сложно поддерживать. И в какой-то момент такой код становится невозможно развивать.
Если ваш костыль живёт в коде достаточно долго, а тем более если он обрастает братьями и сёстрами, — следует запланировать рефакторинг в одной из ближайших итераций.
Такие частные решения всё-таки находят свое применение:
- Позволяют решать задачи и тушить пожары при недостаточности ресурсов разработчиков.
- Помогают, когда заказчик хочет протестировать какую-то гипотезу. Мы можем «быстро накостылять, а потом, если идея сработает, выпилить костыль и написать код с нуля как следует»,. И это хорошее решение для лёгких и быстрых проектов. Но если речь идёт о высоконагруженных проектах, неоптимизированный и не доведённый до ума код может поставить под угрозу работу всей системы.
Чтобы вернувшись к собственному коду пару лет спустя, вы не испытывали неловкость, найдя ответ на вопрос «Кто писал этот бред?».
Что такое «костыль» в программировании? Как часто приходиться «костылить» в вашей практике?
Костыли — это когда вместо того, чтобы исправить логику работы модуля (что может потребовать полного его переписывания), в этот модуль или в место его использования впихивают куски кода, обрабатывающие особые случаи.
В результате нередко случается, что со временем кода «особых случаев» становится в разы больше чем основной логики.
>Что такое «костыль» в программировании?
Некое поделие, призванное оперативно устранить возникшую проблему, невзирая на стилистику в целом и здравый смысл в частности.
>Как часто приходиться «костылить» в вашей практике?
Сейчас нечасто. Я на заводе работаю, тут вообще никто никуда не спешит — поломали-починили.
На прошлой работе костыли обрубались в ходе обязательного code review.
На позапрошлой я сам себе старался таких вещей не позволять. В результате, правда, сваял мегакостыль — целую отдельную систему из маленьких костыликов, которая используется до сих пор и прекрасно работает. Но системка эта была срочно нужна, а я уже уходил. Так что пришлось.
На первой работе приходилось иногда. Промышленный робот — не такое оборудование, которое может долго стоять. Нашли багу — пофиксили абы как — линия работает дальше.