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

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

Имена очень важны, потому что они не только служат способом идентификации и поиска абстракций, но и являются первой точкой соприкосновения пользователей для понимания абстракции. Если имя слишком длинное, его чтение/изменение и обнаружение различий между другими длинными именами становятся более сложными. Однако, если имя слишком короткое, в нем может отсутствовать ключевая информация, помогающая понять абстракцию. Длина имени должна меняться в зависимости от области действия. Если метод имеет глобальную область действия, то имя должно быть длиннее, так как его нужно идентифицировать и понимать на протяжении всего проекта. Согласованность с именованием обязательна. Например, не следует использовать термины get и fetch, а только один из них.

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

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

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

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