РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 16:00
Тезисы:
http://backendconf.ru/2017/abstracts/2703.html
Последние два года я делаю платежную систему с нуля.
Подобные проекты при создании проходят через несколько различных стадий (создание каркаса, запуск и доработка напильником, развитие и сопровождение), каждая из которых требует специальных инструментов, отдельных подходов к организации разработки, своих особенностей в декомпозиции задач и даже разных навыков от разработчиков.
...
Сложный проект с нуля: сквозь воду, огонь и медные трубы / Филипп Дельгядо
1. Сложный проект с нуля:
через воду, огонь и
медные трубы
Филипп Дельгядо
Банальности, проверенные опытом
2. О чем этот доклад
Дельгядо Филипп, ИТИС, 2017
2
До запуска Запуск Развитие
3. О чем этот доклад
О людях
О процессах
Об инструментах
Дельгядо Филипп, ИТИС, 2017
3
4. О чем этот доклад
О людях
О процессах
Об инструментах
Но для разработчиков
Дельгядо Филипп, ИТИС, 2017
4
5. О проекте
Платежная система
1 год до боевых
1.5 года в бою
Много разработки до выхода в свет
Много рисков в процессе выхода
Постоянное развитие
Дельгядо Филипп, ИТИС, 2017
5
13. Работа с требованиями
Зачем?
зачем нужна эта функциональность?
зачем нужно делать именно так?
зачем нужна эта библиотека?
зачем нужен этот отчет?
Дельгядо Филипп, ИТИС, 2017
13
19. Простота изменений
Дешево менять структуру БД
и вообще структуру хранения
Легко менять архитектуру
Дельгядо Филипп, ИТИС, 2017
19
20. Простота изменений
Дешево менять структуру БД
и вообще структуру хранения
Легко менять архитектуру
Не страшно менять UX
еще нет привыкших пользователей
Дельгядо Филипп, ИТИС, 2017
20
21. Надо помнить
Будет дорого менять внешние API
Будет дорого менять архитектуру
Будет дорого менять структуру БД
Будет дорого менять внутренние API
Будет дорого менять контрагентов
Дельгядо Филипп, ИТИС, 2017
21
23. Простота отладки
Провоцирует не писать логи
Но потом будет поздно
на боевых не будет ничего, кроме логов
а иногда и логов не будет (PCI DSS)
на боевых не будет доступа к СУБД
Дельгядо Филипп, ИТИС, 2017
23
25. Простота общения
Провоцирует пренебречь правилами
Но потом будет поздно
сформулируйте сode style
опишите принципы разработки
что такое хорошо и что такое плохо
договоритесь о правила сode review
соблюдайте no warnings
настройте static bug analyzing
Дельгядо Филипп, ИТИС, 2017
25
30. Эксплуатация
Любите ребят из эксплуатации
объясните им смысл настроек и параметров
укажите внешние зависимости и используемые порты
расскажите, что произойдет при внезапном останове
прикиньте, сколько нужно ресурсов
Дельгядо Филипп, ИТИС, 2017
30
31. Эксплуатация
Любите ребят из эксплуатации
объясните им смысл настроек и параметров
укажите внешние зависимости и используемые порты
расскажите, что произойдет при внезапном останове
прикиньте, сколько нужно ресурсов
И тренируйтесь
Дельгядо Филипп, ИТИС, 2017
31
34. Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Дельгядо Филипп, ИТИС, 2017
34
35. Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Слишком сложная работа с VCS
Дельгядо Филипп, ИТИС, 2017
35
36. Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Слишком сложная работа с VCS
Слишком качественное тестирование
Дельгядо Филипп, ИТИС, 2017
36
37. Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Слишком сложная работа с VCS
Слишком качественное тестирование
Потерянный технический долг
Дельгядо Филипп, ИТИС, 2017
37
49. Инструменты
АРМ разработчика
у нас розовенький, с Hello Kitty
Трекеры поддержки
учет инцидентов
задачи эксплуатации
Дельгядо Филипп, ИТИС, 2017
49
50. Инструменты
АРМ разработчика
у нас розовенький, с Hello Kitty
Трекеры поддержки
учет инцидентов
задачи эксплуатации
Чатики
разработки, решения проблем, флудилка
Дельгядо Филипп, ИТИС, 2017
50
51. Инструменты
АРМ разработчика
у нас розовенький, с Hello Kitty
Трекеры поддержки
учет инцидентов
задачи эксплуатации
Чатики
разработки, решения проблем, флудилка
Мониторинг
Дельгядо Филипп, ИТИС, 2017
51
54. Поддержка
Заранее познакомьтесь с поддержкой
кто будет отвечать пользователям
Узнайте их регламенты
как говорят с пользователями
Дельгядо Филипп, ИТИС, 2017
54
55. Поддержка
Заранее познакомьтесь с поддержкой
кто будет отвечать пользователям
Узнайте их регламенты
как говорят с пользователями
Научитесь им доверять
Дельгядо Филипп, ИТИС, 2017
55
61. Особенности
Вы и сами все про это знаете
Но даже в уже запущенном продукте бывают проекты,
проходящие через воду, огонь и медные трубы
Дельгядо Филипп, ИТИС, 2017
61
Руководитель разработки в компании ИТИС,
специализируюсь на создании продуктов с нуля и еще долго потом.
java, базы данных, сложная логика, нагрузки, надежность и вот это все.
В этом докладе я буду рассказывать о особенностях разных стадий продукта.
А, но зачем мне это на BackendConf, тут вам не WhaleRider
Я буду говорить о тех вещах, что нужны именно разработчикам.
Сейчас все больше команда принимает организационные и управленческие решения,
так что коммуникация, процессы, планирование становятся важным не только для менеджеров,
но и для разработчиков.
Увы, никогда нельзя надеяться на достаточную компетентность менеджеров и руководителей,
часто нужно помочь вашему Scrum master или product manager, а многие вещи
в проекте могут сделать и сами разработчики, не надеясь на начальство.
Последние три года я делал платежную систему и заметная часть
примеров взята из нашей истории, хот и не все.
Ну и перед собственно началом рассказа напомню,
Почти 20 лет назад
Продукт решили делать и вот, вы приступаете к разработке
И да, зачастую - сферического коня.
Постановки - обычно высасываются из пальца или, в крайнем случае, подсматриваются у конкурентов
Нет точных знаний, как и что делать - и поэтому многие задачи вида "а как бы это могло быть"
Нет реальных пользователей
Раз нет реальных пользователей, есть ощущение, что все можно просто поменть
И вообще - многие вещи кажутся (да и являются) простыми.
Во время разработки даже пилотной версии заметная часть постановок полностью изменится.
Проект, задуманный как мировой сервис внезапно станет коробочным решением,
в первоначальном списке задач забудут про безопасность, зато будет много про пиковую нагрузку,
хотя в реальности важнее окажется безопасность, а нагрузка к старту проекта окажется не столь важной и т.д.
Я уж и не говорю про сценарии взаимодействия с пользователем, тонкости бизнес-модели или списка контрагентов
для интеграции.
Как следствие, самым важным делом на этом этапе оказвается
Ну, кроме собственно разработки.
Это те вещи, которые лучше сразу делать хорошо.
Расскажем попродробнее о практиках для всех этих действий
Работа с требованиями - это отнюдь не задачи аналитика или тимлида.
В конце концов, пока вы пишете еще сферический проект в вакууме,
вам постоянно приходится принимать решения, которые потом
окажутся архитектурными для вашего проекта
Умение задавать вопрос "зачем" - главный инструмент работы с входящими требованиями.
Когда вы начнете его практиковать, то на вас будут обижаться, ругаться, негодовать, писать докладные записки,
но после десятого раза, когда данный вопрос таки заставил вовремя пересмотреть огромную постановку с съэкономил
кучу ресурсов - ругаться начнут спокойнее и скорее "для виду". Благодарности, впрочем, все равно не ждите.
самое частое - это попытка понять, зачем нужна та или иная функциональность, какие задачи пользователя она решает.
Как ни странно, даже у знающих scrum менеджеров, описывающих все через пользовательские сценарии зачастую нет ответа,
а зачем вообще данный сценарий нужен.
Тут могут быть и варианты "а зачем это пользователю", "а точно ли он без этого не обойдется первые пару лет".
Вопрос вида "а зачем вообще мы делаем продукт" все-таки считаются неприличными, их лучше не задавать.
Этот вопрос и позволяет уменьшить scope разработки и сделает понятным возможные доработки, а зачастую позволяте решать
проблемы задолго до его исчезновения.
Очень часто после понимания "зачем" становится понятно, что задачу можно решить гораздо проще. Например, вместо
попытки придумать, как показать на экране табличку на 100 000 записей, как попросил заказчик, получится показать
десяток строк с частичными суммами. Так как все, что ему было надо - это скопировать табличку в эксель и там сделать
суммирование по месяцам, например.
Точно так же надо не забывать задавать этот вопрос и самому себе - при добавлении в проект новой модной технологии, еще одной
библиотеки или инструмента сборки. И помнить, что ответ "я хочу в проекте эту модную библиотеку, потому что с ней проще устроится
на новую работу" хотя и правдив, но непрофессионален.
Не надо выписывать завитки на гриве сферического коня в вакууме. Очень часто на этом этапе
постановки избыточно точны и универсальны, но при этом не понятно, а нужна ли будет конкретная функциональность
кому-бы то ни было.
Да, вам хорошо понятно, зачем пользователю подробная история всех его платежей за последние три года в разрезе по годам.
Но нет нужды думать, как делать эту задачу, пока у вас вообще нет клиентов с платежами и вы еще далеко от продакшена,
первое время достаточно простых решений. И разработчик вполне себе вправе и должен уточнить у постановщика,
а зачем делать сложный инструмент с поиском, фильтрацией и рассчитанный на длинную историю еще до выхода на боевые.
Очень близок к этому и замечательный принцип
Хотя он уже относится не столько к работе с постановками, сколько к собственно кодированию.
Как бы вам (или постановщику) не хотелось сразу придумать универсальное решение, помните, что прямую можно провести
по двум точкам. Я придерживаюсь эмпирического правила - делать общее решение после того, как сделано три частных,
иначе все равно придется переделывать, так как реальность всегда богаче наших ожиданий.
Ну, например, не надо делать универсального шлюза к платежной системе, пока вы не реализовали хотя бы три разных шлюза
с разными требованиями. Так как выяснится, что даже похожие карточные шлюзы внутри предполагают совершенно разные алгоритмы
работы, разные протоколы и разную ответственность.
После того, как я написал первый вариант "надежной очереди", я честно думал, что он удобен для всех.
После третьего сценария ее использования я посмотрел на костыли и переписал все с нуля, зато теперь
разработчики гораздо довольнее. Но первых двух из сценариев мне было бы мало.
Это, конечно, универсальный принцип работы, важный не только при работе с требованиями.
Лгут не только постановщики, контрагенты, но и вендоры, производители железа, консультанты.
Ну и главное - очень часто врете вы сами - себе.
Обычно врут не специально. Специалист-бухгалтер будет вам говорить, что проводки после закрытия дня не меняются
и только потом вы узнаете, что он хотел сказать "почти никогда не меняются". Контрагент вам скажет, что "платежи
проходят в течении рабочего дня" и признает, что бывает и неделя только после того, как вы ему покажете конкретный пример.
И так - всегда.
Поговорим про архитектуру.
"Разработка в вакууме" делает многие вещи достаточно простыми и этим нужно пользоваться
У вас нет уже имеющихся данных, которые нужно мигрировать. Просто изменили таблицы и все.
Пока еще можно двигать ответственность между компонентами или вообще заменить
SQL-базу на распределенный кэш, не нужно думать о том, как эти изменения применять на продакшене,
цена ошибки пока еще нулевая. И этим нужно пользоваться.
Так что вы можете уговорить дизайнера и продакта поменять UX под более простой или более удобный
в текущей архитектуре или успеть поменять идеологию под выбранный UX.
Но этой простотой будут пользоваться и постановщики, так что надо быть готовым к изменениям.
И этой простотой нужно пользоваться, так как потом, на
Вообще, на этапе "работы до продакшена" надо помнить,
Поэтому все эксперементы стоит сделать заранее, пока еще не поздно.
Для внешних API дописать хотя бы одну тестовую реализацию и посмотреть, насколько это удобно и понятно
Эксперементы с архитектурой провести до выхода в продакшн и понимать, а как она будет меняться
Нужно заранее подумать, а как будете менять БД в будущем, что для этого нужно. Это, впрочем, тема отдельного разговора.
Аналогично, а как будете поддерживать версии вашего API, можно ли его расширять. Это те вопросы, которые стоит задавать сразу.
Именно поэтому на водяной стадии нужно смело менять все вышесказанное, когда это потребуется.
Потом уже у вас не будет таких возможностей, так что эксперименты лучше ставить сразу.
В водной стадии многое просто - и эта простота таит в себе кучу опасностей
Ну зачем логи, если я могу запустить отладчик в IDE, вон он какой крутой.
Лучше сразу привыкать искать проблемы через логирование.
Да, вы все умные и вас еще мало, вы в проекте с самого начала и вы прекрасно договорились друг с другом,
как писать код, что такое хорошо и что такое плохо, зачем вам какие-то документы по этому поводу.
Но потом резко возрастет стоимость коммуникации,
а то, о чем не договорились с самого начала - уже не добавить.
Да, Code style - это стандартно, но лучше сразу договориться, что "магия" - это плохо, а пятистраничные SQL-запросы - это хорошо.
Или наоборот, но единообразно.
Если сразу не предусмотрели, то в живой проект добавить статический анализ кода или поддержать "никаких предупреждений компилятора"
будет сложно и дорого, это надо делать сразу.
Ну, все же все понимают в системе, если что - быстренько расскажем
Полную документацию писать не всегда нужно, но некотрые базовые вещи лучше описывать сразу.
Ну, как минимум для security audit пригодится. Да и при запуске быстрее будет посмотреть на картинку,
нежели думать, к чему приведет такой-то сбой.
Нужно ловить момент фиксации конкретной компоненеты/сервиса/интерфейса и в этот момент его описать
Ну и конечно по максимуму использовать документирование в коде.
Собственно, больше всего документация будет нужна даже не разработчикам,
а тем, кто будет эксплуатировать продукт - системным администраторам, dev-ops,
третьей линии поддержки и так далее.
Хотя проект еще не запущен, уже стоит подумать над тем, как его будут эксплуатировать.
И эту задачу нужно держать в голове каждому разработчику
Неплохо бы с ними познакомиться, узнать что их уже беспокоит и что им будет нужно.
При создании кода, при проектировании отдельных сервисов нужно думать о администраторах и
стараться уменьшить количество проблем.
Чем чаще отдельные программисты будут спрашивать и инженеров и системных администраторов
"а как для вас проще сделать такую-то настройку" и "а есть ли дырка в firewall между этими двумя сервисами",
тем надежнее будет система и тем быстрее будут они отвечать на ваши просьбы.
Мы даже название компонент и настроек стараемся согласовывать с эксплуатацией. Нам не сложно, а им приятно.
А если вы еще и картинки нарисуете - они будут счастливы
Даже если все прекрасно работает на тестовом стенде, то на рабочем датаценте будет плохо.
Это всем всегда очевидно, но времени на решение проблем обычно никто не выделяет
Собственно, при тренировке вам станет понятно, а что нужно написать про все
ваши сервисы, что бы было понятно что и как делать.
Есть еще несколько очень хороших практик, которые не так уж и подходят
на данном этапе разработки.
На этой стадии процесс разработки довольно прост, хотя и не очень
укладывается во многие популярные методологии - задачи в основном длинные,
постановки нечеткие и неподробные, показывать зачастую нечего.
Это приводит к нескольким рискам
Вы используете процесс, который не соответствуем вашим задачам.
на этом этапе даже канбан иногда кажется слишком громоздким и искусственным, зачастую достаточно
доски и текущих крупных задач для разработчиков, а иногда и это лишнее.
Но если у вас очень простой процесс, возникает соблазн использовать простой трекер типа трелло или ютрека.
когда у вас внезапно резко вырастет потребность в инструменте (а это будет как раз незадолго до запуска),
переходить на более удобный инструмент уже не будет времени. Лучше возьмите продукт на вырост сразу.
Все равно точных и подробных постановок не будет, много исследовательских задач, нет
статистики производительности, так что даже процесс декомпозиции не будет иметь особого смысла.
Мы обходились понедельным планом по разработчикам на квартал вперед, пересматривали его раз в пару недель
и этого вполне хватало для всех задач. При этом средний размер задачи на разработчика составлял 2-4 недели.
Пока не нужны feature-бранчи, показ демо можно делать со сборки по конкретному тегу.
Бранчи нужны только если две задачи начинают сильно мешать друг другу
Да, это ужасно, но пока у вас функциональность меняется пять раз на дню, делать полное покрытие тестов
слишком дорого. Unit-тестами надо покрывать совсем уж базовые или важные вещи, в остальном обходится
интеграционными тестами на основные сценарии.
Авторизацию и работу с деньгами надо тестировать максимально качественно сразу, тут вариантов нет.
Да и многие сложные вещи вообще не протестировать - у многих платежных систем вообще нет тестового входа,
а документация сильно расходится с реальностью, так что даже написанный сложный mock будет полностью бесполезен.
Впрочем, тут многое зависит от конкретного выбранного языка )
Да, сейчас у нас есть тестовые имитаторы для некоторых наших контрагентов, но данные для этих тестов собирались
дорогой ценой - и в любой момент могут устареть.
А вот то, что делать обязательно - хранить появившийся технический долг.
Разработка в вакууме часто приводит к неточным решениям, когда нельзя выбрать оптимальный путь из-за нехватки информации
или когда проще было сделать "примерно" из-за "зачем" и "Бережем свой труд". Но все подобные места нужно документировать,
что-бы при уточнении постановок не забыать выплачивать технический долг.
И этот долг нужно фиксировать в месте, доступном для заказчиков/постановщиков/product owner.
Итак, вы закончили с предварительной разработкой и наконец начали запуск
Никакой план не выдерживает столкновения с реальностью, все будет не совсем так, как вы думали.
Контрагенты подведут, железо сломается, клиенты повалят валом в самые неподходящие моменты,
самый важный человек заболеет, а все инвесторы проявят талант тестеров от бога.
Слишком много суетиться. Будет много разных задач, все будут казаться очень важными.
Любой программист будет испытывать огромное давление, все "надо быстро, вчера, почему еще не".
В тяжелых случаях вас даже не сможет спасти ваш начальник и над вами будет нависать кто-то из топов.
Тут очень важно спокойно работать дальше, по приоритетам.
Обычно перед запуском проходит лихорадка последних доработок и кажется, что ну вот запустимся и отдохнем.
Это не так, после запуска первое время будет только сложнее. Так что нужно попробовать отдохнуть - договорится
о дополнительном отгуле с начальством (скорее всего вас поймут) или просто не планировать "доработать" на выходных
за день перед выпуском на продакшене.
Мы запускались почти сразу после Нового Года, так что все успели отдохнуть. Но не всегда так получается.
За время запуска вы понаделаете кучу костылей и нужно время и силы для их упорядочивания.
Да, нужны новые фичи, но если не перевести дух и не вернуть часть долга, то проект
не выйдет из вечного пике.
Нужно заранее об этом помнить, не брать на себя лишних обязательств, а хорошо бы и заранее
договориться об отпуске или паузе в задачах.
Самое важное, на мой взгляд, в процессе запуска - это организация процесса.
Да, по идее это ответственность менеджмента, тим-лидов, но многое могут программисты
сделать сами - что бы им самим было легче жить.
Например, составить график дежурств.
Во время запуска часто что-то ломается или нужно сделать выкладку поздно вечером.
Желательно заранее договориться, кто и когда может задержаться на работе. Тогда не выяснится, что
одному ведущему программисту именно сегодня нужно забирать ребенка со школы, а у другого годовщина свадьбы.
Просто на доске напишите, кто когда может на этой неделе задержаться.
В особо запущенных проектах можно не сообщать эти информацию менджменту, так как возможность задержаться
совсем не то же, что и желание это сделать.Мы вот такое не сделали, что привело пару раз к большому огорчению пары человек, которым пришлось менять планы
Гораздо проще внезапные проблемы в субботу вечером исправлять из дома, а не из офиса.
Так что стоит заранее обеспечить себя возможностью доступа из дома.
Договорится с службой безопасности, поднять удаленные рабочие столы и VPN, проверить работоспособность системы.
Заодно, раз уж и так из дома работать можно, сможете в будущем этим пользоваться - ну, когда вызвали сантехника.
Почему то об организации доступа из дома постоянно забывают до самого последнего момента
У вас будут довольно сложные дни и неплохо бы для себя решить, а зачем вам вообще надо спасать проект по вечерам.
Может, вы рассчитываете на премию? Или хотите накопить пару выходных к отпуску? Или вам важно уважение коллег.
Очень полезно довести это до вашего тим-лида или проджекта, просто что бы он заранее запланировал для вас
фонд на премии или подумал, как красиво презентовать ваш героизм для высокого начальства.
Да и вам будет проще работать по субботам, если вы понимаете, зачем вы это делаете.
Организация процесса затронет и используемые инструменты
Разработке надо уметь видеть, что происходит. Мониторинга недостаточно,
логи часто малодоступны и медлительны, к БД или сервисам прямого доступа нет (и правильно).
Нужен свой арм, который может показать важные для разработки "кишки" системы.
Лучше бы его начать делать заранее, но точно понятно, что нужно - обычно в тот момент, когда потребуется.
Поэтому АРМ должен быть простой для доработок, без изысков и без лишних выкрутасов.
И постоянно дорабатываться.
Наш, например, розовенький и с hello kitty, что бы было приятнее им пользоваться
В нем, например, можно посмотреть параметры операций as-is, в точности как они хранятся в СУБД,
состояние очередей и многое другое. И нас не пугает вывод данных прямо в json, чем меньше
преобразований - тем лучше.
И в нем ничего нельзя сделать, только read only.
Если раньше вы смотрели только на задачи для разработки и трекер использовался в основном для багов,
то сейчас появятся (или вы сами сделаете) отдельные трекеры для инцидентов и для эксплуатации.
И вам очень нужно заранее получить доступ к этим трекерам, что бы не узнавать о происходящем
из слухов.
Вам нужно будет оперативно обсуждать происходящее, причем зачастую из метро, на ходу и т.д.
Впрочем, зачем нужен Slack или Telegram особенно объяснять не нужно.
Но вот сделать чатик отдельно для обсуждения проблем без участия менеджеров - полезно, уменьшает
суету и спасает от нетехнических вопросов.
Ну и добавьте в свои контакт-листы всех, кто вам будет нужен заранее - поддержку, девопсов,
сетевиков - всех, кто может понадобиться.
Знать, что на самом деле он меряет и как.
Очень часто это не совсем очевидно.
Например, мы долго не могли понять, что у нас происходит с числом платежей, пока не вспомнили, что Prometheus усредняет и интерполирует значения и вместо прямой может быть гребенка
И как именно считается в вашем мониторинге доступная память или успешность операции.
Но главный инструмент (не только на этой стадии, но тут - особенно) это люди
Так что надо по мере сил заботится и беречь.
Запуск - именно то время, когда CTO бегает за кофе и пиццой для разработчиков,
пока они чинят проблемы на продакшене (и, кстати, да, у нас и СТO и начальник разработки ходили в магазин за едой для
программистов).
Но кроме этого помните и о всех, с кем общаетесь - о эксплуатации, поддержке, пользователях.
Запуск - очень нервное время, когда легко сорваться и поругаться. Лучше до этого не доводить.
В крайнем случае - попросите купить грушу или хотя бы дартс.
И почаще ходите вместе выпить пиво.
Еще забытые герои процесса запуска - поддержка
Те люди, что отвечают реальным пользователям и помогают с их проблемами
Узнайте, кто и как там работает, кто что умеет, у кого какие знания
Поддержка - это и важнейший инструмент понимания "зачем" и лучший индикатор проблем и
источник самых неприятных сообщениий о багах и инцидентах.
Заодно расскажите им о известных вам кусочках системы, что и как и почему работает.
Очень часто ваши рассказы откроют им глаза на многие проблемы.
Вроде бы вам это не важно, и скрипты общения с пользователями - не дело разработки, но лучше попробовать
с ними разобраться. Хотя бы вы будете уверены, что у пользователя спросят версию браузера или
модель смартфона и вам не придется через неделю поисков выяснить, что проблема была под старой оперой-мини
на мобильной джаве на телефоне 10-летней давности.
Не всегда будет время подробно разобраться, зачем нужно то или иное изменение, так что нужно
достаточно им поверить, что бы (иногда) просто быстро делать то, что просят. И чем больше вы им рассказываете
и с ними общаетесь, тем проще будет верить их данным по поведению пользователя или замеченной проблеме.
О процессе.
Процесс при процессе внедрения стоит подбирать под конкретную вашу специфику.
Обычно тут короткое планирование, четкие задачи.
У нас фактически был SCRUM, со всеми его атрибутами.
Но с размером спринта в один день.
Утром распределяли задачи, в середине дня делали демо, вечером выкладывали фикс и делали ретроспективу
И так несколько недель.
Разумеется, кто-то продолжал работать надо долгосрочными задачами, но в отдельных бранчах
И вот мы наконец запустились
Про эту стадию рядом целая конференция и куча книжек
И все, что я уже успел рассказать – вам опять пригодится
Но расскажу еще о нескольких практиках, которые мы у себя активно применяем
Почему-то, хотя все знают про этот принцип, его все время забывают и я много раз видел, как после долгого выпиливания отдельного проекта выясняется, что он уже мало совместим с общей кодовой базой и его надо полностью переделывать.
Особенно проблематично, когда большую задачу делают аутсорсеры.
Большие задачи делаем и выкладываем кусочками, в единицы человекодней.
Не всегда выходит, но минимальные риски для выживания системы.
Вот сейчас внедрение асинхронной шины на кафке начниаем с дальнего угла системы
Код должно быть удобно читать и ревьюить. Для этого должна работать навигация по коду из IDE.
Это довольно сильно ограничивает в использовании библиотек, как ни странно. И заставляет писать
внутри довольно сложные вещи. Но часто спасает.
Язык со статической типизацией вообще много что позволяет сделать до запуска кода )
Мы не доверяем технологиям, про которые непонятно, как они работают, никакой магии. В крайнем случае
наймем внешних профи (например, для присмотра за СУБД).
Кстати, именно поэтому мы не используем, например, ORM.
Все тестируется у программиста
А это значит, что система должна быть разворачиваема у программиста. Но не уверен, что
эта практика переживет еще год
Тот, кто отвечает за качество продукта только и может говорить, что и когда можно выкладывать.
YouTrack - это как раз слишком простой инструмент, выбранный в начале проекта. Думаем о миграции на Jira,
но процесс медленный
Git - грустно, но куда деваться
Confluence - наконец догнал по возможностям версию 3.5, хотя языка разметки не хватает. Но все еще лучшая wiki
TeamCity - пока устраивает как система сборки
Telegram - очень не хватает нормальной адресной книги