Як "нейтралізувати" тих, хто пише в команді поганий код?


9

Мені завжди подобалася ця стаття про JoelOnSoftware під назвою "Здійснення речей, коли ти лише грубий". Я особливо міг сказати, коли я був новачком (і все ще відчуваю, що я ВЖЕ завжди буду одним).

Про №4, що нейтралізує бозо. Які поради ви маєте насправді реалізувати це в реальних ситуаціях на роботі? Це здається не таким простим (принаймні для нашої команди), як просто зафіксувати помилку проти чийогось поганого коду. Що працює для всіх вас там?


1
Гармати. Багато їх.
CodesInChaos

Відповіді:


9

Постійна оцінка.

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

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

Навіть якщо це зробить їх менш продуктивними, все одно буде набагато краще, якщо вони виробили якийсь хороший код проти вдвічі більших розмірів, але незрозумілого розмаху помилок.


2
Чудова відповідь. Якщо я можу просто додати це, якщо ця людина є однолітком, то це найкраще робити керівник команди. Таким чином, його відповідь "непогано робити" зробить набагато ефективнішою, якби це наказало ієрархією магазину.

1
@Surfer, якраз навпаки. Ви стаєте лідером команди, роблячи подібні дії, пропонуючи кращі рішення, дбаючи про те, що робить команда. Не навпаки. (Але, звичайно, допомагає отримання допомоги від вищих рівнів ієрархії).
П Швед

1
Тож виникає питання, хто має повноваження змусити їх переписати це? Я думаю, відповідь - моральний авторитет усього колективу, якщо проблеми транслюються на весь колектив.
C Johnson

За відсутності надійного механізму перегляду коду для кожного члена команди це доцільно. Доречно також переконатися, що бозо не викопає по-справжньому глибоку яму (навіть не варто витрат на фіксацію), перш ніж запропонувати переробити її.
mattnz

5

Якщо людина просто не знає нічого кращого, але хоче навчитися, запропонуйте деякий менторство та перегляд коду. Переконайтеся, що вони піддаються хорошому коду.

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


1
Ставлення дійсно має значення. Зазвичай я вважаю новичка більш скромним і відкритим для коду відгуків та критики. З цими людьми легко розмовляти. І ви можете легко поговорити з ними про їх слабкість. Це зарозумілі ветерани, які розгромуться, як мільйон склянок, коли їх критикують за роботу.
C Johnson
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.