Формирование компетенций PHP в организации
Это на самом деле не вопрос технического программирования, но он больше связан с лучшими практиками и процессами программирования / управления проектами. Вот некоторая справочная информация:
Я являюсь консультантом в гибкой (scrum) компании по разработке программного обеспечения, которая специализируется на стеке технологий Java, J2EE, Flex.
Здесь многие обычно считают, что качество людей, связанных с PHP, проектов и т. Д. Не на должном уровне по сравнению с Java. Несмотря на то, что я часто оспариваю это утверждение, я согласен с тем, что существует общий низкий барьер для входа в PHP, что иногда привлекает людей более низкого качества, которые затем выполняют работу низкого качества.
Для нас качество на первом месте. В течение следующих нескольких кварталов мы также планируем развивать очень высокий уровень компетенции в PHP. И мы хотим достичь наивысшего уровня качества, и наши процессы должны быть такими, чтобы мы постоянно совершенствовались, начиная с самого высокого уровня.
Наши новобранцы проходят строгий отбор, где очень много технических заданий. Мы оцениваем, как они кодируют, мы оцениваем, как они тестируют свой код, мы оцениваем их навыки с помощью стандартных отраслевых сред (Zend, CakePHP, CodeIgniter/Kohana, Symphony).
У нас есть двухмесячное (два раза в месяц) мероприятие по обмену знаниями, на которое приглашаются отдельные лица. У нас также есть руки на события.
Я бы попросил вас поделиться своим опытом о том, как мы, как отдельные лица, так и плоская, гибкая, относительно небольшая организация, можем привить хорошие методы разработки PHP и постоянно совершенствоваться.
Спасибо Шри
5 ответов
Лучший способ стать лучше - это привлекать только тех людей, которые хотят стать лучше. Затем вы должны поддержать этих людей, когда они делают ошибки в стремлении стать лучше. Таким образом, они не боятся пробовать новые вещи.
В США есть такая поговорка: "Нанимай людей с ГПД менее 3,9(из 4,0)"; это отражает цель нанимать людей, которые не достигли совершенства (то есть они научились не совершенствоваться).
Один из лучших способов стать лучше - это мышление "Lean", которое породило гибкие методологии, а также значительное количество историй успеха в производстве.
Общая идея состоит в том, чтобы постоянно участвовать в итеративном процессе самооценки и никогда не тратить ресурсы или блокировать свой рабочий процесс. К этому, конечно, нужно относиться с осторожностью: исследовательские проекты настолько плохо определены, что их почти невозможно поставить на конвейер, и большая часть разработки программного обеспечения - это исследования.
Что касается языка, ваши разработчики должны быть в курсе последних вопросов безопасности, их установки должны постоянно обновляться ИТ-персоналом, компания должна финансировать некоторое количество учебных материалов, будь то курсы, книги, конференции или что там у вас.
В общем, общая концепция заключается в том, что качество - это дело каждого, и хорошо, что вы нашли время, чтобы сделать это правильно.
Я лично считаю, что хорошие практики развития выходят за рамки языка. Ваши требования для проектов PHP должны быть такими же, как и для Java. Например, код должен быть четким и прокомментированным, хорошо отформатированным и протестированным, как и для любого другого языка.
Я думаю, что один из самых важных первых шагов - установить стандарты. Установить обязательный стиль кодирования (без однострочных операторов if / for / while / etc., Табуляции вместо пробелов, документации по каждой функции и т. Д.); наличие минимального требования к чистоте кода очень важно для поддержания высокого уровня контроля качества.
Хороший следующий шаг - выяснить, где ваши сотрудники компетентны, а где нет. Выясните, с какими частями языка у ваших сотрудников возникают проблемы (например, новые функции PHP 5, эффективное использование DOMDocument, написание безопасных классов...) и назначьте обязательное чтение.
Это подводит меня к следующему предложению: иметь "библиотеку компании". Для мест, где я работал, это была книжная полка, из которой сотрудники могут брать книги для справок или для обучения. Храните его с различными книгами разных издателей. Из того, что я видел, сотрудники более чем готовы изучать что-то новое, если это им не навязано, и они могут делать это на досуге. Хороший программист всегда стремится учиться.
Наконец, запустите блог / список рассылки / форум, в котором сотрудникам предлагается регулярно участвовать. Публикуйте лакомые кусочки (и поощряйте своих сотрудников также публиковать) о лучших практиках Вы можете написать о том, как с помощью gettype с оператором switch это плохо или как правильно отключить магические кавычки программно.
Удачи!
Очевидными методами были бы регулярные обзоры кода и парное программирование; последнее особенно важно, если вы можете использовать его в качестве инструмента для внедрения передового опыта новым сотрудникам. Убедитесь, что разработчики, которые ближе к вашему идеалу написания хорошего кода, могут потратить достаточно времени на обучение других разработчиков.
Все это, к сожалению, совершенно бессмысленно, если вы нанимаете людей, которые решили, что они уже знают все, что им нужно знать; убедитесь, что вы нанимаете кандидатов, которые хотят стать лучшими программистами и готовы работать над этим.
У всех приведенных выше ответов есть хорошие моменты для прослушивания. Надеюсь, это будет просто в дополнение.
Суть в том, что это требует практики. Определенно не берите людей, которые думают, что они совершенны или не нуждаются в особом росте. Я думаю, что я довольно хороший программист, но я вижу много, много возможностей для роста.
Положитесь на мудрость и опыт других программистов. Дайте им несколько хороших материалов для чтения с выделенными разделами о том, как они влияют на вашу организацию или влияют на нее.
Намного легче "ХОЧУ" стать лучше, если известна важность улучшения. Присутствует поддержка совершать ошибки и расти, и цели ясны и достижимы.