Говнокод или суперархитектура? Сначала говнокод, а потом эволюционный рефакторинг!

Да ничего не узнаётся. Не знаю, откуда авторы берут рассказы про проекты, в которых код либо изначально правильный, либо становится таким эволюционно. Не бывает таких.

так это нормальный, опытный подход к разработке. быстрое прототипирование (говнокод) и последовательное улучшение с рефакторингом почаще.
«все сразу по правильному» — делается только при избытке бабла, и то не всегда оправдывается.
действительно узнается, классический пример фейсбук — чтобы идея заработала достаточно было говнокода в первой версии.

На рефакторинг как раз время не остается, если всегда пытаться делать хорошо. Такой вот странный парадокс. Пример с меню из статьи очень хорошо показывает, что иногда нет смысла что-то делать на отличненько, пока не станет понятно, что это действительно нужно. А то получится, что сделали не просто хорошо, а великолепно, но это нафиг никому не нужно.

Другими словами, идеальный код, как бы грустно это не звучало, противоречит требованиям бизнеса. Бизнес продает решение, а не качество кода. Качество помогает в высококонкурентной среде, и стремиться к нему нужно, но никогда не перегибать палку.

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

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

Такую фигню можно сколько угодно генерировать:

Вася и Петя одновременно начали писать один и тот же продукт.

Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру. А Петя начал решение задачи с описания продукта со стороны пользователя, потом сделал тесты, и только потом начать писать. Писал не больше и не меньше, а ровно столько, чтобы все тесты прошлись.

Чтобы выйти на рынок раньше, Петя выделил необходимым минимум и сконцентрировался на нём, в то время как Вася говнокодил без плана в голове.

На удивление Васи, Петя вышел на рынок раньше. Во-первых, autotest сэкономил Пете дни, которые Вася тратит на ручное тестирование после каждого сохранения. А, во-вторых, упавшие тесты и незачёркнутые пункты в туду чётко показывали Пете где финиш. Поэтому он двигался намного быстрее, чем Вася, у которого постоянно то там, то там что-то отваливалось, света в конце тунеля не видно, и от того опускались руки и запускался контр-страйк.

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

Они вышли на рынок с небольшой разницей, несмотря на то, что Петин интерфейс был более продуманным и привлёк больше пользователей, оба не угадали, и пошел фидбек.

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

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

Нет, Вася не винит себя, он винит судьбу. Ну почему ему не попался тот «Петя», который перфекционист и идеалист, с которого все ржут? Почему ему попался практичный Петя, который с умом и в меру использовал известные практики, тем самым оставив говнокод Васи далеко позади?

Про тесты. Я считаю, критические места должны быть покрыты тестами (отправка заказа, логи платежей и тд), а на каждый чих тест на первом этапе не нужен — YAGNI. Но не всегда это возможно.

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

Что делать, если результат надо отдать конечному пользователю на web-странице?

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

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

Как пример, нам достался проект считалки хайлоад. Разработчики там хранили уникальные айди юзеров как комбинацию куки и еще других вещей хз где, а потом для повышения производительности «отрефакторили», что записываться айди стал в мемкешд. А че, типа быстро работает. То, что такое ACID и что мемкешд стирает ключи в процессе работы — ну не бд это, как, видимо, думали — это не про наших парней.

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

И таких примеров море. Эффект Даннига-Крюгера в действии

Невозможно получить качественный продукт, постоянно экономя на качестве

Пока вы делаете качественный 3 года, конкуренты сделали «средненько» за год. Да много недовольных, но паровоз уже поехал. Через 3 года вы закончите первую итерацию, а ваш конкурент, делавший «ширпотреб» прошел уже 3 итерации, и бабок нарубил и клиента лучше понимает.

Вот если вы выходите на более-менее стабильный рынок со стратегией «порвать конкурентов качеством» тогда да. Только так.

Автор не указал главного: если система написана модульно (на примере XAML — каждый блок интерфейса вынесен в user-control, имеет понятный интерфейс и простой код для связи этих блоков), то легко экспериментировать, перетасовывая блоки и подкручивая их параметры.

Если всё написано одним большим блоком говнокода, чтобы перенести поле ввода на 30 пикселей выше и ничего не поломать, надо час времени.
Это будет сильно сдерживать эволюцию проекта, программеры будут сопротивляться внесению изменений.

Руководитель проекта должнен хорошо чувствовать границу в эволюции проекта, до которой говонокод разрешен, и после которой говнокод запрещен.

Иначе получется ситуация: «Пока можно говнокодить… все еще можно… еще немного поговнокодим… Ааааа… Покатился снежный ком говнокода и похоронил проект.»

Роберт опытен и многое предвидит.

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

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

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

А лучший способ влезть в шкуру клиента и понять его задачи — дать ему пластелин, чтобы он сваял макет. А потом вы ему из золота (чуть не написал «гранита») отольете его протип.

Но тратить золото (время программистов и других специалистов) на задачи, которые решает пластилиновый протип, имхо неверно.

Так что на сотой итерации должен быть крутой код

Если его нет, вопрос qa

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

Говорят, он стал лучше.

Но чем прет Симфони — бери и юзай отдельные куски. Философия Юникс в действии. SOLID, low coupling, high cohesion — все давно известно.

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

Хотя фреймворк, если на нем все писать, достойный

Значит, надо на говнокоде понять, какие требования к проекту и нанять других программистов, которые по этим требованиям напишут красивый код

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

