Как убедить вашего коллегу-разработчика написать короткие методы? - PullRequest
33 голосов
/ 19 мая 2009

Длинные методы злы на нескольких основаниях:

  • Их трудно понять
  • Их трудно изменить
  • Их трудно использовать повторно
  • Их сложно проверить
  • У них низкая когезия
  • Они могут иметь высокую связь
  • Они имеют тенденцию быть слишком сложными

Как убедить вашего коллегу-разработчика написать короткие методы? (оружие запрещено =)

вопрос от agiledeveloper

Ответы [ 22 ]

3 голосов
/ 19 мая 2009

Заставьте его прочитать «Код завершён» Стива Макконнелла. Скажите, что каждый хороший разработчик должен прочитать это.

2 голосов
/ 19 мая 2009

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

Вопрос, который я всегда задаю своей команде: «Сейчас 11 часов вечера, и вы должны прочитать этот код - можете ли вы? Вы понимаете, что под давлением? они могут исправить ошибку? Если ответ «нет», последующее наблюдение - «Можете ли вы выделить некоторые сложности?»

Если вы получите взамен аргумент, это безнадежное дело. Брось что-нибудь потом.

2 голосов
/ 19 мая 2009

Заставьте их прочитать книгу «Чистый код», есть много других, но этот новый, хороший и легко читаемый.

2 голосов
/ 19 мая 2009

напоить его? : -)

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

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

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

2 голосов
/ 19 мая 2009

Я бы дал им 100 строк кода под одним методом, а затем еще 100 строк кода, разделенных между несколькими методами, и попросил бы их написать объяснение того, что делает каждый.

Время, необходимое для написания обоих абзацев, а затем показа им результат.

... Удостоверьтесь, что вы выбрали код, который займет в два или три раза больше времени, чтобы понять, если бы все было под одним методом - Main () -

Нет ничего лучше, чем учиться на собственном примере.

2 голосов
/ 19 мая 2009

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

1 голос
/ 19 мая 2009

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

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

пс. Кроме того, это упражнение можно использовать в качестве мини-передачи знаний по старым проектам.

1 голос
/ 19 мая 2009
  • Покажите ему, насколько проще тестировать короткие методы. Докажите, что написание коротких методов облегчит и ускорит его написание тестов для его методов (он тестирует эти методы, верно?)

  • Воспользуйтесь этим, когда вы просматриваете его код. «Этот метод довольно длинный, сложный и, кажется, выполняет четыре разные вещи. Извлечь метод здесь , здесь и здесь

0 голосов
/ 14 октября 2009

Нет смысла учить свинью петь. Это тратит впустую ваше время и раздражает свинью.

Просто затмить кого-то.

Когда придет время исправить ошибку в подпрограмме из 5000 строк, у вас будет подпрограмма из десяти строк и подпрограмма из 4990 строк. Делайте это медленно, и никто не замечает внезапного изменения, за исключением того, что все начинает работать лучше и медленно испаряется большой ком грязи.

0 голосов
/ 20 мая 2009

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

Делайте это только если у него нет комплекса превосходства

[править] почему это сбор отрицательных баллов?

...