Как предотвратить возможное дерьмо
Все вы, наверное, знаете термин эвентуальная согласованность. Определение из Википедии гласит: если в данный элемент данных не вносятся новые обновления, в конечном итоге все обращения к этому элементу будут возвращать последнее обновленное значение. Я придумал еще один термин: возможная дрянь: в конце концов все программы станут дрянью. Как бороться с этим надоедливым законом дэв-природы?
Возможная хрень — в конце концов все программное обеспечение станет дерьмом
Вам не знакомо это чувство? Вы начинаете строить «следующую великую вещь», которая никогда не станет «жалким куском дерьма». Но через какое-то время понимаешь: «блин, я опять это сделал».
Недавно мы получили интересный вывод на нашем внутреннем канале Slack: «этот проект на самом деле лучше спроектирован, и с каждым выпуском работать с ним все приятнее!». Ни в коем случае, как это может быть? Мы начали анализировать это явление и вот что обнаружили:
Всегда находите время подумать и обсудить
Будет ли ваш клиент доволен этим? Смотря как. Если вы скажете ему, что вам нужно 10 часов, чтобы ДУМАТЬ, а не КОДИТЬ, он, вероятно, скажет, что платит вам за написание кода и доставку программного обеспечения, верно? Но, пожалуйста, скажите мне: кто вы, ИНЖЕНЕР с опытом разработки программного обеспечения или кодовая обезьяна, которая взламывает какой-то грязный спагетти-код, потягивая соевый латте в Starbucks? Бьюсь об заклад, ваш клиент предпочел бы хирурга, у которого есть план операции, прежде чем он вскроет его, а не горячую резню.
Всегда создавайте контрольный список: план реализации. И попросите кого-нибудь просмотреть его, прежде чем вы начнете кодировать.
Когда мы получаем запрос на новую функцию, мы никогда не открываем Visual Studio и не хакаем. Открываем OneNote, где сохранены все наши знания по проекту. Затем мы создаем новую заметку с именем функции. Затем мы вставляем всю информацию, которую получили от заказчика. Затем мы создаем контрольный список: план реализации! Как только план готов, другой разработчик просматривает его и либо принимает, либо отклоняет. Все просто: подумайте, прежде чем делать. Всегда. Вы будете удивлены, узнав, сколько глупых идей никогда не воплощаются в код только потому, что мы сначала пишем на простом английском языке.
Это было бы невозможно без «резервного времени/буфера бюджета» в оценках, предоставленных заказчику. Владелец бизнеса должен убедиться, что все понимают и принимают это. Собственно: это одна из его основных обязанностей. Без этого кусочка головоломки все в конечном итоге развалится. Если «буфера» оказалось слишком много и он не был использован, он «возвращается» заказчику. Это чрезвычайно важно — это укрепляет доверие.
ЛЮБОЙ код стоит дешево. Не требующий пояснений, хорошо спроектированный и протестированный код — вот что важно.
Оценивайте, критикуйте, оставляйте отзывы
Мы часто просим друг друга взглянуть на наш код, прежде чем объединять наши частные ветки в общую ветку кода. А знаете, как часто каждого из нас критикуют? Почти каждый раз. Проверка кода — это не рукопожатие, признание того, какие мы классные, и кивание головой в слепом одобрении. Обзор кода — это поиск слабых мест и обсуждение возможных лучших альтернатив. Когда мы говорим этот код — дерьмо, он нам здесь не нужен, мы не имеем в виду, что автор — паршивый разработчик. У нас нет паршивых разработчиков в нашей команде. Это просто означает, что, возможно, есть лучший способ выразить намерения разработчиков. Мы понимаем, что отзывы не обязательно должны быть положительными, чтобы быть ценными. Отрицательный отзыв — это то, что делает нас лучше, что позволяет нам совершенствоваться. Никогда не обижайтесь на это! С другой стороны: не будьте Линусом, давая обратную связь :).
Код-ревью — это не рукопожатие, рассказ о том, какие мы классные, и кивание головой в слепом одобрении. Отрицательные отзывы делают нас лучше.
Мы всегда пытаемся представить, что читаем один и тот же код через 6 или 12 месяцев. Поймем ли мы, что он делает? Это должным образом задокументировано с тестами? Достаточно ли детализированы и связны коммиты в Git? Как видите, мы не ограничиваемся только обзорами CODE. Весь процесс разработки важен, поэтому вам также следует уделять пристальное внимание контролю версий и истории проекта. Вам ПОНАДОБИТСЯ удобочитаемая история проекта раньше, чем вы ожидаете.
Автоматизировать
Эти практики требуют времени. И все мы знаем, что время имеет значение. Но! Если вы не будете тратить время на другие вещи, у вас будет время на то, о чем я пишу здесь.
Код -> фиксация -> нажатие -> готово. Буквально СДЕЛАНО. Вам просто НУЖНО иметь этот процесс.
Вы когда-нибудь создавали «развертываемые zip-архивы» на своей машине для разработки? Вы когда-нибудь вручную переносили их через FTP? Вы когда-нибудь обращались к веб-серверу, чтобы остановить пул приложений и заменить файлы вашего веб-сайта? Вы когда-нибудь заходили вечером на рабочий сервер базы данных, чтобы копировать/вставлять SQL-скрипты для обновления вашей БД? И еще: вы когда-нибудь ВРУЧНУЮ писали примечания к выпуску? Ты…
Ну… ты делаешь это неправильно!
Если вы не занимаетесь непрерывной доставкой, неудивительно, что у вас нет времени на важные вещи. Сделайте себе одолжение и стремитесь к этому: код > зафиксировать > нажать > выполнить. Буквально СДЕЛАНО. Все остальное (сборка/тестирование/развертывание) должны делать машины. Вот для чего они нужны. Воспользуйтесь тем, что они еще не ВОССТАЛИ, чтобы сделать нас своими рабами. Вы удивитесь, сколько времени у вас будет.
Рефакторинг
Новые функции редко «вписываются» идеально, превращаясь в еще одну часть головоломки. Как часто вы вынуждены просто разбить его, а затем смотреть в другую сторону, делая вид, что все по-прежнему хорошо? Ну вот и все: после нескольких итераций ваша программная головоломка развалится. Мы все были там, верно? Но нельзя ожидать, что голем будет стоять вечно, если его ноги сделаны из дерьма.
Хороший дизайн в конечном итоге приносит прибыль.
Не ждите, что это будет легко. Каждый раз, когда вы изменяете свой код, вы можете в конечном итоге реорганизовать его МНОГО. И это прекрасно. Как только вы обнаружите, что это можно смоделировать другим способом, чтобы лучше выразить свои намерения, действуйте и посоветуйтесь со своими коллегами, если они тоже думают так же.
Каждый разработчик и каждый клиент (внутренний или внешний, не имеет значения) должен понимать, что: хороший дизайн в конечном итоге приносит прибыль.
Но код — это еще не все. Процессы тоже подлежат рефакторингу! Вам действительно нужны все эти формы, которые разработчики заполняют вручную? Вам нужно отслеживать время в нескольких местах? Разве интеллектуальный автоматизированный процесс не может собрать все данные со всех инструментов, которые вы используете, и создать ежедневный отчет о том, «что было сделано кем и почему»? Сомневайтесь в своем процессе разработки! На это потрачено много времени, гарантирую.
Командная работа – это КОРОЛЬ
Вам не нужна команда гениев, чтобы создать отличное программное обеспечение. Только в самых удачливых компаниях (одна из них — та, в которой я работаю ;)) нет ленивых невежественных ублюдков, которым просто «все равно». Но часто достаточно обычной КОМАНДНОЙ РАБОТЫ.
Не сосредотачивайтесь только на LOC, созданных командой. Сосредоточьтесь на долгосрочной цели.
Когда один разработчик терпит неудачу — другой может вмешаться. Не указывая пальцами. Многие пары глаз улавливают больше глупых решений, чем одна пара глаз, особенно если она принадлежит тому, кто принимает решения. Несколько мозгов найдут лучшее решение, чем один мозг, каким бы умным он ни был. Примите этот факт и поощряйте обмен знаниями в своей команде, чтобы получить максимальную отдачу от своих людей. Над каждой задачей должны работать несколько человек — сделайте это привычкой. Им не нужно все время работать вместе: стопроцентное парное программирование неэффективно, независимо от того, что вы читаете в блогах «догматиков парного программирования». Но работа одного разработчика должна быть принята и одобрена кем-то другим.
Не сосредотачивайтесь только на LOC, созданных командой. Сосредоточьтесь на долгосрочной цели.
Резюме
Можете звать меня Мистер Очевидность: в этом посте нет ничего революционного. Но поверьте мне: всего этого в совокупности достаточно для создания высококачественного программного обеспечения. Это не НАСТОЛЬКО сложно. Также: обратите внимание, что мы работаем удаленно и все еще можем применять все эти правила. Я считаю, что это еще проще, когда вся команда находится на месте.
Удачного кодирования!
