#РазрабошнаяЧитает #SoftwareDesignPhilosophy В прошлой заметке мы коснулись техники организации кода в виде "глубоких модулей", позволяющей значимо уменьшить количество зависимостей, а также сделать очевидной как минимум часть необходимой информации о системе. Увы, даже по тому, как это звучит, становится понятно, что "глубокие модули" - не серебряная пуля. Особенно, если у куска кода есть история( Дело в том, что код - это некий итог зачастую достаточно сложного мыслительного процесса, происходившего в голове разработчика. И, если для того, чтобы код работал здесь и сейчас, достаточно его просто написать, то для того, чтобы его использовать и развивать, нужно нечто большее. Особенно, если в голове разработчика действительно вершилась магия))) Тут уже важно иметь перед глазами информацию о том, что код делает и почему он это делает именно так. Добиться этого автор книги предлагает при помощи комментариев. Комментарии? Тоже мне, изобретение, скажете вы) Что тут может быть нового?! И вообще, Мартин давным-давно всем велел заменить комментарии говорящими именами! Однако, не всё так просто) Да, действительно, всему, чему только можно, стоит давать говорящие и осмысленные имена. Однако, имена никогда не станут полноценной заменой комментариям, особенно, в сложных случаях. Или по длине будут сопоставимы с ними) Кроме того, комментарий комментарию рознь, их вид и назначение могут разниться. В целом, автор книги выделяет два вида комментариев. - Комментарии, описывающие, что код делает на едином языке проекта. Цель их добавления в том, чтобы все заинтересованные лица могли самостоятельно понять, как кодом пользоваться. - Комментарии, поясняющие, почему код написан именно так, как написан. Цель их добавления в том, чтобы любой разработчик мог внести в этот код необходимые правки. По сути, в понимании автора книги, цель добавления комментариев — обеспечить коду возможность существовать самостоятельно в отсутствие тех, кто, принимал участие в его написании. Для того, чтобы добавленные комментарии оставались актуальными и приносили пользу, достаточно соблюдать два "простых" правила: - не пересказывать код в комментариях; - обновлять комментарии после внесения правок в код. В итоге, по мнению автора книги, организации кода в виде "глубоких модулей", а также его документирования при помощи двух видов комментариев, должно быть достаточно для того, чтобы держать сложность разрабатываемой системы под контролем. Подписаться | Чат