Длинные методы злы по нескольким причинам:
Как убедить своего коллеги-разработчика написать короткие методы? (оружие запрещено =)
вопрос от agiledeveloper
Вы сделали список недостатков. Попробуйте составить список того, что вы получите, используя короткие методы. Конкретные примеры. Затем попробуйте снова убедить его.
Попросите его написать модульные тесты для методов.
Это зависит от ваших определений "короткий" и "длинный".
Когда я слышу, что кто-то говорит "пишите короткие методы", я сразу же плохо реагирую, потому что я столкнулся с слишком большим количеством спагетти, написанным людьми, которые думают, что идеальный метод состоит из двух строк: одна строка, чтобы сделать мельчайшую возможную единицу работы одной строкой, чтобы вызвать другой метод. (Вы говорите, что длинные методы являются злыми, потому что "их трудно понять"? Попробуйте войти в проект, где каждое тривиальное действие генерирует сложность стека вызовов 50 методов и пытается выяснить, какой из этих 50 слоев - тот, который вам нужно изменить...)
С другой стороны, если "короткий" означает "автономный и ограниченный одной концептуальной функцией", то я все для этого. Но помните, что это невозможно измерить просто строками кода.
И, как указал тыдок, вы улавливаете больше мух с медом, чем уксусом. Попробуйте сказать им, почему ваш путь хорош, а не почему их путь плох. Если вы можете сделать это без каких-либо явных сравнений или ссылок на них или их практики (если только они не спросят, как ваши идеи будут относиться к чему-то, что они делают), это будет работать еще лучше.
Я прочитал эту цитату где-нибудь:
Напишите свой код, как будто человек, который должен его поддерживать, является жестоким психо, который знает, где вы живете.
По моему опыту, лучший способ убедить сверстника в этих случаях - пример. Просто найдите возможности показать им свой код и обсудите с ними преимущества коротких функций и длинных функций. В конце концов они поймут, что лучше спонтанно, без необходимости заставить их чувствовать себя "плохими" программистами.
Обзор кодов!
Я предлагаю вам попробовать и получить некоторые обзоры кода. Таким образом, вы могли бы провести небольшой семинар по лучшим практикам и любому формату, который придерживается ваша компания. Это добавляет контекст, что короткие методы - это способ сделать код более понятным и понятным, а также совместимым с SRP.
Чтобы расширить ответ на rvanider, выполнение анализа циклической сложности в коде делало чудеса, чтобы привлечь внимание к проблеме большого метода; заставить людей меняться, все еще находилось в работе, когда я уходил (слишком большой импульс к большим методам).
Переломным моментом было то, что мы начали связывать циклическую сложность с базой данных ошибок. У CC более 20, не являющихся factory, было гарантировано наличие нескольких записей в базе данных ошибок, и часто эти ошибки имели "родословную" (исправление ошибки B вызвало ошибку B, исправление ошибки B вызвало ошибку C и т.д.).). На самом деле у нас было три CC более 100 (максимум 275), и эти методы составляли 40% случаев в нашей базе данных ошибок - "вы знаете, может быть, что 5000 функций линии не такая хорошая идея..."
Это было более очевидно в проекте, который я возглавлял, когда я начал там. Цель состояла в том, чтобы сохранить CC как можно ниже (97% были менее 10), и конечный результат был продуктом, который я в основном прекратил поддерживать, потому что 20 ошибок, которые у меня были, не стоили исправления.
Программное обеспечение без ошибок не произойдет из-за коротких методов (и это может быть аргумент, который вам придется решать), но исправления ошибок очень быстрые и часто не имеют побочных эффектов, когда вы работаете с короткими, сжатыми методами.
Хотя письменные модульные тесты, вероятно, излечивают их от длинных методов, ваша компания, вероятно, не использует модульные тесты. Риторика только заходит так далеко и редко работает на разработчиков, которые застряли на их пути; показать им цифры о том, как эти методы создают больше работы и багги программного обеспечения.
Если вы попытались объяснить хороший дизайн, и люди просто не получают его или просто отказываются его получить, то перестаньте пытаться. Это не стоит усилий. Все, что вы получите, это плохая репутация для себя. Некоторые люди просто безнадежны.
В сущности, это то, что некоторые программисты просто не вырезаны для разработки. Они могут понимать код, который уже написан, но они не могут создать его самостоятельно.
Эти люди должны быть ориентированы на роль поддержки, но им не должно быть позволено работать над чем-то новым. Поддержка - это хорошее место, чтобы увидеть много разных кодов, поэтому, возможно, через несколько лет они придут, чтобы увидеть преимущества хорошего дизайна.
Мне нравится идея обзоров кодов, которые кто-то предложил. Эти неряшливые программисты должны не только проверять свой собственный код, но также должны анализировать хороший код. Это даст им возможность увидеть, какой хороший код. Возможно, они никогда не видели хороший код.
Поиск правильной комбинации между длиной функции и простотой может быть сложным. Попробуйте применить метрику, такую как Cyclomatic Complexity, чтобы продемонстрировать сложность в поддержании кода в его нынешнем виде. Ничто не сравнится с неличным измерением, основанным на критериях тестирования, таких как подсчет ветвей и решений.
Заставьте его прочитать "Код завершен" Стив Макконнелл. Скажите, что каждый хороший разработчик должен это прочитать.
Не знаю, откуда эта отличная цитата, но:
"Отладка в два раза сложнее, чем запись кода в первую очередь. Поэтому, если вы пишете код настолько умно, насколько это возможно, вы по определению недостаточно умны, чтобы отлаживать его"
Получить его пьяным?: -)
Серьезным моментом в этом ответе является вопрос: "Почему я постоянно пишу короткие функции и ненавижу себя, когда я этого не делаю?"
Причина в том, что я с трудом понимаю сложный код, будь то длинные функции, вещи, которые поддерживают и управляют многими состояниями или что-то в этом роде. Я заметил много лет назад, что есть довольно много людей, которые значительно лучше справляются с такой сложностью, чем я. Как ни странно, вероятно, из-за этого я склонен быть лучшим программистом, чем многие из них: мои собственные ограничения заставляют меня противостоять и очищать такой код.
Извините, я не могу дать реальный ответ здесь, но, возможно, это может дать некоторое понимание, чтобы помочь нам ответить.
Заставить их читать книгу "Чистый код", есть много других, но это новое, хорошее и легкое чтение.
Просить их написать модульные тесты для сложного кода - это хороший путь. Этот человек должен сам убедиться в том, что этот долг приносит сложность при проведении технического обслуживания или анализа.
Вопрос, который я всегда прошу у моей команды: "Это 11 часов вечера, и вы должны прочитать этот код - не так ли? Вы понимаете под давлением? Можете ли вы, по телефону, удаленной авторизации, привести их в раздел, где они могут исправить ошибку?" Если ответ отрицательный, последующее действие: "Можете ли вы выделить какую-то сложность?"
Если вы получите аргумент взамен, это потерянная причина. Тогда брось что-нибудь.
Я бы дал им 100 строк кода всего по 1 методу, а затем еще 100 строк кода разделили между несколькими методами и попросили их записать объяснение того, что каждый делает.
Время, необходимое для записи обоих абзацев, и затем покажите им результат.
... Убедитесь, что вы выбрали код, который будет занимать в два или три раза больше времени, чтобы понять, были ли все под одним способом - Main() -
Ничто не лучше, чем обучение на примере.
короткие или длинные термины, которые можно интерпретировать по-разному. Для одного короткого является 2-строчный метод, а кто-то еще подумает, что метод с не более чем 100 строками кода довольно короткий. Я думаю, было бы лучше заявить, что единый метод не должен делать больше, чем одно, в то же время, то есть он должен иметь только одну ответственность. Возможно, вы могли бы позволить своим коллегам-разработчикам прочитать что-то о том, как применять принципы SOLID.
Обычно я показываю им старые проекты, у которых есть хорошо написанные методы. Затем я пройду через эти методы, объясняя причины, почему мы так их разработали.
Надеемся, что, посмотрев на большую картину, они поймут причины этого.
пс. Кроме того, это упражнение можно использовать в сочетании как мини-передача знаний по более старым проектам.
Покажите ему, насколько проще тестировать короткие методы. Докажите, что для написания коротких методов будет проще и быстрее писать тесты для его методов (он тестирует эти методы, верно?)
Принесите его, когда вы просматриваете его код. "Этот метод довольно длинный, сложный и, кажется, выполняет четыре разные вещи. Извлеките метод здесь, здесь и здесь."
Длинные методы обычно означают, что объектная модель ошибочна, то есть у одного класса слишком много обязанностей. Скорее всего, вам не нужно просто больше функций, каждый из которых короче, в том же классе, но те ответственные обязанности, назначенные соответствующим классам.
Не нужно учить свинью петь. Он тратит ваше время и раздражает свинью.
Просто заткните кого-нибудь.
Когда пришло время исправить ошибку в строковой процедуре 5000, тогда у вас будет десятилинейная процедура и подпрограмма на 4990 строк. Делайте это медленно, и никто не замечает внезапного изменения, за исключением того, что все начинает работать лучше и медленнее, когда большой шар грязи испаряется.
Вы можете сказать им, что у него может быть действительно хорошая память, но вы этого не сделаете. Некоторые люди могут обрабатывать гораздо более длинные методы, чем другие. Если вы оба должны поддерживать код, это можно сделать, только если методы меньше.
Только делайте это, если у него нет комплекса превосходства
[править] почему это собирает отрицательные оценки?
Вы можете начать рефакторинг каждого метода, который они написали, в несколько методов, даже когда они в настоящее время работают над ними. Назначьте дополнительное время для вашего расписания для "рефакторинга других методов, чтобы сделать основной код". Сделайте это так, как будто вы думаете, что это должно быть сделано, и - вот идет образовательная часть - когда они жалуются, скажите им, что вам не придется реорганизовывать методы, если они сделают это правильно в первый раз. Таким образом, ваш босс узнает, что вам нужно исправить другую ленивость, и ваши коллеги узнают, что они должны сделать это по-другому.
Это, по крайней мере, некоторая теория.