Как преобразовать копир / вставить / спагетти программист, чтобы увидеть свет?

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

Допустим, в вашей команде есть кто-то (или, может быть, большинство), чья стандартная рабочая процедура заключается в копировании / вставке и которая считает, что все можно решить, если только вы добавите достаточно вызовов функций и переменных. Этот человек никогда не слышал о TDD, DRY или SOLID, и за пределами 40 часов на работе, когда он занят работой, он ни разу не прочитал ни одной методологии / практики / книги о дизайне.

В прошлом я (и другие) спрашивал, как вы учите OOD . Но сейчас я думаю, что это не правильный вопрос. На самом деле вопрос в том, как вы подходите к такому человеку / команде и хотите узнать, как лучше поступить? Как вы вдохновляете их учиться? Без этого кажется, что все преподавание, встречи, лекции, дискуссии бесполезны, если они совершенно счастливы, возвращаясь к своему столу и делая то, что они всегда делали.

Я работаю с такими людьми. Они на самом деле довольно яркие люди, но я ненавижу, когда слышу: «Я закончил программировать, мне просто нужно провести рефакторинг и разбить его на несколько классов, чтобы сделать ДХМ счастливым». Они не делают рефакторинг для более чистого, читабельного, обслуживаемого кода, но только потому, что иначе их будут ругать. Я знаю, что они способны к обучению, просто кажется, что вообще отсутствует мотивация.

Когда я выполняю работу, в ней обычно гораздо меньше ошибок, и работа, которой я владел, никогда не становилась чудовищем класса из 5000 строк. Другие будут комментировать, например, «ваш код намного чище и удобнее для чтения, чем наши материалы», поэтому они видят разницу. Но в то же время, я чувствую, что они считают, что им платят за 40 часов, независимо от того, что они делают, поэтому они на самом деле не возражают, если они проведут 3 полных дня в QA в поисках ошибки, которая не должна была быть внесена в первое место. Или что они занимают неделю, чтобы изменить один класс, потому что есть так много зависимостей, которые они в конечном итоге касаются. Тем не менее, «возможно, этот класс должен быть написан по-другому», кажется, никогда не всплывает.

Можно ли что-нибудь сделать в этих ситуациях? Кто-нибудь преуспел? Или лучше изолировать такое мышление от некритических частей проекта и минимизировать ущерб?

ПРИМЕЧАНИЕ: когда я говорю «отсутствие мотивации». Я не думаю, что это отсутствие мотивации, чтобы работать или делать хорошую работу, потому что они просто перестали заботиться. Большая часть нашей команды на самом деле совсем наоборот. Они определенно заботятся о продукте. У нас есть ребята, которые будут работать по вечерам и выходным. Часть, которую я пытаюсь пройти, - это улучшение привычек и навыков, им на самом деле не нужно было бы так много работать. Я думаю, что "40 часов" заставили этот пост звучать слишком негативно.

Вы нашли себе причину: «Я знаю, что они способны к обучению, просто кажется, что вообще отсутствует мотивация».

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

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

Что мы можем сделать? Не очень много. Во всех случаях не вам, а человеческим ресурсам выбирать людей, которые действительно мотивированы ». И увольнять людей, которых нет.

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

Вы можете:

• Убедите своего босса установить ряд строгих правил в вашей компании: правила стиля и т. Д. Это не побудит этих людей выполнять работу лучше, но, по крайней мере, они не смогут коммитить исходный код, который не соответствует требованиям ,

• Работа над требованиями, особенно не функциональными требованиями . Как насчет требования, которое говорит о том, что конкретный проект должен содержать менее 5 000 строк кода IL (нет, я не говорю о бессмысленном LOC ) ³? Как насчет необходимости получать конкретные результаты при цикломатической сложности или сопряжении классов ?

• Увеличьте количество часов, которые вы проводите в своей компании, просматривая код . Укажите, что проверяется: если у вас есть контрольный список, добавьте пункты, связанные с рефакторингом, удобочитаемостью, чистыми и полезными комментариями и т. Д. Если у вас нет контрольного списка, вы должны это сделать.

• Используйте [больше] парного программирования . Это может помочь улучшить качество кода и мотивировать менее мотивированных сотрудников.

• Используйте систему компенсации, аналогичную той, которая используется в Fog Creek.

