Что значит пишу костыли

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

Primary tabs

Forums:

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

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

Работают они как-то так:

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

Часто костыль делают именно как быстрое решение — когда лень (+ отсутствие времени и/или навыков) не позволяет сделать что-то более продуманное и осмысленное.

Костыли обычно чужие — не свои

Как говорит один уважаемый человек: костыли — относительное и субъективное понятие, и обычно их замечают только в чужом коде (почему-то 😉
В своём же коде программист под воздействием таинственных сил часто ничего плохого не видит!
Этот феномен не разгадан до сих пор.

А что у нас в реальности

Большинство реальных программистов так или иначе, хотя бы раз в жизни «костыляли» свои программы — то есть использовали быстрые, но неизящные решения, в связи с чем их (костыли) и отобразили на знаменитом гербе программистов.

Более того, некоторые программисты следуют только стилю костылей, практически не производя иных продуктов))

Как сервировать костыль — и подавать в «правильном» освещении

Если хочется приподнести быстрое решение проблемы в положительном смысле — назовите его хаком 😉

Источник

Всегда ли наличие костылей в коде это плохо?

Вы когда-нибудь серьезно задумывались над вопросом «всегда ли наличие костылей в коде это плохо?». А быть может существуют ситуации, где костыли серьезно экономят время? И быть может фраза «нет ничего более постоянного, чем временное» не всегда применима и ее стоит рассматривать не как постулат? Как бы то ни было, каждый видит за этими вопросами свои ответы. Однако, в рамках данной статьи я рассмотрю несколько аспектов, которые часто остаются за бортом и возможно покажутся вам познавательными.

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

Примечание: Момент рисков не рассматривается в рамках данной статьи, так как иначе она сильно разрастется и превратится в перечисление массы факторов, а суть статьи не в этом.

Ситуация 1. Вам нужно написать небольшой скрипт. Вы точно знаете, что скрипт будет написан один раз и вы его не будете повторно использовать или же наполнять функционалом. К примеру, вам необходимо убедится в какой-то технологии или же проверить js скрипт из консоли браузера. Имеет ли смысл в таком случае писать идеальный и красивый код, снабжая его подробными комментариями? С одной стороны, если задача набить руку, то имеет смысл. С другой стороны, если вам нужно проверить десяток мест, то такая задача становится обременительной и немного бессмысленной, так как потраченное время и силы вы бы могли пустить на что-то более полезное.

Ситуация 2. Вас могут попросить подправить чужой код с костылями. Вы знаете, что в дальнейшем код не будет переделываться, другими словами так и будет кочевать. Человек, который попросил вас подправить код, не рассматривает вариант переделки скрипта/программы, сколько бы вы не убеждали его в необходимости. Не видит человек за этим смысла. Тут важно понимать, что может он и не собирается в дальнейшем поддерживать этот продукт, а просто когда для него ситуация станет лучше, то будет написана программа «с нуля». Другими словами, переписка кода зависит чисто от вашего желания, никто вам за это не скажет спасибо. С одной стороны, вы можете написать этот костыль и свое время направить на что-то другое. С другой стороны, вы можете подправить часть критичных ошибок, не особо увлекаясь полной переделкой, чтобы самому не писать костыль. С третьей стороны, вы можете полностью переписать скрипт. Вот тут важно честно себе ответить на вопрос, а что если у вас времени только на первый вариант?

Ситуация 3. В жизни бывают ситуации, когда ошибки нужно исправлять в срочном порядке. И не всегда бывает время на «качественное» исправление. К примеру, ошибка в системах реального времени. Чтобы немного упростить ситуацию, допустим вы знаете, что в последствии время на переписку этой части с ошибкой будет. С одной стороны, вы можете настоять на своем (или скрыть, что вы не делаете костыль) и тем самым затянуть время исправления. С другой стороны, вы можете спокойно сделать костыль, а уже после этого заняться обдумыванием нормального кода. Какой вариант будет предпочтительнее для вас? А какой вариант был бы оптимальнее для всех сторон?

Ситуация 4. У вас достаточно много времени и поэтому вы постоянно пишите только «качественный» код. Как вы думаете, если возникнет ситуация, где без костыля никак не обойтись, то вы сможете написать нормальный костыль, который в последствии можно будет легко переделать? Или же в спешке вы напишите такой код, что его переделка займет весьма существенное время, так как вы неправильно сэкономили время и действительно важные части были написаны криво? К примеру, поддавшись фразе «все равно пишу костыль» сделали некорректный формат хранения данных, переформирование которого в последствии обойдется весьма существенным временем и силами. Помните, чтобы уметь писать «продуманные» костыли, у вас должен быть опыт написания последних.

Ситуация 5. Представьте себе, что вам нужно написать некоторый функционал. Однако, неизвестно будет ли он полезен или быть может вам придется его вырезать в будущем. Вы знаете, что разница во времени написания существенна. К примеру, на «относительно продуманный» костыль у вас уйдет 1 час, а на нормальное решение уйдет 10. Имеет ли смысл писать нормальное решение в таком случае, особенно, если вы знаете, что если функционал окажется полезным, то времени на него сможете выделить достаточно много?

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

