Применение концепций дизайна в коде - Часть III

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

В: Следует ли мне иметь документ стиля кода для моего проекта?

О: Документ стиля кода - это культурное ограничение. Это способ ограничить способ написания кода в базе кода. Если кто-то когда-либо отправит код, который не соответствует документу стиля кода, вы будете освобождены от всякой вины при запросе изменения какого-либо кода, который не соответствует стилю в вашей базе кода - просто укажите на документ стиля кода! Согласованный код во всей базе кода упрощает чтение кода из файла в файл, что в конечном итоге упрощает обслуживание.

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

В: Что мне следует протестировать?

О: Это зависит от типа тестирования, которое проводит ваша команда. Возможно, хороший способ ответить на этот вопрос - задать другой вопрос: какая функциональность обещана потребителю кода? Вероятно, вам следует проверить, удовлетворены ли обещания пользователю и соответствующие случаи ошибок обрабатываются.

В: Что нам следует думать об архитектуре / шаблонах проектирования?

О: Шаблоны проектирования - эффективные способы быстрого обмена концептуальными моделями. При правильном применении код в вашей кодовой базе может быть интуитивно понятным и простым в использовании. При случайном применении вы можете получить базу кода, которая затрудняет понимание, обслуживание и реализацию новых функций и / или отнимает много времени. Будьте осторожны при использовании бланкет-правила, чтобы всегда применять определенный шаблон проектирования к каждой части вашей кодовой базы - понимание может быть легким, но обслуживание и добавление функций могут занять много времени.

В: Почему я должен использовать дизайн в моем коде?

О: В своем выступлении Простота имеет значение Рич Хики рассказывает о работе с базой кода, которая в конечном итоге превращается в чудовище размером со слона. Когда вы дошли до этого момента, ваш код занимает место за столом, когда вы думаете о добавлении новых функций. Если вы не задумывались о дизайне намеренно, вы можете оказаться в ситуации, когда добавление, казалось бы, тривиальной функции становится нетривиальным. Вы же не хотите ставить себя в ситуацию, когда ваш код диктует, как вы работаете.

В: Что мне следует думать о написании сообщений о фиксации?

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

В: Следует ли мне ограничивать количество строк кода в функциях, которые я пишу?

О: Ответ на этот вопрос зависит от написанного кода. Например, я слышал, что на истребителях F18 код представляет собой одну длинную непрерывную функцию. Это имеет смысл для такого важного программного обеспечения. Для объектно-ориентированного кода одна непрерывная функция не имеет смысла. В колледже меня учили, что функции должны начинаться и заканчиваться в пределах высоты экрана - это гарантирует, что функцию можно будет прочитать / понять без необходимости прокрутки. Это имеет интуитивный смысл, но количество строк в методе, вероятно, не должно быть причиной изменения вашего дизайна. Скорее, длинная функция может быть хорошим показателем того, что слишком много функций объединено в одну функцию.

В: Что мне добавить в README для моего проекта?

О: Считайте README вводной частью вашего проекта. Подумайте о вопросах, которые могут возникнуть у кого-то в начале работы, и поместите ответы на эти вопросы в README. Например, «Как создать и запустить этот проект?», «Где мне найти ресурсы для этого проекта?», «Есть ли кодекс поведения?»

В: Следует ли мне писать документацию?

A: Некоторые люди утверждают, что комментарии в коде не нужны и только добавляют к объему обслуживания, потому что они считают, что код должен быть самодокументированным. Безусловно, замечательно стремиться писать код, который настолько ясен, что комментарии не нужны. Но при написании кода у нас есть преимущество в том, что мы хорошо разбираемся в контексте и предметной области той части системы, над которой мы работаем. При использовании кода у нас не обязательно будет это преимущество. Как писать самодокументированный код, когда речь идет о крайних случаях? Еще одно важное соображение заключается в том, что ваш код может быть чьим-то введением в базу кода. Написание комментариев может улучшить впечатление человека, использующего ваш код, и избавить от разочарования. Комментарии - это один из шести компонентов дизайна - почему бы не использовать их, чтобы донести свой дизайн до пользователей?

В: Что мне следует думать об организации кода в файле?

A: Организация вашего кода - это форма ограничения. Например, если вы знаете, что методы и свойства всегда располагаются в алфавитном порядке, вы точно знаете, где искать метод с именем removeItem. Алфавитный указатель - хороший вариант по умолчанию для организации кода, но может иметь смысл организовать код другими способами в зависимости от проекта. Пока организация последовательна, вы не ошибетесь!

На какие еще вопросы уровня проекта вы можете ответить, используя концепции дизайна?

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