Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 165
>… чтобы соблазнить упрямого программиста прочитать его. Что-нибудь типа «Что делать с плохим кодом»…
>… такой же птенец, как и все остальные…
Мне всегда было интересно, как можно легко подвести человека к самокритике. У меня никогда не получалось. Я использовал те же фразы по своей сути, но ваша форма изложения оказалась великолепной.
Браво!
>… такой же птенец, как и все остальные…
Мне всегда было интересно, как можно легко подвести человека к самокритике. У меня никогда не получалось. Я использовал те же фразы по своей сути, но ваша форма изложения оказалась великолепной.
Браво!
Дак а с кодом что делать все же? :)
Ctrl + A
Del
Del
Отличный подход. Когда нужно добавить функционал в код, который мне совершенно не нравится, я просто постепенно переписываю кусок кода заново с новым функционалом, а потом, заменив вызовы OldImpl.oldBadFunc(smth) на NewImpl.newShinyFunc(smth), просто удаляю старый код. Код всегда нужно оставлять лучшим, чем он был до правки. К сожалению, объективно определить «лучший» довольно сложно.
Если бы всегда так было просто…
Почти никогда не бывает просто. Почти всегда муки перепроектирования и неоплачиваемые овертаймы. Но только при таком подходе меня не мучает совесть после проделанной работы.
Для меня муки обычно заключаются в фиксировании существующей функциональности, причем не в виде покрытия тестами OldImpl.oldBadFunc(smth), а в предварительном её выделени из «простыни спагетти» с кучей неявных связей с остальным кодом.
Но только при таком подходе меня не мучает совесть после проделанной работы.
… более того, прокрастинация работы над проектом уменьшается, т.к. плохой код «отталкивает» от работы.
Сначала прочитал как newShittyFunc, обычно так бывает…
Что делать с плохо сделанной работой? Понять и простить? Отвечать ли за плохую работу других людей своим именем, репутацией? Переделывать все самому?
Ну если вы не объективно смотрите на чужой код, тогда конечно не равносильны.
Можете ли вы, положа руку на сердце, сказать, что всегда объективны в оценке чужого кода?
Многие могут — это и называется отсутствие самокритики.
Конечно нет, но в этих случаях оценку выполненной работе я естественно не даю, оценку же кода (вне зависимости от специфики выполненной работы) можно дать по наличию комментариев, форматированию (точнее его отсутствия), оптимизация, выбранной технологии.
«Да, да, что-то вы знаете хорошо, но во всем остальном — полный отстой». Что здесь подразумевается под Всем остальным? естественно ни один адекватные программист не будет давать оценку работе выполненной на неспецифичной для него технологии, и то есть он все равно будет отстоем?)
«Да, да, что-то вы знаете хорошо, но во всем остальном — полный отстой». Что здесь подразумевается под Всем остальным? естественно ни один адекватные программист не будет давать оценку работе выполненной на неспецифичной для него технологии, и то есть он все равно будет отстоем?)
Нет даже единого мнения нужны ли комментарии в коде или код должен быть самодокументирующимся. По форматированию куча холиваров и код соответствующий одному стандарту оформления человеку незнакомому с ним может показаться неотформатированным, например, много стандартов для Си-подобных языков, где используется смешанный стиль скобок {} — для одних сущностей (классов, интерфейсов, методов, функций и т. п.) — K&R, а для других (if, while и т. д.) — BSD. Если не знать о таких смешанных стилях, то скобки могут казаться расставленными хаотично. То же с отступами — есть стили где отступы фиксированы, а есть где не то, что разрешается, а требуется в отдельных случаях нарушать простую логику «уровень вложенности — стандартный отступ (таб)».
Про оптимизации вообще не понял. Преждевременные оптимизации зло — но можно ли по коду, да еще беглому взгляду без бенчмарков и профилирования утверждать преждевременная она или нет? А про технологиям — это как? Раз код на PHP или использует MS SQL — значит говно по умолчанию, даже без заглядывания в код?
Про оптимизации вообще не понял. Преждевременные оптимизации зло — но можно ли по коду, да еще беглому взгляду без бенчмарков и профилирования утверждать преждевременная она или нет? А про технологиям — это как? Раз код на PHP или использует MS SQL — значит говно по умолчанию, даже без заглядывания в код?
Вы видимо предпочитает разбор тысячи строк без единой строчки комментария?
'форматированию (точнее его отсутствия)' — если вы не обратили внимание на содержимое в скобочках, не важно соответствует моиму принципу форматирования код, главное чтоб он не был написан вообще без форматирования. А насчет стандарта, принято использовать один стиль внутри группы разработчик (всем кто не знаком с установившимся стандартом придется познакомиться).
Что может быть не понятного в слове оптимизация? вы не видели не оптимизированный код? когда куски кода дублируются, забыают память отчистить, плодят кучу переменных, дают имена переменным типа lb17, это самые простые примеры навскидку, и это находится не в 'отладочном' коде, а уже в якобы готов проекте. Причем здесь беглый взгляд? Неоптимальность кода можно разглядеть погрузившись в код с головой.
Про технологии, это если вы для того чтобы скажем удалить десять пикселей с картинки подключите OpenCV, вместо того чтобы заюзать класс Bitmap, просто потому что вам так нравится OpenCV.
'форматированию (точнее его отсутствия)' — если вы не обратили внимание на содержимое в скобочках, не важно соответствует моиму принципу форматирования код, главное чтоб он не был написан вообще без форматирования. А насчет стандарта, принято использовать один стиль внутри группы разработчик (всем кто не знаком с установившимся стандартом придется познакомиться).
Что может быть не понятного в слове оптимизация? вы не видели не оптимизированный код? когда куски кода дублируются, забыают память отчистить, плодят кучу переменных, дают имена переменным типа lb17, это самые простые примеры навскидку, и это находится не в 'отладочном' коде, а уже в якобы готов проекте. Причем здесь беглый взгляд? Неоптимальность кода можно разглядеть погрузившись в код с головой.
Про технологии, это если вы для того чтобы скажем удалить десять пикселей с картинки подключите OpenCV, вместо того чтобы заюзать класс Bitmap, просто потому что вам так нравится OpenCV.
Вы видимо предпочитает разбор тысячи строк без единой строчки комментария?
Да, это порой лучше, чем комментарии, вводящие в заблуждение.
Что может быть не понятного в слове оптимизация? вы не видели не оптимизированный код? когда куски кода дублируются, забыают память отчистить, плодят кучу переменных, дают имена переменным типа lb17, это самые простые примеры навскидку, и это находится не в 'отладочном' коде, а уже в якобы готов проекте. Причем здесь беглый взгляд? Неоптимальность кода можно разглядеть погрузившись в код с головой.
Это называется не «не оптимизированным кодом», а говнокодом. А это, как говориться, две большие разницы.
Оптимизированный код (не важно по памяти или по какому-нибудь классу вычислений), как правило, сложнее для понимания, может использовать хаки и т. п.
Вы видимо предпочитает разбор тысячи строк без единой строчки комментария?
Если не считать *doc комментарии в языках с динамической типизацией для «эмулирования» статической, то почти всегда да. Мне больше понравится
function calcHypothenuse(catet1, catet2) (в словарь лень было лезть), чем function c(a,b) // Calc hypothenuse c by catets a and b using Phifagore theoreme.А насчет стандарта, принято использовать один стиль внутри группы разработчик (всем кто не знаком с установившимся стандартом придется познакомиться).
Зачастую код поступает на доработку без приложенного к нему стандарта или, хотя бы, ссылки на него
Что может быть не понятного в слове оптимизация? вы не видели не оптимизированный код? когда куски кода дублируются, забыают память отчистить, плодят кучу переменных, дают имена переменным типа lb17, это самые простые примеры навскидку
Обычно под оптимизацией по умолчанию имеют в виду оптимизацию производительности, я тоже так воспринял. Любой код практически всегда оптимизирован, только не всегда ясно по какому фактору и, как правило, в ущерб другим факторам. Дублирование кусков кода может означать оптимизацию производительности и/или потребления памяти. Неочищенная память — оптимизация производительности и читаемости. Куча переменных — оптимизация читаемости. Короткие имена переменных — оптимизация производительности. «Костыли» — оптимизация времени на внесение изменений. В общем, имхо, неоптимизированного вообще кода не бывает, просто мы можем не знать параметра по которому оптимизация проводилась, или считать его не важным. Может быть даже код оптимизированный по параметру «нужно заказчику/работодателю показать, что я не зря месяц над „hello word“ сидел». Тоже оптимизация нужная программисту.
С другой стороны, практически для любого кода можно найти параметр, по которому он не оптимизирован. Скажем, длина исходных текстов редко когда оптимизируется, в лучшем случаем производится минификация для продакшена. Имхо, почти любой код не оптимизирован, лишь потому что есть метрики противоречащие друг другу. Из объективных часто противоречат друг другу производительность и потребление памяти. Даже в теории алгоритмов — это две разных метрики оценки сложности алгоритма. А уж если брать субъективные метрики типа «легкость чтения»…
Про технологии, это если вы для того чтобы скажем удалить десять пикселей с картинки подключите OpenCV, вместо того чтобы заюзать класс Bitmap, просто потому что вам так нравится OpenCV.
Опять же, код оптимизирован как минимум по параметру «нравится». Как вариант по параметру «Хорошо знаком с OpenCV, и ни разу не использовал BitMap, а значит время разработки будет не оптимизировано, нужно будет курить маны или читать чужой код ».
K & R — это как раз и есть смешанный стиль, вот такой:
например, на нем написана iOS и много девелоперов ей следуют. А в остальном — полностью согласен.
- (void) method
{
if(condition) {
[self method];
}
}
например, на нем написана iOS и много девелоперов ей следуют. А в остальном — полностью согласен.
Они коррелируют.
Понятие «код, который я считаю плохим» вы пытаетесь ввести только сейчас. В заметке идет речь об объективно плохом коде, а это плохая работа, да.
Можно сколько угодно далеко углубляться в философские вопросы вроде «что понимать под...», «что такое работа» и т.д. Но плохой код (объективно плохой) существует. Как распознать эту объективность? Его существование отнимает дополнительные ресурсы. А это значит, что кем-то была сделана плохая работа.
Это не объективная оценка. Мы не знаем как была поставлена задача. Можно ли говорить, что кто-то сделал плохую работу, если задача была поставлена «как можно скорее запустить в продакшен, игнорирую возможную сложность дальнейшей поддержки»?
Что «это»? С чем именно в моем утверждении вы не согласны? И что вы утверждаете? Каков ваш тезис?
Что плохая работа раз существование плохого кода отнимает дополнительные ресурсы. У владения и использования кода (само существование ресурсов практически не требует), как и у владения и использования большинства других вещей, есть краткосрочная выгода, а есть долгосрочная. Как правило приоритет в пользу долгосрочной увеличивает начальную стоимость. Заказчик волен выбирать достаточно ли он богат, чтобы покупать дешевые вещи.
Типичные пример — софтверный «стартап», когда нужно проверить идею, способна ли она приносить деньги в принципе. Инвестиции в качество кода на этом этапе нецелесообразны зачастую, лишь бы работал. Для проверки идеи нет разницы заплатите вы быдлокодеру 10к, чтобы он за неделю сделал «простыню спагетти», или профессионалу 200к, чтобы он сделал всё «по науке» за месяц при той же функциональности. Если идея «стрельнет», то 10к быдлокодеру за «прототип» на фоне 200к профессионалу, чтобы он всё переписал с нуля за месяц будет выглядеть незначительно, да и месяц код быдлокодера будет приносить деньги. А если не «стрельнет», то лучше «выкинуть» 10к, чем 200. Главное, дать профессионалу месяц, чтобы он переписывал всё с нуля, а не переделывал код быдлокодера.
Типичные пример — софтверный «стартап», когда нужно проверить идею, способна ли она приносить деньги в принципе. Инвестиции в качество кода на этом этапе нецелесообразны зачастую, лишь бы работал. Для проверки идеи нет разницы заплатите вы быдлокодеру 10к, чтобы он за неделю сделал «простыню спагетти», или профессионалу 200к, чтобы он сделал всё «по науке» за месяц при той же функциональности. Если идея «стрельнет», то 10к быдлокодеру за «прототип» на фоне 200к профессионалу, чтобы он всё переписал с нуля за месяц будет выглядеть незначительно, да и месяц код быдлокодера будет приносить деньги. А если не «стрельнет», то лучше «выкинуть» 10к, чем 200. Главное, дать профессионалу месяц, чтобы он переписывал всё с нуля, а не переделывал код быдлокодера.
Итого: раз пришлось тратить доп. ресурсы (переписывание профессионалом), кто-то сделал работу плохо (в вашем примере это быдлокодер). Это как раз то, что я утверждаю.
Он сделал работу так, как было сказано — быстро, и чтобы хоть как-то работало (и давало прибыль и/или отклики пользователей), пока будет писаться новая версия. Вряд ли выполнение требований начальства можно назвать плохой работой.
Нет- нет, не путайте. Если новую версию изначально планировалось писать, то это не дополнительные затраты, а запланированные изначально затраты.
Нет дополнительных затрат на поддержку первой версии — значит, работа по ней сделана хорошо. Что-то не работает, незапланированные доработки, переделки — значит, плохо.
Нет дополнительных затрат на поддержку первой версии — значит, работа по ней сделана хорошо. Что-то не работает, незапланированные доработки, переделки — значит, плохо.
Вот и я о том же. Работа «сделана хорошо», несмотря на то, что это — «простыня спагетти», написанная быдлокодером. Так что даже «объективно плохой код» — это совсем не обязательно «плохая работа».
В другом варианте, это могла быть программа в 10000 строк, рассчитанная на один запуск, от которой важен только результат (проверяемый другими средствами).
В другом варианте, это могла быть программа в 10000 строк, рассчитанная на один запуск, от которой важен только результат (проверяемый другими средствами).
Пожалуйста, не опровергайте утверждений, которых я не делал.
Я говорю о том, что дополнительные затраты говорят о плохой работе, а не о том, что «простыня спагетти» это плохая работа.
Я говорю о том, что дополнительные затраты говорят о плохой работе, а не о том, что «простыня спагетти» это плохая работа.
Только в том случае дополнительные затраты говорят о плохой работе, если в ТЗ было оговорено в той или иной форме, что таких затрат быть не должно. Проще говоря, если заказчик подписал акт «работа выполнена в соответствии с ТЗ», а потом он несет непредвиденные расходы, то это говорит о том, что ТЗ и/или приемка были плохими. Работа не может быть плохой, если все требования ТЗ и обязательных стандартов (есть такие в области разработки софта?) выполнены и она принята без замечаний по сути ТЗ и обязательных стандартов.
Само определение затрат, как дополнительных, говорит о том, что изначально их быть не должно.
Нет. Если я принял сервер держащий 10к соединений в пике, а внезапно мне потребовалось 100к, то затраты на это именно дополнительные. Если я написал, что должен держать 10к, но быть масштабируем до 100к путем покупки ещё десяти серверов и изменения 10% существующего, то это предвиденные дополнительные затраты на код и если потребовалось только 10%, то это нормальный код. Вот потребуется 11 — код плохой, возникли непредвиденные дополнительные затраты. Если я написал, что должен держать 10к, а потом внезапно захотел 100к, то хоть 10% изменения существующего кода, то хоть 100% и покупка 100 серверов не могут говорить о том, что первоначальная работа сделана плохо.
написал, что должен держать 10к, а потом внезапно захотел 100к
Затраты на достижение 100к не связаны с работой старого кода, это новая цель, новый проект.
А если это не работа старого кода привела к допзатратам, то это не тот случай.
В таком случае плох только тот код, который не соответствует требованиям ТЗ, а заказчик не удосужился проверить соответствует он или нет его же требованиям.
Это утверждение легко опровергнуть. Работа может быть плохой вне зависимости от того, проверял ее заказчик или принял и оплатил, не проверяя.
Так не распознать плохую работу. Я предлагаю другой признак разпознавания.
Так не распознать плохую работу. Я предлагаю другой признак разпознавания.
Я тоже другой критерий предлагаю — соответствие требованиям ТЗ. Соотвествует — удовлетворительная работа, независмо от того проверял или нет. Не соотвествует — плохая, опять же независимо от проверки. А вот вариант «соответствует, но внезапно захотелось больше чем в ТЗ записано» назвать плохой работой, это как купить «Ламборджини» или «Порш» и назвать их плохими машинами потому что 30 тонн навоза на дучу отвезти за раз не могут.
Вариант «соответствует, но внезапно захотелось больше чем в ТЗ записано» — это не мой тезис, пожалуйста, не приписывайте это мне.
Мой критерий определения плохой работы — это дополнительные затраты любых ресурсов, связанных с этой работой, которые пришлось понести впоследствии.
Это совсем не то, что «соответствует, но внезапно захотелось больше чем в ТЗ записано».
Мой критерий определения плохой работы — это дополнительные затраты любых ресурсов, связанных с этой работой, которые пришлось понести впоследствии.
Это совсем не то, что «соответствует, но внезапно захотелось больше чем в ТЗ записано».
Так именно этому варианту соответствует ваш критерий. Вы используете квантор всеобщности «любые», который применим обычно только в абстрактных случаях. Согласно нему, если у меня заказали сайт-визитку, а он требует оплаты хостинга и не выдерживает 1ккк посетителей, то я плохо сделал свою работу, потому что заказчику придется нести дополнительные расходы на хостинг и масштабирование архитектуры, пускай код и идеально выглядит.
Оплата хостинга и проч. не связана с существованием вашего кода, это не дополнительные затраты на вашу работу.
Если же вам заказали не код сайта, а просто чтобы сайт был и работал, а вы не оговорили заранее затраты на хостинг, то вы действительно плохо поработали с клиентом.
Ни один из этих вариантов моему определению не противоречит.
Если же вам заказали не код сайта, а просто чтобы сайт был и работал, а вы не оговорили заранее затраты на хостинг, то вы действительно плохо поработали с клиентом.
Ни один из этих вариантов моему определению не противоречит.
Как это оплата не связана с существованием? Перестанут платить и хостер код сотрет. Прямая связь!
Ладно, пускай. Мне заказали «плоскую» гостевую книгу без регистраций. Я её написал, даже бесплатно и без согласования сделав защиту от некоторых видов атак, счёв это профессиональной этикой. Потом мне заказывают на её базе сделать блог с древовидными комментариями и обязательной регистрацией. Если я не предусмотрел такой возможности значит ли, что я плохо сделал свою работу? А если заказали смену дизайна, а я не разделил логику и представление из-за чего смена дизайна не сильно дешевле разработки с нуля? А если я десять раз задал заказчику вопрос «вы точно не будете мой код отдавать кому-то ещё на доработку» и он ответил двадцать раз ответил «нет», в следствии чего я не писал комментарии, давал привычные имена переменным и т. п.?
Ладно, пускай. Мне заказали «плоскую» гостевую книгу без регистраций. Я её написал, даже бесплатно и без согласования сделав защиту от некоторых видов атак, счёв это профессиональной этикой. Потом мне заказывают на её базе сделать блог с древовидными комментариями и обязательной регистрацией. Если я не предусмотрел такой возможности значит ли, что я плохо сделал свою работу? А если заказали смену дизайна, а я не разделил логику и представление из-за чего смена дизайна не сильно дешевле разработки с нуля? А если я десять раз задал заказчику вопрос «вы точно не будете мой код отдавать кому-то ещё на доработку» и он ответил двадцать раз ответил «нет», в следствии чего я не писал комментарии, давал привычные имена переменным и т. п.?
Смотрите: затраты труда на превращение плоской книги в древовидную — q. Если вы тратите не q, а q+d, то вы что-то сделали не так.
d — допзатраты, В этот момент вы понимаете, что надо было делать по-другому. Оказалось, что эта работа была сделана плохо.
d — допзатраты, В этот момент вы понимаете, что надо было делать по-другому. Оказалось, что эта работа была сделана плохо.
Смотрите: затраты труда на чисто плоскую книгу — p, на плоскую с архитектурно заложенной возможностью простого превращения в древовидную — p' (p' >= p), на превращение чисто плоской — q, на превращение «правильной» — q' (q' <= q).
Плохо сделана работа по созданию книги если p'-p > q-q'. Хорошо, если p'-p < q-q'. Предполагается, что все работы оплачиваются.
Плохо сделана работа по созданию книги если p'-p > q-q'. Хорошо, если p'-p < q-q'. Предполагается, что все работы оплачиваются.
Ваша модель показывает вред дополнительных затрат на подготовку к неожиданностям, которые могут и не произойти. Это плохая, ненужная работа.
Но дополнительные затраты по прежнему фигурируют и плохую работу определить помогают.
Но дополнительные затраты по прежнему фигурируют и плохую работу определить помогают.
Плохо сделана работа по созданию книги если p'-p > q-q'.
Не очень понятно — работа в каком сценарии сделана плохо?
Если p'-p > q-q', то надо идти через «чисто плоскую» книгу. В противном случае — через «правильную». Но это если известно, что «древовидная» книга обязательно потребуется. Иначе формула усложняется: через «правильную» книгу надо идти только в случае, когда
p'+dT*R-p < s*(q-q')
где s — вероятность того, что книгу придётся переписывать (s<=1), dT — время, на которое «правильную» книгу было писать дольше, чем «чисто плоскую», а R — доход, который приносит «плоская» книга в единицу времени. Так что перекос в сторону работы через «чисто плоскую» книгу ещё больше.
Пожалуйста, не опровергайте утверждений, которых я не делал.
Разве это не ваше утверждение?
В заметке идет речь об объективно плохом коде, а это плохая работа, да.
Если заказчик не уведомил исполнителя о том, что с кодом планируется делать (выкинуть в любом случае или развивать в случае успеха), то виноват заказчик. Если уведомил, а исполнитель этого не предусмотрел (как вариант — предусмотрел, что только он сможет развивать) — виноват исполнитель.
Если отойти чуть в сторону, то когда я заказываю работу у дизайнеров, то пишу в частичном ТЗ в разделе технических требований что-то вроде «эскиз интерфейса должен предоставляться в формате .psd программы Adobe Photoshop CS 100500, все визуально и(или) логически разделяемые элементы должны быть представлены на отдельных слоях (или их группах) с семантически значимыми именами». Если я не написал про psd и дизайнер мне прислал bmp в соответствующий художественным и эргономическим требованиям ТЗ, то я не назову его работу плохой, я назову свое ТЗ плохим.
Если отойти чуть в сторону, то когда я заказываю работу у дизайнеров, то пишу в частичном ТЗ в разделе технических требований что-то вроде «эскиз интерфейса должен предоставляться в формате .psd программы Adobe Photoshop CS 100500, все визуально и(или) логически разделяемые элементы должны быть представлены на отдельных слоях (или их группах) с семантически значимыми именами». Если я не написал про psd и дизайнер мне прислал bmp в соответствующий художественным и эргономическим требованиям ТЗ, то я не назову его работу плохой, я назову свое ТЗ плохим.
Я смотрю, вы уже перешли к другому вопросу, как искать виноватого в случае обнаружения плохой работы.
Значит ли это, что аргументов против моего начального тезиса больше нет?
Значит ли это, что аргументов против моего начального тезиса больше нет?
Нет. Просто косвенное определение термина «плохая работа». Если работа соответствует требованиям ТЗ и нежелательной для заказчика функциональности добавлено не было, то о плохой работе смысла нет говорить. Как минимум она удовлетворительна.
А никто и не говорит. А вот когда придется к ней возвращаться для переделок, терять время/деньги/репутацию, тогда все и прояснится. Согласны?
Нет. Если новых требований не возникло, тогда не придется возвращаться к удовлетворительно сделанной работе для переделок. К хорошо сделанной работе может не придется возвращаться и в случае каких-то новых требований (она сделана с запасом в ТЗ или обязательных стандартах не обозначенным). К плохо сделанной работе придется возвращаться и без новых требований.
Просто у любой работы есть минимум три критерия качества: «плохо», «удовлетворительно» и «хорошо». А люди часто считают, что раз не «плохо», то должно быть «хорошо».
Просто у любой работы есть минимум три критерия качества: «плохо», «удовлетворительно» и «хорошо». А люди часто считают, что раз не «плохо», то должно быть «хорошо».
Речь не идет о новых требованиях, где вы это взяли? На новые фишки затраты планируются. Речь идет о дополнительных затратах, которых быть де должно.
Конкретный пример таких затрат можно? Чтобы код соответствовал требованиям, но требовал непредвиденных затрат от заказчика? Вариант, что заказчик лопух и не знал, что для того чтобы иметь сайт нужно платить за хостинг и домен, а для запуска екзешника нужен декстоп или ноутбук, не рассматриваем.
Кто говорит о «непредвиденных затрат от заказчика»?
Непредвиденные затраты могут быть и на стороне исполнителя, когда заказчик, например, запланировал новую фичу, а чтобы ее добавить, нужно выбросить старый код и написать новый (допзатраты), который все-таки можно масштабировать и только после этого добавить новое.
В этот момент кто-то поймет, что ту, первую работу сделали плохо.
При этом неважно, какие выгоды удалось или не удалось получить при использовании плохой работы. Речь идет о самом факте того, что кем-то была сделана тогда плохая работа.
Непредвиденные затраты могут быть и на стороне исполнителя, когда заказчик, например, запланировал новую фичу, а чтобы ее добавить, нужно выбросить старый код и написать новый (допзатраты), который все-таки можно масштабировать и только после этого добавить новое.
В этот момент кто-то поймет, что ту, первую работу сделали плохо.
При этом неважно, какие выгоды удалось или не удалось получить при использовании плохой работы. Речь идет о самом факте того, что кем-то была сделана тогда плохая работа.
Поймет заказчик, что он плохо сделал работу по формированию изначального ТЗ, когда счет на новую фичу от испонителя его неприятно удивит, особенно в сочетании с обоснованием типа «если бы вы раньше рассказали о своих планах, то первый заказ бы обошелся вам на 10% дороже, а этот на 90 дешевле, в итоге в 3 раза дешевле оба заказа».
Итак, проверяем мой тезис: допзатраты есть (повышенный счет на новую фичу), понимание, что работа плохо сделана, есть.
Исполнителю не сообщили критерий «дешевое внедрение новых фич», повышенный счет только по сравнению с ситуацией когда ему его сообщили или он его ввел сам.
А если бы исполнитель заранее угадал, что заказчик захочет новую фичу (а он сам о ней ни слухом, ни духом пока, даже слов типа «социальная сеть» пока не знает, хотя через месяц закажет интеграцию с ними), спросил его «а давайте сразу предусмотрим интеграцию с социальной сетью — сейчас вам это выйдет на 10% дороже (вполне объективно на 10% больше трудозатраты), зато потом в 10 раз дешевле будет её интегрировать?», а заказчик отказался по причине «жаба душит из-за какой-то соцсети, еще неизвестно нужной или нет, на 10% больше платить», то был бы такой код плохим или нет?
В целом взять ситуацию: Заказчику сообщили о всех мыслимых и немыслимых ограничениях кода, который будут у кода, который готов создать исполнитель за эти деньги. Заказчик с радостью согласился — он рассчитывал на большие ограничения за эту сумму. Можно ли назвать этот код плохим? Он же полностью удовлетворяет оплачиваемым (причем с радостью) требования заказчика, даже те, которые он не осознавал типа зашиты от SQL-инъекций. Заказчик хотел одно за свои деньги, но ему дают больше. Могли бы дать ещё больше, но у заказчика денег нет, чтобы это оплатить. Ему плохо работу хотят сделать?
А если бы исполнитель заранее угадал, что заказчик захочет новую фичу (а он сам о ней ни слухом, ни духом пока, даже слов типа «социальная сеть» пока не знает, хотя через месяц закажет интеграцию с ними), спросил его «а давайте сразу предусмотрим интеграцию с социальной сетью — сейчас вам это выйдет на 10% дороже (вполне объективно на 10% больше трудозатраты), зато потом в 10 раз дешевле будет её интегрировать?», а заказчик отказался по причине «жаба душит из-за какой-то соцсети, еще неизвестно нужной или нет, на 10% больше платить», то был бы такой код плохим или нет?
В целом взять ситуацию: Заказчику сообщили о всех мыслимых и немыслимых ограничениях кода, который будут у кода, который готов создать исполнитель за эти деньги. Заказчик с радостью согласился — он рассчитывал на большие ограничения за эту сумму. Можно ли назвать этот код плохим? Он же полностью удовлетворяет оплачиваемым (причем с радостью) требования заказчика, даже те, которые он не осознавал типа зашиты от SQL-инъекций. Заказчик хотел одно за свои деньги, но ему дают больше. Могли бы дать ещё больше, но у заказчика денег нет, чтобы это оплатить. Ему плохо работу хотят сделать?
Зачем вы предлагаете обсуждать связь между плохой работой и удовлетворенностью заказчика?
Вы ведь возражаете против показателя дополнительных затрат, как признака плохой работы.
Я прошу вас быть точнее, если вы действительно хотите показать логические недостатки этого утверждения, а не просто спорите ради спора.
Вы ведь возражаете против показателя дополнительных затрат, как признака плохой работы.
Я прошу вас быть точнее, если вы действительно хотите показать логические недостатки этого утверждения, а не просто спорите ради спора.
Потому что только заказчик может оценивать качество работы более-менее объективно. Его удовлетворенность и есть эта оценка. Дополнительные затраты могут служить признаком плохой работы лишь в случае, если они идут на компенсацию недостатков, которых не должно было быть. Не «приходится платить за то, что исполнитель не телепат и провидец», а «приходится платить за то, что исполнитель не сделал то, что ему было сказано явно и однозначно».
Другой вариант: проект не стрельнул и пришлось тратить зря ресурсы на написание профессионалом а могли бы потери быть в 20 раз меньше материальные (не считая процентов по депозиту на 190к на месяц) и в 4 раза меньше временные. Получается профессионал сделал свою работу плохо. Содержание его кода обошлось в 20 раз минимум дороже без всякой пользы — потрачены допресурсы без всякого профита. Профессионал, получается написал плохой код, хотя он и соответствует всем критериям совершенного кода, покрыт и юнит тестами на 100%, и все пользовательские сценарии описаны в приемочных тестах, и тесты на защиту от уязвимостей срабатывают и т. п. Но это заказчику оказалось не нужным, он свои ресурсы потратил зря.
В этом примере нет допресурсов. Тут изначально решили взять профессионала, зная сколько он стоит.
Если после выполнения не пришлось тратить время и деньги на его код, проект не стрельнул по другим причинам, к исполнителю претензий нет.
Если после выполнения не пришлось тратить время и деньги на его код, проект не стрельнул по другим причинам, к исполнителю претензий нет.
В случае быдлокодера его тоже взяли изначально, зная сколько он стоит. Если заказчик решил сэкономить и получить за 10к код с качеством на 200к, то это его риск — такое качество может быть только случайно, если исполнитель себя недооценивает или ему срочно деньги нужны.
Чей это риск, это другой вопрос. Если вы пытаетесь опровергнуть мое определение плохой работы, приводите, пожалуйста аргументы на эту тему. Если аргументов больше нет, то я благодарю вас за дискуссию.
Плохая работа — работа, после завершения которой у заказчика возникают затраты, которые он требовал исключить, а исполнитель это проигнорировал, хотя это бы ему ничего не стоило. Или заказчик требовал возможные (но конкретные) затраты минимизировать, а исполнитель и это проигнорировал. Отвратительная работа — заказчик требования не просто проигнорировал, а их нарушал даже, пускай, в (кратковременный) убыток себе. Удовлетворительная работа — все требования заказчика выполнены. Хорошая работа — предугадана необходимость реализации некоторых новых (которые будут сформулированы в будущем) требований (заказчику придется платить только за новую работу, а не еще и за переделку старой). Отличная — не только необходимость реализации предугадана, но и реализация уже есть, причем заказчику в данный момент она не мешает и в дополнительные расходы не вводит.
В общем, качество работы нельзя оценить объективно без учета конкретных договоренностей между заказчиком и исполнителем. Плохо — заказчик получил меньше чем требовал (и оплатил). Хорошо — больше. Удовлетворительно — ровно.
В общем, качество работы нельзя оценить объективно без учета конкретных договоренностей между заказчиком и исполнителем. Плохо — заказчик получил меньше чем требовал (и оплатил). Хорошо — больше. Удовлетворительно — ровно.
Я рад, что не зря потратил время и вы приняли мое определение плохой работы — она вызывает дополнительные затраты.
Именно это и есть объективный критерий ее определения.
Именно это и есть объективный критерий ее определения.
Нет, не принял. Вернее принял с оговорками. Не все дополнительные затраты служат признаком плохой работы. Только те, которые идут на реализацию невыполненных требований.
Вы сейчас возражаете против утверждения «все дополнительные затраты служат признаком плохой работы».
Напомню, что мое утверждение «плохая работа приводит к дополнительным затратам».
Эти два утверждения — не одно и то же.
Напомню, что мое утверждение «плохая работа приводит к дополнительным затратам».
Эти два утверждения — не одно и то же.
Так что, плохую работу никак нельзя определить? Все можно объяснить/оправдать стилем, постановкой задачи, субъективностью оценок? Я правильно понимаю ваш тезис? (надеюсь, нет)
Плохую работу определить можно. Но не всегда это можно сделать, глядя на код, гораздо больше помогла бы запись разговоров автора кода с его начальником.
Отвечая на вопрос, адресованный UZER2006, вы уверены, что он утверждает именно это?
Плюс запись допущений, по которым автор кода решил начальника не беспокоить или не смог добиться внятного ответа и взял принятие решения на себя. Ещё вариантов множество, но главный, да, формализованные требования к коду. Соблюл ли автор требования, и не добавил ли что-то от себя, о чем начальнику забыл сообщить (баги, бэкдоры и т. п.).
Плохая работа — несоблюдение доведенных до исполнителя требований заказчика. Плюс недокументированная функциональность, введенная исполнителем без согласования с заказчиком случайно или намеренно (в частности уязвимости безопасности или бэкдоры).
Существование любого кода отнимает ресурсы. Ресурсы компьютера, на котором этот код выполняется. Ресурсы, недополученные из-за того, что пришлось потратить силы и деньги на написание этого кода (а можно было бы сделать что-нибудь полезное). И ресурсы на поддержку (развитие и/или багфиксинг). И дальше вопрос — каково в данной ситуации соотношение ценности этих ресурсов? Что ценнее — быстрый код? Быстро написанный? Надёжный? Или понятный? Бывают ситуации, когда по всем этим пунктам код хорош. Но в остальных случаях какой-нибудь пункт да нарушен. И это не означает плохой работы — значит только, что во время написания критерии были другими.
Кроме проблемы существования плохого кода есть проблема понимания, что этот код плохой.
Автора оригинального текста я уволил бы сразу же, в первую нашу встречу.
Программиста, который пишет говнокод, можно (и нужно) научить; человека, вместо работы исповедующего принципы всепрощения и терпимости — только расстрелять. С командой разработчиков не может случиться ничего более ужасного, чем идеология race to the bottom вида «да, да, что-то вы знаете хорошо, но во всем остальном — полный отстой».
Падающего — толкни.
Программиста, который пишет говнокод, можно (и нужно) научить; человека, вместо работы исповедующего принципы всепрощения и терпимости — только расстрелять. С командой разработчиков не может случиться ничего более ужасного, чем идеология race to the bottom вида «да, да, что-то вы знаете хорошо, но во всем остальном — полный отстой».
Падающего — толкни.
> Автора оригинального текста я уволил бы сразу же, в первую нашу встречу.
Автор оригинального текста не пришел бы к вам на работу.
Автор оригинального текста не пришел бы к вам на работу.
Попробуйте аргументированно доказать это.
Просто.
Так как printf имеет право увольнять, значит, с большой вероятностью он же и участвует в собеседованиях. Так как printf расстреливает всепрощающих программистов, то всепрощающие программисты в его компании не работают (трупам вообще сложно работать). Так как автор текста всепрощающий программист, то он не пройдёт собеседование. Чтобы придти на работу в компанию, нужно пройти собеседование. Вывод: автор текста не придёт на работу в компанию printf (при допущении, что printf участвует в собеседованиях).
Так как printf имеет право увольнять, значит, с большой вероятностью он же и участвует в собеседованиях. Так как printf расстреливает всепрощающих программистов, то всепрощающие программисты в его компании не работают (трупам вообще сложно работать). Так как автор текста всепрощающий программист, то он не пройдёт собеседование. Чтобы придти на работу в компанию, нужно пройти собеседование. Вывод: автор текста не придёт на работу в компанию printf (при допущении, что printf участвует в собеседованиях).
Во-первых, нет однозначных критериев того, что считать говнокодом. Во-вторых, автор вовсе не проповедует всепрощение, по-моему, а проповедует не ненависть. От того, что вы будете кричать или просто думать «ненавижу автора этого кода» код лучше не станет.
Про говнокод-то ясно, речь не об этом. Оригинальный текст предлагает именно пожертвовать работой ради непонятных личных обид. Вот это вот:
совершенно излишне. Не надо ничего представлять, фантазировать, воображать себя биологом, лесничим, астронавтом. Все гораздо проще.
Боязнь обидеть человека, указав ему на ошибку, вредит в конечном итоге вообще всем.
Представьте, что код — ваш, и вы изобретете оправдания собственной глупости.
совершенно излишне. Не надо ничего представлять, фантазировать, воображать себя биологом, лесничим, астронавтом. Все гораздо проще.
Боязнь обидеть человека, указав ему на ошибку, вредит в конечном итоге вообще всем.
По-моему, это намек на «не судите опрометчиво». И предложений пожертвовать кодом тут нет. По крайней мере то, что вы процитировали, такого предложения точно не содержит. Я это понял как «попытайтесь понять, может у автора кода были другие причины написать именно так, кроме как настроение лично вам испортить».
Вообще пост, по-моему, о том, чтобы не «посылать лучи ненависти» к автору кода, который вам достался в наследство, если не уверены, что его автор сознательно пакостил приемникам и, тем более, лично вам. Обычно у любого говнокода есть причины по которым он был написан именно так, а не иначе. И эти причины как правило рациональны.
Вообще пост, по-моему, о том, чтобы не «посылать лучи ненависти» к автору кода, который вам достался в наследство, если не уверены, что его автор сознательно пакостил приемникам и, тем более, лично вам. Обычно у любого говнокода есть причины по которым он был написан именно так, а не иначе. И эти причины как правило рациональны.
С говнокодом с ним оно как в реальной жизни. Бывает — идёшь, наступишь во что-то, а не понятно, говно ли это или грязь, а может — просто показалось. А бывает — сразу понятно — оно. По запаху ли, по другим признакам. И на код смотришь — иногда думаешь, может, просто чего-то не понимаешь, не дорос ещё до того или иного подхода, или не уловил авторской задумки, или автор и впрямь был поставлен в такие рамки, что ничего другого выдать не мог, такое с каждым может случиться. А бывает что сразу видно, что перед тобой — настоящий аутентичный говнокод, порождение особой формы мышления, и автор его кроме поганой метлы иных средств воздействия не заслуживает. Особенно в случаях, когда у автора стаж работы «программистом» уже большой и изменить ход своей мысли он уже вряд ли сможет.
Но даже если наступишь в говно, то повод ненавидеть его автора только один — автор сознательно насрал там, где с большой вероятностью в его гавно наступят. Если он не понимает, что его говно посреди улицы другим людям неприятно, то лучше его (автора) просветить (пускай и путем наказания) или вообще игнорировать, тихо убрав говно за ним. А если начинать его ненавидеть, то есть шанс, что вы стали жертвой манипуляции.
На начальных стадиях помогает, если человек говнокодит просто по неопытности или не очень упорствует в своих сомнительных говнокодерских наклонностях. Но бывают упёртые гонокодеры, сознательно придерживающиеся такого стиля и не признающие других. Т.е. если человек делает это посреди улицы не первый год и категорически не признаёт никаких альтернатив такому поведению, тогда — без ненависти, но в биореактор.
Вы правы только в том случае, если человек обязан вам не делать это посреди улицы. Наприсер, вы взяли его на работу с условием «посреди улицы не срать, а то уволю». А если я, не будучи вашим работником, выложил свой говнокод на гитхабе, вам идея и функциональность понравились и вы склонировали себе с ожиданием, что я исправлюсь, присылаете пулл-реквесты, а я их игнорирую, то меня нельзя в биореактор :) — или вы меня игнорируйте, или говно за мной убирайте (держите свой форк).
Тут соглашусь, биореактор — это для первого случая, а также, по возможности, для разных злокачественных vendor lock-in'ов и тому подобных ситуаций. Во втором случае (гитхаб) можно действительно игнорировать/править, ну или максимум, если совсем невмоготу, обложить матюгами в блоге/соцсетях/других сайтах, но тоже, конечно, без излишней ненависти.
Кстати, аутентичный говнокод обычно отличается тем, что начинаешь лихорадочно искать на экране кнопку 
. Надо будет фичреквест гитхабу написать.
. Надо будет фичреквест гитхабу написать.Ну не знаю, я стараюсь исправить «плохой» код, когда нахожу в проекте. Особенно, если проблемы мелкие, но их много. Примеры (С++): прямая работа с указателями там, где гораздо безопаснее использовать scoped_ptr, проверка результата new на null, вынос реализаций виртуальных функций в заголовочные файлы, using namespace std в заголовочных файлах, неуместные использования макросов и преобразований типов, etc.
Никто же не говорит, что его не нужно исправлять. Но исправлять можно по разному. А прежде чем исправлять нужно подумать, что может были объективные причины для такого кода и своим исправлением вы, например, ухудшите производительность или потребление памяти на критически важной задаче.
У нас по отделу бегает десяток человек, взахлёб рассуждающих о том, что виртуальные функции медленные и лучше их никогда не использовать. Места, где производительность имеет такое значение, должны иметь бенчмарки, которые можно запустить до и после исправлений. Без них все рассуждения и доводы о производительности — брехня. Заоптимизированный код должен жить отдельно и быть хорошо задокументирован.
«До и после» каких исправлений? Если этот десяток человек пишет код стразу без виртуальных функций — то с чем вы его будете сравнивать? Особенно, если они сразу выбирают архитектуру программы, рассчитанную и оптимизированную на то, что виртуальных функций не будет?
Ну к одному модулю, который писал я для повышения производительности I/O, есть бенчмарки. И я даже разок заменил публичное API чисто виртуальным интерфейсом, и каждый слой в реализации тоже общался с верхними при помощи интерфейсов. Знаете, какое замедление показали бенчмарки? 0%. Зато позволили полностью спрятать кучу внутренних заголовочных файлов, а также несколько уменьшить время сборки. К слову, 10-15% занимает подсчёт контрольных сумм, но с этим уже вроде ничего не поделать.
Иногда нужны низкоуровневые хаки, но они должны быть тщательно документированны, а их эффект должен быть измерен.
К самоочевидным вещам вроде использования алгоритмов O(n) вместо O(n^2) и batch-обновлений вместо единичных вставок это не относится.
Иногда нужны низкоуровневые хаки, но они должны быть тщательно документированны, а их эффект должен быть измерен.
К самоочевидным вещам вроде использования алгоритмов O(n) вместо O(n^2) и batch-обновлений вместо единичных вставок это не относится.
По-моему, речь в посте идет прежде всего о ситуациях унаследованного кода, а не о вашем отделе или другой команде. В команде должны быть общие правила игры, в том числе, что считать хорошим кодом, а что плохим. Если вы постоянно исправляете код тимлида (со всеми комментариями зачем и почему), а он откатывается на свой (без комментариев), то может стоит подумать о смене команды. Если вы тимлид, а джуниор постоянно говнокодит, то стоит подумать о его обучении или увольнении. В любом случае, делать массовые рассылки в команде или писать гневные посты на хабре обычно контрпродуктивно и для вас, и для команды.
А оптимизация штука тонкая. Хотя бы потому, что у неё множество параметров, а не только производительность. Кто будет против оптимизации улучшающей все метрики кода, включая читаемость? А документировать (не считая комментария в коммите) каждую оптимизацию (например: for (i=count; i; --i) быстрее чем for (i=0; i<count; i = i+1)) смысла нет.
А оптимизация штука тонкая. Хотя бы потому, что у неё множество параметров, а не только производительность. Кто будет против оптимизации улучшающей все метрики кода, включая читаемость? А документировать (не считая комментария в коммите) каждую оптимизацию (например: for (i=count; i; --i) быстрее чем for (i=0; i<count; i = i+1)) смысла нет.
А после таких ваших спонтанных исправлений кто-нибудь проводить code-review? Тестирование?
Код ревью иногда. Тесты, к сожалению, кроме меня пока мало кто пишет. Ну и обычно в случаях
или
- using namespace std;
- string doIt(const string &);
+ std::string doIt(const std::string &);или
- Buf *buf = new Buf;
...
- delete buf;
+ boost::scoped_ptr<Buf> buf(new Buf);мне достаточно компилируемости и беглого смок-теста.С таким подходом рано или поздно вы ошибетесь, согласны?
Кстати, чем
using namespace не угодил?чем using namespace не угодил?
Т. е. вас не смущает using namespace std; в заголовочном файле?
С таким подходом рано или поздно вы ошибетесь, согласны?
Вероятность ошибки ненулевая, согласен. Но для тривиальных транформаций вроде этих, думаю, риск оправдан, тут компилятор может найти большую часть глупых ошибок. Повторюсь, к своему коду я всегда пишу тесты, и рефакторю свой код во время разработки часто и много. Честно говоря, я уже опасаюсь писать production-код без тестов, даже несложные алгоритмы в несколько строк.
«Есть одно тёмное время — когда на свет рождаются самые уродливые строки когда, когда самые витиеватые хаки пробуждаются, когда сумерки опускаются над проектом. И это время кличут — мёртвой чертой. Программисту же все вокруг сочувствуют и сопереживают. В коридорах можно услышать шепот коллег -'Нет, нет — не трогайте его. У него сегодня дэдлайн ...' — и окончание фразы от страха и воспоминаний ещё долго висит в воздухе, ведь каждый переживал это время.»
Честно и внимательно вчитывался, выискивая «разумное, доброе, вечное» — увы… Чушь какая-то, прости Хабр.
Посыл простой: ненависть неконструктивна, особенно если не знаешь мотивов поведения объекта.
Есть кривой код, который написан из-за спешки. Это «технический долг». Это исправимая проблема.
Есть кривой код, который написан из-за неопытности — это исправляется объяснением автору код чем написанный код плох… Это рабочий момент.
Есть кривой код, который написае из-за нежелания писать хорошо вопреки здравому смыслу. И это НЕНАВИСТЬ.
Есть кривой код, который написан из-за неопытности — это исправляется объяснением автору код чем написанный код плох… Это рабочий момент.
Есть кривой код, который написае из-за нежелания писать хорошо вопреки здравому смыслу. И это НЕНАВИСТЬ.
Третье для меня лишь причина применять организационные, дисциплинарные или административные меры. За одним исключением: если я кривой код написал — - это НЕНАВИСТЬ :) Все остальные не обязаны быть совершенными, им простительно :)
> Третье для меня лишь причина применять организационные, дисциплинарные или административные меры
А разве может это сделать рядовой программист в команде? Вот именно поэтому и НЕНАВИСТЬ.
А разве может это сделать рядовой программист в команде? Вот именно поэтому и НЕНАВИСТЬ.
Может. Тёмную, например, устроить. Но спокойно, без эмоций.
А разве может это сделать рядовой программист в команде?Конечно да. Поднимите вопрос руководству. Если не хотите «стучать в тихую» скажите об этом громко и в пристуствии виноватого.
Ваша же позиция «я маленький человек, что я могу» совершенно необъяснима.
Если бы я в своё время не оказался в таком положении и не пробовал предложенное вами — я бы предыдущее утверждение не писал.
Вообще, это очень интересный момент. Далеко не каждый начальник послушает такое утверждение, им далеко не каждый коллектив такое действие поймёт. Так что предложенное вами, в общем случае, риск рабочим местом.
Далеко не каждый начальник послушает такое утверждение, и далеко не каждый коллектив такое действие поймётСамо собой, если в колективе круговая порука, и все прикрывают косяки друг друга, такой номер не пройдет. Встречал я такие ситуации. В таких коллективах принято «ссать в уши» начальству. Наверх докладывается, что все хорошо и все работают, только результатов почему-то нет, сплошные бесконечные отговорки и стрелки. Я надеюсь вы все же не в таком коллективе оказались.
Так что предложенное вами, в общем случае, риск рабочим местом.
Ну если вы им дорожите настолько, что готовы ради рабочего места тихо ненавидеть людей с которыми работаете — тогда да, риск не стоит игры.
Проблема в том, что для вас этот код может быть не кривым, а кристалльно ясным. А вокруг все почему-то кричат «читабельность???».
cbit+=(form[nch++]>>((((val>>cbit)&1)^3)<<3))&0xff; // skip next field
if(cbit>=32){ val=*ptr++;cbit&=31; }
Вроде бы всё понятно. Даже комментарий есть. А читатели даже смотреть не хотят.
cbit+=(form[nch++]>>((((val>>cbit)&1)^3)<<3))&0xff; // skip next field
if(cbit>=32){ val=*ptr++;cbit&=31; }
Вроде бы всё понятно. Даже комментарий есть. А читатели даже смотреть не хотят.
И что, НЕНАВИСТЬ исправит этот код или приблизит дату релиза?
В целом, я согласен с изложенным статье. Почти.
> Да, извините. Вы — отстой по части многих вещей.
Но я не пытаюсь зарабатывать ими на жизнь. Я в такие области пытаюсь вообще не лезть без необходимости.
И каждый раз, когда кто-то выдвигает оправдания существованию говнокода, мне хочется просто дать эту ссылку:
pastebin.com/UaTdN6K2
Написанному там — нет оправдания, и что этот человек забыл в разработке — я решительно не понинаю.
> Да, извините. Вы — отстой по части многих вещей.
Но я не пытаюсь зарабатывать ими на жизнь. Я в такие области пытаюсь вообще не лезть без необходимости.
И каждый раз, когда кто-то выдвигает оправдания существованию говнокода, мне хочется просто дать эту ссылку:
pastebin.com/UaTdN6K2
Написанному там — нет оправдания, и что этот человек забыл в разработке — я решительно не понинаю.
Оправданием говнокоду может служить простой фактор — он работает в соответствии с требованиями без неожиданных побочных эффектов. Проблема говнокода — проблема того, кто заказал только функциональность без требований к качеству.
> Оправданием говнокоду может служить простой фактор
А вы посмотрите ссылку pastebin.com/UaTdN6K2, ага ) Это особый сорт, возникающий отнюдь не из-за сжатых сроков или забивания кодером на качество.
> проблема того, кто заказал только функциональность без требований к качеству.
В теории — может быть. Но не на практике. В конторах, которым пофиг на код — время на устранение чужой кучи приходится выбивать самому программисту, и хорошо если удастся. Конкретно код по ссылке был заменён только потому, что переписать заново было значительно быстрее, чем модифицировать.
> без неожиданных побочных эффектов.
Мой опыт общения с подобным кодом показывает, что сторонние эффекты есть практически всегда. И хорошо если это нарушение порядка сортировки, но это может быть кривой менеджмент памяти. И тогда — привет SIGSEGV в рандомном месте.
Я не исключаю существования говнокода в форме чёрного ящика, но печаль в том, что если в проекте появляется говнокод — он имеет свойство распускать свои тентакли всюду.
А вы посмотрите ссылку pastebin.com/UaTdN6K2, ага ) Это особый сорт, возникающий отнюдь не из-за сжатых сроков или забивания кодером на качество.
> проблема того, кто заказал только функциональность без требований к качеству.
В теории — может быть. Но не на практике. В конторах, которым пофиг на код — время на устранение чужой кучи приходится выбивать самому программисту, и хорошо если удастся. Конкретно код по ссылке был заменён только потому, что переписать заново было значительно быстрее, чем модифицировать.
> без неожиданных побочных эффектов.
Мой опыт общения с подобным кодом показывает, что сторонние эффекты есть практически всегда. И хорошо если это нарушение порядка сортировки, но это может быть кривой менеджмент памяти. И тогда — привет SIGSEGV в рандомном месте.
Я не исключаю существования говнокода в форме чёрного ящика, но печаль в том, что если в проекте появляется говнокод — он имеет свойство распускать свои тентакли всюду.
Сознательную обфускацию в расчет не принимаем :)
В конторах, которым пофиг на код именно так и говорится: «переписать заново значительно быстрее, чем модифицировать», а то и ничего не говорится, а молча пишется заново.
В рамках данного топика я рассматриваю говнокод именно в виде черного ящика. Если он появился в проекте (чаще если проект был таким), то надо из него сделать черный ящик. Хоть как либу, хоть как фреймворк. Возможность не писать говнокод в логике есть практически всегда — пишем совершенную логику и делаем в говнокоде вокруг её вызова говнообертку :)
В конторах, которым пофиг на код именно так и говорится: «переписать заново значительно быстрее, чем модифицировать», а то и ничего не говорится, а молча пишется заново.
В рамках данного топика я рассматриваю говнокод именно в виде черного ящика. Если он появился в проекте (чаще если проект был таким), то надо из него сделать черный ящик. Хоть как либу, хоть как фреймворк. Возможность не писать говнокод в логике есть практически всегда — пишем совершенную логику и делаем в говнокоде вокруг её вызова говнообертку :)
Я бы не сказал, что это сознательная обфускация. Я себя тешу мыслью, что человеку просто не дано программировать. Как у кого-то нет слуха, а кто-то не умеет рисовать.
> В конторах, которым пофиг на код именно так и говорится
«Почему так долго? %name% писал весь модуль столько, а ты не можешь исправить единственный баг?» — «тут надо половину переписать, чтобы сделать хоть что-то» — «нафиг переписывать» — «существующий код ужасен» — «быть этого не может, %name% отличный программист» ;)
Вся проблема в том, что говнокод в виде чёрного ящика — скорее исключение, чем правило. Если вы глянете всё тот же код по ссылке, то найдёте там обращение к глобальным переменным. Этот проект можно в качестве образца использовать, ага.
> В конторах, которым пофиг на код именно так и говорится
«Почему так долго? %name% писал весь модуль столько, а ты не можешь исправить единственный баг?» — «тут надо половину переписать, чтобы сделать хоть что-то» — «нафиг переписывать» — «существующий код ужасен» — «быть этого не может, %name% отличный программист» ;)
Вся проблема в том, что говнокод в виде чёрного ящика — скорее исключение, чем правило. Если вы глянете всё тот же код по ссылке, то найдёте там обращение к глобальным переменным. Этот проект можно в качестве образца использовать, ага.
Ага, а потом все удивляются, почему мы для каждого небольшого изменения все с нуля говнокодим.
Хороший код — технологический актив, он будет сокращать время в дальнейшем.
Плохой код — технологический пассив, он будет в дальнейшем проблемы.
Впрочем, изредка требуется думать только о пятиминутной перспективе.
Хороший код — технологический актив, он будет сокращать время в дальнейшем.
Плохой код — технологический пассив, он будет в дальнейшем проблемы.
Впрочем, изредка требуется думать только о пятиминутной перспективе.
Полностью с вами согласен. Вот только зачастую разработчику (в широком диапазоне — от рядового кодера до аутсорсера мировых масштабов) не приходится думать о технологических активах и пассивах. Он думает только о финансовых/организационных/дисциплинарных. Об активах/пассивах должен думать заказчик — это его прямые риски, для разработчика в худшем случае они репутационные (если приемочные тесты проходят)…
Заказчику, увы, при приемке сложно оценивать качество, так как оно зависит от того, как были восприняты пробелы и недоработки в требованиях. Приходится рассчитывать на то, что разработчик просто не сможет спать, если у него плохой код.
И он будет думать о технологических активах и пассивах если планирует проработать над проектом не один год, так как навредит себе же (тут всплывает проблема одноразового кода, который внезапно оказывается живучим).
И он будет думать о технологических активах и пассивах если планирует проработать над проектом не один год, так как навредит себе же (тут всплывает проблема одноразового кода, который внезапно оказывается живучим).
Сразу вспоминаю один замечательный сайт, учащий жизни: govnokod.ru
К сожалению статья не отвечает на вопрос что делать с унаследованным кодом. Вот был когда-то давно написан код. На фортране. Или даже на паскале. А в проекте он нужен.
Один из подходов, кстати, если код все-таки работает, обернуть его и не трогать…
Один из подходов, кстати, если код все-таки работает, обернуть его и не трогать…
Во-первых, проблему нужно решать до ее возникновения. Такой код просто не должен уйти в систему контроля версии.
Самый позитивный и комфортный опыт моей работы был в команде, где принято проводить код-ревью для абсолютно каждого коммита. В дополнении к этому, были достаточно строгие требования к форматированию кода, названию методов, классов, переменных. С течением времени, стиль написания кода у всех участников команды стал схожий (насколько я ощущаю — достаточно высокий уровень, хотя это субъективное восприятие). Если возникал спорный вопрос — как делать правильно — мы единожды его обсуждали, могли потратить довольно много времени на это. После чего принимали единственное взвешенное решение (не важно кто как привык) и далее договаривались придерживаться именно такого подхода.
Так же этому всему сопутствовал подход — не указывать на сам факт чьей-то вины, но искать хозяина кода. Главное — искать ошибку, недочет, уязвимость, плохой стиль — объяснять (аналогично обучению) почему так делать нельзя, приводить примеры к чему это может привести и показывать как делать надо. Т.е. самое главное — обмен опытом, открытая дружественная дискуссия, наша задача — саморазвитие и совершенствование, все совершают ошибки и это нормально.
Такая атмосфера очень полезна и положительно влияет на успехи команды. Все члены команды открыты друг другу и не пытаются скрыть что-либо от остальных, не пытаются защищаться, не пытаются нападать — нет агрессии. Это не война и тут нет врагов.
Я, к сожалению, работал и в другом коллективе. Где за высказанную в общий чат критику по коду, весь чат ополчился против бедняги. Работа в таком коллективе вызывала только ненависть. Абсолютная деструкция и постоянные подставы среди участников команды.
Самый позитивный и комфортный опыт моей работы был в команде, где принято проводить код-ревью для абсолютно каждого коммита. В дополнении к этому, были достаточно строгие требования к форматированию кода, названию методов, классов, переменных. С течением времени, стиль написания кода у всех участников команды стал схожий (насколько я ощущаю — достаточно высокий уровень, хотя это субъективное восприятие). Если возникал спорный вопрос — как делать правильно — мы единожды его обсуждали, могли потратить довольно много времени на это. После чего принимали единственное взвешенное решение (не важно кто как привык) и далее договаривались придерживаться именно такого подхода.
Так же этому всему сопутствовал подход — не указывать на сам факт чьей-то вины, но искать хозяина кода. Главное — искать ошибку, недочет, уязвимость, плохой стиль — объяснять (аналогично обучению) почему так делать нельзя, приводить примеры к чему это может привести и показывать как делать надо. Т.е. самое главное — обмен опытом, открытая дружественная дискуссия, наша задача — саморазвитие и совершенствование, все совершают ошибки и это нормально.
Такая атмосфера очень полезна и положительно влияет на успехи команды. Все члены команды открыты друг другу и не пытаются скрыть что-либо от остальных, не пытаются защищаться, не пытаются нападать — нет агрессии. Это не война и тут нет врагов.
Я, к сожалению, работал и в другом коллективе. Где за высказанную в общий чат критику по коду, весь чат ополчился против бедняги. Работа в таком коллективе вызывала только ненависть. Абсолютная деструкция и постоянные подставы среди участников команды.
Я бы сказал так: можно ругать код, но не надо при этом бросаться на автора.
И второе: бросаясь на автора (или даже на его код), не следует зарекаться. Возможно, завтра окажешься на его месте.
И второе: бросаясь на автора (или даже на его код), не следует зарекаться. Возможно, завтра окажешься на его месте.
По-моему, в случае команды примерно равной квалификации (то есть нет места обучению, только обмену опытом) конструктивнее указать на факт, чем искать хозяина. Как раз объявить на весь чат «такой код больше приниматься не будет потому-то-потому-то». В идеале «давайте обсудим такой код… как видите, большинство против, потому он приниматься не будет». Но «тоталитаризм » тоже допустим. Но вот на весь чат писать «Владимир, ты пишешь говно, больше так не делай, а делай так» демотивирует желание учиться даже чисто формой.
Где-то в книгах о хорошем стиле программирования читал, что окультуривая подобное безобразие последовательно и достаточно долго, можно добиться приемлемых результатов. Сам пробовал пару раз на небольших проектах — имена переменных, упрощения частями…
Кончалось обычно тем, что разобравшись в сути переписывал.
Не знаю правда чем это считать — подтверждением или опровержением прочитанного…
Кончалось обычно тем, что разобравшись в сути переписывал.
Не знаю правда чем это считать — подтверждением или опровержением прочитанного…
Не знаю правда чем это считать — подтверждением или опровержением прочитанного…
В первую очередь — ответом на заголовок статьи.
А в остальном… скорее, подверждение, но с поправкой — не надо ругать код, но и не надо искать ему оправданий. Просто воспринимать его как задачу, которую надо сначала понять, потом решить.
Осталось придумать где взять такую прорву нервов и лишнего времени.
Времени — известно где: у работодателя. А нервы… тут ничего нельзя советовать, всё индивидуально. Думаю, что, например, у тех 16% хабраюзеров, которые в недавнем опросе сказали, что «могут быстро разобраться в любом коде» такой проблемы не стоит. Один из вариантов ответа — расслабиться и получить максимум удовольствия от этой задачи :D ).
Представьте программу строк тысяч на 5, в которой все переменные, функции и методы называются по принципу — ABAB, NNFG, CCRT ..., сами функции и методы абсолютно нелепы, и попробуйте расслабиться, думая о том, как это разгребать :)
А время работодатель не особо счастлив терять, и программные проблемы ему зачастую не интересны.
За проблемы с программой, которая утрированно описана выше — год назад я был переведен из начальников лаборатории обратно в ведущие инженера, а сотрудник с которым мы вдвоем это разгребали — ушел в другое место.
Боюсь получать удовольствие от подобного у меня никакого дзена не хватит.
А время работодатель не особо счастлив терять, и программные проблемы ему зачастую не интересны.
За проблемы с программой, которая утрированно описана выше — год назад я был переведен из начальников лаборатории обратно в ведущие инженера, а сотрудник с которым мы вдвоем это разгребали — ушел в другое место.
Боюсь получать удовольствие от подобного у меня никакого дзена не хватит.
Представьте программу строк тысяч на 5, в которой все переменные, функции и методы называются по принципу — ABAB, NNFG, CCRT ...,
Приходилось. Переменные, правда, назывались h8302,h8304,hFFD7 и так далее, функции — аналогично, а строчки кода были ассемблерными. Причём не всегда было понятно, где код, а где данные.
Ничего, справились. Исключительно для собственного удовольствия.
В коде я редко встречаю безобразие на каком-то одном уровне, например, когда выглядит ужасно, но при этом идеально организован, все изящно и не пострадало от хорошо выполненной оптимизации.
Знаете, как менеджер, я иногда приветствую порывы программистов не то чтоб рефакторить, а просто удалить код и написать с нуля.
Код он такой, иногда и нужен костыльный, но чтоб быстро заработало (проверить идею на пользователях).
Идеально с нуля пишут единицы.
Код он такой, иногда и нужен костыльный, но чтоб быстро заработало (проверить идею на пользователях).
Идеально с нуля пишут единицы.
Никто не пишет идеально с нуля, ибо не было бы в столь старых и популярных фрэймворках deprecated после каждого мажорного апдейта. Но в целом согласен.
[grammar-nazi-mode]Лучше вообще не употреблять слова («ибо», «кабы», «дабы», «суть»), которые Вы где-то видели, которые кажутся Вам красивыми, но относительно которых Вы не знаете точно их смысл, или детали их употребления, или то управление, которое они требуют использовать. А то получается смешно.[/grammar-nazi-mode]
То ли я не так понял, то ли у вас взаимоисключающие параграфы:
как менеджер, я иногда приветствую порывы программистов не то чтоб рефакторить, а просто удалить код и написать с нуля
Идеально с нуля пишут единицы.
Это разные нули. Нуль после удаления старого кода — это уже +0, с него писать легче. Но, скорее всего, результат будет тем же :( Эволюция безопаснее, чем революция.
Я как менеджер исповедую такой принцип — любой рефакторинг делается с какой-то конкретной целью. Например, новый функционал затрагивает «кривой» модуль, и без рефакторинга придется подпереть еще пару костылей. Такой рефакторинг изначально будет заложен в затраты на реализацию нового функционала.
Если же «кривой» кусок приложения изолирован и не затрагивается новыми доработками и его функциональность/производительность укладывается в заданные условия — такой код будет жить и никто его не тронет. Ибо от такого рефакторинга никакого выигрыша проекту не будет, даже наоборот — придется заново тестировать и перепроверять любой код, который был связан с «кривым».
Кроме того есть такое соображение — кривой код как правило показывает, как не надо было делать. Но далеко не всегда указывает на правильное решение.
Если же «кривой» кусок приложения изолирован и не затрагивается новыми доработками и его функциональность/производительность укладывается в заданные условия — такой код будет жить и никто его не тронет. Ибо от такого рефакторинга никакого выигрыша проекту не будет, даже наоборот — придется заново тестировать и перепроверять любой код, который был связан с «кривым».
Кроме того есть такое соображение — кривой код как правило показывает, как не надо было делать. Но далеко не всегда указывает на правильное решение.
Давайте я еще приведу советы, как нужно поступать с плохим тестом:
Погрузитесь в текст с любопытством и желанием разобраться. Сопереживайте человеку, который его писал. Представьте себя на его месте. Он не такой как вы. Скорее всего, его занимают совсем иные заботы, нежели донести до вас полезную информацию.
Скорее всего, в его знаниях отсутствует знание школьной программы. Пропущенные знаки препинания, или орфографические ошибки могли не попасть в фокус его внимания, как и избыток многоточий или беспорядочно разбросанные вымышленные слова. Может быть, у него — своя жизнь.
Хотите понять, откуда эти бессвязные логические конструкции, отсутствие сопряжения слов, постоянные отступления в скобках, уродливое форматирование и полное отсутствие смысла в большей части написанного?
Это просто. Представьте, что это писал десятилетний имбецил, которым очень гордится его мама. Постарайтесь разделить гордость мамы за него и не ломать голову, почему он при этом член союза писателей.
Погрузитесь в текст с любопытством и желанием разобраться. Сопереживайте человеку, который его писал. Представьте себя на его месте. Он не такой как вы. Скорее всего, его занимают совсем иные заботы, нежели донести до вас полезную информацию.
Скорее всего, в его знаниях отсутствует знание школьной программы. Пропущенные знаки препинания, или орфографические ошибки могли не попасть в фокус его внимания, как и избыток многоточий или беспорядочно разбросанные вымышленные слова. Может быть, у него — своя жизнь.
Хотите понять, откуда эти бессвязные логические конструкции, отсутствие сопряжения слов, постоянные отступления в скобках, уродливое форматирование и полное отсутствие смысла в большей части написанного?
Это просто. Представьте, что это писал десятилетний имбецил, которым очень гордится его мама. Постарайтесь разделить гордость мамы за него и не ломать голову, почему он при этом член союза писателей.
Обучаемость тоже играет роль, нормально в начале своей практики наговнокодить а потом мучаться из-за этого.
Пара таких случаев приводит к выводу, что лучше в следующий раз все делать по-другому. Потом выделяются две основные группы — те кто признался что им есть к чему стремится и пошли читать книжки по своим проблемам, узнавая, что не очень нормально держать много кода в голове, и что его нужно писать и для людей и для машин одновременно, а перед конструированием вообще лучше взять бумагу с ручкой и попробовать набросать проект, обсуждая с другими то, что ты делаешь. За них я спокоен.
И те, кто решил что лично у него проблем нет, так как он профессионал, во всем виноват несовершенный мир как данность, но вот эта серебрянная пуля (экзотическая база данных, фреймворк на closure или переписывание кода на Erlang) сейчас решит все проблемы. И идут читать доки, рассчитывая, что за них все уже сделали другие люди. В итоге человек читает все новые и новые мануалы, набирая технические знания, которые устареют через пару лет, но сам процесс работы выглядит как 10 лет назад.
Пара таких случаев приводит к выводу, что лучше в следующий раз все делать по-другому. Потом выделяются две основные группы — те кто признался что им есть к чему стремится и пошли читать книжки по своим проблемам, узнавая, что не очень нормально держать много кода в голове, и что его нужно писать и для людей и для машин одновременно, а перед конструированием вообще лучше взять бумагу с ручкой и попробовать набросать проект, обсуждая с другими то, что ты делаешь. За них я спокоен.
И те, кто решил что лично у него проблем нет, так как он профессионал, во всем виноват несовершенный мир как данность, но вот эта серебрянная пуля (экзотическая база данных, фреймворк на closure или переписывание кода на Erlang) сейчас решит все проблемы. И идут читать доки, рассчитывая, что за них все уже сделали другие люди. В итоге человек читает все новые и новые мануалы, набирая технические знания, которые устареют через пару лет, но сам процесс работы выглядит как 10 лет назад.
Все это отлично, только иногда бывают такие случае — когда поддерживать такого рода легаси просто невозможно, ибо написано оно так — что вообще не позволяет расширять/изменять функциональность без полного переписывания этой каши. Тут то и уходит «понимание» к программисту писавшему это дерьмо.
На самом деле бизнесы ежедневно страдают от того, что код написан плохо — как минимум теряют деньги на переписывания говеных частей другими-новыми программистами. Это конечно контролируемый уровень затрат, но лично при мне компании теряли много денег — нанимая плохого программаста.
На самом деле бизнесы ежедневно страдают от того, что код написан плохо — как минимум теряют деньги на переписывания говеных частей другими-новыми программистами. Это конечно контролируемый уровень затрат, но лично при мне компании теряли много денег — нанимая плохого программаста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что делать с плохим кодом