С @Julia_Hayward, Джеффом Фостером и со мной @ TheCodeCleaner

Получение обратной связи является частью повседневной жизни в Redgate, и поэтому Редгейт попросил Дэна Норта прийти и оценить, как мы делаем что-то, что у нас хорошо получается, а что - хуже.

Одна из областей, которую выделил Дэн, касалась наличия четкой технологической стратегии, включая Технический радар (см. Сообщение Джеффа) и набор Общепринятых рекомендаций по кодированию.

«Все это нам необходимо, чтобы реализовать набор общепринятых руководящих принципов» - Дэн Норт.

Хотя в прошлом Redgate предпринимала попытки установить правила кодирования, на самом деле они не «застряли»; попытки определить их с нуля увязли в масштабах задачи.

Чтобы быстро начать процесс и дать людям что-то, против чего они могут возразить, Джефф нашел в Интернете (что может возможно, что-то пошло не так), и это дало нам набор для работы.

Рекомендации по написанию кода на C # для решений Aviva: csharpcodingguidelines.com

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

Примером Руководства по кодированию может быть:

Рекомендации по ремонтопригодности: методы не должны превышать 7 утверждений (AV1500).

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

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

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

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

Кроме макета.

Макет отвлекает. Слишком много времени было потрачено на священные войны за то, должны ли скобки стоять на новой строке или в ее конце. Я знаю, что разработчики вовлекаются в Bracket Wars ™ из-за этого: один делает коммит в одном стиле, а другой отменяет его в следующем коммите. И не заставляйте разработчиков начинать с пробелов. Всегда.

Мех. Позвольте автоматическому форматеру (и его настройкам по умолчанию) работать над этим.

Нет, давай потратим время на самые жирные, которые имеют значение.

Например, именование.

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

Мы спросили всех участников об их мнениях, и они варьировались от свежих 12-недельных курсов по программированию, до выпускников, вплоть до старших разработчиков, технических руководителей Redgate и Джеффа в качестве руководителя отдела разработки продуктов. У каждого был голос.

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

  • имена должны состоять только из одного символа, или
  • имена должны состоять из 128 символов

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

Изучив стандартный набор рекомендаций по кодированию и сопоставив мысли каждой группы, мы обнаружили, что у них не было проблем с примерно 80% рекомендаций, но около 20% были более спорными (для вас это похоже на принцип Парето?).

Затем мы дали группам время ознакомиться с остальными областями рекомендаций, включая дизайн, ремонтопригодность и структуру. И снова 80% были спорными, что позволило нам сосредоточиться на оставшихся 20%.

Хотя было предоставлено некоторое время для обсуждения, всех, кто был не согласен с нами, мы попросили несогласного отправить «Проблема» на github, где мы разместили набор руководящих принципов, контролируемых версиями.

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

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

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

Репозиторий Redgate Coding Guideline: codingguidelines.red-gate.com

По мере приближения Нового года любые последние нерешенные вопросы будут решены техническими руководителями Redgate, если они дойдут до этого, и должны быть приняты новые правила на 2019 год.

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

* Как вы понимаете, в то время я работал с Java.