Pull to refresh

Об идеальном коде и суровой реальности

Reading time 3 min
Views 68K
Думаю, никто не будет спорить, что программный код должен быть чистым и «не пахнуть» (code smell), а паттерны проектирования и TDD должны стать верными спутниками любого мало-мальски грамотного разработчика на протяжении его нелегкой, но продуктивной карьеры. Все также знают, что цена ошибки в продакшине возрастает в десятки раз, а также то, что хорошие программисты оптимизируют код, а плохие — покупают новые сервера, а еще то, что 9 женщин не родят одного ребенка за месяц.



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

Аутсорсерам выгодно писать говнокод


Что уж тут скрывать — большинство успешных компаний, работающих на локальных рынках — аутсорсеры, которые, как все знают, зарабатывают на оказании сервисных услуг внешним заказчикам. Если fixed price — ок, еще есть надежда, что код будут писать грамотно, но если time & materials…

Когда-то была такая ситуация: неделю делали один функционал, потом два дня переделывали, потом возвращали как было, а потом пришли спецификации. На мой резонный вопрос, почему нельзя было подождать спеки, а потом уже писать получил вполне резонный ответ: ты ж деньги получил и за то, что делал, и за то, что переделывал, почему ты не доволен?

Знаю случаи, когда разработчики умышленно в системе делали баги, чтобы потом получить дополнительно заказ на поддержку. А в одной из прошлых компаний товарищ назвал свою роль в компании как «bug maker»! Он этим очень гордился, т.к. не давал расслабиться еще 3 разработчикам и 2 тестерам :-)

Пишете хороший код — вас могут уволить!


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

А как же поддержка, новые разработки? Все очень просто. Очень многие компании живут за счет одного заказчика и делают все (абсолютно все), что он скажет, т.к. его уход == конец компании. Поэтому в такой войне все средства хороши. Зачем связываться с такими компаниями? Они в краткосрочной перспективе могут быть гораздо выгодней за счет жестоких дедлайнов, нехватки ресурсов и капризов начальства.

Рефакторинг ради рефакторинга


Пожалуй, проблема всех хороших (или потенциально хороших) разработчиков. Выбросить все и написать сначала! Добавим еще синдром «Not invented here» и получим полный набор проблем… для начальства и заказчика. Ведь разработчики во главе с тимлидом не бизнес проблему решают, а играют в игру под названием «идеальный код».

Писать говнокод иногда нужно


Например, если вы пишите прототип, проверяете идею, занимаетесь Research & Development. В таких случаях идеальный код с трехуровневым ООП поверх TDD с эджайлом — скорее враг, чем помощник. Т.к. задача — проверить гипотезу, догадку, сэкономить время в будещем на исправление архитектурных или функциональных косяков.

Почему все-таки считается, что нужно писать идеальный код?


Аргументация тех, кто говорит, что нужно писать идеальный код строится, чаще всего, на том, что плохой код в будущем трудно сапортить. Ментальная ошибка в том, что чаще всего код не нужно поддерживать или нужно будет поддерживать не вам. Поэтому с точки зрения бизнеса написание идеального кода — лишняя трата времени и ресурсов.

В одной из компаний перед тем как садиться писать оценку проекта и комерческое приложение, я (в обход начальства) всегда спрашивал у заказчика: выберите желаемый тип оценки среди трех вариантов — «подешевле, но побыстрей», «работает — донт тач», «делаем как надо». В зависимости от желания клиента бюджет вырастал в 2-5 раз, но зато я сразу четко понимал, как мы будем писать.

Вторая проблема — постоянная неудовлетворенность разработчика своим кодом. Месячный код хочется сжечь, полугодичный — съесть, из-за кода, написанного 3 года назад, хочется кого-то убить. Не дайте Астронавтам Архитектуры вас запугать!

Не нужно писать говнокод умышленно


Только по расчету!

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

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

Заставьте себя написать хотя бы один проект «правильно», и потом вы просто не сможете это делать по другому ;-)

Спасибо за внимание и белоснежного вам кода!
Tags:
Hubs:
+75
Comments 101
Comments Comments 101

Articles