Разработка
Григорий Петров: Объектно-Ориентированное программирование
Но самое главное во всей этой истории: понимание, почему при взгляде на чужой код хочется все выкинуть и переписать. Очень часто это совсем не потому, что код плохой. А потому, что его писал другой человек.
Я уже много раз рассматривал гипотезу о работе нашего мозга, который любит строить и использовать модели окружающего мира. Это даже не одна гипотеза, а целый ряд наблюдений: как люди рождаются, растут, изучают окружающий мир и взаимодействуют с ним. Одна из гипотез предполагает, что многие механизмы моделирования у нас встроенные. К примеру, есть подозрение, что у младенцев существуют готовые механизм моделирования и распознавания лиц, социальных ситуаций, выделения «действующего лица» (actor) и его цели (intent).
Если вы посмотрите на две точки и линию под ними, то увидите «лицо». Как в этом смайлике: «:)». Встроенный механизм этого, возможно, заложен у нас на генетическом уровне. Похожий механизм, известный как «мифологическое сознание», это выделение «действующих лиц» и их «целей». Люди по своей природе социальны, эти механизмы позволяют ребенку понять, как работает социум и стать его частью. Когда ребенок видит другого человека, то он воспринимает этого человека как «действующее лицо», а его действия воспринимает как имеющие какую-то «цель». Механизмы довольно простые и распространяются не только на живых людей, но и на окружающий мир. Ребенок нескольких месяцев от роду уже способен различать, что квадратик на экране «гонится» за треугольником, а круг треугольнику «помогает».
Действующие лица и их мотивы
Мозг — не компьютер, в нем, скорее всего, нет жестко изолированных друг от друга программ. Мифологическое сознание не только позволяет ребенку понять работу нашего общества и верить в деда мороза. Эти же механизмы влияют на наш язык и на модели окружающего мира. Во фразе «машина едет к дому» этот механизм формирует образ одушевленного действующего лица, машины, которая движется с определенной целью. «Дождь идет». «Солнце светит». «Кофеварка сломалась мне на зло!». Все эти привычные фразы раскрашивают окружающий мир осознающими себя существами, совершающими действия с какими-то целями.
Кстати, паранойа — одно из нарушений работы этого механизма, когда мозг слишком активно начинает искать действующих лиц. Параноик понимает, что лист летит по ветру, чтобы что-то ему сказать. И теперь вы знаете, почему. Но все равно не сможете избавиться от ощущения, что кофеварка сломалась вам на зло. Потому что так работает наш мозг.
Декомпозиция
Объектно-ориентированное программирование является одним из способов борьбы со сложностью. Сначала мы видим в коде повторяющиеся штуки и начинаем давать им имена. Затем мы видим группы штук, которыми мы оперируем вместе, и даем имя такой группе. После чего группа становится объектом. А через некоторое время у этого объекта появляются методы. Если не повезет — класс, наследование и миксины.
А теперь следите за руками. Наши модели мира используют «действующих лиц». Наш язык использует «действующих лиц». И тут нам нужно именовать в программе объекты, с которыми что-то происходит! Логично предположить, что мозг будет использовать для этой сложной задачи уже существующие, обкатанные и более-менее хорошо работающие механизмы. «файл.открыть()», «окно.закрыть()» — все вот это.
А теперь сюрприз. Механизм, который позволяет ребенку понять, что квадратик «гоняется» за треугольником, а секретарше, что «кофемашина на нее обиделась» — не то чтобы очень точный инструмент. И если для окружающего мира у нас есть жизненный опыт, прочитанные книги, пример других людей — то в случае программы, в отсутствии фундаментального образования, программист предоставлен самому себе. Как сгруппировать объекты? Какие у них будут отношения друг с другом? Окно будет регистрироваться в области нотификаций, или область нотификаций будет добавлять в себя окно?
А это важно?
Кто вокруг кого вращается
А теперь еще один сюрприз — важно. В зависимости от того, как выбраны объекты и взаимодействия между ними, сложность системы может отличаться кардинально. Давайте вспомним известную шутку с солнечной системой. На анимации ниже объекты движутся друг относительно друга одинаково. Но в одном случае в центре внимания объект «Земля», относительно которого рассматриваются остальные участники движения, а в другом случае это «Солнце».
Нарисованная справа Марсом траектория как бы намекает нам, что неудачно выбранные объекты могут привести к печальным последствиям. Я сам могу вспомнить множество случаев, когда при разработке Windows приложений все начиналось с объекта «главное окно». Который со временем начинал обрастать все большей и большей функциональность, пока, наконец, не превращался в чудовищный клубок запутанных связей, обеспечивающий работу нескольких десятков других окон, фоновых потоков, дочерних процессов и множества других шутки. Поддерживать, а тем более развивать такие программы было очень тяжело.
Программист художник, он так видит
Программирования — очень молодая отрасль. Множество программистов — самоучки. «Лучшие практики» разработки сменяют друг друга раз в пару лет. Полагаю, что не открою Америку, если скажу, что программисты по-разному группируют объекты и методы их взаимодействия. А потом им тяжело читать и поддерживать код друг друга. Чужая ментальная модель — она как чужая одежда. Иногда жмет, иногда свисает, а иногда просто не налезает.
Если мы хотим, чтобы программисты работали в команде и могли поддерживать код друг друга, то важно ментальные модели синхронизировать. Большую роль в этом играют opinionated фреймворки, которые жестко диктуют состав и отношения объектов внутри программы. Когда все разработчики используют один, выбранный тим лидом фреймворк — это хорошо. Почетное второе место занимает стандарт кодирования, в котором команда записывает общие моменты, о которых разработчики договорились друг с другом. Найм разработчиков с похожим бэкграундом также играет нам на руку.
Но самое главное во всей этой истории: понимание, почему при взгляде на чужой код хочется все выкинуть и переписать. Очень часто это совсем не потому, что код плохой. А потому, что его писал другой человек. Если научиться понимать физиологические причины такого неприятия, то можно спокойно работать самой разношерстной командой. Ведь со сложностью можно бороться разными способами.