^{¹ Вот о чем идет речь: перед тем, как нанимать вас, человеческие ресурсы должны оценивать не только ваш технический уровень, но и вашу мотивацию . К сожалению, некоторые компании забывают об этой второй части интервью и нанимают людей, которые не слишком любят программирование. К счастью, в большинстве случаев работа в этих компаниях никогда не бывает приятной, и тест Джоэла редко превышает 2.}

^{² Им действительно все равно, даже если они получают меньше денег. Я довольно близок к одному из моих клиентов (я фрилансер), который считает, что его работа заключается в разработке веб-сайтов для своих клиентов. У него также есть дизайнер. Я много раз рассказывал им о том, как они могут повысить свою производительность на 2 и более. Если бы они просто наняли кого-то компетентного, они бы увеличили свой доход как минимум на 3. Но у них достаточно денег, и им нет дела до качества или того, сколько они стоят для невежественных клиентов, по сравнению с кем-то продуктивным.}

^{³ Я имею в виду количество строк кода IL, которые вы видите в метриках кода в Visual Studio , метрика, которая на самом деле что-то значит. Реальный LOC не имеет значения , и вы не должны измерить; это один из самых глупых показателей за всю историю. Применение строк кода IL означает, что разработчики будут вынуждены фактически реорганизовать код, а не просто свести десять строк кода в одну нечитаемую строку.}

«Я закончил программировать, просто нужно провести рефакторинг и разбить его на несколько классов, чтобы сделать ДХМ счастливым».

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

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

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

Вы поддерживаете лучшие практики и стандарты, указывая команде, как они улучшили процесс разработки программного обеспечения или качество программного обеспечения.

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

Они будут владеть этими стандартами и процедурами и будут применять их так, чтобы вам это не требовалось. Как технический руководитель, вы не должны объявлять указы и указы, это плохой способ быть лидером.

Как только команда почувствует, что владеет этими процедурами, члены команды, которые начнут приписывать вам определенные процедуры и лучшие практики, будут недопустимы. Ваша команда поможет исправить это отношение в других.

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

• Они думают, что слишком заняты, чтобы изучать что-то новое, или думают, что новый способ работы (например, написание всех этих тестов) займет у них больше времени, и у них нет на это времени. Тогда очевидный ответ: дать им больше времени. Изучение чего-либо или попытка чего-то подобного TDD, когда вы всегда делаете что-то по-другому , в первые пару раз займет больше времени. Если у ваших программистов нет этого времени, вы не можете винить их за то, что они не пытались.
• Они по-разному воспринимают свои навыки, т. Е. Считают себя очень хорошими программистами, создающими высококачественный код. Это сложный психологический ландшафт, потому что разрушение этой веры может быть очень демотивирующим. Может быть, какая-то неформальная конкуренция может помочь (кто производит наименьшее количество дефектов / функций, самый короткий код, наименьшее количество WTF / минут в обзоре кода?).
• Может быть реальная проблема с мотивацией (то есть они просто хотят «сделать свое время и остаться один» до закрытия). К счастью, это слишком общее / не связанное с программированием, потому что у меня действительно нет ответа на это.
• Они новички, и они не знают лучше. В этом случае может помочь обучение, проверка кода или «книжный клуб», где член команды должен обсуждать новую техническую книгу каждый месяц.
• Они видели серебряные пули раньше (и были горько разочарованы), и они думают, что то, что вы пытаетесь продать им, это просто еще одно модное слово, которое звучит хорошо в теории и мало полезно на практике. В этом случае демонстрация преимуществ во время анализа кода и парных сеансов программирования может работать. Старайтесь не быть всезнайкой, когда будете это делать.

Лучшее решение действительно зависит от основной проблемы: например, формальные руководящие принципы кодирования, метрики и обзоры могут работать для начинающих, но люди, которые «неправильно воспринимают свои собственные навыки» - толпа может бороться с ними или играть метриками, потому что они видят они как контрпродуктивные бюрократические препятствия для выполнения своей работы.

На самом деле вопрос в том, как вы подходите к такому человеку / команде и хотите узнать, как лучше поступить? Как вы вдохновляете их учиться? Без этого кажется, что все преподавание, встречи, лекции, дискуссии бесполезны, если они совершенно счастливы, возвращаясь к своему столу и делая то, что они всегда делали.

