YAGNI и младшие разработчики

Question

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

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

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

Кто-нибудь из вас сталкивался с подобными проблемами? Как ты это решил?

Answer 1

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

Answer 2

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

Обзоры кода и парное программирование - прекрасные идеи. Они особенно хороши, потому что они не "только для младших людей" - я делаю оба с одним из моих близких коллег; нам вместе почти 100 лет, и у нас более 70 лет опыта программирования: -)

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

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

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

• Чтобы показать, что это вкусно, вам может потребоваться съесть собачью еду самостоятельно. Выберите что-то, с чем вы можете жить и быть продуктивным.

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

Удачи!

Answer 3

Есть причина, по которой они младше, а вы старше.

Одна из них - способность понять, когда необходимо изменить дизайн.

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

Answer 4

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

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

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

Answer 5

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

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

Тогда рефакторинг. Знание того, что нужно искать при рефакторинге, требует немного практики. Начните с

• Есть ли дублирование в только что написанном коде, который мы можем устранить?
• Есть ли дублирование между только что написанным и ранее существовавшим кодом?
• Касается ли только что написанный нами код слишком многих вещей? (То есть, мы должны вывести коллаборационистов?)

Повторите это несколько десятков раз, и вам станет легче.

Answer 6

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

Answer 7

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

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