Мне, почему-то, всегда казалось, что просто кодить, пусть и качественно, не поднимая головы и не интересуясь о чем думают коллеги, ПМ, QA и даже заказчик, — это крайне безответственно.

Так всегда и бывает, у хорошего программиста всегда идет background refactoring.

Вообще, это очень многогранная проблема. Мой опыт отличается от вашего, обычно либо «правильно и долго», либо «неправильно и долго». Поэтому для решения бизнес-задач и появилось чередование «быстро и неправильно» с «долго и правильно».

А аспекта два. Первый — это заблуждение людей, что они могут сделать правильно. Простой пример — на собеседовании спрашиваю, что такое инкапсуляция. Человек уверен в себе и читает определение. Теперь прошу пример из жизни — молчит. Вы рулите машиной, не видя деталей ее реализации, а имея только интерфейс. И человек смущается, понимания нет. И добиваю — ну окей, разобрались что это, а зачем оно? и вот ответ осмысленный, типа чтобы не порождать неявных зависимостей и кривой граф циклический, или чтобы состояние объекта кто угодно извне не менял (вечный спор геттеры и сеттеры против паблик), способны дать немногие

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

То есть имеют инструмент, но все за и против не взвешивают, что дает overengineeering, а потом нежелание менять слишком рано усложненный код.

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

Если вы объяснили разработчикам, что нужно меню версткой потестить, а они ушли на неделю делать компонент в библиотеку, то в консерватории что-то надо менять.

И обратно, если вы уже нашли нужный функционал и попросили запилить стабильно, чтобы оно работало, а люди тестами не покрыли и оставили говнокод, это писец

То есть я согласен, что нужно думать

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

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

Это трудно сразу принять, меня год учили этому хорошие учителя, спасибо им.

Почему-то часто встречаю альтернативы — сделать «неправильно и быстро» или «правильно и долго». На практике же это часто выглядит как сделать «неправильно и долго» или «правильно и быстро».

Такое бывает, когда в команде есть принципы, из-за которых кода пишется больше, а это делать лениво.

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

Ещё пример: вместо того, чтобы разобраться с какой-то тонкостью ORM, пишем прямой SQL. Сиюминутно быстрее, в будущем сложнее рефыакторить

Другой пример. Принято использовать паттерн MVVM, но вот что-то не придумывается сходу, как через binding сделать. Надо гуглить, думать или читать исходники компонента. Вместо этого пишется небольшой костыль, выполняющий бизнес логику не в Presenter, а во View. Проблема решена, закоммитили, забыли. Затем этот Presenter подсунули другому View — костыль придётся копипастить.

говнокод может быть приемлем только там, где он может быть локализован

+100. Один из способов я предлагал в прошлом топике. Пускай не покрывать код тестами, но писать его имея тесты в ввидую Постоянно думать «как я это буду тестировать»…

На мой взгляд, при минимальном планировании, такие вещи как меню изменяются не часто. Предварительно нужно продумать все «за» и «против», сделать прототип, оценить…

Так что в данной ситуации, похоже, конкуренты имеют преимущество.

Опечатки не успел поправить :)

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

Самое смешное, что легко называть чужой код говнокодом.
Так же после вас придёт поколение поддерживать, что вы написали, и так же будет плеваться: «наговнокодили, а нам теперь всё переписывать и рефакторить» ))

Эх, если бы «владельцы» госпроектов относились к ним как многие стартаперы к своим, никому ненужным проектам…

взяли у государства миллиард и пишите почту России то подход должен быть с большим колличеством метрик.

Скажите честно, вам приходилось работать с госструктурами? (я про РФ, конечно)

По-моему, речь о возможности по разному писать код в пределах каждой итерации. Допустим решили сделать в текущей простое плоское меню на HTML, только навскидку 5 вариантов:
— жесткий хардкод в шаблоне. Максимум урлы хелперами генерируются. Добавить пункт меню — нужно ручками в исходниках писать теги li, а, может img и т. п.
— какой-то захардкоженный массив, который в шаблоне циклом выводится. Добавить пункт — элемент в исходниках в массив добавить, возможно перекомпилировать, в любом случае деплоить
— то же, но файлик или таблица в БД, откуда массив заполняется. добавить пункт — файлик отредактировать или табличку, в исходники лезть не нужно
— то же, но есть полноценная админка
— автоматически формируемое меню на основе списка подключенных модулей, к каждому модулю добавляется метаинформация о его отображении в меню или для отображения используется существующая метаинформация.

При этом ещё любой пункт может быть сделан качественно (покрыт тестами, задокументирован, тщательно подобраны имена сущностей, отмечены будущие возможные todo и т. п.), а может быть сделан по принципу «лишь бы работало» (тестов нет, документации нет, имена типа a1, a2 и т. п.), а может только частично за качеством следили. В общем вариантов масса и какой из них счесть «минимально необходимым» напрямую к Agile не относится, это вопрос QA.

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

Рефакторинг нужно проводить непрерывно. Три недели разрабатываем, неделю рефакторим — это не самый удачный подход. Удачный — сделали фичу (задачу), отрефакторили тесты, отрефакторили код. Время на рефакторинг закладывается при оценке задачи, точно так же, как и время на написание тестов.

Все зависит от точки зрения, что именно считать говнокодом. Для меня говнокод это не тот код, который написан в спагетти-стиле, а тот, который не решает поставленную задачу. Я видел немало людей, которые увидев тот подход, который мы используем, и тот код, который мы пишем, говорили одну фразу: «Что за говно?». Зато я точно уверен, что с поставленной задачей мы справляемся на ура.