Привет, я Виктор. Двенадцать лет назад я пришел в веб-студию в Самаре. Так начался мой путь в разработке. У нас не было гита, CI/CD, тестовых стендов и много чего еще. Я видел, как это мешало развитию команды и бизнеса. Приходилось на ощупь собирать грабли, открывать для себя хорошие практики и внедрять их. С тех пор успел поработать старшим разработчиком в российском финансовом холдинге и немецком b2b-стартапе. Был тимлидом в фудтех-проекте, СTO в образовательных стартапах для российского и латиноамериканского рынка — и почти везде поначалу натыкался на похожие проблемы. Недавно переехал в Израиль, стал консультировать стартап. И что бы вы думали…
Ниже собрал примеры из практики, как мы стреляем себе и бизнесу в ногу, хотя казалось бы, цель в стартапе — “бежать быстро”. И выложил схему, как можно это починить, которой сам обычно пользуюсь. Она и побудила меня написать этот пост. Найти схему можно в конце поста.
Нет Git, разработка ведется на продакшн-сервере
Классическая история, когда проект стартует с одного разработчика. Он что-то делает, заливает по FTP, тестирует и правит прямо на проде. Может быть, где-то и есть репозитории, но они пустуют или не обновляются.
Затем бизнес масштабируется, нанимаются разработчики. И тут случается интересное. Например, как-то раз такой товарищ, работавший один и без гита, затер пару дней моей работы. Благо, я привык пользоваться системой контроля версий в любых проектах и ситуациях. Вопрос, что было бы с его кодом, затри я его... Чтобы продать команде стартапа идею "гит нужен, он даст бэкапы и поможет масштабироваться", я сделал презентацию и выступил на пятничной встрече за пиццей. И помогло. Когда прод упал, а второй разработчик был не на связи, я хотя бы смог понять, что он менял. И относительно быстро исправить ошибку.
Нет код-ревью
Я пришел в проект, где из прошлой команды уже никого не осталось. Встала задача сменить один вид пагинации на другой. Казалось бы, делов, - зайди в функцию и поменяй за 2 минуты. Но замену сделать нельзя, потому что предшественник использовал хитрую схему: копипасту кода, в которую каждый раз вносил какие-то изменения. Итого, у нас 200 вхождений и геморрой с их правкой вручную на 3 дня. Думаю, ревью от любого коллеги эта хитрая копипаста не прошла бы.
Но хорошо, тогда у меня было хотя бы время посидеть, подумать и сделать лучше. Вот пример, когда отсутствие ревью оказалось критичным. Новый проект. CRM, основа всего бизнеса, тормозит. Нужно чинить, менеджмент давит. Разработчик решает проигнорировать стандартные процессы: код-ревью, тестирование, запуск автотестов. Просто сразу пушит в гит и релизит. CRM падает совсем. Оказалось, в условиях стресса, когда “надо прям вот сейчас”, человек допустил ошибку в коде. Гораздо безопаснее, если бы коммит посмотрел кто-то еще. Имхо, в критических условиях можно проигнорировать автотесты, если они крутятся долго. Но не стоит игнорировать код-ревью.
Нет CI/CD
На одном проекте, куда я пришел, ребята релизили вручную через git pull. Сайт при этом регулярно падал. Например, как-то раз попросту не сделали установку пакетов. У поддержки, бизнеса и пользователей копились вопросики к команде. После настройки CI/CD ситуация магически исправилась.
В другой раз наличие git и CI/CD сильно помогло нам то самое “релизить быстро”. Понадобилась немецкая версия сайта, причем срочно и чисто как лендинг для показа потенциальным инвесторам. Имея автоматизированный процесс развертывания и создания новых тестовых серверов на базе CI/CD, мы быстро обрезали все ненужное, подняли отдельные базы, залили переводы - и вуаля - превратили тестовый стенд в сайт для показа инвесторам.
Нет прозрачного процесса постановки задач
Моя “любимая” история — постановка задач методом развести тред на 150 сообщений в чате. Или в личке
.
Как-то у нас был общий чат с колл-центром. И был QA, в задачи которого входило фильтровать информацию в чате, уточнять детали и если действительно всплывал баг — заводить задачу в трекере. Но сотрудники колл‑центра быстро сообразили, что если писать в чат, то им будут по всей форме задавать всякие уточняющие вопросы, просить скриншотов, урлов и других «сложных» вещей. А вот если писать напрямую «тестировщику Жене», он в половине случаев поправит что‑то быстро через админский доступ.
QA был полностью уверен, что делает доброе дело, а на деле из‑за неизвестных другим багов и масштабов ручной работы мы теряли деньги. Все вскрылось после ухода человека из компании. На нас обрушился шквал новой информации и мелких, но противных багов, которые пришлось срочно исправлять.
А как‑то раз удалось такое пресечь. Появилась «важная» задача, интеграция с большим клиентом. Менеджер в обход всех процессов пошел к разработчику ставить задачу голосом: «Не надо даже думать, просто сделай, как я говорю». Благо, команда уже научилась работать по процессам. Обсудили на дейлике, внесли в трекер. Пошли исследовать и задавать вопросы. Оказалось, методом «не думая» мы могли слить всю коммерческую базу.
Нет правила "1 задача=1 ветка в коде"
Мы делали новый большой кусок системы, который уже ждали платящие клиенты. Запуск должен был принести нам много денег. Каждый день задержки, наоборот, эти деньги съедал. Вместе с командой декомпозировал все на отдельные максимально независимые куски, чтобы мы могли зарелизить функционал как можно быстрее, а различные хотелки и доделки пилить уже в процессе.
Создал в трекере 10 задач, но ребята решили делать их в одной ветке. В итоге дедлайн был вчера, но зарелизить мы не можем: в одной из некритичных задач критичный баг, который быстро не исправишь. При этом, если бы не общая ветка, мы без проблем могли бы зарелизить остальные 9 задач - и запустить систему. После разбора команда приняла подход. Но что интересно, когда я переходил в другую команду, нам пришлось проходить подобный “восхитительный” опыт заново.
По мере роста не заводятся автотесты
Некоторые стартапы живут долго. И копят легаси. Сам я пришел к автотестам как раз потому, что мне было сложно тестировать проекты с историей, к которым я присоединялся. Хотелось автопроверок, чтобы быть уверенным, что моя правка ничего не сломает.
Но был в одном проекте разработчик, который вместо покрытия легаси автотестами хотел все «переписать с нуля». Очень хотел. Я дал ему попробовать переписать кусок с нуля. Он зарелизил свои правки и положил некритический функционал сайта. Все переписанное пошло на помойку, потому что вернуть старый код было дешевле, быстрее и проще. И на «контролируемых потерях» узнал что такое, постмортем. А в качестве своего рода урока человек писал автотесты.
Нет мониторинга ошибок
Часто в стартапах есть чаты с ранними или активными пользователями. И вот приходит к тебе поддержка или продакт, говорит, «у пользователя не работает» (а дальше варианты: «то, не знаю что», «вот это, но деталей не знаю» и так далее). Если у тебя работает, пойти и выяснить, что именно и как не работает — адище. Ты получаешь обрезанный скриншот. Или просто повтор в духе «все еще не работает, почините СРОЧНО» — например, от того же пользователя.
Пока мы не подключили систему мониторинга, о том, что лежит сайт, мы узнавали с задержкой минут в 10 в лучшем случае. От пользователей. С мониторингом мы наконец-то стали устранять баги до того, как нам напишут. А бонусом не раз вскрывали по логам критические баги — например, то, что заказ на сайте как бы создается, но в базу не сохраняется.
Вместо выводов
Вы спросите — так зачем же ты ешь кактус продолжаешь работать в основном стартапах?! Мне нравится выстраивать процессы из хаоса. За это время я заметил, что у таких проектов две беды. Не ведется работа с людьми. И нет нужной автоматизации. Поэтому остается два пути. Образовывать людей. И внедрять проверенные временем инструменты и практики везде, где только можно: если все совсем плохо, то начать с организации релизов через CI\CD. В рамках этого придется и о git договориться, и код-ревью внедрить. А все вместе послужит хорошей базой для дальнейших улучшений: организации процессов, наладки мониторинга и так далее.
Пройдя оба пути, вы получите совершенно другой уровень скорости и качества разработки. Сам я обычно иду по такой схеме. Если захочется обсудить или дополнить ее в комментариях — буду рад и благодарен. Ну и конечно же делитесь своими историями!
Комментарии (124)
Hamlet_dat
00.00.0000 00:00+15Описанных проблем не встречал уже лет 5.
Чтобы без git, так вообще давненько.
Где автор таких находит?
anzay911
00.00.0000 00:00+3А сколько компаний перепробовал?
Hamlet_dat
00.00.0000 00:00+2Так или иначе за последние годы взаимодействовал с почти тридцатью командами разработки и двумя десятками одиночек.
Я не исключаю, что просто у меня такое окружение ввиду специфики взаимоотношений, но чтобы появился кто-то, кто работает без git, такого не было вообще. Это в целом, ИМХО, начало начал.
Более того, даже большинство одиночек практикуют CI/CD и вполне нормально отслеживаются задачи по коммитам. GitHub, GitLab, Bitbucket. Предпочтения разные у людей, но пользуют все.
Может, конечно, команды, которые варятся сами в себе, позволяют себе такое... не отрицаю.
Ivan22
00.00.0000 00:00+2от технологий зависит, BI разработчки до сих пор ни в PowerBI ни в Tableau ни в чем другом в 99% случаев гит не используют.
Hamlet_dat
00.00.0000 00:00Как мне кажется, перечисленный Вами инструментарий - это всё же не про написание кода.
Само собой, мы не обсуждаем, например, использование git при работе в Photoshop или чем-то, отличным от кода.Ivan22
00.00.0000 00:00там полно кода например на DAX в PowerBI, или на Python + R в Tibco или на JS в Cognos. Но он зашит внутри тула
Hamlet_dat
00.00.0000 00:00+1"Полно кода вместе с чем-то еще" и "код" - это разные вещи.
В общем, если git применим, то он должен использоваться и все это давно понимают.
Если git неприменим или применим с массой оговорок, соглашений и костылей, то зачем об этом в принципе говорить?
Ivan_Fedyanin
00.00.0000 00:00+4недавно в таком участвовал. и все на прод, и без гита.
все бывает
RomanistHere
00.00.0000 00:00+2Очевидно, что всё может быть, но когда ты читаешь "стартапы" в названии, первая мысль про команды профессионалов, которые разрабатывают что-то на грани новых технологий, а не про челов, которые, не читая новости из мира разработки за последние 15 лет, решили п̶о̶г̶о̶в̶н̶о̶к̶о̶д̶и̶т̶ь̶ написать приложуху.
Зачем про них вообще писать? Если бы они читали статьи, они бы не стали делать так, как они делают. А люди, которые читают статьи (и прочитали эту), наверняка понимают, что без гита на прод сервере изменения делать это полнейшее невежество по отношении к клиентам, пользователям и себе. Типа фарм плюсиков на джунах?
YegorP
00.00.0000 00:00+3когда ты читаешь "стартапы" в названии, первая мысль про команды профессионалов, которые разрабатывают что-то на грани новых технологий
Стартапы запускаются не только прожжёнными программистами и не только для них. В этих случаях код получается очень "бизнесовым", без всех этих ваших абстракций в самом коде и в процессах вокруг него.
Сам участвовал в переписывании таких стартапов когда код уже невозможно развивать дальше базовой реализации изначальной идеи. Заказчик приходил с backup.zip от предыдущей команды, и даже папочки /.git внутри не было (не значит, что всегда не было, но разбираться с этим уже никто не будет).
PowerMetall
00.00.0000 00:00Заказчик приходил с backup.zip от предыдущей команды, и даже папочки /.git внутри не было
Вот прямо сегодня скинули точно такой же проект (старая контора закрылась, старая команда разбежалась, проект передали нам). Только там еще и дампа структуры БД нет, придется по коду смотреть и додумывать ))
RomanistHere
00.00.0000 00:00-2Какой же это стартап? Сейчас модно называть прототип сайта, который ты сделал стартапом, но когда я вижу статью "плохие практики, которые я встречаю в стартапах" - я не ожидаю (теперь уже ожидаю) увидеть про двух челов, которые в фотошопе цсс сгенерили абсолютами. Нафига мне вообще про такое читать? Ладно бы на виси статья, а тут вроде тех. ресурс был когда-то. Видимо пора закругляться с хабром по-тиху.
DMGarikk
00.00.0000 00:00+2Какой же это стартап?
зажрались, есть два вида стартапов:
контора, с бюджетом лямов 150 на полгода, 15 разработчиками и офисом в москва-сити — это нормальный стартап которого будут рассматривать фонды как цель для развития и финансирования (на сумму в 15лямов с условием 60% доли… хаха… нервный смех)
и вот тут можно неспеша поиграть с процессами
===
А есть, когда два-три чела на коленке собирают прототип и умудряются поднять с ним продажи
вот данная статья — про второй вариант, и он существует. спуститесь с небес на землю, люди до сих пор умудряются с нуля создавать бизнесы и таких довольно много, просто с верхних этажей москвасити и бюджетами в сотни лямов — кажется что все остальные нищеброды неудачникиRomanistHere
00.00.0000 00:00-2хз что за слепая ненависть к... даже не знаю кому, но да ладно - когда у тебя прототип на коленке, это ещё не стартап. Это МВП, пруф оф концепт - частично реализованная идея стартапа. Челы, которые называют себя стартапами на данном этапе это как если бы студенты первого курса называли себя докторами.
стартап начинается когда ты сделал МВП, запустил, оно показало что можно двигаться дальше и ты/вы это делаете уже всерьёз. Ключевое слово. Всерьёз и всё то, что автор написал в статье не сочитается ну никак.
если не сложно, привидите примеры "стартапов" в вашем понимании, которые собраны в конструкторе на коленке, и умудряются зарабатывать. Где работают программисты не выше уровня "стажёр", которые не знают про вещи, написанные в этой статье. Если что, называть маркетплейс купленный и развернутый на каком-то сервисе стартапом это как называть верстальщика, пишущего штмл и цсс онли, программистом. Технически можно доказать что цсс это язык по тьюрингу, но стоит ли?
DMGarikk
00.00.0000 00:00+2если не сложно, привидите примеры «стартапов» в вашем понимании, которые собраны в конструкторе на коленке, и умудряются зарабатывать. Где работают программисты не выше уровня «стажёр», которые не знают про вещи, написанные в этой статье.
ну я в таком работал, контора плюс-минус работала с 12 по 22 год (пока не обрубили гуглплей, а у инвесторов не возникли известные проблемы)
контора начиналась с сделанного на коленке в конструкторе приложений — приложения, и успешно зарабатывала деньги, потом когда денег стало достаточно, привлекли меня и переписали этот ужас на более менее вменяемом стеке (тем не менее почти все недостатки описанные выше были, из-за ограниченного бюджета)
потом активную разработку приостановили и просто работали с клиентами, параллельно договариваясь о следующем раунде финансирования… а потом наступил 22 год
==
у меня честно говоря пригорает когда мне тыкают 'а, у тебя нет 100500млн, чё ты ваще в бизнес суешься, тут большие дяди!!'… вот блин нет, тут ИТ и тут реально собрать бизнес из желудей и спичек и оно полетит
бизнес это про продажи, а не про пайплайны в гитлабе и красивый код на проде
MiraclePtr
00.00.0000 00:00+6Ха! Веб-разработка, стартапы... Да половина отечественного embedded и АСУТП так работает даже в 21 веке. И это я сейчас не шучу и не преувеличиваю.
Причем в таких, казалось бы, проектах, где важно качество результата и соответствие требованиям (цена ошибки очень высока, вплоть до экологических катастроф).
YegorP
00.00.0000 00:00+7Курица - не птица, АСУТП - не программирование... Спокойно-спокойно, сам из АСУТП. Лет через 20 там обязательно будут бранчеваться и терраформить инфраструктуру кодом.
По состоянию на 2016-й, когда я ещё был занят в той сфере, там был жёсткий vendor lock-in. Хочешь побаловаться гитом? На, попробуй проект в бинарном формате и/или с графическими языками. Хочешь в другую IDE? На, попробуй проект в бинарном формате и/или с графическими языками. Хочешь портировать проект на другой контроллер? Написать автотесты? Ну вы поняли... А если ещё хоть какая-то мотивация осталась, то вот тебе вендорские расширения к IEC 61131-3, дружок; они не совместимы ни с чем, и только вендор знает что там у них под капотом. Короче, плохо всё.
За эмбеддеров ничего не скажу, впрочем.
MiraclePtr
00.00.0000 00:00Для графических языков и бинарных файлов есть проблема с diff'ами и слияниями, однако версионирование и распределенное хранение для них работает точно так же хорошо как и для всего другого, поэтому есть смысл использовать VCS хотя бы для этого. Сименс, вон, в свою WinCC поддержку контроля версий всё-таки завёз, насколько я знаю.
АСУТП - не программирование, но в одном шаге от него.
Например, бывает попадаются ПЛК, код для которых пишется на Си. Какие-нибудь там SCADAPack, Advantech или ICP-DAS илиьочередныеттворения каких-нибудь отечественных сумрачных "импортозаместительных" гениев.
Или на волне импортозамещения и санкций, когда железки от иностранных вендоров пропали вообще или стали стоить неприлично, то фирма решает запилить свое производство аналогов каких-нибудь модулей ввода-вывода, конвертеров протоколов или вторичных преобразователей - и к ним надо писать прошивку на том же Си.
На верхнем уровне HMI может быть очень плотно обскриптован с кучей кода и логики.
Или нужно дописать .dll'ку плагина/драйвера для OPC-сервера, а то и отдельный OPC-сервер для какой-нибудь диковинной железки с необычным протоколом.
Или нужен сервис-адаптер, который будет данные из базы вашей SCADA лить в какую-нибудь смежную систему по одному им известному методу в одним им известном формате...
Вот тут то и начинается чистое программирование, правда, зачастую качество этого программирования такое, что на код без слез не взглянешь, и процессы выстроены в точности так, как ужасы описанные в посте...
Toloymak
00.00.0000 00:00+1То же кажется, что если человек без гита начинает писать любой (особенно бизнесовый) код, то дело тут не в стартапа... Он и в энтерпрайзе может крошить все без коммитов в течении месяца.
VladimirFarshatov
00.00.0000 00:00+9В программировании с 1979года. Видел многое, в том числе и всё описанное в статье. Но .. ровно также видел как эти рекомендации исполнялись, мягко скажем через "задний проход".. к примеру:
версионирование. Да, был SVN (гита ещё не было в природе), продакт поднимался из специальной ветки, мастер - то что оттестировано и готово заливаться на прод, стеджинг с песочницей и ветки по трекерам задач .. "всё по уму", кроме мелочи: ветки разработки (8 программистов в команде) часто конфликтовали промеж себя и мердж делал тот, кто лил в стейджинг. Автотестов ещё не было, QA тестировал новый трекер и давал "добро" в мастер .. в итоге старый код, поломаный мерджем легко попадал в прод..
-
коде ревью. 2 программиста - 4 мнения о коде.. на многих местах коде ревью выливалось или в долгие обсуждения, если не споры или .. "я начальник - ты дурак".. в итого, сроки разработки срывались неоднократно. Польза? она есть конечно, когда ревьюер примерно равен или выше по опыту чем разработчик, но не наоборот..
В этой части интересен опыт разработки "хирургической бригадой". Имел всего дважды, но оба раза воспоминания только положительные.
Мониторинг ошибок, даже больше, ведение журнала ошибок .. видел ровно 1(один) раз, было крайне полезно. Как правило, не доводится до ума и часто (особенно сейчас) вижу ситуацию когда исправление новой ошибки приводит .. к появлению пары новых. Релиз месячной разработки в итого растягивается до полугода..
как-то так, на моей практике. Но, в теории - все исключительно "за". ;)
vitaly_il1
00.00.0000 00:00+3Да, был SVN
Вначале был CSV :-)
VladimirFarshatov
00.00.0000 00:00Да, запамятовал уже.. Ещё раньше было хранение версий в отдельных папках на компе... ;) Ещё раньше - шкаф с полками для колод перфокарт.
nik_savchenko
00.00.0000 00:00Просветите, пожалуйста, что имеется ввиду под опытом разработки "хирургической бригадой", если не затруднит.
VladimirFarshatov
00.00.0000 00:00+1Хорошо было описано в работе (Баррон?) по истории создания ОС 360. Лучше не напишу.. извините. ;)
victor_1212
00.00.0000 00:00-1>В программировании с 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
DMGarikk
00.00.0000 00:00+3бая экзотика мешающая пониманию кода вырывается с корнем, это по части project leader, при повторении может быть увольнение,
стаж работы людей примерно 8-10 лет
кхм… жуть, честно говоря какаято ;)
я разок так работал:
«есть точка зрения лида и неправильная, в нашей компании работают люди только с правильной точкой зрения»
это такое болото было… жесть…
отсюда кстати растут всякие забавные казусы (не в моем случае, но я такое видел в соседнем отделе)
автоматизация на bat файлах (не шелл, именно bat и на винде, потому что так понятнее и надежнее)
докер — никому не нужная молодежная хрень, только хардкор, только железные сервера, в серверной стойка — отдельно dns отдельно apache (nginx сложно и не нужно… парадокс) отдельно сервис-монолит, отдельно БД, каждый сервер железный
предлагать решения которые непонимает и непринимает лид — нельзя (я бы сказал запрещено, прям как вы описали с увольнением)
я оттуда ушел, как из тюрьмы вырвалсяvictor_1212
00.00.0000 00:00> кхм… жуть, честно говоря какаято
это не FAANG конечно, в основном про работу на дороге 128/495,там где делают oem, в том числе embedded
sved
00.00.0000 00:00-2докер — никому не нужная молодежная хрень, только хардкор, только железные сервера, в серверной стойка — отдельно dns отдельно apache (nginx сложно и не нужно… парадокс) отдельно сервис-монолит, отдельно БД, каждый сервер железный
Ну вот и пришло поколение людей которые не знают как без докера приложение развернуть ....
DMGarikk
00.00.0000 00:00+4«но зачем?» ©
==
я как раз из поколения которое без докера все разворачивало… но вот только появление докера я воспринял как чудо какоетоsved
00.00.0000 00:00+1Ну раз у вас монолит и вы это восприняли это как чудо, то:
Вы делали что-то не то
Не пробовали и не умели работать с аналогами
А по поводу зачем, но во первых это дополнительный компонент, а значит дополнительная точка отказа и дополнительные усилия на его поддержку.
Во вторых у докера есть ограничения, например, нельзя кастомизировать ядро.
DMGarikk
00.00.0000 00:00Вы делали что-то не то
всмысле чтото не то?
как вы представляете себе процесс быстрого масштабирования сервиса если это нужно срочно, а он у вас на железном сервере стоит? искать срочно свободную железку (или правильно планировать чтобы таких ситуаций не было? ха!) и там всё разворачивать?Не пробовали и не умели работать с аналогами
пример?А по поводу зачем, но во первых это дополнительный компонент, а значит дополнительная точка отказа и дополнительные усилия на его поддержку.
пока мой опыт показывает что кубер или swarm гораздо надежнее и проще чем собирать кластер по старинке вручную, и организовывать менеджмент конфигураций и создание образов серверов.
а потом еще обновление ОС делать перекрестившись и обложившись неплановыми бекапами
у меня были блейд сервера под управлением vmware… этож адовый оверхед по памяти как минимум, держать полноценные (хоть и виртуальные) машины под вебсервера например или под dns или ad (хотя конечно хотябы один контроллер должен быть железным)sved
00.00.0000 00:00+1всмысле чтото не то?как вы представляете себе процесс быстрого масштабирования сервиса если это нужно срочно, а он у вас на железном сервере стоит? искать срочно свободную железку (или правильно планировать чтобы таких ситуаций не было? ха!) и там всё разворачивать?
Если у вас нет свободных железок, то как вы собираетесь докеры масштабировать? Если же есть ресурсы на существующем то увеличить число потоков в настрйоках приложения и добавить памяти. Не надо приписывать докера волшебные свойства которыми он не обладает
пример?
Вы это серьёзно или вы на самом деле не знаете аналогов?? https://en.wikipedia.org/wiki/OS-level_virtualization
пока мой опыт показывает что кубер или swarm гораздо надежнее и проще чем собирать кластер по старинке вручную
Если вы что-то делали вручную, то см мой комментарий, про то что вы что-то делали не так.
организовывать менеджмент конфигураций
Докер этого не отменяет.
а потом еще обновление ОС делать перекрестившись и обложившись неплановыми бекапами
С докером вам надо креститься в 2 раза чаще - сначала при обновлении хоста, потом про обновлении докера. См мой комментарий про дополнительный компонент и соответствующее уменьшение надёжности.
у меня были блейд сервера под управлением vmware
Ну кто вас заставлял есть кактус. Для линуксов в основном юзается KVM и XEN. KVM насколько я знаю к памяти бережно относится.
Но, в любом случае, не путайте контейнеризацию с виртуализацией
DMGarikk
00.00.0000 00:00Вы это серьёзно или вы на самом деле не знаете аналогов?? en.wikipedia.org/wiki/OS-level_virtualization
Я вообще не о самом докере как софтине говорю, а о принципе скорее именно принципе контейнеризацииЕсли у вас нет свободных железок, то как вы собираетесь докеры масштабировать?
сервисы масштабировать, а не докерыЕсли же есть ресурсы на существующем то увеличить число потоков в настрйоках приложения и добавить памяти.
приложение может не уметь (плохо уметь) в многопоточностьsved
00.00.0000 00:00Я вообще не о самом докере как софтине говорю, а о принципе скорее именно принципе контейнеризации
Принцип существовал задолго до появления докера. Если вы по какой-то причине его не использовали, значит он вам не особо был и нужен.
Я вообще не вижу выгод использования докера для монолита, которых нельзя было бы достичь более простыми и стандартными инструментами.
сервисы масштабировать, а не докеры
Ну какая разница. Докер чудесными образом железок не добавит.
приложение может не уметь (плохо уметь) в многопоточность
Сложно представить такое в 2023 году
victor_1212
00.00.0000 00:00> кое-что из собственного в основном embedded ...
собственно комментарий первоначально для Владимира, типа из уважения к опыту, надеюсь что ему по крайней мере интересно, начал свою работу еще раньше чем он, видел достаточно, но писать статьи желания нет, минусование приветствуется, типа как местный обычай :)
MiraclePtr
00.00.0000 00:00+2код ревью требуется редко
Это как так? Code review требуется всегда. Ревью - это не "я не знаю как запилить или ничего не работает, помогите", речью это "ч сделал фичу, все работает, готов множить, посмотрите, все ли нормально". Потому что люди не идеальны, а N пар глаз всегда лучше чем одна. И заодно ещё повышается bus factor команды.
victor_1212
00.00.0000 00:00понимаю конечно, но зависит от практики, то что Вы описываете это типа просмотр нового (добавленного) кода перед merge на одну из веток, при интенсивной работе группы случается каждые 2-3 дня, параллельно с bug fixing, если человек новый или ситуация трудная project leader смотрит Вашу рабочую копию перед merge, проверяет, смотрит результаты тестирования и пр., наблюдает за возможными конфликтами merge рядом с Вами, при необходимости помогает, поскольку это происходит часто дополнительно привлекать людей возможности нет, если кто еще конкретно требуется конечно позовут, с другой стороны если начинается новый проект и для него пишется типа своей framework, это тот случай когда code review делается полностью, привлекаются многие типа поймать проблемы на ранней стадии, люди специально готовятся, изучают код и пр., также бывают аварийные ситуации типа что-то не получается вовремя сделать, одна из мер code review типа как выйти из этой ситуации,
короче качество кода это ответственность Ваша и project leader, если есть необходимость выделят дополнительно столько глаз сколько требуется для code review, но постоянно так группа работать не может слишком много надо сделать за ограниченное время, заметим junior вероятно вообще не встречал за много лет
Andrey_Solomatin
00.00.0000 00:00+1Работал в компании, где некоторые программисты решили что им ревью не нужно, так как оно сильно мешает.
Менеджеры были довольны, скорость закрытия задач возросла. А вот тестировщики, клиенты и те кто потом это поддерживал не радовались.но постоянно так группа работать не может слишком много надо сделать за ограниченное время
Видел такие группы, они были очень заняты переписывание существующего кода, потому, что он был плохо написан и ревью было сделано спустя рукава, исправлением ошибок, и попыткам разобраться, что не работает.
Возможно у вас не так. Или просто никто не занимается реальными подсчётами куда уходит время.victor_1212
00.00.0000 00:00везде конечно по-разному, в том числе как Вы описываете, там где работал было организовано неплохо, список компаний большой включая digital, если интересны детали пишите в личку
ps
моя область - сети и real time
Anton_Olegovich
00.00.0000 00:00+2>> Моя “любимая” история — постановка задач методом развести тред на 150 сообщений в чате. Или в личке
Это вообще самая лучшая изюминка из взаимоотношений разрабов и бизнеса. ))RomanistHere
00.00.0000 00:00фиксится любым работником компании примерно следующими словами: "не флудите плиз, напиши это в жире". Это если вдруг хочется, чтобы такого не было
Trabant_Vishnya
00.00.0000 00:00+2Потом тикет в JIRA правишь, потому что там вот такое :)
Hidden text
yoshka
00.00.0000 00:00Ага, мне один раз чувак сделал тикет с заголовком Bug, лейблом Ugrent и пустым телом.
VladimirFarshatov
00.00.0000 00:00+1Очень хочется посмотреть на того сеньора, который это напишет в вацап с Генеральным Директором градообразующей фирмы, который считает что раз он математик по образованию, то способен поставить вам ТЗ "на пальцах" прямо вот тут, в вацапе и только ваша непроходимая тупость не позволяет ему донести до вас такие простые вещи. ;)
event1
00.00.0000 00:00+2Такие вещи надо согласовать на уровне команды и донести до всех внешних соучастников. И строго следовать. Если директору охота ставить задачи вербально и напрямую, то можно выделить специального человека для перевода из директора в жиру.
Хотя, конечно, против начальника самодура бороться трудно.
Trabant_Vishnya
00.00.0000 00:00В нормальных компаниях директор обычно обмазан такими постановщиками. Другое дело, ЧТО они пишут порой в ТЗ - сильно отличается от изначальной адекватной идеи.
RomanistHere
00.00.0000 00:00Если гендиректор ничего не делает по поводу чатов с сотнями сообщений обсуждения (в которых он состоит), то:
ему глубоко плевать на чаты, работу, процессы и на всё остальное, а потому ничего не случится
он настолько неэффективен, что вчера была пора начинать искать другую работу
Trabant_Vishnya
00.00.0000 00:00+2И классическое из этих чатов:
- ВСЕ СЛОМАЛОСЬ!111
- Что сломалось, вижу по логам только сбой обновления в 02:10...- Вы что не поняли, НИЧЕГО не работает, МНЕ СРОЧНО НАДО ЗАЙТИ!1111
mrfloony
00.00.0000 00:00+3А потом сидишь, пытаешься исправить, тратишь N часов, вроде находишь решение, заливаешь, пишешь в чат, чтобы проверили...и в ответ получаешь:
- А всё ещё N часов назад заработало, ошибок больше не было, проверять не буду, занят, иди н...Trabant_Vishnya
00.00.0000 00:00Ну после такого отношения политика «тикет или GTFO» это самое гуманное, что ждет. Обычно благодарят, но от этого толку, что от золотого костыля в бархатной коробке
panzerfaust
00.00.0000 00:00+4Моя “любимая” история — постановка задач методом развести тред на 150 сообщений в чате. Или в личке
Это не так уж и плохо. Альтернатива - это когда заказчик ставит вас перед фактом, что священные скрижали ТЗ у него уже есть, и, кроме того, они уже подписаны и одобрены всем "уполномоченными органами". А вы, мартышки, теперь танцуйте с этим как хотите.
После обсуждения в чате всегда можно подбить и зафиксировать резюме для будущей самообороны.
DMGarikk
00.00.0000 00:00+6так зачем же ты ешь кактус продолжаешь работать в основном стартапах?!
горькая правда в том что такое не только в стартапах. и самый смак — что в стартапах еще чтото поменять можно, а вот в компании которой лет 20 где все замумифицировалось уже не совсем
я вот работал в одной компании, где все перечисленное в статье было, и ревью и мониторинг и тесты и вообще всё по феншую, и при этом некоторые департаменты генерили в прод такое безумие что у меня до сих пор волосы шевелятся… и начиналась тенденция 'упростить кодревью чтобы ускорить деливери'… ведь очень удобно отправлять код на ревью не овнерам продукта, а в соседний департамент… они МЕНЬШЕ ПРИДЕРАЮТСЯ и быстрее деливери!.. я пытался с этим бороться и меня чуть не уволили ;)) (а потом сократили из-за порезки костов)
EvgeniiR
00.00.0000 00:00+3упростить кодревью чтобы ускорить деливери
Но долгий, блокирующий, итеративный(нашли проблему => вернули задачу в разработку => исправили => отправили на ре-ревью) код-ревью это действительно проблема. И для деливери, и для последующей интеграции кода, и для разработчиков, которым нужно либо ждать пока пройдет ревью, либо постоянно следить за статусами нескольких задач и постоянно переключаться между ними.
Если такое происходит регулярно, стоит подумать о том, как дать разработчикам удочку а не рыбу (передача знаний для достижения общего уровня команды / неблокирующий ревью / дизайн-ревью до разработки)
DMGarikk
00.00.0000 00:00+4ну то как это решать — отдельный разговор. ревью действительно бывают токсичными, когда придираются к мелочам и держат релиз споря по нескольку дней как переносы в коде делать и т.п. вот с этим действительно надо бороться
а когда в релизе концептуальная архитектурная недоработка или вообще дырка в безопасности (меня кстати чуть не уволили когда я привлек СБ к ревью релиза из-за подозрений что сама по себе задача неверно поставлена и задержал его из-за этого на неделю) то такой ревью крайне необходим чтобы остановить выкатывание в прод всякого бреда.
в моем примере, компания была довольно крупной (более 500 человек только разработчиков) и архитектурный ревью был упразднен довольно давно (т.к. сильно замедлял релизы) что приводило к довольно большому количество копипаст-кода просто потому что нет времени разбираться, лучше впилим рядом тоже самое.
VladimirFarshatov
00.00.0000 00:00Коллега прямо сейчас сидит парсит БД с названиями таблиц "townНазвания" .. в формате EAV с такой же мешаниной анг-rus.
shasoftX
00.00.0000 00:00+1ведь очень удобно отправлять код на ревью не овнерам продукта, а в соседний департамент… они МЕНЬШЕ ПРИДЕРАЮТСЯ и быстрее деливери
Продвинутый менеджер предложил бы привлекать для ревью уборщицу. Она всё сделает ещё быстрее. И вас бы вместо угрозы увольнения премировали
morijndael
00.00.0000 00:00Мотивировать тем, что после профессиональной уборки отдавать запашком код ну никак не может :D
ivegner
00.00.0000 00:00я пытался с этим бороться и меня чуть не уволили
А я пытался с этим бороться и меня уволили.
acordell
00.00.0000 00:00+6Странно, а по моей практике все наоборот: как раз стартапы пытаются сделать все по уму. Люди с опытом наконец-то дорываются до возможности сделать так как надо, а не как сложилось из-за непонятных исторических завихрений... А вот на многолетних энтерпрайз проектах совершенно легко может оказаться дыра практически в любом месте. Так чтобы вообще не было версионного контроля, не попадалось, но то, что там какой-нибудь даже уже не ископаемый Source Safe, где все в одной куче и даже без лейблов по версии - попадалось. Несколько раз попадались проекты вообще без тестировщиков... Жесть, доложу я вам, но как она есть. Тестовые контуры обычно есть, хоть и очень далекие от боевых, а вот стейджей как правило ни у кого нет. Какие-то грабли и поперек них волшебные костылики вместо нормального CI/CD - скорее норма. Так же как и отсутствие поставленного процесса кодревью. Причем, что наши компании, что американские, большие, маленькие - никакой разницы.
gsome90
00.00.0000 00:00+2Пока стартап будет заводить CI/CD и покрывать код тестами, терять время на ревью, конкуренты на коленке слепят демо и продадутся.
rg_software
00.00.0000 00:00+3Не забывайте, что 99% процентов этих конкурентов вообще не слепят ничего работающего. Ваш гипотетический конкурент с работающей демкой, но без CI -- экземпляр из Красной книги.
Kanut
00.00.0000 00:00+2Моя первая работа была в стартапе. Причём взяли меня как раз на этапе когда стартап "продался" и из "легаси
-говнокода" надо было делать новое адекватное решение.Так там в этом легаси такое местами встречалось что у даже у джунов вроде меня волосы дыбом становились. То есть по хорошему всё работало только на презентациях и если их делал человек, который точно знал как делать презентацию. Шаг влево-шаг вправо и приложение начинало глючить или просто падало...
rg_software
00.00.0000 00:00+1Вот прикол в том, что статистически ваш стартап уже лучше 90% других стартапов, которые с таким подходом даже до этапа презентации не дошли.
Впрочем, я не утверждаю, что с первого дня надо всё делать идеально (тут и люди соответствующие требуются...), но уж прикрутить контроль версий и систему автобилда дело совсем нехитрое, и если у конторы на это не нашлось нескольких рабочих дней, вряд ли именно эта задержка определит отставание от конкурента.
Kanut
00.00.0000 00:00+3Ну контроль версий у них действительно был. Автобилда как такового не было. Но это было начало 2000-х. Тогда многие вещи из современных "стандартов" были не особо распространены.
и если у конторы на это не нашлось нескольких рабочих дней
Несколько дней здесь, несколько там. Если у вас есть всего полгода-год времени, то и несколько дней становятся долгим сроком. Плюс это ведь ещё надо найти людей, которые всё это умеют. Или дать имеющимся время чтобы разобраться.
rg_software
00.00.0000 00:00+2Да, я это понимаю. Просто если мы начинаем заниматься арифметикой типа "день тут потеряли из-за настройки контроля версий, день там потеряли из-за билд-машины, вот и отстали", то надо честно таким же образом считать время, упущенное на дебаг или просто неадекватно долгое добавление простой функции. Это ведь тоже происходит по нашей вине, а не "само собой".
Kanut
00.00.0000 00:00+4Так в том то и дело что пока проект на старте, кода мало, людей над ним работает мало(а то и вообще один человек) , все всё знают и так далее и тому подобное, то большинство "классических" проблем ещё просто не возникают.
Отдебажить код на пару тысяч строк или добавить туда новую функцию? Причём в код, который я сам писал меньше полугода назад? Да вообще не проблема.
Проблема будет через пять лет когда кода станет на порядок-два больше, менять его надо будет абсолютно новому человеку и никто уже не будет помнить что там этот код на самом деле делает и почему.
И да, если говнокодил в течении полугода-года, то потом переписывать всё заново займёт не особо меньше времени. И это тоже надо понимать.
mayorovp
00.00.0000 00:00Нормальный CI/CD настраивать нужно не день, а порядка месяца-двух (особенно когда за дело берётся человек который никогда не делал эту задачу в прошлом), если только используется не trunk-based development.
Andrey_Solomatin
00.00.0000 00:00Чем раньше начнешь, тем быстрее делать.
А в идеале заложить расчет на него в самом начале разработки.
Очень часто вижу мучительные переписывания конфигов, когда дело дошло до интеграции. Конфиги писались для локальной системы, а вот начали деплоить и тесты делать, то выяснилось, что уж очень неудобно.mayorovp
00.00.0000 00:00Если на проекте всего один разработчик — то чем раньше он начнёт делать CI/CD, тем позже он приступит к, собственно, написанию кода.
Конфиги же на локальной системе, на отладочном стенде и на проде будут отличаться всегда, это данность. И избежать их мучительного переписывания можно только одним способом — не делать их мучительными, он времени появления CI/CD оно не зависит.
Andrey_Solomatin
00.00.0000 00:00Если на проекте всего один разработчик — то чем раньше он начнёт делать
CI/CD, тем позже он приступит к, собственно, написанию кода.
Если есть опыт, то это не так долго так что CI можно и сразу. А CD в превые дни и не нужен. Но начать получать доступы можно и сразу, иногда это месяцы.Конфиги же на локальной системе, на отладочном стенде и на проде будут отличаться всегда, это данность
Не то чтобы сильно разные, после того как везде запустили.
И избежать их мучительного переписывания можно только одним способом —
не делать их мучительными, он времени появления CI/CD оно не зависит.
Зависит, когда CI/CD есть ты делаешь сразу чтобы работало.
А когда нет то делают как получится.
Работал с приложением на Spring. Для деплоя скриптом распаковываешь war (Web application Archive) файл, меняешь sedом плейсхолдеры в файле с настройками, запаковываешь обратно, вот и система готова к запуску.
Вишенкой на торте было то, что перед тем как выполнить этот скрипт, на него накладывался патч.mayorovp
00.00.0000 00:00Не то чтобы сильно разные, после того как везде запустили.
Если в разных конфигах есть совпадающие элементы — что они вообще делают в конфиге?
Работал с приложением на Spring. Для деплоя скриптом распаковываешь war [...] меняешь sedом плейсхолдеры в файле с настройками
Если распаковку war я ещё могу как-то понять, то вот плейсхолдеры в файле настроек выглядят дико. Откуда скрипт вообще берёт данные для этих плейсхолдеров, и почему из этого источника не может взять данные само приложение?
Andrey_Solomatin
00.00.0000 00:00то вот плейсхолдеры в файле настроек выглядят дико
Всё было хорошо пока деплоли сами и руками. А как оказалось, что деплоить будут другие люди, то пришлось срочно сделать автоматический деплой. А конфиг это текстовый файл внутри докер образа, внутри war архива. А параметры которые нужно вставлять были нам не доступны.
Сделали быстро, без ревью. По быстро я имею ввиду "нужно еще вчера", это никак не связанно со скоростью выкатывания рабочей фичи. Выкатывали долго и болезненно.
Если бы заренее начали переписывать всё это на кубернетес какой-нибудь, то потратили бы столько же времени, только без нервотрёпки и потерь репутации.Откуда скрипт вообще берёт данные для этих плейсхолдеров, и почему из этого источника не может взять данные само приложение?
Вы задаёте правильные вопросы.
Вся эта ситуация случилась через несколько лет после появления стартапа. По отдельности отстутсвие CI/CD на старте, спешка в один из моментов и отсутствие код ревью может быть прошли бы не так болезненно, но вместе они наложились и получилось очень хреново.
Можно ли сделать сразу и нормально? Если есть опыт делать нормально, то да. Но к сожалению, он не так часто встречается. У меня опыта как не надо намного больше, чем как надо. В общем оригинальная статья как раз о том, что можно сделать нормально сразу при старте проект.
fomiash
00.00.0000 00:00+2Хорошая статья, но остается незавершенность. Общий посыл - "раз у меня однажды сломалось, подход плохой". Нет какого-то исследования что-ли, почему так, а не иначе, поступать другим. Такое ощущение, что проекты в которые вы не приходили - обречены) Одно из отличий стартапа в первые месяцы - большой процент, что это просто демо, которое после испытаний положат в стол. А вы приравняли стартапы, которые уже нашли нишу к только образованным. Естественно, гит нужен везде, с этим не спорю.
Andrey_Solomatin
00.00.0000 00:00Очень много коментариев про скорость разработки. Но я не видел, чтобы кто-то это измерял нормально.
Скрость для ленивых, это скорость закрытия задачи и мердж кода в ветку. Если еще когда тестировщик найдёт баг, не переоткрывать задачу а создать новую, так еще и медаль за количество закрытых задач можно получить. То есть, измеряют только первую часть цикла, а остальное остаётся за кадром. Для менеджмента просто счастье, чтобы отчитаться.
Я ни разу не работал в комании, которая пытается оценить скорость разработки фичи от и до. Были попытки следить за количесивом переоткрытых, но не взлетели. Мой опыт мне подсказывает, что при таком измерении, сделать первую часть абы-как а потом посмотрим, не всегде быстрей чем подумать и сделать нормально.
Да есть прототипы, где есть только начальная часть и нет хвоста и там можно фигачить не думая. Но большинство задач обычно живут в продакшене более полугода, а потом еще и эволюционируют.
Есть у кого реальная статисика по скорости, по который можно оценить подходы?
Мартина Фаулер териотезирует о скорости разработки через качество архетиктуры. Отстутствие архитектуры даёт хороший старт, наличие выигрывает в долгосрочной перспективе. На его взгляд, точка пересечия это недели, даже не месяц.
https://martinfowler.com/bliki/DesignStaminaHypothesis.html
kisskin
00.00.0000 00:00Сейчас такие времена, что пока "семь раз отмеришь другие уже отрежут".
Поэтому в идеале всё написано правильно,а в реалиях делают всё как можно быстрее, а это далеко не всегда так как правильно.
fominslava
00.00.0000 00:00+2Классическая история, когда проект стартует с одного разработчика. Он что-то делает, заливает по 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 вообще рекомендует использовать техники парного программирования, в чем действительно есть определенный смысл, хотя недальновидным менеджерам такое предложение вряд-ли сильно понравится… :)
glendemon Автор
00.00.0000 00:00Полностью согласен, что везде требуется здравый смысл и нужно смотреть по каждой конкретной ситуации какой подход лучшего всего применим.
SkiperX
00.00.0000 00:00Посоветуйте, пожалуйста, что почитать из литературы на тему организации процессов, и внедрению всего того, что есть на схеме в миро
glendemon Автор
00.00.0000 00:00Довольно сложный вопрос. К сожалению, не могу назвать пару книг, после которых можно пойти легко реализовать любой процесс.
В будущих статьях как раз хочу подробнее расписать остальные этапы и как можно применять на практике. Но каждую ситуацию надо рассматривать отдельно, очень сложно давать советы, которые будут применимы всегда и везде.
При работе с тимлидами использую вот такой список литературы: https://github.com/wowworks-team/developer-roadmap/blob/master/FAQ_PM.md и много материалов в файле Развитие тимлида.
Если нужно,то могу пояснить, объяснить какие-то моменты со схемы в миро голосом в частном порядке.
ncix
00.00.0000 00:00Бывает еще кровавый Энтерпрайз в который нельзя просто так взять и внедрить CI/CD - вы пилите у себя код по всем канонам а потом отгружаете апдейт файлами в закрытый корпоративный контур местному админу и молитесь чтобы ничего не отъехало при обновлении. Там же бывают ситуации, когда приходится в режиме "шеф, все пропало" править прод. Иногда по телефону. По тем же причинам. Sad but true.
Govar
00.00.0000 00:00Я проходил программу в стартап-инкубаторе в Минске. В моем наборе было примерно 25 стартапов. Состою еще в нескольких немалых стартап-комьюнити.
Хочу дополнить, что одной из самых плохих практики в разработке на ранних стадиях являлась сама разработка, когда еще рано пилить.
Если встречаю новых стартаперов, всегда начинаю с "последнее, что вам надо будет делать – разрабатывать". Часто вплоть до раунда А можно существовать на ноукоде/лоукоде. У нас, например, приложение с 4к пользователей и кучей проверенных гипотез собрано на FlutterFlow. Правки вносятся невероятно быстро, первую версию из нарисованного дизайна собрали за 13 дней на iOS и Android сразу. А первые тесты (дошли до примерно 1300 пользователей) проводили в MVP, в котором механика приложения была проверена на боте, собранном в Bothelp.
websitedev
Думаю, многие стартапы идут путем переписывания спагетти-кода и выстраивания процессов, когда стартап уже выстрелил. Потому что написание плохого кода по-быстрому в начальном этапе обходится дешевле. В начале для создателей стартапа самая приоритетная задача, это когда кликаешь всё заработало. А об улучшении системы задумываются только, когда начинаются проблемы и торможения.
arkamax
У кого-то может это и работает. Я подрабатываю сейчас на стартап, шестой год идет коду, функциональность расширена процентов так на 500 за это время. Автотесты и гит были со второй недели - стало ясно, что иначе добром это не кончится. К чему это говорю - "выстрел" может случиться через годы, и тогда писать тесты с нормальным покрытием будет в разы сложнее (особенно когда сверху давят расширять функционал итп).
centralhardware2
6 лет это конечно формально стартап, но фактически от обычной компании уже отличается не так сильно. Выше все таки шла речь об ситуации когда все пилится бесплатно, вообще без какого финансирования или инвестиций и тогда у тебя блин нету 6 лет на то чтобы написать код по красоте
panzerfaust
Давайте уточним. Не написание плохого кода, а найм говнокодеров. Нет такого принципиального закона природы, согласно которому писать говнокод быстрее, чем писать по-человечески. Профессионал пишет чисто и быстро даже в условиях недостатка информации - на то он и профессионал. А вот нанять вместо профессионала черт знает кого - это у стартаперов всегда пожалуйста.
shasoftX
В условиях недостатка информации даже профессионал напишет говнокод. Не потому что он так хотел, а потому что он писал чистый код по другой постановке.
Банальное разделение по функциям/классам мог сделать исходя из других соображений. А когда другой разраб будет вносить правки в этот код по уже другой постановке, то уже и будет "что за говнокод тут написан, ведь теперь фиг поправишь быстро"
Andrey_Solomatin
Недостаток информации, это просто понимание, что потом надо будет этот код развивать. В общем это та ситуация в которой все разработчки и живут. С этими вводными можно написать хороший код, который будет решать текущую задачу и готов к изменениям. Да через полгода этот код может стать плохим, но это не значит, что сейчас его надо делать плохим прямо здесь и сейчас.
> Банальное разделение по функциям/классам мог сделать исходя из других соображений
Если вообще не угадали, то код который разбит на модули переписывать намного проще, чем код написанный одной функцией.
А если почти угадали, то разница между обновить модульный код и спагети будет просто огромной.
Layan
Это в случае, если код разбит так, что его действительно можно изменить под новые требования.
Andrey_Solomatin
Читаемость очень сильно коррелириет с цикломатической сложностью. А сложность с разбиением на модули.
Код разбитый на модули обычно легче читать. Так что, его легче переписывать, чем портянки на тысячи строк.
Тут еще важна глубина разбиения. Если на нижнем уровне маленькие атомарные функции специфичные для данного бизнес домена, то шанс что они без изменений найдут место в новой архитектуре выше.
ss-nopol
При нехватке ресурсов (то есть почти всегда) часто возникает вопрос, как решать в данный момент возникшую проблему, быстро или качественно. Я не стал бы это возводить в ранг закона, это просто неизбежность.
По-моему профессионализм не в том, чтобы всегда писать идеальный код, а в том чтобы правильно определить, что именно необходимо в данном случае и реализовать это.
rezedent12
Об этом за программиста подумает менеджер и потом несколько раз передумает. Поэтому программисту придётся писать плохой код, там где надо писать хороший.
panzerfaust
Формально вы правы, но после 10 лет в отрасли я не представляю ситуацию, когда я скажу "ок, времени нет, давайте напишем тут спагетти-функцию на 2к строк без всякой структуры и с всратным неймингом". Все эти DRY, KISS, YAGNI, GRASP, SOLID после какого-то порога опыта уже на кончиках пальцев. Сразу пишешь программу как набор элементарных блоков. Изменяются требования - пересобираешь блоки. Косямба на проде - по одному мессаджу уже понимаешь, в каком блоке проблема, 9 из 10 багфиксов готовятся за час максимум. Да, есть проблемы, когда заказчику утром нужно одно, а вечером другое - но опять же, рефлекс подстилания соломки уже сам собой срабатывает. В конце концов, если тебя наняли сеньором-помидором, то надо уровень показывать и перед самим собой и перед теми, кто после тебя будет твой код поддерживать. Для сеньора компромиссное решение наговнокодить должно быть исключительно редким и обоснованным.
vedenin1980
Речь скорее всего не про это — скажем, делаем прототип стартапа — денег на юнит-тесты, на автоматизированны и интеграционный тесты у нас нет — делаем без них. Проще вытащит все записи из базы и отсортировать их в коде, вместо базы данных — делаем так, все равно данных у нас в прототипе будет сотня строчек и плевать на их производительность и т.п. Проще взять старый компонент в UI и копипастом получит из него новый — можно и так и плевать, что архитектура не особо красивой получается.
То есть не сказать, что код будет прямо говнокодным говнокодом, но производительность, тестирование и архитектура будут далеко не идеальными.
Fulborg
Тесты - банально ускоряют разработку за счет того что работа кода проверяется за секунды вместо минут на запуск кода и ручные вызовы функционала. Вопрос в 100% покрытии и моканьи всего подряд - на этапе стартапа хорошо закрывается фокусом на функциальных и интеграционных тестах (diamond of testing), покрытие основных пользовательских сценариев может занять минуты, даже не часы работы.
Работу с БД прячет под собой ORM и вызовы с фильтрами/сортировками не отличаются от «достать все из базы и обработать». Заодно упрощается работа с версиями БД, форматами данных, можно использовать разные хранилища для разработки и прода, что тоже ускоряет разработку.
Компоненты/иерархия классов - тут наверное соглашусь, в условиях недостатка информации может быть сложно выделить сразу с прицелом на будущее и проще сначала закопипастить, а когда требования устаканятся - вытащить общие компоненты. И то, что-то однозначно универсальное просто вытаскивается во внешние компоненты/классы и экономится время на копипаст лишних строк.
0x131315
Верно, тесты ускоряют разработку. Просто не все их умеют готовить - для многих это как религия, они себе лоб расшибают, послушно обкладывая тестами вообще все-все-все из каких-то своих представлений о том как нужно писать тесты, или же наоборот, упорно из игнорируют, полагаясь на ручное тестирование или мысленное моделирование. Ручное тестирование жрет много времени, причем иногда его нужно выполнять повторно несколько раз, пока не исчерпается поток доработок. В мысленном моделировании ничего плохого нет, если есть опыт, это быстро и достаточно надежно, но тут играет чисто человеческий фактор: с удивлением узнал, что некоторые в этом настольные преисполнились, что сдают код, который из-за грубых опечаток даже запуститься не в состоянии, т.е. код даже ни разу не запускался автором, все из головы накидано, а в результате получается очень некрасиво, воспринимается это скорее как не накидано, а наложено. Ну а автотесты приходится межу делом подключать даже там, где их никогда не было, чисто для себя: они хорошо экономят силы и время, позволяют не вникать повторно в код, не тестировать его повторно, тем более вручную, позволяют сразу выкинуть из головы и сам код, и все сомнения относительно его надежности, а также, в случае проблем, позволяют не перебирать код, а сразу перейти к проблемному фрагменту. Также они снимают такую проблему, как скрытые ошибки: иногда ошибки в общем коде остаются незамеченными годами, автотесты такое вскрывают сразу, если написаны не через одно место.
А что касается прицела на будущее - для себя взял за правило так не делать. Это не окупается, никому не нужно, и никому не интересно. Минимально соломы набросать конечно нужно, но минимально, только из эгоистичных побуждений, для облегчения себе жизни, для облегчения отладки и тестирования, не больше. Это вполне хорошо бьёт код на тестируемые фрагменты, и вполне логично и обоснованно их раскладывает по структуре, просто потому что следует не абстрактной цели, а вполне конкретной. Это также автоматически отрезает весь тот ад абстракций, который любят порождать особо дальновидные товарищи, закладывая то, что вообще никогда не будет использовано, но всегда будет требовать внимания и поддержки.
И по мне такой подход неплохо окупается: забот гораздо меньше, только выполнить требования задачи и немножко облегчить себе жизнь, и ничего более. Меньше думаешь, меньше кода, он проще, лучше и легче читается, меньше времени тратишь на его написание и отладку. Как итог сил прикладываешь меньше. А если и когда требования изменятся - будет потребность, будут ресурсы, и самое главное, будут известны конкретные требования, что позволит провести целевой рефакторинг.
Особенно ярко это контрастирует, когда натыкаешься на код дальновидного товарища, в котором даже разобраться та ещё задача, десяток классов для какого-нибудь десятистрочного одноразового фильтра, и ты такой на вот эту гору запутанного абстрактного и абсолютно бесполезного кода взираешь и только один вопрос: "Зачем ты это сотворил? Кто и как теперь это будет поддерживать?". Как итог у такого товарища код бесполезен и переусложнен без какой-либо потребности в этом.
Andrey_Solomatin
Я тоже такой фигнёй страдал, пока с SQL был на Вы. Но потом научился нормально делать.
Когда в проекте есть ревью, это сильно отбивает желание срезать углы. Проще сделать нормально, чем проталкивать свои костыли.
Проблемы с прототипом, что он только на словах прототип, а на деле и особенно в голове мереджеров это и есть продукт.
И когда через год приходит клиент и под реальной нагрузкой всё ложиться, то на исправление нужно полгода, потому, что эти костыли уже обросли мясом.
aamonster
Если бы... Ошибаешься в требуемых структурах данных, а они уже тянут за собой...
Но, конечно, некоторой гигиены придерживаешься с самого начала, и "запас прочности" на последующие переделки стараешься оставлять.
Andrey_Solomatin
Я предпочитаю, формулировку, тип данных перестаёт соответствовать текущим требованием. "Ошибаешься" звучит, как будто этого можно было избежать. Зачастую нельзя, то есть работа в направлении избежать этого ведёт в тупик. Тут надо смириться и писать код с учётом этого. В данном случае использовать архитектуру, а если точнее то делать границы между модулями.
Сталкивался с такой ситуацийе. Есть схема базы данных, есть ORM, есть API для фронтенда. Данные читаются из базы и как есть отдаются на фронтенд а там просто JSON показывают как таблицу.
Бэкенд решило, что надо переименовать поле в базе данных. Нужно поменять всё: ORM, API, код фронтенда, у пользователя на UI поменяется имя поля. Оченень интуитивно всего один класс используется для представления объекта.
Ошибка здесь не в том, что имя поля не угадали. Ошибка здесь в том, что нет границ. Чтобы переименовать поле на фронтенде надо поменять базу и наоборот.
В идеале в базе лежит одно представление, на уровне бизнес логики другое, на уровне API третье, а фронтенд когда рисует таблицу адаптирует пришедшие данные. Да эти представления похожи и иногда могут быть одинаковыми, но мы никогда не меняем болше одного за раз. В итоге одна доменная сущность в системе представленна уже разными сущностями, у каждой из которых своя узкая область пременения и нужно конвертировать их при переходе между областями. Это добавляет сложности, но окупается на долших дистанциях.
Плюс в том, что каждая новая фича может быть задержанна одной из границ.
Переименовали поле в базе, ORM продолжает использовать старый аттрибут, просто поменяли его маппинг.
Переделываем ORM то на фронтенд идёт таже информация.
Нужно на фронтенеде переименовать поле? Не трогаем базу, просто меняем адаптер в API.
Да эти границы строить не бесплатно, но за это вы получаете изолированное тестирование и независимость от соседа. Даже когда нужно пересеч границу, это можно делать поэтапно, а не везде сразу.
Когда вы хотите соломки подстелить, то вкладываётесь только в изоляцию одной части кода от другогой. Если на всё не хватает, то изолируйте те части, которые скорее всего будет сильно меняться.
изменения до той точки, где в коде проведенна граница данного модуля.
Архитектура никогда не получается нормальной сама собой. Для этого нужно её целенапрваленно делать. И скорее всего с первых попыток ничего не получиться, а выйдет та самая гора абстарктного запутанного кода.
Мне помогает обкладываться тестами. Метрика простая, чем больше моков, тем больше зависимостей. Перевисываете код чтобы всесто моков были заглушки и архитектура улучшается.
aamonster
Да. Это именно то, что я имел в виду – вплоть до практик, которые вы используете, чтобы "подстелить соломки".
И всё равно не всегда угадаешь: разобьёшь систему на юниты, сделаешь для уменьшения сцепленности два-три уровня косвенности – а потом выясняется, что именно эта граница тебе нафиг не нужна, и код ты зазря усложнил (в цепочке юнитов A-B-C у A образуется новая возможность – но чтобы C мог её задействовать, приходится менять и B, ибо С про A знать не положено... Хотя зачастую, конечно, это свидетельствует, что на юниты разбил неверно). Хорошо, когда есть возможность, поняв задачу глубже, переделать архитектуру – но это не всегда возможно.
Andrey_Solomatin
Не надо противопоставлять быстро и качественно. Многие вещи которые повышают качетсво не требуют доп премени времени, а порой даже быстрей.
- Статический анализ практически бесплатен, а он ловит много глупых ошибок, а также учит разработчиков их не делать.
- Юниттесты, если это реально юнит-тесты, а не компоненные реально ускоряют время завершения задачи, так как сильно сокращают время не ручное тестирование и дебаггинг.
- Написать всё в одной функции или написать сразу с разбиением практически одинаково по времени.
На мой взгяд главная проблема, что нет понимания, что это легко или времени желания этому научиться.
> По-моему профессионализм не в том, чтобы всегда писать идеальный код, а в
том чтобы правильно определить, что именно необходимо в данном случае и
реализовать это.
В общем да. Главный мой инструмент для этого это разбиение на модули по степени понимания источника изменений. То есть разделять в коде те части где понятно и части где много туманности. Чем непонятней здача, тем более она должна быть изолированна от остального кода. В этом контексте становится намнго лече примать решения о качестве, где стоит сделать хорошо, а где и так сойдёт.
Daddy_Cool
"Нет такого принципиального закона природы, согласно которому писать говнокод быстрее, чем писать по-человечески".
Есть. Чтобы писать хорошо надо подумать о многом, о том к чему это приведет, как сделать лучше, чем может быть плохо то как есть...
Это всё затрата мозговых ресурсов.
Paul_Arakelyan
В ситуации "бесплатно" - никто никого не нанимает. И вполне может быть ситуация "есть идея - реализую, как умею", и оно до каких-то пор работает. Потом выясняется, что "всё не так", но к тому моменту - уже могут быть деньги для найма тех, кто знает и умеет то, что нужно.
WraithOW
Закон в том, что писать меньше кода быстрее, чем больше кода, а простой код — быстрее, чем сложный. Тесты — дополнительный код. Модная архитектура с разбиением на 100500 модулей/микросервисов/что там у вас популярно — дополнительный код. Скопипастить решение из соседнего модуля и быстренько его подкрутить быстрее, чем сделать правильную абстракцию.
И вполне нормально, что в начале пути на стадии обкатки прототипов будут срезаться углы. Просто нужно отдавать себе отчет, что техническим долгом нужно управлять.
websitedev
В принципе, в экстремальных условиях, когда очень сжатые сроки, профессионал вынужден писать плохой код. Когда есть постоянное давление со стороны менеджеров или заказчиков, очень сложно применить все хорошие практики.
Согласитесь, что всё хреначить в контроллере получается быстрее, чем, если вывести бизнес-логику на другой уровень абстракции и обдумать архитектуру. И таких примеров можно привести много.
Наверно, в начальном этапе стартапам выгоднее нанимать говнокодеров, нежели профессионалов. Поэтому и чаще они их нанимают, потому что их час работы стоит дешевле.
panzerfaust
Не соглашусь. Как я уже писал выше, когда ты в течение карьеры написал уже штук 500 этих рест-контроллеров (если вы о них), то на автомате пишешь как надо. Если видел данный архитектурный паттерн множество раз, то заложить точки расширения - вообще не рокет-саенс ни разу.
Vladimirsencov
Да в том то и дело, что не быстрее. Потом контроллер обрастает логикой и все становиться очень сложно.
websitedev
Да, но вот я имею в виду, что это быстро в самом начале. Понятное дело, что в дальнейшем такой код будет тормозить разработку. Но условно говоря, если тебе надо написать какую-то логику и больше не трогать этот контроллер какое-то время, это будет быстро. Например, написал MVP для того, чтобы проверить гипотезу, потом, если уже понял, что проект представляет коммерческий интерес, переписал всё используя хорошие практики.
Andrey_Solomatin
Очень хорошая практика, это изолировать код с неясным будущем от всего остального. Тогда плохой код не будет тормозить остальную разработку.
atomic1989
Великооепный ответ). Все просто забывают про бизнес составляющую и много философствуют). В начале самая лучшая архитектура - это чёрный ящик)