Всё старое в один прекрасный день снова становится новым. Наступает время, когда даже опытные программисты наступают на те же грабли. Невозможно перечислить все «неписаные правила» любой дисциплины, отчасти потому, что многие из них — даже не правила. Зачастую это способ перефразировать абстрактные и вечные истины.Мари Кондо сделала карьеру, применив универсальные принципы эффективности, чистоты и красоты к бытовой задаче ведения домашнего хозяйства. Оказывается, многим людям нужен просто переводчик между вечной мудростью и их повседневной жизнью, чтобы действительно «понять» смысл происходящего вокруг (см. также «Дзен и искусство обслуживания мотоциклов»). Мы искренне надеемся, что вам понравится наша попытка сделать то же самое для программирования.
1. Никаких деплоев в пятницу
Даже если у вас система непрерывного развёртывания. Пятница — самый неподходящий день, чтобы запушить мастер, по очевидной причине: остаётся всего полрабочего дня на исправление возможных косяков. Обычно после обновлений наблюдаются всплески в тикетах техподдержки, особенно после выпуска новых функций и, неизбежно, новых ошибок. Люди по пятницам сонные, невнимательные, склонны всё откладывать на потом… знаете, как это бывает.
Никто не застрахован от потусторонних сил, которые всегда выбирают пятницу для багов! Поэтому наблюдайте за лучшими практиками, а если не уверены, обратите внимание на лидеров отрасли. Например, Apple, предположительно, делает релизы по вторникам, оставляя достаточно времени с двух сторон такого критического события как деплой: понедельник, чтобы оттестировать и выловить последние ошибки, а со среды по пятницу — чтобы внести любые срочные изменения. И с доходами Apple вы понимаете, что их модель деплоя обмыта кровью и потом.
2. Регулярные бэкапы
Трудно переоценить важность регулярного резервного копирования. Вся наша индустрия построена на абстрактной системе прогрессивного бэкапа. Конечно, я говорю о Git, но этого недостаточно. Ваша БД, криптографические ключи, конфигурационные файлы, образы VM, изображения/видео… даже импортированные пакеты следует надёжно хранить там, где они будут всегда доступны в случае чрезвычайной ситуации. Если у вас нет автоматизированной системы, то пусть хотя бы парочка сотрудников регулярно архивирует рабочую папку и копирует на внешний диск. Да, именно парочка — избыточность не лишняя.
Вероятно, вам никогда не пригодятся 9 из 10 сделанных резервных копий. Но однажды, как я сегодня, вы захотите вернуться в прошлое и выяснить, когда именно мы сделали эту незаметную, но совершенно убийственную ошибку, которую никто до сих пор не замечал?! Тогда вы будете рады, что нашли время на бэкап. Или, ну вы знаете, когда новый сотрудник случайно удалит 100 000 строк кода. Бывает. Мы не держим обиды на людей, а учимся на ошибках. Делайте бэкапы, даже если это тяжело!
3. Получите полную спецификацию перед началом разработки
Я часто страдаю синдромом «начал слишком рано». Не раз приходилось переписывать большие фрагменты кода, потому что я не задал достаточно вопросов на первых встречах с заказчиком, где тот обрисовал контуры задачи. Наш мозг действительно крошечный, и он ненавидит точность, особенно когда точность сложна и дорога (читай: необходима клиенту). Он находит сходство там, где его и близко нет. Это особенно верно в дизайне программ — в достаточно сложном приложении десять похожих кнопок выполняют десяток совершенно разных задач. Перед началом кодирования следует уловить эти тонкости, если вы хотите получить максимальную отдачу от своего времени и времени клиентов. Не будьте таким, как я или мой мозг. Нарисуйте всё на бумаге, убедитесь, что всё понятно, а при необходимости можете перерисовать систему с нуля (с учётом достаточного время на подготовку — все мы люди).
Никто никогда не достигнет совершенства в этом процессе. Я всё ещё слишком часто полагаюсь на догадки. Но с тех пор, как я осознал проблему, необоснованных предположений стало меньше. Следует размышлять как компьютер: недвусмысленно и бездумно в своей логике. В концепции проектирования системы изучайте пограничные ситуации, будьте «адвокатом тестера» — и вы, вероятно, найдёте дизайн, который сразу исключает целые классы ошибок, допустимые в менее продуманном дизайне.
4. Если видите неважную чепуху, так и скажите
Постарайтесь мягко остановить или предотвратить непродуктивные дискуссии, прежде чем они выйдут из-под контроля. Наше время в офисе почти так же ценно, как те 3-8 часов, которые мы проводим без сознания каждую ночь — то есть оно очень важно! С точки зрения бизнеса, чем больше народу — тем эффективнее должна быть встреча, потому что почасовая оплата умножается на 20-500 разработчиков в одной комнате / конференц-зале / и т. д. Это сумасшедшие деньги, особенно в солнечной Калифорнии с её зарплатами. Время — деньги! И мы отрабатываем эти деньги, придумывая интеллектуальные трюки вокруг монстров со щупальцами, которые скрываются за каждой кодовой базой и только ждут, чтобы разбить невинные ожидания жестокими багами и сбоями.
Но мы не всегда бродим по забытым кодовым катакомбам с дрожащим факелом и потным лбом. Иногда мы сидим на собраниях или напряжённо что-то обсуждаем вне формальных митингов. Slack славится тем, что повышает сплочённость команды, но какой ценой (кроме ежемесячной платы)? По моему опыту, Slack резко увеличивает «бессмысленное время» вашего мозга — время, потраченное на фильтрацию ещё одного постоянного потока (часто неуместных) звуковых оповещений, когда вы пытаетесь делать то, за что компания вам платит; то есть разрабатывать и ремонтировать полезный код. А люди довольно легко впадают в ненужные споры.
Ничего страшного в том, чтобы попросить закончить дискуссию, если она займёт слишком много времени. В наше время дети любят говорить, что «настоящий видит настоящее»: люди, которые действительно делают реальную работу, помогают клиентам, пользователям и миру, — они будут благодарны вам за то, что вы попросили закончить дискуссию о том, должен быть новый холодильник чёрным или хромированным. «Да бросьте вы монетку, какая разница… у нас более серьёзные проблемы». И многие из людей, которые обратят на вас внимание, будут из руководства.
Спасибо, что присоединились ко мне в этом путешествии. Да увидите вы ту же мудрость, что и те, кто впервые до нас написал эти советы. И, пожалуйста, если на своём опыте вы усвоили какие-то ещё негласные правила, напишите их и сообщите нам!
Комментарии (43)
yoshka
22.03.2019 15:0810. Нет тестов — нет фичи. Пока нет внятного покрытия тестами, фича в прод не уйдет.
pesh1983
22.03.2019 19:59-3Опять же зависит от конкретной ситуации. Вы же код не ради тестов и самого кода пишите (если конечно не свой проект). Обычно за это платят деньги и ожидают, что эти расходы как минимум окупятся. Если бизнесу надо как можно быстрее выпустить продукт/фичу и он в краткосрочной перспективе готов идти на риски из-за отсутствия тестов, но с условием, что в ближайшем спринте/итерации нас эти тесты выделят время, то почему бы и нет. В итоге все в выигрыше — и бизнес, который получил профит, и разработчики, потому что работа принесла максимум прибыли и в итоге покрыли все тестами.
yoshka
22.03.2019 22:28+1Обычно так и делаем. Если надо «вот прям щас к демке», то выпускается и показывается с минимальными тестами. Но руководство знает, что при таком раскладе следующий спринт будет про тесты. У меня болезненный опыт в прошлом, когда тесты 5 лет подряд откладывалиссь на потом. Теперь я выторговываю точный срок, когда код будет покрыт тестами, если фича покажется полезной и пойдет в прод, после этого пилим фичу.
sentyaev
23.03.2019 02:20+1Если бизнесу надо как можно быстрее выпустить продукт/фичу и он в краткосрочной перспективе готов идти на риски из-за отсутствия тестов, но с условием, что в ближайшем спринте/итерации нас эти тесты выделят время, то почему бы и нет.
Я такое слышу много лет, но результат всегда такой:
1. У нас есть срочная задача, нужно вот прям сейчас.
2. Соглашаемся написать быстро, с костылями, без тестов. Договариваемся, что переделаем в следующем спринте.
3. Повторить #1 и #2
Теперь я в это не верю, начинаю с планирования и тестов, а если бизнесу нужно быстро и без тестов, то могут коллег попросить, кто-нить да согласится.pesh1983
23.03.2019 10:21Проблема в том, что вы не планируете написание текстов. Договориться и реально запланировать в ближайший спринт — совершенно разные вещи) Вы не стоите на своем и не тыкаете бизнес в то, о чем с ним договаривались и о то, чего он не выполняет. Вы же написали код в срок? Написали, выполнив таким образом договор с бизнесом. А бизнес свою часть договора не выполнил, потому что должен вам тесты.
pesh1983
23.03.2019 10:51Но, в вашем случае, если бизнес не соблюдает своим же собственные обещания, лучше сразу писать код с тестами и оценку давать с учётом этого.
pesh1983
23.03.2019 10:24Что-то я не понял) А чего минусуем? Лучше пусть меньше заработаем, но зато сразу с тестами? Ну ок
DSolodukhin
22.03.2019 15:253. Получите полную спецификацию перед началом разработки
Если бы это еще работало. Ни разу не сталкивался с ситуацией, чтобы к моменту начала разработки было полное и окончательное ТЗ. Даже если аналитик и/или заказчик считает, что всё продумано и описано, обязательно в процессе реализации всплывёт что-нибудь еще.pesh1983
22.03.2019 20:04Я бы перефразировал этот пункт так: "Получите наиболее исчерпывающую спецификацию ..". Естественно, все предусмотреть на раннем этапе невозможно, но попытаться покрыть риски по максимуму — вполне.
YgReEk
23.03.2019 11:00Отвечу вам как аналитик.
Хотел подробно, но после третьей стёртой простыни понял что такое лучше в личку :)
1. Если требования готовить заранее, они устаревают или замыливается глаз. Поэтому детализацию необходимо повышать итерационно.
2. Можно проводить ревью требований, но к такому не готов ни один участник процесса: у заказчика нет времени, разработчикам необходимо отдельно сесть подумать, ПМ/другой аналитик имеет ещё достаточно много дел. В нашей команде если грядёт большая фича мы после выявления достаточно полного набора требований садимся и обсуждаем реализацию.
3. Если готовить требования по мере востребованности (вечером на митинге обсудили что будет сделано завтра), обеспечивая актуальность, получится очень много TBD пунктов.
Краткий вывод: полное и окончательное ТЗ физически невозможно на сложную систему. Даже одноатомные молекулы и те с допусками. Метрологией, ITIL, процессами управления разработки или иной борьбой со сложностью можно найти нужный баланс между полнотой и оперативностью уточнения.
Вывод: требованиями необходимо управлять так же, как бэклогом, баглистом, сроками и прочим. Команда может прожить без компетентного архитектора/аналитика/тестера/etc. Но зачем?
ivanych
23.03.2019 12:23В нашей команде если грядёт большая фича мы после выявления достаточно полного набора требований садимся и обсуждаем реализацию.
А кто у вас решает, что фича большая и требует обсуждения?
YgReEk
23.03.2019 13:19Менеджер проекта обычно. Но можем и силами команды спокойно всё организовать. Главное отделить встречу про техническую реализацию (проводимую без заказчика) от встречи про потребности и видение (такие встречи и с командой, и с заказчиком иногда проводятся для обеспечения взаимопонимания, контроля работы аналитика и успокоения заказчика).
ivanych
23.03.2019 13:58А как он определяет, что это большая фича? Может там требуется переделать половину архитектуры, но без обсуждения это заранее не видно?
YgReEk
23.03.2019 14:07Совместная оценка трудозатрат с разработчиками на основании выявленных требований и известном техдолге. Например, у текущей фичи оценки были в 2-4 месяца, пока укладываемся и, похоже, уложимся. Могу разработчика призвать, прокомментирует :)
ivanych
23.03.2019 14:17Погодите, но оценка трудозатрат — это и есть обсуждение. А кто и почему решил, то требуется обсуждение?
YgReEk
23.03.2019 15:53Решил ПМ. Почему — в идеале надо у него спрашивать.
Как видится мне: нам необходимо добавить новый функционал, предполагающий новый подход работы с системой. Для того, чтобы это сделать, необходимо его аккуратно положить на старые рельсы и архитектуру как минимум ничего не сломав, как максимум по пути разгрести частично имеющийся техдолг (система осталась в наследство от другой группы разработки и создавалась как прототип). Я не знаю имеющихся архитектурных ограничений и не в моей компетенции определять детали реализации, этим занимаются разработчики, и сроки или глубину декомпозиции задач, этим занимается ПМ. Таким образом, на момент до обсуждения (в котором оценка трудозатрат лишь малая часть), информация и экспертиза размазана по отдельным лицам в команде, после — имеется у всей команды.
Наверное, в практике или теории проектного управления есть рекомендации когда необходимо проводить такие обсуждения, что на них должно быть и т.д. Я же могу оттолкнуться только от своей оценки по количеству затрагиваемых пользовательских сценариев и практики работы команды. С этой точки зрения фича достаточно большая, т.к. затрагивает минимум 5 сценариев (это так, с ходу) и на реализацию сравнимого функционала у команды (два разработчика, тестировщик и аналитик) ушло два месяца в прошлый раз.
Perlovich
22.03.2019 16:24+1Как раз выкатили обновление в прод, открыл хабр и тут эта статья. Думаю, тут таких много.
Но в целом, согласен, что это не лучшая дата для обновлений.
samhuawey
22.03.2019 16:40+1Хорошо говорить — не деплойте в пятницу — а что делать если продукт работает на собственном железе и кроме как во время даунтайма нет возможности задеплоиться? Остаётся вечер пятницы.
Я бы так сказал — не деплойте недотестированный продукт в пятницу. Если деплоймент стандартизован и клиент(ы) имеют доступ к фазе UAT — почему нет? В релиз пролезут только самые малоотлавливаемые баги, которые наверняка были и в предыдущем релизе. Ну и регрессионное тестирование никто не отменял, если у заказчика нет на него денег — пусть готовится разгребать в продакшене.
Главное чтобы были прописаны ответственные за каждый этап деплоймента и без их согласия не было бы никаких выкладок кроме пожарных (но и там решение принимает биг босс вместе с заказчиком). Когда сразу ясно кто именно виноват в проколе это как правило стимулирует деплоить правильно, люди становятся осторожнее в своих словах и решениях и бардака становится меньше.
Если тяжело в пятницу — пусть будет специальный ответственный за релиз человек, который отдыхает в четверг и работает в пятницу-субботу.pesh1983
22.03.2019 20:14Я бы посмотрел в сторону zero downtime deployment. Конечно, многое зависит от конкретных условий/технологий и проекта и может быть не везде применим, но подход очень полезный и позволяет деплоить даже под нагрузкой. Вот тут хорошо описано https://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html касательно питона, но в общем применимо и для других языков и технологий
eugene_bx
22.03.2019 16:4511. Иметь контактную информацию ключевых людей и их подмен, особенно не в своей команде.
12. Провести тренинг по реальному DR, первый раз выявит много проблем. Потом можно раз в год повторять, если проект более-менее часто обновляется.
13. Сделать чеклист действий в случае возникновения проблем.eugene_bx
22.03.2019 20:1614. Создайте SWAT team и вовлекайте её членов в кросс-командную разработку.
izuware
22.03.2019 17:01Наше время… почти так же ценно как те 3-8 часов, которые мы проводим без сознания каждую ночь...
Как можно не догадаться что не стоит ожидать под таким заголовком увидеть реально полезный текст. Да еще каменты эти читать потом…
Вобщем «Ты Сам Себе Делаешь Свой Недосып»
Firz
22.03.2019 17:35+3Но однажды, как я сегодня, вы захотите вернуться в прошлое и выяснить, когда именно мы сделали эту незаметную, но совершенно убийственную ошибку, которую никто до сих пор не замечал?!
И выяснится что бэкап умер, по-этому есть пункт 2.2 — регулярно проверять эти самые регулярно сделанные бэкапы.
dss_kalika
22.03.2019 17:41+1=) У нас, как то, при разворачивании бэкапа выяснилось, что он битый. И прошлый битый. И все битые. И бой бит.
Откатились на тестовый сервер, где программисты три недели делали что хотели и как хотели…
И бурно имитировали деятельность за три недели в течении всех выходных.
Ваша правда, короче… бэкапы надо проверять.
Z80A
22.03.2019 19:11+2Прочитал как
Вся наша индустрия построена на абстрактной системе прогрессивного факапа
и прослезился…
nomadmoon
22.03.2019 22:35> см. также «Дзен и искусство обслуживания мотоциклов»
Сижу читаю… Эта штука посильнееФауста ГётеГарри Поттера и методов рационального мышления.
Xambey
23.03.2019 06:16Расскажу сказочку про деплои в пятницу:
В прошлую пятницу разработчики из Google решили, что фильтры для поиска на YouTube не нужны. Во вторник они сообщили, что в курсе проблемы и пофиксят ее… Прошла неделя, весь бизнес завязанный на ютуб, занимающихся аналитикой — встал. Спасибо гугл ?\_(?)_/?uldashev
23.03.2019 23:05Т.е. если бы они выкатили обновление в понедельник, такого бы не случилось?
Можно много говорить, про то, какие мы все ответственные и профессионалы, но про пятницу, это из системного администрирования, потому что, если что то пойдет не так, придется сидеть и исправлять все выходные, причем за бесплатно, руководство не оценит и есть вероятность еще и штраф получить, а вот если что то пойдет не так на рабочей неделе, то скорее всего будет премия за героическое преодолевание трудностей и возвращение работоспособности системы.
zodchiy
5. Сам уронил — сам поднял.
Снес половину базы? Восстанавливай!
6. Никаких микрооптимизаций и рефакторинга ДО окончании этапа основной разработки.
Или сразу пиши оптимальный код или выделяй время после окончания.
7. Новичок в проекте никогда и не при каких обстоятельствах не разобравшись во всей истории не должен произносить слов «А давайте это перепишем заново/на GO/ на Ruby/ на Java».
Я слышал, что Python/Go/Rust быстрее C#/Java/Python, давайте перепишем все!
8. Никогда не критикуй не разобравшись.
Может оказаться так, что стыдно будет тебе.
9. Никогда и не при каких обстоятельствах, не критикуй чужой стэк.
Только в курилке и только в формате уличной драки. Исключение — одинэсников можно.
dss_kalika
5. И… чем это должно помочь?)
…
7. Почему не должен? Деструктива это не несёт само по себе и непроизнесение этого ни от чего не защитит.
Hardcoin
Дать ему доступы к бекапам? Приостановить бизнес, пока он со всем разберётся? А вы рисковый.
hippohood
А вы на любите критику, это заметно )
worldxaker
пэхапэшников тоже можно!
Perlovich
Позвольте не согласиться по некоторым пунктам.
Число людей, у которых вообще есть доступ к тому, чтобы уронить БД, должен быть минимальным. А все sql update скрипты должны быть проверены перед исполнением на тест-среде.
Пусть подчеркивает очевидные проблемы, пока глаз не замылился. Бывает, что так долго варишься в своем проекте, что перестаешь обращать внимание на что-то. Но, конечно, большую часть предложений новичка придется отклонить по тем или иным причинам.
При ревью кода коллег не всегда есть время прям полностью вникать во все мелочи. Если не уверен, лучше прокомментировать/спросить. В худшем случае, тебе скажут, что не прав. В лучшем — поможет найти проблему. Даже если код корректен и ты сам неправильно что-то понял, такие замечания могут выявить места, которые лучше закомментировать или переписать более явно.
Но это все, конечно, варьируется от команде к команде.
Fenzales
pesh1983
Зависит от. Рефакторинг же тоже разный бывает. Серьезный обычно проводят, если есть очевидные проблемы при поддержке кода. А мелкий конечно можно и в процессе сделать. Главное — не искать идеальную архитектуру, тем более на ранцами это раннем этапе разработки, потому что в большинстве это пустая трата времени. Этим и опасно.
androidovshchik
Это не опечатка?) Не думаю, что Python быстрее C#. Мб на его место можно поставить C/C++ или тот же Rust
zodchiy
— Мне сказали, что Python быстрее C#. — Это слова, мне на полном серьезе сказала новый руководитель ИТ-отдела очень крупной компании, я возразил и меня быстро перевели в другой отдел. Она еще была очень удивлена, после покупки кластера hadoop, что он не онлайн, она думала это что-то типа распределенной БД.
Кстати, вместо Python-а, она выбрала erlang.
disanem
Смотря для какой задачи. Вполне может быть ситуация, когда решение из библиотечки python будет намного быстрее самописного решения на C#. За счёт того что сама библиотечка написана на C/C++/Cython
firedragon
Быстрее для чего?
Разработки, развертывания или выбрасывания в мусор?