Если вы пишете код не менее 4 лет, вы наверняка сталкивались с ситуацией, когда вам приходилось работать с чужой кодовой базой. Это нормально в сегодняшней быстро развивающейся ИТ-индустрии, когда кто-то начинает проект, а в середине другие должны вмешиваться, чтобы завершить его. Причиной может быть что угодно: от того, что первоначальная команда покинула компанию, или от того, что ей нужны руки, чтобы привлечь новых разработчиков в середину. В любом случае, работа с чужим кодом может быть болезненной. И дело не только в том, что вы работаете с чужим кодом, но и кто-то другой, работающий с вашим кодом, может быть столь же болезненным. Причина этой боли в основном в том, что мы склонны следовать своему языку. Не язык программирования, а язык кодирования. Я мог бы следовать некоторым другим концепциям, таким как написание логики в классах обслуживания, тогда как вы могли бы следовать чему-то другому. И если не быть осторожным, вся наша кодовая база может превратиться в беспорядок, когда каждый разработчик, работавший над проектом, следовал своему языку. Чтобы решить эту проблему, разработчики в большинстве случаев соглашаются следовать обобщенному языку. Опять же, этот язык может полностью отличаться от того, чему следует мир. Это означает, что когда новый разработчик начинает работать над вашим проектом, он должен выучить ваш язык программирования. В худшем случае он или она начнет реализовывать свой язык, делая существующую кодовую базу более беспорядочной. Некоторые классы могут внедрять зависимости, некоторые могут расширять родительские классы, потому что один разработчик подумал о написании общего кода в отдельном классе и решил наследовать этот класс для повторного использования. Некоторые могут предпочесть делегирование наследованию.

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

Проблема

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

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

Мой взгляд

То, как люди интерпретируют религию, то, как мир разделен между экстремистами и мыслителями, где-то мы пытаемся найти общую связь со всеми, мы называем это «эмпатией». Я никогда не осознавал, насколько сильно это слово, пока не прочитал «Hit Refresh» Сатьи Наделлы. Теперь основное определение эмпатии — это способность понимать и разделять чувства другого. Но тогда что это значит для программистов?

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

Нашей целью должно быть написание «удобочитаемого» кода. Ни программистам, ни машиночитаемым, а «человекочитаемым». Важно определить разницу. Что я имею в виду под «человекочитаемым» кодом?

// The regular cod
$post = $user->getPost($post);
// If post is empty then user is not the owner and redirect
if ($post !== null) {
  // Do something
}
// Alternative
if ($user->owns($post)) {
    // Do something
}

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

Теперь вы поняли разницу? Что я имею в виду под «человекочитаемым» кодом? И вот тут на сцену выходит эмпатия. Сочувствие к нашим коллегам-разработчикам поможет нам писать более гуманный код. И, честно говоря, вы, вероятно, можете просто написать элегантный читаемый код и выполнить работу, а не следовать шаблонам проектирования по книге. Любой проект малого и среднего размера можно написать простым читаемым кодом, следуя основным принципам ООП и SOLID. Вы можете положиться на шаблоны проектирования в отношении 10–20% сложности там, где это кажется «действительно» необходимым.

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