Что еще должен знать PHP-разработчик?
Как бы странно это ни звучало, чтобы успешно закрепиться на позиции «PHP-программист», знания PHP не всегда достаточно. Например, еще ни один новичок не приходил ко мне с вопросами типа: «а какой функцией можно отсортировать хэш?», или «можно ли обратиться к методу статического класса из трейта?», или «как в симфони поменять путь для логгера?». Поэтому мне хотелось бы привести навыки и умения, отсутствие которых часто вставляет новичкам палки в колеса на старте их работы.
Итак, на первом месте рейтинга косяков, с которыми сталкиваются новички, находится проблема с настройкой окружения. Однажды у меня был случай, когда новенький PHP-программист три дня просидел без дела, потому что не смог разобраться с настройкой песочницы. Выяснилось, что ему было очень стыдно подойти самому с этой проблемой, и конечно, нам пришлось расстаться. Да, в этой ситуации есть часть и моей вины: я оказался так занят завершением очередной итерации, что только на третий день вспомнил о новом члене команды. Итак, я бы выделил это в правило: каждый программист PHP должен уметь настраивать свое окружение. И начать можно с простейших инструментов LAMP, WAMP, MAMP. Но после обязательно освоить любой из этих инструментов: HHVM, Vagrant, Docker, VirtualBox, Ansible, Chef, Puppet или их аналоги. А еще лучше познакомиться с каждым.
Дальше. У новеньких программистов возникают проблемы при совместной работе. Очень часто это связано с отсутствием понимания ветвления и стратегии слияния кода, или просто есть только поверхностное понимание Git. На моей памяти есть история о разработчике, который писал критически важную BackEnd часть приложения. Он упорно отказывался использовать SCM, аргументируя это тем, что все равно никто, кроме него, не осилит этот участок кода, так что до конца проекта он будет работать над ним один. Его все-таки уговорили создать репозиторий, но сделал он это для вида, отправив туда единственный инициализирующий коммит. История кончилась тем, что после месяца разработки у него сгорел винчестер, и месячная работа была потеряна. В итоге проект не уложился в срок, его финансирование прекратилось. Поэтому перед тем, как закапываться в туториал по классам SPL, лучше сначала откройте книжку по Git, и это окажется куда ценнее в будущем. Выработайте в себе внутреннюю привычку работать по GitFlow.
И напоследок можно привести еще несколько небольших советов, ценность каждого из каждого из которых на пути развития до уровня senior может быть подкреплена примерами из реальных проектов в следующих заметках:
- Научитесь пользоваться командной строкой, ssh в особенности
- Подружитесь со своей IDE
- Овладейте слепой техникой печати
- Обязательно используйте менеджер зависимостей composer
- Разберитесь с инструментами деплоя, например ant, capifony, capistrano, phing
- Пользуйтесь инструментами контроля качества кода
- Научитесь оценивать сроки выполнения задач
#deeppostphpbackend
Как бы странно это ни звучало, чтобы успешно закрепиться на позиции «PHP-программист», знания PHP не всегда достаточно. Например, еще ни один новичок не приходил ко мне с вопросами типа: «а какой функцией можно отсортировать хэш?», или «можно ли обратиться к методу статического класса из трейта?», или «как в симфони поменять путь для логгера?». Поэтому мне хотелось бы привести навыки и умения, отсутствие которых часто вставляет новичкам палки в колеса на старте их работы.
Итак, на первом месте рейтинга косяков, с которыми сталкиваются новички, находится проблема с настройкой окружения. Однажды у меня был случай, когда новенький PHP-программист три дня просидел без дела, потому что не смог разобраться с настройкой песочницы. Выяснилось, что ему было очень стыдно подойти самому с этой проблемой, и конечно, нам пришлось расстаться. Да, в этой ситуации есть часть и моей вины: я оказался так занят завершением очередной итерации, что только на третий день вспомнил о новом члене команды. Итак, я бы выделил это в правило: каждый программист PHP должен уметь настраивать свое окружение. И начать можно с простейших инструментов LAMP, WAMP, MAMP. Но после обязательно освоить любой из этих инструментов: HHVM, Vagrant, Docker, VirtualBox, Ansible, Chef, Puppet или их аналоги. А еще лучше познакомиться с каждым.
Дальше. У новеньких программистов возникают проблемы при совместной работе. Очень часто это связано с отсутствием понимания ветвления и стратегии слияния кода, или просто есть только поверхностное понимание Git. На моей памяти есть история о разработчике, который писал критически важную BackEnd часть приложения. Он упорно отказывался использовать SCM, аргументируя это тем, что все равно никто, кроме него, не осилит этот участок кода, так что до конца проекта он будет работать над ним один. Его все-таки уговорили создать репозиторий, но сделал он это для вида, отправив туда единственный инициализирующий коммит. История кончилась тем, что после месяца разработки у него сгорел винчестер, и месячная работа была потеряна. В итоге проект не уложился в срок, его финансирование прекратилось. Поэтому перед тем, как закапываться в туториал по классам SPL, лучше сначала откройте книжку по Git, и это окажется куда ценнее в будущем. Выработайте в себе внутреннюю привычку работать по GitFlow.
И напоследок можно привести еще несколько небольших советов, ценность каждого из каждого из которых на пути развития до уровня senior может быть подкреплена примерами из реальных проектов в следующих заметках:
- Научитесь пользоваться командной строкой, ssh в особенности
- Подружитесь со своей IDE
- Овладейте слепой техникой печати
- Обязательно используйте менеджер зависимостей composer
- Разберитесь с инструментами деплоя, например ant, capifony, capistrano, phing
- Пользуйтесь инструментами контроля качества кода
- Научитесь оценивать сроки выполнения задач
#deeppostphpbackend