Источник

[сленг] «костыль» по английски.

Как наиболее адекватно перевести программистское сленговое «костыль» на английский? Чтобы сохранить такой пренебрежительный тон и аналогию с инвалидами?

Workaround — слишком нейтрально, hack — слишком широкое понятие. Crock — не то вроде бы. Kludge, видимо?

Re: [сленг] «костыль» по английски.

«Horrible piece of shit» в терминологии Линуса.

Re: [сленг] «костыль» по английски.

Re: [сленг] «костыль» по английски.

Можно попробовать буквально так и перевести, crutch.

Re: [сленг] «костыль» по английски.

Хм, идея. А поймут?

Re: [сленг] «костыль» по английски.

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

Re: [сленг] «костыль» по английски.

cheap and dirty workaround? хотя длинно

Re: [сленг] «костыль» по английски.

А kludge-то не подойдёт?

Re: [сленг] «костыль» по английски.

Re: [сленг] «костыль» по английски.

«Kludge is a programming techinque which is neither robust nor clean, but gets the job done» (c) То есть это более узкое понятие, чем наш «костыль».

Re: [сленг] «костыль» по английски.

to fix something cheaply, and temporarily using minimal materials at no cost, either recycled or (most likely) stolen. «yo yo, I’s needs me a new rim. It be broke»

«on fear not, negro, you can always not risk prison stealing a new rim, and fix yours. It’s free, just nigger rig it»

Re: [сленг] «костыль» по английски.

А чем хак-то не устраивает? Костыль тоже понятие широкое. Quick & dirty hack.

Re: [сленг] «костыль» по английски.

Да, duct tape. Приходилось однако слышать (от носительницы языка) такое — linguistic crutch. По смыслу близко и не слишком позитивно — в речи оно означает кое-как сляпанное наскоро, не совсем грамотное вспомогательное выражение чего-то, что не можешь описать иначе. А для технарства duct tape самое то, мне кажется

Re: [сленг] «костыль» по английски.

Самое близкое. Что-то крайне ненадёжное, что работает только по чистой случайности.

Или hack, но это не столь пренебрежительно.

Re: [сленг] «костыль» по английски.

> «Horrible piece of shit» в терминологии Линуса.

Линус вроде слово crap любит =)

Re: [сленг] «костыль» по английски.

ЗЫ: dirty hack я думаю.

Re: [сленг] «костыль» по английски.

Re: [сленг] «костыль» по английски.

Kludge, конечно. Более точного варианта не найти.

Re: [сленг] «костыль» по английски.

А quirk — это что?

Re: [сленг] «костыль» по английски.

> Не понимают. В их психологии костыль — это то, что помогает, а не мешает.

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

Re: [сленг] «костыль» по английски.

Re: [сленг] «костыль» по английски.

> А quirk — это что?

«Изгиб, загогулина, странность», применительно к технике, и программам — странная особенность, как правило неудобная. Пример: падение компилятора, если в исходниках идут 2 пробела подряд.

С «костылём» (в том числе в смысле «некрасивое и неуниверсальное временное решение») ничего общего.

Re: [сленг] «костыль» по английски.

crap будет нормально 🙂

Re: [сленг] «костыль» по английски.

> Workaround — слишком нейтрально

как раз workaround и надо использовать:

Workaround, noun 2. (computing) A procedure or a temporary fix that bypasses a problem and allows the user to continue working until a better solution can be provided; a kluge.

а вот это навряд ли:

kluge (plural kluges) 1. Something that should not work, but does.

Re: [сленг] «костыль» по английски.

QUIRK — QUIck and diRty hacK

Re: [сленг] «костыль» по английски.

> пренебрежительный тон и аналогию с инвалидами?

Этого делать не стоит, буржуи относятся к инвалидам весьма трепетно и серьезно, по крайней мере в США.

Re: [сленг] «костыль» по английски.

>[сленг] «костыль» по английски.

Re: [сленг] «костыль» по английски.

>а вот это навряд ли:

>kluge (plural kluges) 1. Something that should not work, but does.

Изучать язык по словарям — это хорошо. Проблема только в том, что не знаешь, какие словари правильные 😀

[from the German `klug’, clever; poss. related to Polish `klucza’, a trick or hook] 1. /n./ A Rube Goldberg (or Heath Robinson) device, whether in hardware or software. 2. /n./ A clever programming trick intended to solve a particular nasty case in an expedient, if not clear, manner. Often used to repair bugs. Often involves ad-hockery and verges on being a crock. 3. /n./ Something that works for the wrong reason. 4. /vt./ To insert a kluge into a program. «I’ve kluged this routine to get around that weird bug, but there’s probably a better way.» 5. [WPI] /n./ A feature that is implemented in a rude manner.

И кстати, обычно пишется именно «kludge», не «kluge». Из предложенного ITT kludge — ближе всего к желаемому — обратите внимание на отсылку к Руби Голдберг.

Источник

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

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

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

Источник