Комментарии 16
Это же про гейм дев?
В сфере бизнес приложений поверх понимания кода есть еще один уровень - это понимание бизнес процесса. Выглядит это так - пользователь пожаловался, что у него не печатаются этикетки, а в процессе раскапывания узнаешь об особенностях конфигурации бизнес процесса под конкретного клиента.
А код то в целом понятен. Каждый блок делает одну законченную вещь. Понятные входные/выходные данные. Без дублирования. Но из-за сложности процесса - тот или иной блок участвует в разных местах.
И, знаете, с недавних пор я стал не любить отсутствие дублирования - потому что когда вижуал студия подсвечивает 5 reference над методом - это означает вплоть до 5! потенциальных комбинаций, которые мне предстоит раскопать, чтобы выяснить почему этикетки не печатаются. И только один приведет к победе ?
Короче линейный лапшекод с дублированием - порой самый понятный код ?
Мало того: после раскопать ты потом задумаешься какой метод починки применить так, чтобы починить у этого конкретного клиента и не поломать у всех остальных, про которых ничего вообще не знаешь. И повезло тебе, если дело обойдётся простеньким IF'чиком (дай бог, если ты всего лишь пятый кто ставит там IF, а не двадцать пятый!) и то стоит молиться, чтобы у остальных ничего не упало. А, ну да - хорошо если всё это покрыто тестами и надо всего лишь починить неработающие и добавить новые.
В сфере бизнес приложений поверх понимания кода есть еще один уровень - это понимание бизнес процесса.
В разработке игр есть точно такой же уровень, но клиентом в этом случае выступает сам заказчик. Такая корпоративная биполярочка, когда разработчики игры, и разработчики движка это два не пересекающиеся мира, но могут сидеть одном и том же опенспейсе
...линейный лапшекод...
Я на этом месте чуть-чуть сломался, лапшекод линейным быть не может, потому-то он и лапшекод.
Проблема в том, что каждое дублирование кода, это место для потенциальных ошибок.
IMHO, различные комбинации – это следствие недостаточной атомарности функций.
Я автора хорошо понимаю, потому что есть аналогичный опыт отсутствующей документации и без онбординга, только не в геймдеве, а кровавом энтерпрайзе.
Но есть у меня и другой опыт, прямо противоположный и дело в том, что там тоже не всё гладко. Например, проект на 99% покрытый тестами (я не шучу), подробная документация сделанная аналитиками и грамотный онбординг от простых задач к сложным, с погружением в разные аспекты и нюансы. Нет проблем? Есть. Например, искать в огромной документации - это боль и отдельное искусство.
Но в целом статья толковая, заслуженный плюс.
Суровая реальность. Сложные проекты сложны не смотря на документацию и тестовое покрытие. И дообучение (онбординг) сениора, разучившегося учиться занимает несколько месяцев.
KISS
А это вы ещё не сталкивались, похоже, с Data Driven programming - когда именно совокупность, корректно, полнота и так далее входных данных определяют поведение программы. Причём эти данные и их состояние - это целиком на совести юзверей, не очень или совсем неграмотных в этом вопросе. Вот тогда приходится предусматривать самые разнообразные обходные решения и метаалгоритмы по приведение входных данных к единому знаменателю.
Добро пожаловать в реальный мир! Сколько бы умных дяденков, изучивших перед написанием кода 20-30 опенсорс движков в свое время, ни программировали бы свои движки, стараясь сделать все правильно, сколько крутых движков уже готовых ни было бы доступно, суть разработки одна - взять и сделать все неправильно, а потом, истязая себя, жить с этим и страдать каждый день. И бесполезно говорить начальству "давайте не будем так, ладно?". Раньше я интересовался вакансиями по разработке движков, но пройдя несколько собеседований, ни одна компания не смогла ответить на вопрос, а зачем им, собственно, собственный движок? Как я потом понял, что они страдают от этого, и постоянно приходится кого-то нанимать на эту грязную работу.
...а зачем им, собственно, собственный движок?
Я отвечу даже, если вам интересен ответ. Для других читателей.
Решение о разработке своего движка в компании принимается по определённым причинам. Одна из основных причин — чтобы не зависеть от других разработчиков. То есть чтобы новые фитчи в движке появлялись, или исправлялись ошибки, не тогда, когда захочет компания-разработчик движка, а сразу, как появляется задача в бэклоге. Ещё одна причина — чтобы не было сюрпризом, что теперь что-то не работает, или работает не так. Недавняя ситуации с Unity яркий тому пример. Руководство Unity в одностороннем порядке поменяла механизм монетизации, по которому стоимость лицензии движка вырастала динамически (и в некоторых случаях существенно), и сделать точный расчёт финансовых затрат уже было бы нельзя. Ряд разработчиков, использующих Unity заявили, что, если новая монетизация начнёт работу, то они просто обанкротятся. Сообщество разработчиков начало бойкотировать Unity. Кто-то начал переход на другие движки. Кто-то стал заниматься разработкой своего собственного
Не вижу ничего необычного. Особенно если это касается нешаблонных новых проектов. Часто заранее не известно, каким именно будет новый проект, во что выльется, как пойдет и пойдет ли вообще. У заказчика есть общая концепция, идеи, но нет конкретики. Можно, конечно, целый год составлять ТЗ, утопая в бесконечных согласованиях и спорах о деталях и архитектуре проекта... А можно быстро "на коленке" запустить хоть в каком-то виде проект, ввязаться в драку, и сразу смотреть, что из этого выходит, анализируя реальную информацию, реальные грабли. Да, лапшекод. Да, костыли. Но уже имеется рабочий проект и уже имеется информация для анализа - для принятия решений, куда двигаться дальше. Не предположительно, а осознанно.
Но как водится, дальше вступает в силу принцип: работает - не трогай...
По хорошему счету, такой подход предполагает в будущем полный рефакторинг проекта, но заказчики скорее смотрят в сторону дополнительного функционала, чем в сторону рефакторинга. До тех пор, пока лапшекод не станет стеной на пути развития проекта.
Если же начать сразу детально и глубоко разрабатывать архитектуру нового нетипового проекта в условиях неопределенности, то... вижу больше проблем, чем в быстрой "разведке боем"...
Еще момент. Надо учитывать, когда разрабатывался проект, в каком окружении. Если кто-то сейчас глянет на мой проект на джанго 15-летней давности, то он ужаснется, будет негодовать, рвать и метать... Но... надо просто откатиться на 15 лет назад и увидеть, что джанго тогда была еще в альфаверсии, 90% батареек и в помине не было...
В общем, в сабже не вижу ничего необычного. Да, проект требует рефакторинга. Но если бы не было быстрого запуска (пусть и с кривым кодом, написанным на колнке), то с весьма большой вероятностью и проекта бы не было, не выстрелил бы, утонул в согласованиях... и всё равно пришлось бы переделывать.
Спасибо за комментарий. У меня есть и такой опыт. Когда на коленке делают проект, чтобы посмотреть на первичный результат, а потом этот же проект, сделанный на коленке, запускается в полноценное плаванье без каких-либо изменений. Это грубейшая ошибка менеджмента. Это явные признаки жадного менеджмента.
Вы правильно описываете суть «проекта на коленке». В бизнес терминологии это MVP, и в MVP нет ничего плохого. Совсем. Я неоднократно делал MVP. Потому что я сам понимаю важность на практике увидеть результат. Возможно еще это связано с визуализацией результата, типа увидеть глазами хотя бы цифры в отчёте. Проблемы начинаются в тот момент, когда менеджмент отказывается переписывать MVP на нормальную архитектуру. Но и здесь по опыту не все так плохо. Даже не смотря на плохой код, есть способы и методы этот код привести в надлежащий вид. Проблема в этот момент связана с тем, что на MVP обычно не разрабатывают полноценную документацию. Документация есть, но обычно не на код, а проектная. И тем более нет документации на уже имеющиеся проблемы. И потому, когда приходит новый разработчик, которого наняли на волне увеличения численности команды разработчиков, так как проект вышел в полноценную работу, то новый разработчик долго входит в понимание кода. И я лично как раз на этой стадии. Есть места в кодовой базе на текущем месте работы, которые я понимаю, так как уже «прошёл» их. А есть те, которые меня повергают в ступор, так как я не вижу логики в них. Будто результат нейросетки. Всё как бы работает, но при попытке что-то изменить - ломается. И ломается вообще в другом месте, как раз там, где ломаться по логике не должно
Да, здесь наверно проблема недопонимания подводных камней со стороны заказчика и разного рода менеджеров. Их отчасти понять можно: вот ведь всё работает, даже лучше, чем ожидалось, глаза горят, начинают сыпаться предложения о расширении по разным направлениям, короче все полны энтузиазмом... В итоге сложно обьяснить, что текущий вариант быстро запиленного кода надо рассматривать, как экспериментальный и надо будет притормозить и выделить достаточно времени для серьезного рефакторинга. И лучше это сделать на ранних этапах, пока сервис еще не сильно нагружен, клиентская база небольшая. Но зачастую, чувствую, всё это пропускают мимо ушей, хотя внешне соглашаются...
Например, искать в огромной документации - это боль и отдельное искусство.
Документация это тот же самый код. Просто на другом языке. И если исходный-то код кривой, то какие основания полагать, что документация внезапно будет вся такая и хорошо структурированная, и понятная, и удобная, и вообще прелесть ?
Проблема понимания существующего кода, или Как делать иногда [не] надо