Это оно! Это действительно настоящий вопрос.

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

Поэтому вопрос, который я им задаю, не в том, как научить их, а в том, как заставить их учиться? Разница невелика, но именно она и будет иметь значение.

Я не знаю, прав ли я; но часто я верю в диалог Матрицы фильма - «Это вопрос, который движет нами!» Самое главное - заставить их думать, заставить их спросить, почему! И, конечно же, большинство из тех, кто думает, что они уже знают все о некоторых шаблонах проектирования, потому что они получили хорошие оценки на университетских курсах, - являются самыми трудными там.

Как вы задаете им такие вопросы? Мой общий подход - «бросайте их в пруд, если хотите, чтобы они научились плавать» . Я согласен, что люди могут не соглашаться; и я с удовольствием соглашусь не соглашаться с ними. Когда вы бросаете их в пруд - они на самом деле не учатся плавать автоматически; но это вызывает инстинкт самосохранения, который заставляет их думать - как только это произойдет, они естественно будут думать о том, КАК и ПОЧЕМУ.

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

Это может показаться немного экстремистским, это может показаться пустой тратой ресурсов . И я уверен, что есть много других, которые дадут мне совет не делать этого. Но это сработало для меня!

Независимо от того, какие пакеты оплаты и HR-теги вы назначите, они не решат основную проблему мотивации . Ибо единственный путь состоит в том, что им бросают вызов; Если вы зажигаете этот основной человеческий дух - все остальное работает. Если ты не можешь, это свободная свободная игра.

PS: просто случайно я разместил ответ здесь https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - и я получил всю побои; в первую очередь большинство людей считают, что предприятия не могут тратить ресурсы впустую! Я уверен, что этот ответ может получить подобное лечение здесь. Но правда в том, что заставлять людей работать и заставлять их верить в то, что они делают хорошую работу, является предметом человеческой психологии о том, как составить учебную программу курса.

В любом случае, задача, которую вы здесь описываете, сводится к тому, чтобы зажечь внутреннюю страсть к великим переменам. И чем больше система, тем сложнее становится. Начните с младших ребят, которые все еще живут в духе « я не буду делать хорошую работу», и бросьте вызов статус-кво.

Как вы указываете, его мотивация. Не путайте их, не заботясь о них, не зная. Они четко знают, что делать. Им просто все равно . Если это так, то реальный вопрос здесь ... что ваше руководство делает неправильно, что делает их такими немотивированными? Вы самый новый член команды? Возможно, они уже прошли через все это, и это только приводило к проблемам со стороны их руководства. Таким образом, они просто придерживаются самого низкого объема работы, необходимой для сохранения своей работы, потому что они не думают, что на выполнение большего труда ответит работодатель.

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

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

Я думаю, что есть две части этого - образование и методы работы.

• Обучение можно начинать один раз в неделю - все едят вместе, вы проводите 20–30-минутную презентацию с вопросами и ответами. Вы начинаете с основ, которые вы хотите - SOLID может занять первые 2–4 недели - со временем вы заставите команду говорить по очереди, и вы сможете решить, кто решает, о чем говорить между вами. Дайте ораторам некоторое время на подготовку к работе. Кроме того, поощряйте посещение местных групп пользователей (сделав это, по крайней мере, частично социальным, если это возможно)
• Практика работы ... ну, это зависит от того, что вы делаете сейчас и какие инструменты у вас есть, но вы, возможно, захотите взглянуть на согласованные стандарты кодирования, введение рецензирования кода (это верно), модульное тестирование (необязательно сначала тестировать) запуск сервера непрерывной интеграции и поиск более автоматизированного тестирования (в дополнение к модульным тестам). Но они должны быть введены с согласия / соглашения (а не сервера build / CI!), И вы должны стремиться продвигать качество как команда. Всегда есть вещи, которые можно улучшить (Кайдзен)

Также стоит посмотреть на Канбан (который рассматривается как движущая сила перемен / улучшений).

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

Я попал в программирование случайно ~ 30 лет назад. Я был мотивирован, чтобы изучить основные принципы разработки программного обеспечения, будучи назначенным для поддержки / поддержки кода других людей. В этих заданиях я узнал, как читатель кода испытывает код - как сопереживать с читателем кода. Я не хотел причинять боль моего плохо написанного кода другим!

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