Код, который невозможно поддерживать (часть 3, заключительная)

[@Vladson]

№4 встречал в практике не редко (и не только программисты против тестирования, чтоб босс не наругал, но и босс против, чтоб не финансировать бесполезную трату времени недо-людей которые могут быть и не программисты даже)

[@sunnybear]

непонятно, это «плохие» советы или хорошие?

[@Nicolette]

Совсем-совсем непонятно? Ни по смыслу, ни по тэгам «вредные советы» и «сарказм»? :-(

[@sunnybear]

например, насчет обработки аппаратныъ исключений можно холивар развернуть — как их тестировать да еще и автоматически прикажете?

[@Nicolette]

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

[@sylvio]

В песочнице, как еще, bochs в руки и вперед

[@SeLarin]

Советую еще первые две части почитать, если есть сомнения. ;)

[@anaximen]

Раньше были посты про то, как писать хороший код! Вот уже третья часть о том как писать плохой. Про хороший мне нравилось больше.

[@Nicolette]

Инвертируйте советы, только и всего.

[@anaximen]

из советов «как не делать», сложно получить однозначное «как делать». Но в целом почитать можно. Главное чтобы это не вошло в моду. А то может получиться что папа алкаш скажет сыну алкашу «а вот так, сынок, делать не надо!» :)

[@Nicolette]

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

[@anaximen]

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

[@Vladson]

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

[@amlet]

Что-то как-то первые 2 части вроде без воспоминаний прошли, а тут автор, как в воду глядел:

6. Избегайте библиотек

Ну прямо как в компании, из которой я месяц назад свалил. Да и над заменой TRUE на FALSE у нас разработчик один очень часто шутил… Наверное где-то такое он всё же использовал.

[@amlet]

P.S. Кстати, шутки шутками, а ведь приколы а-ля TRUE/FALSE были только не такие очевидные. Вот вспомнил несколько примеров:

double GetWidth()
{
return _dHeigth;
};
double GetHeight()
{
return _dWidth;
};

а в некоторых местах было прямое обращение к _dHeigth и _dWidth, потому что они были public, и вроде как «все» знали про то, что они перепутаны где-то в самом начале были… Помню так огрёб с этим приколом, что вот сейчас вспомнил и всего аж трясёт!

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

[@apollonin]

#define TRUE (random()>0.5)

Вот это реально весело =)

[@ksdaemon]

Мне больше всего Эпилог понравился Ж)
А так — как бы ни было это смешно и весело, но когда встречаешься с таким в жизни — улыбка как-то очень быстро пропадает.

[@Nicolette]

Это вполне естественно — текст я только переводила, а эпилог — писала сама :-)
Затем и написано, чтобы читатель хотя бы сам так не делал.

[@Throwable]

Это все хорошо, но как это ни странно звучит, данный гидлайн — пособие как заработать минимум денег при максимуме работы. Моя практика показывает, что если у клиента все будет работать «как надо», то клиент к Вам больше не обратится. Естественно, у клиента что-то все-таки должно работать. Но вот беда, если изначально в цену засандалишь все затраты на тесты, рефакторинг, коментарии и все прочее о чем тут писалось, просто провалишь тендер. Клиент скажет: «Вася Пупкин Консалтинг делает дешевле» и точка. Качество работы — не объективный показатель при заключении сделки. Чаще всего выигрывается тендер, заключается контракт, клиенту предоставляется первая рабочая, но сырая версия системы, не лишенная недостатков. Далее исправление ошибок, доработка, доводка техзадания — за отдельную плату. А то, что у вас в коде нет комментариев, гарантирует, что клиент для второй фазы обратится к Вам.

[@Nicolette]

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

[@Throwable]

В таком случае у Вас есть риск сорвать проект. Согласитель, что накладывание жестких дополнительных требований (таких как полный тестинг, документация, коментарии, etc...) повышает объем работы, увеличивает риски, а соответственно, и стоимость проекта. Но на такую вещь как риски далеко не все смотрят и не умеют их оценивать. Скажем, непрофессиональный подрядчик может неправильно оценить проект, поставить заведомо низкую цену и выиграть тендер. Когда же обнаружится, что это недоделка, и объем работ сильно превышает запланированное, он просто откажется дальше делать (ему просто это будет не выгодно). А суды, согласитесь, не лучший результат для исполнительного директора.

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

Поэтому обычно закладывают, если объем незапланированных работ не превышает 10-15%. Если больше, то за пересматривается цена. К этому должны быть готовы как подрядчик, так и заказчик.

Есть еще модель, в которой с подрядчиком помимо разработки заключается договор на обслуживание системы. Часть денег снимается а разработки и раскидывается на поддержку. За фиксированную плату в месяц он обязуется оперативно исправлять все возникшие инциденты. Это хорошо тем, что ответственность ложится на самого разработчика (ему выгоднее делать хорошо), и за фиксированную плату заказчик гарантирует себе функциональность с минимальными рисками.