Комментарии 126
Думаю, многие стартапы идут путем переписывания спагетти-кода и выстраивания процессов, когда стартап уже выстрелил. Потому что написание плохого кода по-быстрому в начальном этапе обходится дешевле. В начале для создателей стартапа самая приоритетная задача, это когда кликаешь всё заработало. А об улучшении системы задумываются только, когда начинаются проблемы и торможения.
У кого-то может это и работает. Я подрабатываю сейчас на стартап, шестой год идет коду, функциональность расширена процентов так на 500 за это время. Автотесты и гит были со второй недели - стало ясно, что иначе добром это не кончится. К чему это говорю - "выстрел" может случиться через годы, и тогда писать тесты с нормальным покрытием будет в разы сложнее (особенно когда сверху давят расширять функционал итп).
Потому что написание плохого кода по-быстрому в начальном этапе обходится дешевле
Давайте уточним. Не написание плохого кода, а найм говнокодеров. Нет такого принципиального закона природы, согласно которому писать говнокод быстрее, чем писать по-человечески. Профессионал пишет чисто и быстро даже в условиях недостатка информации - на то он и профессионал. А вот нанять вместо профессионала черт знает кого - это у стартаперов всегда пожалуйста.
В условиях недостатка информации даже профессионал напишет говнокод. Не потому что он так хотел, а потому что он писал чистый код по другой постановке.
Банальное разделение по функциям/классам мог сделать исходя из других соображений. А когда другой разраб будет вносить правки в этот код по уже другой постановке, то уже и будет "что за говнокод тут написан, ведь теперь фиг поправишь быстро"
Недостаток информации, это просто понимание, что потом надо будет этот код развивать. В общем это та ситуация в которой все разработчки и живут. С этими вводными можно написать хороший код, который будет решать текущую задачу и готов к изменениям. Да через полгода этот код может стать плохим, но это не значит, что сейчас его надо делать плохим прямо здесь и сейчас.
> Банальное разделение по функциям/классам мог сделать исходя из других соображений
Если вообще не угадали, то код который разбит на модули переписывать намного проще, чем код написанный одной функцией.
А если почти угадали, то разница между обновить модульный код и спагети будет просто огромной.
Если вообще не угадали, то код который разбит на модули переписывать намного проще, чем код написанный одной функцией.
Это в случае, если код разбит так, что его действительно можно изменить под новые требования.
Читаемость очень сильно коррелириет с цикломатической сложностью. А сложность с разбиением на модули.
Код разбитый на модули обычно легче читать. Так что, его легче переписывать, чем портянки на тысячи строк.
Тут еще важна глубина разбиения. Если на нижнем уровне маленькие атомарные функции специфичные для данного бизнес домена, то шанс что они без изменений найдут место в новой архитектуре выше.
Нет такого принципиального закона природы, согласно которому писать говнокод быстрее, чем писать по-человечески.
При нехватке ресурсов (то есть почти всегда) часто возникает вопрос, как решать в данный момент возникшую проблему, быстро или качественно. Я не стал бы это возводить в ранг закона, это просто неизбежность.
По-моему профессионализм не в том, чтобы всегда писать идеальный код, а в том чтобы правильно определить, что именно необходимо в данном случае и реализовать это.
а в том чтобы правильно определить, что именно необходимо в данном случае и реализовать это.
Об этом за программиста подумает менеджер и потом несколько раз передумает. Поэтому программисту придётся писать плохой код, там где надо писать хороший.
При нехватке ресурсов (то есть почти всегда) часто возникает вопрос, как решать в данный момент возникшую проблему, быстро или качественно
Формально вы правы, но после 10 лет в отрасли я не представляю ситуацию, когда я скажу "ок, времени нет, давайте напишем тут спагетти-функцию на 2к строк без всякой структуры и с всратным неймингом". Все эти DRY, KISS, YAGNI, GRASP, SOLID после какого-то порога опыта уже на кончиках пальцев. Сразу пишешь программу как набор элементарных блоков. Изменяются требования - пересобираешь блоки. Косямба на проде - по одному мессаджу уже понимаешь, в каком блоке проблема, 9 из 10 багфиксов готовятся за час максимум. Да, есть проблемы, когда заказчику утром нужно одно, а вечером другое - но опять же, рефлекс подстилания соломки уже сам собой срабатывает. В конце концов, если тебя наняли сеньором-помидором, то надо уровень показывать и перед самим собой и перед теми, кто после тебя будет твой код поддерживать. Для сеньора компромиссное решение наговнокодить должно быть исключительно редким и обоснованным.
То есть не сказать, что код будет прямо говнокодным говнокодом, но производительность, тестирование и архитектура будут далеко не идеальными.
Тесты - банально ускоряют разработку за счет того что работа кода проверяется за секунды вместо минут на запуск кода и ручные вызовы функционала. Вопрос в 100% покрытии и моканьи всего подряд - на этапе стартапа хорошо закрывается фокусом на функциальных и интеграционных тестах (diamond of testing), покрытие основных пользовательских сценариев может занять минуты, даже не часы работы.
Работу с БД прячет под собой ORM и вызовы с фильтрами/сортировками не отличаются от «достать все из базы и обработать». Заодно упрощается работа с версиями БД, форматами данных, можно использовать разные хранилища для разработки и прода, что тоже ускоряет разработку.
Компоненты/иерархия классов - тут наверное соглашусь, в условиях недостатка информации может быть сложно выделить сразу с прицелом на будущее и проще сначала закопипастить, а когда требования устаканятся - вытащить общие компоненты. И то, что-то однозначно универсальное просто вытаскивается во внешние компоненты/классы и экономится время на копипаст лишних строк.
Верно, тесты ускоряют разработку. Просто не все их умеют готовить - для многих это как религия, они себе лоб расшибают, послушно обкладывая тестами вообще все-все-все из каких-то своих представлений о том как нужно писать тесты, или же наоборот, упорно из игнорируют, полагаясь на ручное тестирование или мысленное моделирование. Ручное тестирование жрет много времени, причем иногда его нужно выполнять повторно несколько раз, пока не исчерпается поток доработок. В мысленном моделировании ничего плохого нет, если есть опыт, это быстро и достаточно надежно, но тут играет чисто человеческий фактор: с удивлением узнал, что некоторые в этом настольные преисполнились, что сдают код, который из-за грубых опечаток даже запуститься не в состоянии, т.е. код даже ни разу не запускался автором, все из головы накидано, а в результате получается очень некрасиво, воспринимается это скорее как не накидано, а наложено. Ну а автотесты приходится межу делом подключать даже там, где их никогда не было, чисто для себя: они хорошо экономят силы и время, позволяют не вникать повторно в код, не тестировать его повторно, тем более вручную, позволяют сразу выкинуть из головы и сам код, и все сомнения относительно его надежности, а также, в случае проблем, позволяют не перебирать код, а сразу перейти к проблемному фрагменту. Также они снимают такую проблему, как скрытые ошибки: иногда ошибки в общем коде остаются незамеченными годами, автотесты такое вскрывают сразу, если написаны не через одно место.
А что касается прицела на будущее - для себя взял за правило так не делать. Это не окупается, никому не нужно, и никому не интересно. Минимально соломы набросать конечно нужно, но минимально, только из эгоистичных побуждений, для облегчения себе жизни, для облегчения отладки и тестирования, не больше. Это вполне хорошо бьёт код на тестируемые фрагменты, и вполне логично и обоснованно их раскладывает по структуре, просто потому что следует не абстрактной цели, а вполне конкретной. Это также автоматически отрезает весь тот ад абстракций, который любят порождать особо дальновидные товарищи, закладывая то, что вообще никогда не будет использовано, но всегда будет требовать внимания и поддержки.
И по мне такой подход неплохо окупается: забот гораздо меньше, только выполнить требования задачи и немножко облегчить себе жизнь, и ничего более. Меньше думаешь, меньше кода, он проще, лучше и легче читается, меньше времени тратишь на его написание и отладку. Как итог сил прикладываешь меньше. А если и когда требования изменятся - будет потребность, будут ресурсы, и самое главное, будут известны конкретные требования, что позволит провести целевой рефакторинг.
Особенно ярко это контрастирует, когда натыкаешься на код дальновидного товарища, в котором даже разобраться та ещё задача, десяток классов для какого-нибудь десятистрочного одноразового фильтра, и ты такой на вот эту гору запутанного абстрактного и абсолютно бесполезного кода взираешь и только один вопрос: "Зачем ты это сотворил? Кто и как теперь это будет поддерживать?". Как итог у такого товарища код бесполезен и переусложнен без какой-либо потребности в этом.
Проще вытащит все записи из базы и отсортировать их в коде, вместо базы данных
Я тоже такой фигнёй страдал, пока с SQL был на Вы. Но потом научился нормально делать.
Когда в проекте есть ревью, это сильно отбивает желание срезать углы. Проще сделать нормально, чем проталкивать свои костыли.
вместо базы данных — делаем так, все равно данных у нас в прототипе
будет сотня строчек и плевать на их производительность и т.п.
Проблемы с прототипом, что он только на словах прототип, а на деле и особенно в голове мереджеров это и есть продукт.
И когда через год приходит клиент и под реальной нагрузкой всё ложиться, то на исправление нужно полгода, потому, что эти костыли уже обросли мясом.
Если бы... Ошибаешься в требуемых структурах данных, а они уже тянут за собой...
Но, конечно, некоторой гигиены придерживаешься с самого начала, и "запас прочности" на последующие переделки стараешься оставлять.
Ошибаешься в требуемых структурах данных, а они уже тянут за собой
Я предпочитаю, формулировку, тип данных перестаёт соответствовать текущим требованием. "Ошибаешься" звучит, как будто этого можно было избежать. Зачастую нельзя, то есть работа в направлении избежать этого ведёт в тупик. Тут надо смириться и писать код с учётом этого. В данном случае использовать архитектуру, а если точнее то делать границы между модулями.
Сталкивался с такой ситуацийе. Есть схема базы данных, есть ORM, есть API для фронтенда. Данные читаются из базы и как есть отдаются на фронтенд а там просто JSON показывают как таблицу.
Бэкенд решило, что надо переименовать поле в базе данных. Нужно поменять всё: ORM, API, код фронтенда, у пользователя на UI поменяется имя поля. Оченень интуитивно всего один класс используется для представления объекта.
Ошибка здесь не в том, что имя поля не угадали. Ошибка здесь в том, что нет границ. Чтобы переименовать поле на фронтенде надо поменять базу и наоборот.
В идеале в базе лежит одно представление, на уровне бизнес логики другое, на уровне API третье, а фронтенд когда рисует таблицу адаптирует пришедшие данные. Да эти представления похожи и иногда могут быть одинаковыми, но мы никогда не меняем болше одного за раз. В итоге одна доменная сущность в системе представленна уже разными сущностями, у каждой из которых своя узкая область пременения и нужно конвертировать их при переходе между областями. Это добавляет сложности, но окупается на долших дистанциях.
Плюс в том, что каждая новая фича может быть задержанна одной из границ.
Переименовали поле в базе, ORM продолжает использовать старый аттрибут, просто поменяли его маппинг.
Переделываем ORM то на фронтенд идёт таже информация.
Нужно на фронтенеде переименовать поле? Не трогаем базу, просто меняем адаптер в API.
Да эти границы строить не бесплатно, но за это вы получаете изолированное тестирование и независимость от соседа. Даже когда нужно пересеч границу, это можно делать поэтапно, а не везде сразу.
Когда вы хотите соломки подстелить, то вкладываётесь только в изоляцию одной части кода от другогой. Если на всё не хватает, то изолируйте те части, которые скорее всего будет сильно меняться.
а они уже тянут за собой...
изменения до той точки, где в коде проведенна граница данного модуля.
Архитектура никогда не получается нормальной сама собой. Для этого нужно её целенапрваленно делать. И скорее всего с первых попыток ничего не получиться, а выйдет та самая гора абстарктного запутанного кода.
Мне помогает обкладываться тестами. Метрика простая, чем больше моков, тем больше зависимостей. Перевисываете код чтобы всесто моков были заглушки и архитектура улучшается.
Да. Это именно то, что я имел в виду – вплоть до практик, которые вы используете, чтобы "подстелить соломки".
И всё равно не всегда угадаешь: разобьёшь систему на юниты, сделаешь для уменьшения сцепленности два-три уровня косвенности – а потом выясняется, что именно эта граница тебе нафиг не нужна, и код ты зазря усложнил (в цепочке юнитов A-B-C у A образуется новая возможность – но чтобы C мог её задействовать, приходится менять и B, ибо С про A знать не положено... Хотя зачастую, конечно, это свидетельствует, что на юниты разбил неверно). Хорошо, когда есть возможность, поняв задачу глубже, переделать архитектуру – но это не всегда возможно.
Не надо противопоставлять быстро и качественно. Многие вещи которые повышают качетсво не требуют доп премени времени, а порой даже быстрей.
- Статический анализ практически бесплатен, а он ловит много глупых ошибок, а также учит разработчиков их не делать.
- Юниттесты, если это реально юнит-тесты, а не компоненные реально ускоряют время завершения задачи, так как сильно сокращают время не ручное тестирование и дебаггинг.
- Написать всё в одной функции или написать сразу с разбиением практически одинаково по времени.
На мой взгяд главная проблема, что нет понимания, что это легко или времени желания этому научиться.
> По-моему профессионализм не в том, чтобы всегда писать идеальный код, а в
том чтобы правильно определить, что именно необходимо в данном случае и
реализовать это.
В общем да. Главный мой инструмент для этого это разбиение на модули по степени понимания источника изменений. То есть разделять в коде те части где понятно и части где много туманности. Чем непонятней здача, тем более она должна быть изолированна от остального кода. В этом контексте становится намнго лече примать решения о качестве, где стоит сделать хорошо, а где и так сойдёт.
"Нет такого принципиального закона природы, согласно которому писать говнокод быстрее, чем писать по-человечески".
Есть. Чтобы писать хорошо надо подумать о многом, о том к чему это приведет, как сделать лучше, чем может быть плохо то как есть...
Это всё затрата мозговых ресурсов.
В ситуации "бесплатно" - никто никого не нанимает. И вполне может быть ситуация "есть идея - реализую, как умею", и оно до каких-то пор работает. Потом выясняется, что "всё не так", но к тому моменту - уже могут быть деньги для найма тех, кто знает и умеет то, что нужно.
Закон в том, что писать меньше кода быстрее, чем больше кода, а простой код — быстрее, чем сложный. Тесты — дополнительный код. Модная архитектура с разбиением на 100500 модулей/микросервисов/что там у вас популярно — дополнительный код. Скопипастить решение из соседнего модуля и быстренько его подкрутить быстрее, чем сделать правильную абстракцию.
И вполне нормально, что в начале пути на стадии обкатки прототипов будут срезаться углы. Просто нужно отдавать себе отчет, что техническим долгом нужно управлять.
В принципе, в экстремальных условиях, когда очень сжатые сроки, профессионал вынужден писать плохой код. Когда есть постоянное давление со стороны менеджеров или заказчиков, очень сложно применить все хорошие практики.
Согласитесь, что всё хреначить в контроллере получается быстрее, чем, если вывести бизнес-логику на другой уровень абстракции и обдумать архитектуру. И таких примеров можно привести много.
Наверно, в начальном этапе стартапам выгоднее нанимать говнокодеров, нежели профессионалов. Поэтому и чаще они их нанимают, потому что их час работы стоит дешевле.
Согласитесь, что всё хреначить в контроллере получается быстрее
Не соглашусь. Как я уже писал выше, когда ты в течение карьеры написал уже штук 500 этих рест-контроллеров (если вы о них), то на автомате пишешь как надо. Если видел данный архитектурный паттерн множество раз, то заложить точки расширения - вообще не рокет-саенс ни разу.
Да в том то и дело, что не быстрее. Потом контроллер обрастает логикой и все становиться очень сложно.
Да, но вот я имею в виду, что это быстро в самом начале. Понятное дело, что в дальнейшем такой код будет тормозить разработку. Но условно говоря, если тебе надо написать какую-то логику и больше не трогать этот контроллер какое-то время, это будет быстро. Например, написал MVP для того, чтобы проверить гипотезу, потом, если уже понял, что проект представляет коммерческий интерес, переписал всё используя хорошие практики.
Великооепный ответ). Все просто забывают про бизнес составляющую и много философствуют). В начале самая лучшая архитектура - это чёрный ящик)
Описанных проблем не встречал уже лет 5.
Чтобы без git, так вообще давненько.
Где автор таких находит?
А сколько компаний перепробовал?
Так или иначе за последние годы взаимодействовал с почти тридцатью командами разработки и двумя десятками одиночек.
Я не исключаю, что просто у меня такое окружение ввиду специфики взаимоотношений, но чтобы появился кто-то, кто работает без git, такого не было вообще. Это в целом, ИМХО, начало начал.
Более того, даже большинство одиночек практикуют CI/CD и вполне нормально отслеживаются задачи по коммитам. GitHub, GitLab, Bitbucket. Предпочтения разные у людей, но пользуют все.
Может, конечно, команды, которые варятся сами в себе, позволяют себе такое... не отрицаю.
от технологий зависит, BI разработчки до сих пор ни в PowerBI ни в Tableau ни в чем другом в 99% случаев гит не используют.
Как мне кажется, перечисленный Вами инструментарий - это всё же не про написание кода.
Само собой, мы не обсуждаем, например, использование git при работе в Photoshop или чем-то, отличным от кода.
там полно кода например на DAX в PowerBI, или на Python + R в Tibco или на JS в Cognos. Но он зашит внутри тула
недавно в таком участвовал. и все на прод, и без гита.
все бывает
Очевидно, что всё может быть, но когда ты читаешь "стартапы" в названии, первая мысль про команды профессионалов, которые разрабатывают что-то на грани новых технологий, а не про челов, которые, не читая новости из мира разработки за последние 15 лет, решили п̶о̶г̶о̶в̶н̶о̶к̶о̶д̶и̶т̶ь̶ написать приложуху.
Зачем про них вообще писать? Если бы они читали статьи, они бы не стали делать так, как они делают. А люди, которые читают статьи (и прочитали эту), наверняка понимают, что без гита на прод сервере изменения делать это полнейшее невежество по отношении к клиентам, пользователям и себе. Типа фарм плюсиков на джунах?
когда ты читаешь "стартапы" в названии, первая мысль про команды профессионалов, которые разрабатывают что-то на грани новых технологий
Стартапы запускаются не только прожжёнными программистами и не только для них. В этих случаях код получается очень "бизнесовым", без всех этих ваших абстракций в самом коде и в процессах вокруг него.
Сам участвовал в переписывании таких стартапов когда код уже невозможно развивать дальше базовой реализации изначальной идеи. Заказчик приходил с backup.zip от предыдущей команды, и даже папочки /.git внутри не было (не значит, что всегда не было, но разбираться с этим уже никто не будет).
Заказчик приходил с backup.zip от предыдущей команды, и даже папочки /.git внутри не было
Вот прямо сегодня скинули точно такой же проект (старая контора закрылась, старая команда разбежалась, проект передали нам). Только там еще и дампа структуры БД нет, придется по коду смотреть и додумывать ))
Какой же это стартап? Сейчас модно называть прототип сайта, который ты сделал стартапом, но когда я вижу статью "плохие практики, которые я встречаю в стартапах" - я не ожидаю (теперь уже ожидаю) увидеть про двух челов, которые в фотошопе цсс сгенерили абсолютами. Нафига мне вообще про такое читать? Ладно бы на виси статья, а тут вроде тех. ресурс был когда-то. Видимо пора закругляться с хабром по-тиху.
Какой же это стартап?
зажрались, есть два вида стартапов:
контора, с бюджетом лямов 150 на полгода, 15 разработчиками и офисом в москва-сити — это нормальный стартап которого будут рассматривать фонды как цель для развития и финансирования (на сумму в 15лямов с условием 60% доли… хаха… нервный смех)
и вот тут можно неспеша поиграть с процессами
===
А есть, когда два-три чела на коленке собирают прототип и умудряются поднять с ним продажи
вот данная статья — про второй вариант, и он существует. спуститесь с небес на землю, люди до сих пор умудряются с нуля создавать бизнесы и таких довольно много, просто с верхних этажей москвасити и бюджетами в сотни лямов — кажется что все остальные нищеброды неудачники
хз что за слепая ненависть к... даже не знаю кому, но да ладно - когда у тебя прототип на коленке, это ещё не стартап. Это МВП, пруф оф концепт - частично реализованная идея стартапа. Челы, которые называют себя стартапами на данном этапе это как если бы студенты первого курса называли себя докторами.
стартап начинается когда ты сделал МВП, запустил, оно показало что можно двигаться дальше и ты/вы это делаете уже всерьёз. Ключевое слово. Всерьёз и всё то, что автор написал в статье не сочитается ну никак.
если не сложно, привидите примеры "стартапов" в вашем понимании, которые собраны в конструкторе на коленке, и умудряются зарабатывать. Где работают программисты не выше уровня "стажёр", которые не знают про вещи, написанные в этой статье. Если что, называть маркетплейс купленный и развернутый на каком-то сервисе стартапом это как называть верстальщика, пишущего штмл и цсс онли, программистом. Технически можно доказать что цсс это язык по тьюрингу, но стоит ли?
если не сложно, привидите примеры «стартапов» в вашем понимании, которые собраны в конструкторе на коленке, и умудряются зарабатывать. Где работают программисты не выше уровня «стажёр», которые не знают про вещи, написанные в этой статье.
ну я в таком работал, контора плюс-минус работала с 12 по 22 год (пока не обрубили гуглплей, а у инвесторов не возникли известные проблемы)
контора начиналась с сделанного на коленке в конструкторе приложений — приложения, и успешно зарабатывала деньги, потом когда денег стало достаточно, привлекли меня и переписали этот ужас на более менее вменяемом стеке (тем не менее почти все недостатки описанные выше были, из-за ограниченного бюджета)
потом активную разработку приостановили и просто работали с клиентами, параллельно договариваясь о следующем раунде финансирования… а потом наступил 22 год
==
у меня честно говоря пригорает когда мне тыкают 'а, у тебя нет 100500млн, чё ты ваще в бизнес суешься, тут большие дяди!!'… вот блин нет, тут ИТ и тут реально собрать бизнес из желудей и спичек и оно полетит
бизнес это про продажи, а не про пайплайны в гитлабе и красивый код на проде
вычитку делал последние 5 лет видимо
Курица - не птица, АСУТП - не программирование... Спокойно-спокойно, сам из АСУТП. Лет через 20 там обязательно будут бранчеваться и терраформить инфраструктуру кодом.
По состоянию на 2016-й, когда я ещё был занят в той сфере, там был жёсткий vendor lock-in. Хочешь побаловаться гитом? На, попробуй проект в бинарном формате и/или с графическими языками. Хочешь в другую IDE? На, попробуй проект в бинарном формате и/или с графическими языками. Хочешь портировать проект на другой контроллер? Написать автотесты? Ну вы поняли... А если ещё хоть какая-то мотивация осталась, то вот тебе вендорские расширения к IEC 61131-3, дружок; они не совместимы ни с чем, и только вендор знает что там у них под капотом. Короче, плохо всё.
За эмбеддеров ничего не скажу, впрочем.
большинство, достаточно открыть hh
То же кажется, что если человек без гита начинает писать любой (особенно бизнесовый) код, то дело тут не в стартапа... Он и в энтерпрайзе может крошить все без коммитов в течении месяца.
В программировании с 1979года. Видел многое, в том числе и всё описанное в статье. Но .. ровно также видел как эти рекомендации исполнялись, мягко скажем через "задний проход".. к примеру:
версионирование. Да, был SVN (гита ещё не было в природе), продакт поднимался из специальной ветки, мастер - то что оттестировано и готово заливаться на прод, стеджинг с песочницей и ветки по трекерам задач .. "всё по уму", кроме мелочи: ветки разработки (8 программистов в команде) часто конфликтовали промеж себя и мердж делал тот, кто лил в стейджинг. Автотестов ещё не было, QA тестировал новый трекер и давал "добро" в мастер .. в итоге старый код, поломаный мерджем легко попадал в прод..
коде ревью. 2 программиста - 4 мнения о коде.. на многих местах коде ревью выливалось или в долгие обсуждения, если не споры или .. "я начальник - ты дурак".. в итого, сроки разработки срывались неоднократно. Польза? она есть конечно, когда ревьюер примерно равен или выше по опыту чем разработчик, но не наоборот..
В этой части интересен опыт разработки "хирургической бригадой". Имел всего дважды, но оба раза воспоминания только положительные.
Мониторинг ошибок, даже больше, ведение журнала ошибок .. видел ровно 1(один) раз, было крайне полезно. Как правило, не доводится до ума и часто (особенно сейчас) вижу ситуацию когда исправление новой ошибки приводит .. к появлению пары новых. Релиз месячной разработки в итого растягивается до полугода..
как-то так, на моей практике. Но, в теории - все исключительно "за". ;)
Классика. Культ карго в начале, ситуация "король голый" в конце.
Да, был SVN
Вначале был CSV :-)
Просветите, пожалуйста, что имеется ввиду под опытом разработки "хирургической бригадой", если не затруднит.
>В программировании с 1979года. Видел многое, в том числе и всё описанное в статье...
с уважением к Вашему опыту, кое-что из собственного в основном embedded -
source code management используется типа сколько помню, min с середины 80x, из первых RCS, CVS и пр., если правильно помню одни из первых были сделана в bell и переписаны на С очень рано, стандартная практика merge вечером (с частотой 2-3 дня), QA начинает тестировать ночью, утром email со списком проблем, назначение ответственных и пр., обычно кроме своей основной работы, 8-10 bugs постоянно висят разного уровня сложности, среднее время исправления 2-3 дня, веток много с разным приоритетом, типично работа с 2-3 одновременно, project leader хозяин merge на своей ветке, если не доверяет смотрит код лично перед merge, конфликты возникают, но решаются быстро, если не получается договориться то решает project leader, типичный размер группы 30-40 человек, стаж работы людей примерно 8-10 лет,
код ревью требуется редко, обычно в порядке помощи если что-то срывается по срокам, хотя чужой код обсуждается часто и свободно, любая экзотика мешающая пониманию кода вырывается с корнем, это по части project leader, при повторении может быть увольнение, design review более часто - рассматриваются спецификации, и пр., иногда приводятся фрагменты кода, если требуется для понимания, все в свободном доступе, вопросы и замечания приветствуются если по делу,
мониторинг ошибок постоянно, состояние регулярно сообщается до уровня sw director, обычно раз в неделю общее собрание, большая часть времени обсуждение списка bugs (типичный размер 50-100), в том числе возможное перераспределение ответственных, отказов взять чужой bug практически не бывает, хотя радости мало,
> было описано в работе (Баррон?)
David Barron типа из uk, имел отношение к созданию BCPL
бая экзотика мешающая пониманию кода вырывается с корнем, это по части project leader, при повторении может быть увольнение,
стаж работы людей примерно 8-10 лет
кхм… жуть, честно говоря какаято ;)
я разок так работал:
«есть точка зрения лида и неправильная, в нашей компании работают люди только с правильной точкой зрения»
это такое болото было… жесть…
отсюда кстати растут всякие забавные казусы (не в моем случае, но я такое видел в соседнем отделе)
автоматизация на bat файлах (не шелл, именно bat и на винде, потому что так понятнее и надежнее)
докер — никому не нужная молодежная хрень, только хардкор, только железные сервера, в серверной стойка — отдельно dns отдельно apache (nginx сложно и не нужно… парадокс) отдельно сервис-монолит, отдельно БД, каждый сервер железный
предлагать решения которые непонимает и непринимает лид — нельзя (я бы сказал запрещено, прям как вы описали с увольнением)
я оттуда ушел, как из тюрьмы вырвался
> кхм… жуть, честно говоря какаято
это не FAANG конечно, в основном про работу на дороге 128/495,там где делают oem, в том числе embedded
докер — никому не нужная молодежная хрень, только хардкор, только железные сервера, в серверной стойка — отдельно dns отдельно apache (nginx сложно и не нужно… парадокс) отдельно сервис-монолит, отдельно БД, каждый сервер железный
Ну вот и пришло поколение людей которые не знают как без докера приложение развернуть ....
==
я как раз из поколения которое без докера все разворачивало… но вот только появление докера я воспринял как чудо какоето
Ну раз у вас монолит и вы это восприняли это как чудо, то:
Вы делали что-то не то
Не пробовали и не умели работать с аналогами
А по поводу зачем, но во первых это дополнительный компонент, а значит дополнительная точка отказа и дополнительные усилия на его поддержку.
Во вторых у докера есть ограничения, например, нельзя кастомизировать ядро.
Вы делали что-то не то
всмысле чтото не то?
как вы представляете себе процесс быстрого масштабирования сервиса если это нужно срочно, а он у вас на железном сервере стоит? искать срочно свободную железку (или правильно планировать чтобы таких ситуаций не было? ха!) и там всё разворачивать?
Не пробовали и не умели работать с аналогами
пример?
А по поводу зачем, но во первых это дополнительный компонент, а значит дополнительная точка отказа и дополнительные усилия на его поддержку.
пока мой опыт показывает что кубер или swarm гораздо надежнее и проще чем собирать кластер по старинке вручную, и организовывать менеджмент конфигураций и создание образов серверов.
а потом еще обновление ОС делать перекрестившись и обложившись неплановыми бекапами
у меня были блейд сервера под управлением vmware… этож адовый оверхед по памяти как минимум, держать полноценные (хоть и виртуальные) машины под вебсервера например или под dns или ad (хотя конечно хотябы один контроллер должен быть железным)
всмысле чтото не то?как вы представляете себе процесс быстрого масштабирования сервиса если это нужно срочно, а он у вас на железном сервере стоит? искать срочно свободную железку (или правильно планировать чтобы таких ситуаций не было? ха!) и там всё разворачивать?
Если у вас нет свободных железок, то как вы собираетесь докеры масштабировать? Если же есть ресурсы на существующем то увеличить число потоков в настрйоках приложения и добавить памяти. Не надо приписывать докера волшебные свойства которыми он не обладает
пример?
Вы это серьёзно или вы на самом деле не знаете аналогов?? https://en.wikipedia.org/wiki/OS-level_virtualization
пока мой опыт показывает что кубер или swarm гораздо надежнее и проще чем собирать кластер по старинке вручную
Если вы что-то делали вручную, то см мой комментарий, про то что вы что-то делали не так.
организовывать менеджмент конфигураций
Докер этого не отменяет.
а потом еще обновление ОС делать перекрестившись и обложившись неплановыми бекапами
С докером вам надо креститься в 2 раза чаще - сначала при обновлении хоста, потом про обновлении докера. См мой комментарий про дополнительный компонент и соответствующее уменьшение надёжности.
у меня были блейд сервера под управлением vmware
Ну кто вас заставлял есть кактус. Для линуксов в основном юзается KVM и XEN. KVM насколько я знаю к памяти бережно относится.
Но, в любом случае, не путайте контейнеризацию с виртуализацией
Вы это серьёзно или вы на самом деле не знаете аналогов?? en.wikipedia.org/wiki/OS-level_virtualization
Я вообще не о самом докере как софтине говорю, а о принципе скорее именно принципе контейнеризации
Если у вас нет свободных железок, то как вы собираетесь докеры масштабировать?
сервисы масштабировать, а не докеры
Если же есть ресурсы на существующем то увеличить число потоков в настрйоках приложения и добавить памяти.
приложение может не уметь (плохо уметь) в многопоточность
Я вообще не о самом докере как софтине говорю, а о принципе скорее именно принципе контейнеризации
Принцип существовал задолго до появления докера. Если вы по какой-то причине его не использовали, значит он вам не особо был и нужен.
Я вообще не вижу выгод использования докера для монолита, которых нельзя было бы достичь более простыми и стандартными инструментами.
сервисы масштабировать, а не докеры
Ну какая разница. Докер чудесными образом железок не добавит.
приложение может не уметь (плохо уметь) в многопоточность
Сложно представить такое в 2023 году
> кое-что из собственного в основном embedded ...
собственно комментарий первоначально для Владимира, типа из уважения к опыту, надеюсь что ему по крайней мере интересно, начал свою работу еще раньше чем он, видел достаточно, но писать статьи желания нет, минусование приветствуется, типа как местный обычай :)
понимаю конечно, но зависит от практики, то что Вы описываете это типа просмотр нового (добавленного) кода перед merge на одну из веток, при интенсивной работе группы случается каждые 2-3 дня, параллельно с bug fixing, если человек новый или ситуация трудная project leader смотрит Вашу рабочую копию перед merge, проверяет, смотрит результаты тестирования и пр., наблюдает за возможными конфликтами merge рядом с Вами, при необходимости помогает, поскольку это происходит часто дополнительно привлекать людей возможности нет, если кто еще конкретно требуется конечно позовут, с другой стороны если начинается новый проект и для него пишется типа своей framework, это тот случай когда code review делается полностью, привлекаются многие типа поймать проблемы на ранней стадии, люди специально готовятся, изучают код и пр., также бывают аварийные ситуации типа что-то не получается вовремя сделать, одна из мер code review типа как выйти из этой ситуации,
короче качество кода это ответственность Ваша и project leader, если есть необходимость выделят дополнительно столько глаз сколько требуется для code review, но постоянно так группа работать не может слишком много надо сделать за ограниченное время, заметим junior вероятно вообще не встречал за много лет
Работал в компании, где некоторые программисты решили что им ревью не нужно, так как оно сильно мешает.
Менеджеры были довольны, скорость закрытия задач возросла. А вот тестировщики, клиенты и те кто потом это поддерживал не радовались.
но постоянно так группа работать не может слишком много надо сделать за ограниченное время
Видел такие группы, они были очень заняты переписывание существующего кода, потому, что он был плохо написан и ревью было сделано спустя рукава, исправлением ошибок, и попыткам разобраться, что не работает.
Возможно у вас не так. Или просто никто не занимается реальными подсчётами куда уходит время.
>> Моя “любимая” история — постановка задач методом развести тред на 150 сообщений в чате. Или в личке
Это вообще самая лучшая изюминка из взаимоотношений разрабов и бизнеса. ))
и в чате и в личке и в нескольких мессенджерах
фиксится любым работником компании примерно следующими словами: "не флудите плиз, напиши это в жире". Это если вдруг хочется, чтобы такого не было
Потом тикет в JIRA правишь, потому что там вот такое :)
Hidden text
![](https://habrastorage.org/getpro/habr/upload_files/d10/7b3/7bb/d107b37bb78aa25909cec58bb65ace8e.png)
Очень хочется посмотреть на того сеньора, который это напишет в вацап с Генеральным Директором градообразующей фирмы, который считает что раз он математик по образованию, то способен поставить вам ТЗ "на пальцах" прямо вот тут, в вацапе и только ваша непроходимая тупость не позволяет ему донести до вас такие простые вещи. ;)
Такие вещи надо согласовать на уровне команды и донести до всех внешних соучастников. И строго следовать. Если директору охота ставить задачи вербально и напрямую, то можно выделить специального человека для перевода из директора в жиру.
Хотя, конечно, против начальника самодура бороться трудно.
Если гендиректор ничего не делает по поводу чатов с сотнями сообщений обсуждения (в которых он состоит), то:
ему глубоко плевать на чаты, работу, процессы и на всё остальное, а потому ничего не случится
он настолько неэффективен, что вчера была пора начинать искать другую работу
И классическое из этих чатов:
- ВСЕ СЛОМАЛОСЬ!111
- Что сломалось, вижу по логам только сбой обновления в 02:10...
- Вы что не поняли, НИЧЕГО не работает, МНЕ СРОЧНО НАДО ЗАЙТИ!1111
А потом сидишь, пытаешься исправить, тратишь N часов, вроде находишь решение, заливаешь, пишешь в чат, чтобы проверили...и в ответ получаешь:
- А всё ещё N часов назад заработало, ошибок больше не было, проверять не буду, занят, иди н...
Моя “любимая” история — постановка задач методом развести тред на 150 сообщений в чате. Или в личке
Это не так уж и плохо. Альтернатива - это когда заказчик ставит вас перед фактом, что священные скрижали ТЗ у него уже есть, и, кроме того, они уже подписаны и одобрены всем "уполномоченными органами". А вы, мартышки, теперь танцуйте с этим как хотите.
После обсуждения в чате всегда можно подбить и зафиксировать резюме для будущей самообороны.
так зачем же ты ешь кактус продолжаешь работать в основном стартапах?!
горькая правда в том что такое не только в стартапах. и самый смак — что в стартапах еще чтото поменять можно, а вот в компании которой лет 20 где все замумифицировалось уже не совсем
я вот работал в одной компании, где все перечисленное в статье было, и ревью и мониторинг и тесты и вообще всё по феншую, и при этом некоторые департаменты генерили в прод такое безумие что у меня до сих пор волосы шевелятся… и начиналась тенденция 'упростить кодревью чтобы ускорить деливери'… ведь очень удобно отправлять код на ревью не овнерам продукта, а в соседний департамент… они МЕНЬШЕ ПРИДЕРАЮТСЯ и быстрее деливери!.. я пытался с этим бороться и меня чуть не уволили ;)) (а потом сократили из-за порезки костов)
упростить кодревью чтобы ускорить деливери
Но долгий, блокирующий, итеративный(нашли проблему => вернули задачу в разработку => исправили => отправили на ре-ревью) код-ревью это действительно проблема. И для деливери, и для последующей интеграции кода, и для разработчиков, которым нужно либо ждать пока пройдет ревью, либо постоянно следить за статусами нескольких задач и постоянно переключаться между ними.
Если такое происходит регулярно, стоит подумать о том, как дать разработчикам удочку а не рыбу (передача знаний для достижения общего уровня команды / неблокирующий ревью / дизайн-ревью до разработки)
а когда в релизе концептуальная архитектурная недоработка или вообще дырка в безопасности (меня кстати чуть не уволили когда я привлек СБ к ревью релиза из-за подозрений что сама по себе задача неверно поставлена и задержал его из-за этого на неделю) то такой ревью крайне необходим чтобы остановить выкатывание в прод всякого бреда.
в моем примере, компания была довольно крупной (более 500 человек только разработчиков) и архитектурный ревью был упразднен довольно давно (т.к. сильно замедлял релизы) что приводило к довольно большому количество копипаст-кода просто потому что нет времени разбираться, лучше впилим рядом тоже самое.
Коллега прямо сейчас сидит парсит БД с названиями таблиц "townНазвания" .. в формате EAV с такой же мешаниной анг-rus.
ведь очень удобно отправлять код на ревью не овнерам продукта, а в соседний департамент… они МЕНЬШЕ ПРИДЕРАЮТСЯ и быстрее деливери
Продвинутый менеджер предложил бы привлекать для ревью уборщицу. Она всё сделает ещё быстрее. И вас бы вместо угрозы увольнения премировали
я пытался с этим бороться и меня чуть не уволили
А я пытался с этим бороться и меня уволили.
Странно, а по моей практике все наоборот: как раз стартапы пытаются сделать все по уму. Люди с опытом наконец-то дорываются до возможности сделать так как надо, а не как сложилось из-за непонятных исторических завихрений... А вот на многолетних энтерпрайз проектах совершенно легко может оказаться дыра практически в любом месте. Так чтобы вообще не было версионного контроля, не попадалось, но то, что там какой-нибудь даже уже не ископаемый Source Safe, где все в одной куче и даже без лейблов по версии - попадалось. Несколько раз попадались проекты вообще без тестировщиков... Жесть, доложу я вам, но как она есть. Тестовые контуры обычно есть, хоть и очень далекие от боевых, а вот стейджей как правило ни у кого нет. Какие-то грабли и поперек них волшебные костылики вместо нормального CI/CD - скорее норма. Так же как и отсутствие поставленного процесса кодревью. Причем, что наши компании, что американские, большие, маленькие - никакой разницы.
Пока стартап будет заводить CI/CD и покрывать код тестами, терять время на ревью, конкуренты на коленке слепят демо и продадутся.
Не забывайте, что 99% процентов этих конкурентов вообще не слепят ничего работающего. Ваш гипотетический конкурент с работающей демкой, но без CI -- экземпляр из Красной книги.
Моя первая работа была в стартапе. Причём взяли меня как раз на этапе когда стартап "продался" и из "легаси-говнокода" надо было делать новое адекватное решение.
Так там в этом легаси такое местами встречалось что у даже у джунов вроде меня волосы дыбом становились. То есть по хорошему всё работало только на презентациях и если их делал человек, который точно знал как делать презентацию. Шаг влево-шаг вправо и приложение начинало глючить или просто падало...
Вот прикол в том, что статистически ваш стартап уже лучше 90% других стартапов, которые с таким подходом даже до этапа презентации не дошли.
Впрочем, я не утверждаю, что с первого дня надо всё делать идеально (тут и люди соответствующие требуются...), но уж прикрутить контроль версий и систему автобилда дело совсем нехитрое, и если у конторы на это не нашлось нескольких рабочих дней, вряд ли именно эта задержка определит отставание от конкурента.
Ну контроль версий у них действительно был. Автобилда как такового не было. Но это было начало 2000-х. Тогда многие вещи из современных "стандартов" были не особо распространены.
и если у конторы на это не нашлось нескольких рабочих дней
Несколько дней здесь, несколько там. Если у вас есть всего полгода-год времени, то и несколько дней становятся долгим сроком. Плюс это ведь ещё надо найти людей, которые всё это умеют. Или дать имеющимся время чтобы разобраться.
Да, я это понимаю. Просто если мы начинаем заниматься арифметикой типа "день тут потеряли из-за настройки контроля версий, день там потеряли из-за билд-машины, вот и отстали", то надо честно таким же образом считать время, упущенное на дебаг или просто неадекватно долгое добавление простой функции. Это ведь тоже происходит по нашей вине, а не "само собой".
Так в том то и дело что пока проект на старте, кода мало, людей над ним работает мало(а то и вообще один человек) , все всё знают и так далее и тому подобное, то большинство "классических" проблем ещё просто не возникают.
Отдебажить код на пару тысяч строк или добавить туда новую функцию? Причём в код, который я сам писал меньше полугода назад? Да вообще не проблема.
Проблема будет через пять лет когда кода станет на порядок-два больше, менять его надо будет абсолютно новому человеку и никто уже не будет помнить что там этот код на самом деле делает и почему.
И да, если говнокодил в течении полугода-года, то потом переписывать всё заново займёт не особо меньше времени. И это тоже надо понимать.
Нормальный CI/CD настраивать нужно не день, а порядка месяца-двух (особенно когда за дело берётся человек который никогда не делал эту задачу в прошлом), если только используется не trunk-based development.
Чем раньше начнешь, тем быстрее делать.
А в идеале заложить расчет на него в самом начале разработки.
Очень часто вижу мучительные переписывания конфигов, когда дело дошло до интеграции. Конфиги писались для локальной системы, а вот начали деплоить и тесты делать, то выяснилось, что уж очень неудобно.
Если на проекте всего один разработчик — то чем раньше он начнёт делать CI/CD, тем позже он приступит к, собственно, написанию кода.
Конфиги же на локальной системе, на отладочном стенде и на проде будут отличаться всегда, это данность. И избежать их мучительного переписывания можно только одним способом — не делать их мучительными, он времени появления CI/CD оно не зависит.
Если на проекте всего один разработчик — то чем раньше он начнёт делать
CI/CD, тем позже он приступит к, собственно, написанию кода.
Если есть опыт, то это не так долго так что CI можно и сразу. А CD в превые дни и не нужен. Но начать получать доступы можно и сразу, иногда это месяцы.
Конфиги же на локальной системе, на отладочном стенде и на проде будут отличаться всегда, это данность
Не то чтобы сильно разные, после того как везде запустили.
И избежать их мучительного переписывания можно только одним способом —
не делать их мучительными, он времени появления CI/CD оно не зависит.
Зависит, когда CI/CD есть ты делаешь сразу чтобы работало.
А когда нет то делают как получится.
Работал с приложением на Spring. Для деплоя скриптом распаковываешь war (Web application Archive) файл, меняешь sedом плейсхолдеры в файле с настройками, запаковываешь обратно, вот и система готова к запуску.
Вишенкой на торте было то, что перед тем как выполнить этот скрипт, на него накладывался патч.
Не то чтобы сильно разные, после того как везде запустили.
Если в разных конфигах есть совпадающие элементы — что они вообще делают в конфиге?
Работал с приложением на Spring. Для деплоя скриптом распаковываешь war [...] меняешь sedом плейсхолдеры в файле с настройками
Если распаковку war я ещё могу как-то понять, то вот плейсхолдеры в файле настроек выглядят дико. Откуда скрипт вообще берёт данные для этих плейсхолдеров, и почему из этого источника не может взять данные само приложение?
то вот плейсхолдеры в файле настроек выглядят дико
Всё было хорошо пока деплоли сами и руками. А как оказалось, что деплоить будут другие люди, то пришлось срочно сделать автоматический деплой. А конфиг это текстовый файл внутри докер образа, внутри war архива. А параметры которые нужно вставлять были нам не доступны.
Сделали быстро, без ревью. По быстро я имею ввиду "нужно еще вчера", это никак не связанно со скоростью выкатывания рабочей фичи. Выкатывали долго и болезненно.
Если бы заренее начали переписывать всё это на кубернетес какой-нибудь, то потратили бы столько же времени, только без нервотрёпки и потерь репутации.
Откуда скрипт вообще берёт данные для этих плейсхолдеров, и почему из этого источника не может взять данные само приложение?
Вы задаёте правильные вопросы.
Вся эта ситуация случилась через несколько лет после появления стартапа. По отдельности отстутсвие CI/CD на старте, спешка в один из моментов и отсутствие код ревью может быть прошли бы не так болезненно, но вместе они наложились и получилось очень хреново.
Можно ли сделать сразу и нормально? Если есть опыт делать нормально, то да. Но к сожалению, он не так часто встречается. У меня опыта как не надо намного больше, чем как надо. В общем оригинальная статья как раз о том, что можно сделать нормально сразу при старте проект.
Мне нравится схема!
Хотелось бы ещё почитать от вас про работу с багами и про организацию связки "жира - база_знаний - баг-трекер"
Здравствуйте, очень понравилась ваша статья. У меня тоже есть стартап, но я еще на первом курсе бакалавриата и испытываю трудности. Может вы сможете и меня проконсультировать?
Хорошая статья, но остается незавершенность. Общий посыл - "раз у меня однажды сломалось, подход плохой". Нет какого-то исследования что-ли, почему так, а не иначе, поступать другим. Такое ощущение, что проекты в которые вы не приходили - обречены) Одно из отличий стартапа в первые месяцы - большой процент, что это просто демо, которое после испытаний положат в стол. А вы приравняли стартапы, которые уже нашли нишу к только образованным. Естественно, гит нужен везде, с этим не спорю.
Очень много коментариев про скорость разработки. Но я не видел, чтобы кто-то это измерял нормально.
Скрость для ленивых, это скорость закрытия задачи и мердж кода в ветку. Если еще когда тестировщик найдёт баг, не переоткрывать задачу а создать новую, так еще и медаль за количество закрытых задач можно получить. То есть, измеряют только первую часть цикла, а остальное остаётся за кадром. Для менеджмента просто счастье, чтобы отчитаться.
Я ни разу не работал в комании, которая пытается оценить скорость разработки фичи от и до. Были попытки следить за количесивом переоткрытых, но не взлетели. Мой опыт мне подсказывает, что при таком измерении, сделать первую часть абы-как а потом посмотрим, не всегде быстрей чем подумать и сделать нормально.
Да есть прототипы, где есть только начальная часть и нет хвоста и там можно фигачить не думая. Но большинство задач обычно живут в продакшене более полугода, а потом еще и эволюционируют.
Есть у кого реальная статисика по скорости, по который можно оценить подходы?
Мартина Фаулер териотезирует о скорости разработки через качество архетиктуры. Отстутствие архитектуры даёт хороший старт, наличие выигрывает в долгосрочной перспективе. На его взгляд, точка пересечия это недели, даже не месяц.
https://martinfowler.com/bliki/DesignStaminaHypothesis.html
Сейчас такие времена, что пока "семь раз отмеришь другие уже отрежут".
Поэтому в идеале всё написано правильно,а в реалиях делают всё как можно быстрее, а это далеко не всегда так как правильно.
Классическая история, когда проект стартует с одного разработчика. Он что-то делает, заливает по FTP, тестирует и правит прямо на проде.
От плохих практик, которые Вы описываете аж волосы стынут в жилах. Если честно, сам уже лет 10 не сталкивался с тем, чтобы кто-то использовал FTP. Тяжело представить, что в наше время 12-факторных приложений, эфемерных сервисов, Кубернетиса и канареичных деплоев, кто-то занимается чем-то подобным. Надеюсь они увидят Вашу статью и она принесет им пользу.
Нет правила "1 задача=1 ветка в коде"
Создал в трекере 10 задач, но ребята решили делать их в одной ветке. В итоге дедлайн был вчера, но зарелизить мы не можем: в одной из некритичных задач критичный баг, который быстро не исправишь. При этом, если бы не общая ветка, мы без проблем могли бы зарелизить остальные 9 задач - и запустить систему. После разбора команда приняла подход. Но что интересно, когда я переходил в другую команду, нам пришлось проходить подобный “восхитительный” опыт заново.
Конечно, проблема с которой Вы столкнулись вполне объективна, но я бы на Вашем месте не был бы столь категоричным в выборе решения, т. е. в отказе от разработки в одной ветке. Это далеко не панацея. Представьте себе другую ситуацию — несколько разработчиков работают над большими фичами, каждый в своей ветке, в течение некоторого продолжительного времени. Когда приходит время объединить правки — оказывается, что между ветками накопилось столько конфликтов, что смержить их — непосильная задача. При этом первый разработчик кому это удалось сделать может пойти отдыхать, а всем остальным придется разбираться с конфликтами и переписывать свой код. В некоторых особо запущенных случаях (коим я был свидетелем) — работу из отдельной ветки можно было вообще выкинуть и начать писать с чистого листа используя только небольшие фрагменты ранее написанного кода.
У каждого подхода есть сильные и слабые стороны, Вы как CTO должны это понимать и не бросаться в крайности, призывая других однобоко выбрать тот или иной подход, не взвесив все плюсы и минусы.
Альтернативный подход не только существует, но и приобретает всё большую популярность. Называется он — Continuous Integration / Continuous Deployment или CI/CD. Почему-то в сообществе этим термином принято называть автоматизацию сборки приложения и всякие пайплайны, хотя это не совсем корректно и приводит к упущению сути. Адвокатом этого подхода является, например, Dave Farley (https://www.youtube.com/%40ContinuousDelivery).
Суть подхода в том, чтобы объединять правки как можно чаще, по-сути несколько раз в течение рабочего дня. Очевидно, что напилить целую фичу таким образом не получится. По этой причине код пишется таким образом, чтобы не ломать мастер и активироваться только после включения соответствующего фича-флага в конфигурации приложения. Это позволяет всем разработчикам комитить незавершенную работу в мастер небольшими кусочками и при этом этот код можно деплоить в продакшен. А чтобы ничего не сломалось (как в описанном Вами случае) как раз и нужен code review и автотесты. Такой подход позволяет в частности обнаруживать конфликты гораздо раньше и более успешно взаимодействовать с командой. Dave вообще рекомендует использовать техники парного программирования, в чем действительно есть определенный смысл, хотя недальновидным менеджерам такое предложение вряд-ли сильно понравится… :)
Посоветуйте, пожалуйста, что почитать из литературы на тему организации процессов, и внедрению всего того, что есть на схеме в миро
Довольно сложный вопрос. К сожалению, не могу назвать пару книг, после которых можно пойти легко реализовать любой процесс.
В будущих статьях как раз хочу подробнее расписать остальные этапы и как можно применять на практике. Но каждую ситуацию надо рассматривать отдельно, очень сложно давать советы, которые будут применимы всегда и везде.
При работе с тимлидами использую вот такой список литературы: https://github.com/wowworks-team/developer-roadmap/blob/master/FAQ_PM.md и много материалов в файле Развитие тимлида.
Если нужно,то могу пояснить, объяснить какие-то моменты со схемы в миро голосом в частном порядке.
Бывает еще кровавый Энтерпрайз в который нельзя просто так взять и внедрить CI/CD - вы пилите у себя код по всем канонам а потом отгружаете апдейт файлами в закрытый корпоративный контур местному админу и молитесь чтобы ничего не отъехало при обновлении. Там же бывают ситуации, когда приходится в режиме "шеф, все пропало" править прод. Иногда по телефону. По тем же причинам. Sad but true.
Я проходил программу в стартап-инкубаторе в Минске. В моем наборе было примерно 25 стартапов. Состою еще в нескольких немалых стартап-комьюнити.
Хочу дополнить, что одной из самых плохих практики в разработке на ранних стадиях являлась сама разработка, когда еще рано пилить.
Если встречаю новых стартаперов, всегда начинаю с "последнее, что вам надо будет делать – разрабатывать". Часто вплоть до раунда А можно существовать на ноукоде/лоукоде. У нас, например, приложение с 4к пользователей и кучей проверенных гипотез собрано на FlutterFlow. Правки вносятся невероятно быстро, первую версию из нарисованного дизайна собрали за 13 дней на iOS и Android сразу. А первые тесты (дошли до примерно 1300 пользователей) проводили в MVP, в котором механика приложения была проверена на боте, собранном в Bothelp.
Ноукод и лоукод — это в большинстве случаев тоже код, только на неудобном языке программирования. И их разработка — это тоже разработка.
Если вы ничего не разрабатываете- значит, вы просто перепродаёте чужие решения. Не то чтобы это было чем-то плохим — но стартапом такая деятельность называться не может.
Ноукод и лоукод — это в большинстве случаев тоже код, только на
неудобном языке программирования. И их разработка — это тоже разработка.
Соглашсь, но с оговоркой, не на неудобном, а на узко специалтзированном. Такие вещи обычно очень хороши, пока ты работаешь в парадигме, но вот выйти из неё сложно, а порой даже невозможно.
Плохие практики разработки, которые до сих пор встречаю в стартапах