Здравствуйте, Нomunculus, Вы писали:
Н>Отмаза. Обычно говно-код дает говно-результат.
Совершенно не обязательно (или, если быть более точным, обычно никто и не рассчитывает на что-то более интересное, чем говно-результат).
На самом деле 1) люди не умеют писать новый код 2) бизнес боится писать новый код
Обычно правильным путем считается найти в интернете что-то похожее на то, что требуется написать, и напильником довести. Вот так взять и написать с нуля тысяч несколько десятков строк нового кода — скажи такое менеджеру, он поседеет.
Ну и результат предсказуемо соответствующий. Но поскольку он ожидаемый, никто особо и не расстраивается.
Re[3]: Хорошее объяснение природы возникновения говнокода
Здравствуйте, ути-пути, Вы писали:
УП>Смотря какой результат тебе нужен. Быстрый и качественный код гораздо менее важен, чем доходы бизнеса здесь и сейчас. А завтра часть этих доходов можно пустить на разгребание говна.
Но никто никогда не пустит.
Re[2]: Хорошее объяснение природы возникновения говнокода
Здравствуйте, Pauel, Вы писали:
P>Сейчас до сих пор нет внятных стандартов на написание кода. Думаю, это не скоро появится.
В мире Go эти стандарты 1) есть 2) энфорсятся тулингом. Как результат, код на Go в целом довольно приличный.
P>Что делать, когда они оба считают подход друг друга говнокодом?
Уволить обоих.
Первый, очевидно, не может ясно сформулировать, что его маленькие функции делают — поэтому приходится прыгать по файлам, чтобы понять полную картину происходящего. Если название, проторип и описание функции ясно и точно объясняют, чего она делает, зачем я в нее буду смотреть, пока не заподозрю, что в ней самой какая-то проблема.
Второй, очевидно, не может ясно сформулировать, чего его большая функция делает — поэтому ее трудно тестировать и использовать.
Каждая функция должна делать одно какое-то контретное и понятное дело. Тогда ее и использовать просто, и тестировать, и размер определяется этим требованием.
Re: Хорошее объяснение природы возникновения говнокода
Здравствуйте, Shmj, Вы писали:
S>Основа проекта выполняетя на говнокоде творческими ребятами — иначе будет слишком долго и никому не нужно. Тут работа на результат.
Смешно. Если продукт нужен, то им будут пользоваться, даже если он плохого качества. Если продукт не нужен (так как такой уже есть, например), то тогда им могут воспользоваться только если он хорошего качества. А вариант "слишком долго и никому не нужно" — это про инвесторов, а не про программирование. Если инвестор видит, что продукт пользуется успехом, то его аж на другой язык перепишут, если надо.
S>Далее, когда проект прошел все этапы становления — уже нанимают ремесленников, работа которых разгребать говно за первыми ребятами, у которых получилось.
Чушь. Чаще бывает иначе: продукт не пользуется успехом и менеджеры считают, что это из-за ошибок "творческих ребят". Поэтому нанимают "ремесленников, работа которых разгребать говно за первыми ребятами". (Тут надо понимать, что "ремесленники" тоже могут оказаться "творческими ребятами", тогда, если у менеджеров ещё остались деньги, то они могут набрать новых "ремесленников" ещё раз). В результате, даже готовый и хорошо написанный продукт могут выкинуть (если он никому не нужен), но чаще продукт выкидывают сразу после "творческих ребят".
S>Ремесленики, конечно, считают что они умнее, ведь первая категория ребят не способны так высококлассно писать. Однако эта умная категория годится только разгребать говно — что-то с нуля они сделать не смогут — это будет несовместимо с жизнью, несовместимо с бизнесом.
Зачем бизнесу тратить много денег на высококлассных специалистов, если не понятно, нужен ли этот продукт или нет. Поэтому сначала ставят опыты на "творческих ребятах", а потом уже можно и высокооплачиваемых нанять, если проект взлетит.
Однако бывает, что и высокооплачиваемые всё портят, но уже по другим причинам...
И каждый день — без права на ошибку...
Re: Хорошее объяснение природы возникновения говнокода
Давным-давно, когда доллар стоил около 30 рублей, я работал в компании, которая захотела нанять белорусов. Оказалось что топовые разработчики в Беларуси, которые получали ЗП в баксах, были дешевле мидлов в Москве. Взяли в итоге двух, чуть ли не самых крутых спецов в нашей области, сманив из какого-то интегратора. Чтобы проверить их уровень дал им тестовое задание: надо было синхронизировать дерево OU из AD в базу данных через АПИ системы, с которой мы работали. Узлы которые добавились — добавить, которые переместились — переместить, а удаленные из АД пометить неактивными в целевом дереве. Я такой код писал на повершелл, уложившись в 40 строк. По условию задания этим товарищам надо было написать аналогичный код на C# и оформить его в виде периодически запускаемого задания целевой платформы. В сумме от силы строк 100 получилось бы.
Писали они неделю. Через неделю выдали 400 строк кода (по метрике VS), там было около 10 классов. У каждого класса был базовый абстрактный класс и интерфейс. Тестов, как ни странно, не было, но они сказали что с тестаи не успели бы сделать. Фактические каждая операция обхода и присвоения полей элементов дерева была оформлена в отдельный класс. С DI они тоже не заморочились, так как тоже было бы слошком долго, поэтому в корневой функции был гигантский new с созданием и подстановкой 100500 объектов и кучей закомментированного кода для тестирования.
Но самое главное: в коде не было операции сохранения данных в базе, а алгоритм обхода не учитывал перемещение узлов в исходном дереве. С точки зрения архитектуры целевой платформы были выбраны не самые подходящие компоненты для развертывания. То есть код фактически не делал то, что надо. тем не менее все гайды и бестпрактисы были сюблюдены, GOF и SOLID в полный рост.
Теперь у меня вопрос — что есть "говнокод"?
Я из своей практике могу сказать что "говнокод" это когда код делает то, что не требуется, но не делает то, что требуется. Это касается как вопросов анализа требований, архитектуры программы и быстродействия.
Если код делает то, что требуется, то это уже не "говнокод", а "код который можно улучшить, но и так сойдет". Большая часть кода, который вы встретите в своей жизни это код разряда "и так сойдет".
Причина появления настоящего "говнокода" это всегда сочетание минимум двух из трех факторов: плохое понимание задачи (что делать), плохое знание инструментов (как делать), плохая мотивация (зачем делать). Менеджмент, сроки и другие внешние факторы не при чем.
В моем примере именно мотивация подвела белорусов, они больше хотели показать себя знания ООП, а не умение решать задачу. Но и два других фактора тоже сыграли.
