В конце моей веревки [закрыто]

Я являюсь подрядчиком крупной компании. В настоящее время в проекте участвуют три разработчика, в том числе и я.

Проблема в том, что другие 2 разработчика не понимают этого. Под «этим» я подразумеваю следующее:

• Они не понимают лучшие практики для технологий, которые мы используем. После 6 месяцев, когда я и другие приводили им примеры, используются ужасные анти-паттерны.
• Это программисты «копируй и вставляй», которые производят в основном спагетти-код.
• Они постоянно ломают вещи, внедряют изменения, но не проводят базового теста на дым, чтобы увидеть, все ли хорошо
• Они отказываются / редко просят о пересмотре кода.
• Они отказываются / редко даже делают простые вещи, такие как форматирование кода.
• Нет документации по любым классам (jsdocs)
• Боюсь удалить код, который ничего не делает
• Оставляйте комментированные блоки кода везде, хотя у нас есть контроль версий.

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

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

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

Есть ли тонкий / не очень тонкий способ объяснить, сколько вещей я чиню?

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

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

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

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

Безусловно, наступит момент, когда они либо сдаются и делают правильные вещи, либо руководство получает сообщение и удаляет их из проекта.

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

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

В моей компании и Agile, и TDD были навязаны нам руководством, и сначала мы просто делали это, потому что нам сказали (что противоположно agile). Мы пробовали TDD дважды, и, хотя я большой сторонник использования автоматических тестов, я лично выбросил все те, которые команда собрала вместе в последнем выпуске. Они были хрупкими, гигантскими, копировали / вставляли wazoo и пронизаны заявлениями о сне, которые заставляли их бежать очень медленно и непредсказуемо. Мой совет для вашей команды: НЕ ДЕЛАЙТЕ TDD ... пока.

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

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

Итак, если у вас есть уважение и внимание вашей команды. Что теперь?

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

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

