Nicolette Jul 18 2010 at 18:19

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

7 min

2.5K

GTD*

Translation

+45

Comments 22

Vladson Jul 18 2010 at 19:02

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

UFO just landed and posted this here

sunnybear Jul 18 2010 at 19:33

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

-3

Nicolette Jul 18 2010 at 19:36

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

sunnybear Jul 18 2010 at 19:38

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

-1

Nicolette Jul 18 2010 at 19:43

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

sylvio Jul 18 2010 at 21:20

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

SeLarin Jul 18 2010 at 19:44

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

anaximen Jul 18 2010 at 22:24

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

Nicolette Jul 18 2010 at 22:53

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

anaximen Jul 18 2010 at 23:09

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

Nicolette Jul 18 2010 at 23:16

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

anaximen Jul 19 2010 at 07:23

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

Vladson Jul 19 2010 at 04:14

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

amlet Jul 19 2010 at 01:06

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

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

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

amlet Jul 19 2010 at 01:15

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

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

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

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

apollonin Jul 19 2010 at 01:19

#define TRUE (random()>0.5)

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

-3

ksdaemon Jul 20 2010 at 00:11

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

Nicolette Jul 20 2010 at 09:51

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

Throwable Jul 20 2010 at 10:55

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

Nicolette Jul 20 2010 at 12:28

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

Throwable Jul 20 2010 at 13:23

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

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

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

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

Show the best of all time