[не3доровые_асс0циацыи]

Во время разгребания репозитория мне было видение.
А именно - стартап является организацией, которая получает кратковременное преимущество через вынос энтропии в будущее

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

Но потом начинается долгосрочный период, и с кодом нужно знакомить как новых сотрудников, так и олдам вспоминать, а зачем в функции X прокидывается параметр Y. Причем документация - это не только отчеты (их все равно читают только в самых экстремальных ситуациях). Документацией здорового человека может быть упоминание в коммите номера задачи в таск-трекере или подробный и соответствующий спеке JSDoc.

А копипаст компонентов выстреливает…ну, например, раздуванием базы кода и необходимостью одновременно вносить точечные правки сразу во все связанные модули.

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

@темы: кодерастия

Comments

[RBS_Vader]

Ну тащемта, такова любая организованная жизнь.

[не3доровые_асс0циацыи]

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

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

В том плане, что вотерфолл и аджайл - это один и тот же цикл принятия решений, но с разной "тактовой частотой". Кстате, OODA сюда тоже подходит.

P.S.
Сорри за некоторую сумбурность, много впечатлений, часть из которых "ну вот сейчас" нужно выгружать в коде + на мне висит вероятность участвовать в формировании и техлидстве новой команды

[Солнечный ветерок]

[L]не3доровые_асс0циацыи[/L], По своему опыту могу сказать вот что:
1. Отказ от документации это плохая затея. Когда сталкиваешься с разработкой, по которой документация в стиле "лишь бы приняли" или вообще не соответствует коду, очень много времени приходится тратить, что бы понять как это работает. То есть увеличивается время на поддержку, которая как правило бесплатная или не сопоставима с затратами заказчика на саму реализацию. То есть ты выкидываешь очень много денег просто в унитаз просто потому что не соизволили сделать нормальную документацию.
2. Есть другая крайность, которая встречается даже совместно с первой. Это  избыточность документации. Когда в документацию забивают куча воды или информации, которая там не нужна или изменчивая. Поэтому документация обязательно нужна, но надо соблюдать разумную меру, что бы она отражала суть процесса, но не содержала мусора.
3.  Реализация каких то фич без согласованной документации, черевато тем, что в процессе заказчик передумает и время будет потрачено впустую. Но мало кому удается так построить работу, что бы исключить данную проблему.
4. Отказ от проектирования затея совсем плохая. Некоторые руководители попадаются на кажущуюся оптимизацию процесса. Но в итоге это выливается в огромные затраты на поддержку и вероятное переделывание за всего проекта.
Я с таким встречался, поверь, заканчивается только проблемами. Копипаст кода конечно иногда можно использовать, но чаще это копипаст плохого кода, на который наворачивается гора костылей. А потом всех задалбывают недовольные пользователи ПО, что выливается в траты и экономически и репутационно.
5. Что такое "годный код", и как его писать, это вообще понятие субъективное.
Нельзя найти на все задачи суперспециалистов. Крутой специалист не будет заниматься мелочевкой, это не рентабельно.

Эджайл, как по мне, это просто способ корректно послать заказчика в ж...у.
Помню от некоторых кадров фразы "Да, у нас не работает, это будет исправлено с следующем спринте". И заказчик думает "Ну да, у них же спринт, это круто. Не понимая, что его тупо послали."
Но некоторые думают что задачи типа "Аааа, срочно надо вот этот отчет переделать..." и эджайл могут сосуществовать. Я подозреваю, что оно несовместимо. И получится не эджайл, а недоэджайл со снижением производительности покруче чем вотерфол.  

[Солнечный ветерок]

[L]не3доровые_асс0циацыи[/L], Кстати, если интересно, как раз недавно размышлял на предмет стиля кода разных разработчиков.
Вот здесь: dybr.space/blog/solar_wind/5312042?scroll=true

[не3доровые_асс0циацыи]

2Солнечный ветерок, Меня впечатлили такие темы, как openApi и graphQL. Потому что единый формат как для бэка, так и для клиента + возможность расширять уже существующие эндпойнты в рамках спеки.
+ То, что все это легко интегрируется в IDE и позволяет понять, что делает тот или иной метод, просто подведя курсор. Swagger тоже близко к этой теме, но так вышло, что я с ним работал меньше, чем с openApi или GQL, а потому прокомментировать не могу.

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

Если добавить автогенерацию отчетов (есть скрипты, которые, к примеру, на базе jsdoc рождают годный отчет в маркдауне), то это закроет и потребности анализа. Но да, тут будут издержки на управление этим процессом, написание конфигов и скриптов, которые крутят всю цепочку от скачивания спеки до создания

+ Если код специфический, то матмодель к нему лучше описать отдельно. Потратить страницу на katex с описанием дифуров, например