1. Как только у вас есть поддержка со стороны руководства. Вы можете начать вводить множество централизованно продиктованных методов / процессов, которые MainMa предложила в ответ на мой вопрос . Мы сделали много из них (кроме парного программирования), и вы определенно видите преимущества. Обзоры кода особенно помогли стандартизировать стилизацию, документацию, а также позволили нам поделиться знаниями / методами среди команды. Несмотря на то, что проверки кода были продиктованы, команда на самом деле любит их, и мы проверяем каждую функциональность, которая отмечена. Однако ...
2. Вы замечаете, что код, который обычно написан, все еще слишком связан, дизайн плох или полностью отсутствует. Обзоры кода отлавливают некоторые из них, но вы можете переписать только так много. Почему дизайн плох в первую очередь? - Многие разработчики никогда не знакомились с передовой практикой и никогда не обучались формально OOD. Многие люди просто «закодировали» любую задачу, которую им дали.
3. При поддержке руководства вы можете внедрить больше процессов, таких как обсуждение дизайна до того, как произойдет кодирование. Но вы всего лишь один человек, и кажется, что, как только вы не обращаете внимания, команда возвращается к тому, что они всегда делали. Почему?
4. Можно ли внедрять и преподавать лучшие практики или привычки, чтобы вам не приходилось постоянно следить? - Оказывается, эта часть не так просто.
5. Почему другие члены команды неохотно изучают и выбирают новые методы и почему они так устойчивы к SOLID или DRY, когда об этом так много написано в современной литературе по методологии программного обеспечения? Со всеми положительными изменениями, которые произошли в моей команде, 2 недели назад у меня был спор о том, что я реорганизовал 2 функции с одинаковыми 15 строками кода, и рецензент назвал это героическим, ненужным усилием, потому что нет ничего плохого в копировании / вставке только 15 строк. Я категорически не согласен с такими взглядами, но сейчас мы решили согласиться не соглашаться. -- Ну что теперь? Теперь мы подошли к теме моего другого поста .
6. Как указали maple_shaft и nikie в своих ответах (извините, MainMa , вы набрали наибольшее количество голосов, но отстали на 5 шагов :)), вы достигли стадии, когда «процесс» больше не может вам помочь, и никто на этом форуме могу сказать вам, что такое "исправить". Следующий шаг - обратиться к людям, может быть, один на один, может быть, как команда, возможно, одновременно или в другое время, и поговорить с ними. Спросите их, что работает, а что нет. Единственный способ определить первопричину того, что движет ими, - это поговорить с ними индивидуально и выяснить это. В рамках этого шага я недавно столкнулся с совершенно другой командной проблемой, но я думаю, что ответ Джоэля здесь, что очень подробно и проницательно, применимо и к этому делу. Таким образом, хотя использование менеджмента в качестве «короткого поводка» является возможным подходом практически ко всему, нам нужно помнить, что мы имеем дело с людьми, поэтому, чтобы по-настоящему понять мотивацию, нам нужно больше переходить к психоанализу, чем к чистому управлению или техническому лидерству.
7. Итак, теперь вы говорите со своими товарищами по команде? Что вы у них спрашиваете? Я не уверен в этой следующей части, потому что я никогда не был здесь. Вот возможный сценарий: В: Как получилось, не ТВЕРДЫЙ? A: Мне это не нужно. Q: Это может помочь. A: У меня все хорошо, как есть. - каким-то образом вам нужно сгенерировать серию звуков, которые покинут ваш рот и заставят слушателя признать, что все может быть лучше, если они дадут вам то, что вы торгуете. Если вы потерпите неудачу здесь, они никогда не будут убеждены, что какой бы «процесс» их ни делал, на самом деле имеет какую-то ценность. С другой стороны, если вы пройдете этот этап, вы, вероятно, обнаружите, что вам больше не нужен «процесс».
8. ИМО в самом корне, ваши товарищи по команде не узнают, если они не видят ничего плохого в своих нынешних привычках / практиках. Поэтому, возможно, следующий шаг во всем этом - найти способ проиллюстрировать, выделить проблемы и сделать их очевидными. В конце концов, мы не пишем читаемый код, не используем принципы SOLID / DRY и не ведем документацию только потому, что это дает нам ощущение тепла и нечеткости. Мы делаем это потому, что он производит код лучшего качества и, откровенно говоря, делает его быстрее. Это можно измерить? Может быть, это где метрики программного обеспечения приходят?
9. Вот сумасшедшая идея, и я понятия не имею, сработает ли это на самом деле (это может быть стандартная отраслевая практика, или это может быть совершенно недопустимым. Я только придумал это за последние 24 часа), но я очень соблазнен, чтобы принести это к столу, как только начинается следующий год:
   • Вопреки мнению многих других , представьте идею Автор / Владелец для всех исходных файлов. Как предполагает прагматичный программист, это даст чувство ответственности и ответственности одному человеку, который будет нести ответственность за кусок исходного кода. Это не означает, что другие люди не могут изменять код, мы все работаем как команда, но в конце концов, человек, которому принадлежит код, отвечает за проверку изменений.
   • Создайте триггер исходного репозитория, который отслеживает все проверки и специально ищет те, которые являются исправлениями ошибок. Сделайте так, чтобы каждое исправление ошибки имело ссылочный идентификатор прямо в описании регистрации. Теперь напишите сценарий, который будет анализировать список файлов, которые были изменены, и убрать «Автор» из блока комментариев заголовка файла. Создайте базу данных SQL, которая будет отслеживать количество дефектов, зарегистрированных в каждом файле / проекте / автора.
   • Как только у вас будет достаточно статистики, надеюсь, вы заметите, что в вашем коде меньше дефектов / изменений, чем в другом коде. Это жесткие данные, которые вы можете использовать. Если в одном проекте уровень брака значительно выше среднего, выдвиньте его в качестве кандидата для следующей попытки очистки / рефакторинга для погашения некоторого технического долга.
   • Если у проекта или файла уровень дефектов значительно выше среднего, и у него один владелец, поговорите один на один с этим человеком. Спросите их, очень вежливо, без конфронтации, что они могут сделать, чтобы решить эту проблему. Так как они являются владельцами, они должны управлять изменениями, но предложить любую помощь с вашей стороны. Надеемся, что владелец проследит множество причин в своем собственном коде спагетти, и как только они попросят помощи, вот когда вы начнете действовать и положите немного твердого.

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

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

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