Как сделать лучшие практики разработки программного обеспечения более интересными для людей без опыта работы в области программного обеспечения?

Как сделать лучшие практики разработки программного обеспечения более интересными для людей без опыта работы в области программного обеспечения?
Как сделать лучшие практики разработки программного обеспечения более интересными для людей без опыта работы в области программного обеспечения? - edouarddognin @ Unsplash

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

Какие темы, по вашему мнению, мы должны обсудить, чтобы помочь этим людям стать более эффективными разработчиками программного обеспечения?

В частности, нам трудно добиться энтузиазма в этих беседах, поскольку многие разработчики не считают программное обеспечение интересным предметом. Как мы можем сделать их более интересными для людей, не имеющих опыта работы с ПО?

Спасибо

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

Прежде всего, сделайте беседы и семинары веселыми сами по себе – бесплатная еда (убедитесь, что это вкусная еда!) и подобные угощения – хорошее начало. Постарайтесь также добавить немного юмора и, по крайней мере, поначалу, делайте их довольно краткими и настолько неформальными, насколько это возможно.

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

Наконец, попробуйте ввести некоторые базовые стандарты кодирования, желательно такие, которые не слишком навязчивы в том, как они работают в настоящее время. Если вы находитесь в мире .net, лучше всего начать с Resharper, поскольку он предупредит о таких вещах, как соглашения об именах. Вы можете пойти дальше с помощью StyleCop (который можно интегрировать в Resharper), но сначала убедитесь, что вы настроили набор правил. Если вы не в .net, я уверен, что подобные инструменты будут существовать где-то еще. Это немного, но это начало.

Не ожидайте мгновенных результатов (за исключением, возможно, каких-либо автоматически применяемых стандартов кодирования) - я слышал, что 6, 9 и 12 месяцев используются для внедрения лучших практик.

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


LetsCodeIt, 24 мая 2023 г., 06:04