Было бы глупо спорить с тем, что писать хороший код — не правильно. Более того, внимательный читатель найдет среди моих прошлых статей целые серии статей а тему идеального кода. Но эту заметку я решил написать по причине того, что в последнее время очень часто сталкиваюсь с идеализацией процесса разработки и кучи советов в стиле «пофиг на все, главное — идеальный код». Далее несколько наблюдений и историй из жизни.
Аутсорсерам выгодно писать гавнокод
Что уж тут скрывать — большинство успешных компаний, работающих на локальных рынках — аутсорсеры, которые, как все знают, зарабатывают на оказании сервисных услуг внешним заказчикам. Если fixed price — ок, еще есть надежда, что код будут писать грамотно, но если time & materials…
Когда-то была такая ситуация: неделю делали один функционал, потом два дня переделывали, потом возвращали как было, а потом пришли спецификации. На мой резонный вопрос почему нельзя было подождать спеки а потом уже писать получил вполне резонный ответ: ты ж деньги получил и за то, что делал, и за то, что переделывал, почему ты не доволен?
Знаю случаи, когда разработчики умышленно в системе делали баги, чтобы потом получить дополнительно заказ на поддержку. А в одной из прошлых компаний товарищ назвал свою роль в компании как «bug maker»! Он этим очень гордился, т.к. не давал расслабиться еще 3 разработчикам и 2 тестерам 🙂
Пишите хороший код — вас могут уволить!
Звучит совсем чудовищно, но вам не показалось. Хороший разработчик и сильный архитектор — всегда (?) ценный сотрудник, но в некоторых случаях (например, во фрилансе или если вы подрядчик) от вас могут избавиться, как только вы сделаете всю сложную работу и обучите индийских обезьянок методически раскрашивать код в нужном порядке. Шучу? Нет.
А как же поддержка, новые разработки? Все очень просто. Очень многие компании живут за счет одного заказчика и делают все (абсолютно все), что он скажет, т.к. его уход == конец компании. Поэтому в такой войне все средства хороши. Зачем связываться с такими компаниями? Они в краткосрочной перспективе могут быть гораздо выгодней за счет жестоких дедлайнов, нехватки ресурсов и капризов начальства.
Рефакторинг ради рефакторинга
Пожалуй, проблема всех хороших (или потенциально хороших) разработчиков. Выбросить все и написать сначала! Добавим еще синдром «Not invented here» и получим полный набор проблем… для начальства и заказчика. Ведь разработчики во главе с тимлидом не бизнес проблему решают, а играют в игру под названием «идеальный код».
Писать гавнокод иногда нужно
Например, если вы пишите прототип, проверяете идею, занимаетесь Research & Development. В таких случаях идеальный код с трехуровневым ООП поверх TDD с эджайлом — скорее враг, чем помощник. Т.к. задача — проверить гипотезу, догадку, сэкономить время в будещем на исправление архитектурных или функциональных косяков.
Почему все-таки считается, что нужно писать иделальный код?
Аргументация тех, кто говорит, что нужно писать идеальный код, строится, чаще в всего, на том, что плохой код в будущем трудно сапортить. Ментальная ошибка в том, что чаще всего код не нужно поддерживать или нужно будет поддерживать не вам. Поэтому с точки зрения бизнеса написание идеального кода — лишняя трата времени и ресурсов.
В одной из компний перед тем как садиться писать оценку проекта и комерческое приложение, я (в обход начальства) всегда спрашивал у заказчика: выберите желаемый тип оценки среди трех вариантов — «подешевле, но побыстрей», «работает — донт тач», «делаем как надо». В зависимости от желания клиента бюджет вырастал в 2-5 раз, но зато я сразу четко понимал, как мы будем писать.
Вторая проблема — постоянная неудовлетворенность разработчика своим кодом. Месячный код хочется сжечь, полугодичный — съесть, из-за кода, написанного 3 года назад, хочется кого-то убить. Не дайте Астронавтам Архитектуры вас запугать!
Не нужно писать говнокод умышленно
Только по расчету!
В одном проекте для очень именитого заказчика в начале работы не было требований по поводу code conventions. Собственно, не поддавшись на такую халяву, в команде были установлены вполне конкретные жесткие правила + регулярный код ревью. В итоге, за неделю до сдачи проекта заказчики таки раздуплились и выкатили code conventions, что ввело в ступор начальство (ну и меня тоже, т.к. сдавать продукт нужно было мне). Но за счет контроля с самого начала проекта все доработки заняли максимум день.
В общем, у каждого свои примеры и антипримеры, но, думаю, все согласяться, что разработчик, а там более профиссиональный, должен быть прагматиком, и лишь потом архитектурным астронавтом или поклонником идеально чистого кода.
Заставьте себя написать хотя бы один проект «правильно», и потом вы просто не сможете это делать по другому 😉
Спасибо за внимание и белоснежного вам кода!
ссылка на оригинал статьи http://habrahabr.ru/post/167877/
Добавить комментарий