Когда над кодом работает команда, приходится прилагать дополнительные усилия, чтобы лебедь, рак и щука тянули проект не строго в разные стороны, а хотя бы примерно туда, где деньги. Обычно этого легко удается добиться за счет того, что рак делает всю работу, щука валяется на больничном, а лебедь уволился, и компания прямо сейчас нанимает двух новых.
Шутки шутками, но редко команда состоит сплошь из профессионалов до мозга костей, одинаково легко работающих с любой частью проекта, способных при этом еще и находить общий язык друг с другом. И, разумеется, ставящих на первое место интересы компании, а не свои собственные.
Для больших проектов нежелательна, но вполне естественна ситуация, когда разработчики специализируются по своим “участкам”, влезая в чужую область только по необходимости. Например, Василий Предсказалов по заданию партии разработал сервис “Продавака”, определяющий, какие дополнительные товары стоит порекомендовать к покупке клиенту, купившему “зюзюблик горизонтальный, 1м”.
Кому менеджер проекта выдаст задачу на обновление функционала этого сервиса? Исправить ошибку, причина которой не выглядит очевидной? Разумеется, Василию.
В этот момент опытный менеджер уже напрягся, как так в отделе появился незаменимый сотрудник. Поэтому в помощь Василию выделяется Иван Саппортень, которому сгружают менее важные задачи, связанные с “Продавакой”.
А потом Василий уходит в другой отдел и начинает со страшной силой работать над другим проектом. Менеджер вынужден ставить Ивана на место Василия и начинать обучать кого-то третьего.
Для более-менее опытного управленца эти процессы являются рутиной, поэтому индустрия выработала несколько приемов, облегчающих совместную работу разных программистов над кодом.
Небольшое отступление для тех, кто работает над проектом в одиночку и не планирует командной работы. Дело в том, что человеческая память, к счастью, несовершенна, и возврат к коду, написанному год назад без соблюдения мер предосторожности, способен вызвать экзотермический процесс (возгорание) в области кресла в результате возросшего числа WTF (восклицание “что за хрень?”) на единицу кода. Поэтому разумно будет воспринимать себя-через-год как отдельного разработчика, озабоченного совсем иными проблемами и плохо представляющим себе контекст задачи, выполненной сегодня.
Первое. Существуют так называемые стандарты PSR, представляющие собой сборник рекомендаций по организации кода. К ним можно относиться по-разному, но начинающим программистам разумно будет временно отложить возмущение тоталитарным принуждением и начать соблюдать самые важные:
Coding style представляет собой набор хороших привычек, которые требуется выработать в первую очередь.
Хорошая новость заключается в том, что современные средства разработки (как мой любимый PhpStorm) могут самостоятельно “причесывать” код по набору правил. Для этого требуется лишь вовремя нажать нужное сочетание клавиш. Среда разработки не будет автоматически переименовывать классы в соответствии с PSR, но переносы строк, отступы, поддержка в актуальном состоянии списка импортируемых классов ей вполне по силам.
Кстати, хотя ничего переименовывать среда не будет, она не постесняется поругать вас за то, что вы использовали неправильное название класса.
Вторая важная вещь, которую непременно надо освоить и использовать даже в проектах, рассчитанных на одного программиста - система контроля версий. Она позволяет отслеживать изменения в рабочих файлах проекта и помнить, кем и зачем это было сделано. И что в этот момент изменилось в других местах кода.
Если вы хотите где-то работать, это должен быть Git. Там все тоже довольно просто, есть интеграция в PhpStorm, есть командная строчка.
Если вы освоили Git и в состоянии отформатировать свой код по стандартам, вы уже красавчик и можете его показывать другим людям.
Готовьтесь к ревизии кода (Code review) - это лучшее, что придумано для совместной разработки.
#программирование с нуля #php #программирование