День двести шестьдесят седьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
4. Автоматизируйте стандарт кодирования
У вас наверняка тоже такое бывало. В начале проекта у всех много добрых намерений. Многие из этих намерений документируются. Те, что касаются кода, попадают в стандарт кодирования проекта. На первом собрании тимлид просматривает документ и, в лучшем случае, все соглашаются, что они попытаются следовать ему. Однако, как только проект начинается, все эти благие намерения отпадают одно за другим. Когда проект, наконец, завершается, в коде полный бардак, и никто не знает, как это произошло.
Где вы свернули не туда? Вероятно, уже на первом собрании. Одни участники проекта не обратили внимания, другие неправильно поняли, третьи вообще не согласились и сразу решили делать по-своему. Оставшиеся всё поняли и согласились, но, когда дедлайн стал поджимать, от стандартов пришлось отступить. Правильно отформатированный код не получит очков от клиента, который хочет больше функциональности. Кроме того, следование стандарту кодирования может быть довольно скучной задачей, если оно не автоматизировано. Просто попробуйте навести порядок в классе, чтобы убедиться в этом.
Но если всё так сложно, зачем мы вообще вводим стандарт кодирования? Одна из причин форматирования кода единообразным способом заключается в том, что никто не может «владеть» частью кода, просто отформатировав его по-своему. Мы можем запретить разработчикам использовать определенные антипаттерны, чтобы избежать некоторых распространенных ошибок. Стандарт кодирования должен облегчить работу в проекте и поддерживать скорость разработки от начала до конца. Из этого следует, что все должны согласиться с принятым стандартом кодирования: если один разработчик использует три пробела для отступов кода, а другой использует четыре, ничего хорошего не выйдет.
Существует множество инструментов, которые можно использовать для составления отчетов о качестве кода, а также для документирования и поддержания стандарта кодирования, но это не панацея. Стандарт должен быть автоматизирован и применён везде, где это возможно. Вот несколько примеров:
- Сделайте форматирование кода является частью процесса сборки, чтобы оно выполнялось при каждой компиляции.
- Используйте статические анализаторы кода для обнаружения антипаттернов. Если они найдены, отменяйте сборку, как при критической ошибке.
- Научитесь настраивать эти инструменты, чтобы вы могли обнаруживать свои собственные специфические для проекта антипаттерны.
- Измеряйте не только охват кода тестами, но и автоматически проверяйте результаты. Опять же, отменяйте сборку, если покрытие тестами слишком слабое.
Попробуйте применить это ко всему, что вы считаете важным. Вы не сможете автоматизировать всё, что вас действительно волнует. Для того, что вы не можете автоматически проверять или исправить, создайте набор правил, дополняющих автоматизированный контроль. Однако смиритесь с тем, что и вы, и ваши коллеги не всегда будут им следовать.
Наконец, стандарт кодирования должен быть гибким. По мере развития проекта потребности меняются, и то, что казалось логичным вначале, не обязательно останется правильным несколько месяцев спустя.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
97 Вещей, Которые Должен Знать Каждый Программист
4. Автоматизируйте стандарт кодирования
У вас наверняка тоже такое бывало. В начале проекта у всех много добрых намерений. Многие из этих намерений документируются. Те, что касаются кода, попадают в стандарт кодирования проекта. На первом собрании тимлид просматривает документ и, в лучшем случае, все соглашаются, что они попытаются следовать ему. Однако, как только проект начинается, все эти благие намерения отпадают одно за другим. Когда проект, наконец, завершается, в коде полный бардак, и никто не знает, как это произошло.
Где вы свернули не туда? Вероятно, уже на первом собрании. Одни участники проекта не обратили внимания, другие неправильно поняли, третьи вообще не согласились и сразу решили делать по-своему. Оставшиеся всё поняли и согласились, но, когда дедлайн стал поджимать, от стандартов пришлось отступить. Правильно отформатированный код не получит очков от клиента, который хочет больше функциональности. Кроме того, следование стандарту кодирования может быть довольно скучной задачей, если оно не автоматизировано. Просто попробуйте навести порядок в классе, чтобы убедиться в этом.
Но если всё так сложно, зачем мы вообще вводим стандарт кодирования? Одна из причин форматирования кода единообразным способом заключается в том, что никто не может «владеть» частью кода, просто отформатировав его по-своему. Мы можем запретить разработчикам использовать определенные антипаттерны, чтобы избежать некоторых распространенных ошибок. Стандарт кодирования должен облегчить работу в проекте и поддерживать скорость разработки от начала до конца. Из этого следует, что все должны согласиться с принятым стандартом кодирования: если один разработчик использует три пробела для отступов кода, а другой использует четыре, ничего хорошего не выйдет.
Существует множество инструментов, которые можно использовать для составления отчетов о качестве кода, а также для документирования и поддержания стандарта кодирования, но это не панацея. Стандарт должен быть автоматизирован и применён везде, где это возможно. Вот несколько примеров:
- Сделайте форматирование кода является частью процесса сборки, чтобы оно выполнялось при каждой компиляции.
- Используйте статические анализаторы кода для обнаружения антипаттернов. Если они найдены, отменяйте сборку, как при критической ошибке.
- Научитесь настраивать эти инструменты, чтобы вы могли обнаруживать свои собственные специфические для проекта антипаттерны.
- Измеряйте не только охват кода тестами, но и автоматически проверяйте результаты. Опять же, отменяйте сборку, если покрытие тестами слишком слабое.
Попробуйте применить это ко всему, что вы считаете важным. Вы не сможете автоматизировать всё, что вас действительно волнует. Для того, что вы не можете автоматически проверять или исправить, создайте набор правил, дополняющих автоматизированный контроль. Однако смиритесь с тем, что и вы, и ваши коллеги не всегда будут им следовать.
Наконец, стандарт кодирования должен быть гибким. По мере развития проекта потребности меняются, и то, что казалось логичным вначале, не обязательно останется правильным несколько месяцев спустя.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/