Предпочитайте ясность и ясность разуму и неявной магии

Предпочитайте делать свой код доступным для поиска, а не использовать много динамической магии, которая затрудняет поиск использования. Если что-то волшебно и не поддается восприятию, не делайте этого. «Соглашение важнее конфигурации» не всегда правильно, когда оно затемняет.

Предпочитайте намеренное раскрытие названий методов встроенным комментариям.

Комментарии могут устаревать. Имена методов выполняют двойную функцию, поскольку четко указывают на свои намерения.

Избегайте метапрограммирования, если только вы не создаете общую структуру.

Признайте, что общие вещи создать намного сложнее, чем конкретные. Обобщайте, когда у вас достаточно понимания конкретных вариантов использования, что обычно означает внедрение чего-то дважды или трижды.

Предоставьте документацию на уровне класса, раскрывающую общую картину

Расскажите нам, какова цель вашего класса по отношению к другим классам, вариантам использования и рабочим процессам.

Предпочитайте более мелкие методы и классы

Отдавайте предпочтение небольшим методам (‹8 строк кода) и небольшим классам (‹70 строк кода).

Предпочитайте частные методы локальным переменным

Используйте извлечение локальной переменной для рефакторинга метода. Классы, в которых растут большие наборы частных методов, не связанных между собой, обычно требуют наличия объектов-сотрудников.

Держите код в рамках методов одного и того же «уровня абстракции».

т.е. если код - это все вызовы других методов, то не должно быть никаких подробностей. -абстракция-при-писании-составлено-f»

Предпочтите конкретизировать поведение (классы вариантов использования) и конкретизировать условную логику (объекты политики)

Не втискивайте бизнес-логику в классы сущностей/моделей в виде методов и условий, за исключением самых простых случаев, связанных с объектом. Распознавайте разные скорости изменений и размещайте их в разных местах.

Покидайте кемпинг лучше, чем вы его нашли

Внедряя новые функции, старайтесь очистить область, в которой вы работаете, в разумных пределах и пропорционально боли, которую вы испытываете при работе над функцией. Следуйте «правилу 3» — если больно 3 раза, сделайте рефакторинг. Не тратьте день на рефакторинг фрагмента кода, который используется небольшой долей пользователей и никогда не затрагивается разработчиками, но потратьте неделю на исправление критической части инфраструктуры, которая причиняет боль всей команде.

Расставьте приоритеты над ошибками, а когда они возникнут, инвестируйте пропорционально

Разбейте проблемы на части — почему возникла ошибка? Копайте глубже, понимайте коренные, а не поверхностные причины, и инвестируйте пропорционально на каждом уровне. Если ошибка затронула одного пользователя, исправьте ошибку и двигайтесь дальше. Если это привело к падению всей системы, вложите средства в исправление основного процесса.

Дважды подумайте, когда будете называть имя, и получите отзывы от других.

Назвать что-то — это самое важное, что вы делаете как разработчик. Используйте узкие и конкретные имена для конкретных случаев использования (например, CreateAccount, а не UserService), чтобы классы не становились огромными.

Попробуйте назвать понятия, используя повседневный язык

Отдавайте предпочтение языку, уже используемому в бизнесе, а не инженерно-техническим именам. Попросите кого-нибудь проверить ваши решения об именах, прежде чем они закрепятся в кодовой базе. Лучшее время — это когда вы собираетесь создать новый код, а не когда вы собираетесь его выпустить.

Не думайте, что система и процессы, которые у нас есть сегодня, самые лучшие

При создании систем всегда учитываются сегодняшние предположения. Не все, что мы делали полгода назад, будет актуально сегодня. Высказывайтесь и подвергайте сомнению существующие практики, реализации и процессы, если у вас есть конструктивная критика.

Все изменения в рабочих системах должны быть внесены в сценарий

Не редактируйте файлы на серверах. Имеют свойство исчезать. Убедитесь, что любые изменения конфигурации сохраняются в централизованном репозитории, который может быть автоматически применен к новым серверам.

Создавайте хорошие модели поведения для тех, кто придет после вас

Уменьшите дублирование бизнес-знаний (в отличие от случайного дублирования структуры), чтобы у следующего человека, который коснется вашего кода, не возникло соблазна вырезать и вставить для создания нового экземпляра. Назовите свои переменные, классы и методы как можно четче. Получите сторонний взгляд от другого члена команды и убедитесь, что он может легко понять, что вы написали.

Усилия, вложенные в код, должны быть пропорциональны ценности для бизнеса

Хотя мы все хотели бы тратить время на полировку каждой строки, которая входит в кодовую базу, затраты времени должны быть пропорциональны ценности для бизнеса. Это означает, что код для администратора может быть просто тестом счастливого пути, а не полной серией регрессионных тестов. Это никогда не должно использоваться в качестве предлога для выпуска небрежного кода, просто для того, чтобы убедиться, что наши усилия расходуются таким образом, который отражает нашу роль как драйверов ценности для бизнеса.

Лучший код в мире не имеет значения, если он создает плохой пользовательский интерфейс

В конечном счете, люди, которые используют наш сайт, не заботятся о нашем коде, они просто хотят, чтобы все работало, было весело и легко в использовании. Мы всегда должны вкладывать пропорциональные усилия в работу с нашей командой UX, чтобы гарантировать, что пользовательский интерфейс любой функции находится на должном уровне. Срезать углы на UX, тратя много времени на улучшение кода, контрпродуктивно. При создании своей функции заранее и часто общайтесь с заинтересованными сторонами, чтобы убедиться, что вы создаете правильную вещь, и получите рекомендации от нашей команды UX.

Проверьте свой код экспертами

Получите раннюю помощь в дизайне через сопряжение и используйте проверки работоспособности во время работы над своими историями. Пары помогают вам определить, когда вы идете в неправильном направлении и тратите время впустую, а также помогают вам проверять и улучшать дизайн вашего кода. Используйте запросы на вытягивание, чтобы остальная часть команды могла понять, что добавляется в кодовую базу, но используйте сопряжение заранее и часто, особенно в сложных историях, чтобы предотвратить «синдром полной перезаписи» при просмотре запроса на вытягивание.

Будьте добры друг к другу и проявляйте эмпатию

Мы команда, а команды могут иметь разные мнения и часто не соглашаться друг с другом. Несогласие — это нормально, но мы всегда должны уважать друг друга и идти еще дальше, чтобы быть хорошими. Мы не являемся нашим кодом, поэтому обсуждение кода и его качества не следует принимать на свой счет. Постарайтесь сделать хотя бы один положительный комментарий к пулл-реквесту, даже если у вас есть критические замечания. Все мнения должны подвергаться тщательной проверке, и каждый член команды должен чувствовать, что может высказываться. Основной принцип хорошего отношения друг к другу отражает нашу веру в то, что мы можем добиться успеха только при всеобщей помощи и доверии.