Как мне убедить мою команду использовать меньшие классы / методы?

Отказ от ответственности: я новичок (это мой третий день работы), и большинство моих товарищей по команде более опытны, чем я.

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

• Несколько непоследовательные правила именования
• Свойства не помечены как доступные только для чтения, когда это возможно
• Большие классы - я заметил вспомогательный класс, состоящий из сотен методов расширения (для многих типов). Это было более 2500 строк!
• Большие методы - я пытаюсь изменить метод длиной 150 строк.

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

Моя команда получила наставника из основной команды (мы сателлитная команда). Должен ли я пойти к нему первым?

ОБНОВЛЕНИЕ : Поскольку некоторые ответы на вопросы о проекте, пожалуйста, знайте, что это рабочий проект. И ИМХО, огромные классы / методы такого размера всегда плохи.

В любом случае, я никогда не хочу разозлить мою команду. Вот почему я спросил: «Должен ли я сделать это, и если да, то как мне сделать это мягко?

ОБНОВЛЕНИЕ : Я решил сделать что-то на основе принятого ответа: потому что я новичок, поэтому я вижу все "свежим взглядом", я приму к сведению все запахи кода, которые я нашел (позиция, почему это плохо, как мы можем это сделать лучше, ...), но в данный момент я просто стараюсь завоевать уважение у моей команды: написать "лучший код", узнать людей, знать, почему мы это сделали ... Когда придет время, я постараюсь спросить мою команду о некоторых новых политиках кода (правила именования, меньшие классы, меньшие методы, ...) и, если возможно, реорганизовать старый код. Должно работать, ИМХО.

Спасибо.

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

Code Complete, Стив Макконнелл, имеет массу хорошей статистики по той теме, о которой вы говорите. Я не помню все цифры, но он говорит о том, как увеличивается количество ошибок с более длинными методами / классами, сколько времени занимает отладка и т. Д.

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

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

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

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

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

Как дела? «Измерить дважды, разрезать один раз».

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

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

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

Удачи.

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

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

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

И да, во что бы то ни стало показать материал из Code Complete для всех.

Вот пара трюков:

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

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

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

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

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

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

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

Как мне убедить мою команду использовать меньшие классы / методы?

Не.

Купите себе лицензию Resharper и приведите пример. [Сильно опираться на рефакторинг « Метод извлечения ».]

Со временем другие должны оценить ваш более читабельный код и убедить себя сделать то же самое. *

• Да - есть шанс, что их не убедят; но это все равно ваш лучший выбор.

IMO - не стоит пытаться убедить своих товарищей по команде стать лучшими программистами, прочитайте « Code Complete » и следуйте @Uncle Bob. Твердые принципы, и стать лучшими программистами, если они еще не убеждены.

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

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

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

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

Visual Studio имеет «Анализ кода», который может помочь с соглашениями об именах.

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

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

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

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

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

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

Так что, если это работает, сколько бы вы ни ненавидели это, вам, возможно, придется оставить это в покое.

Теперь новый код, это другое. Это должен быть хороший код.

Методы, которые 150 строк ... Я видел методы с 10.000 строк кода.

Две ваши проблемы могут быть решены с помощью внешних инструментов :

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

В C # Resharper можно проверить обе проблемы. Имена, которые не соответствуют вашим правилам, помечаются как ошибки. Свойства, не помеченные как доступные только для чтения, также отображаются как ошибки. FxCop также может помочь.

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

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

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

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

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

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