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

Умственно утомительный пример

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

Вам не нужно поддерживать несколько форм на каждой странице. Если вам когда-либо понадобится изменить внешний вид формы, добавить или удалить поля, вам нужно только посетить эту функцию и изменить поведение функции. Это соответствует принципу DRY, который является аббревиатурой от «Не повторяйся».

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

В этом примере мы добавляем oldAddress в качестве новой переменной, которую отслеживает наш <UsersBioForm />. Несколько дней спустя, с добавлением и изменением требований каждый раз, ваш <UsersBioForm /> может превратиться в новый кошмарный код, наполненный условными выражениями. Допустим, мы хотим различать форму регистрации и форму редактирования профиля, добавив флажок.

Наша простая форма биоданных превратилась в своего рода «супер» форму, которой, как мне кажется, будет трудно следовать, если этот код будет обрабатываться новым программистом в будущем.

Управление сложностью - основная цель всех принципов кодекса

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

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

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

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

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

TL; DR: пожалуйста, упростите мне просмотр вашего кода

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