Как убедить Вашего поддерживающего разработчика писать сокращенные методы?

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

Это по крайней мере некоторая теория.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не уверен, откуда взялась эта замечательная цитата, но:

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

Проверка кода!

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

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

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

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

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

Я откуда-то читал эту цитату:

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

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

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

Это зависит от ваших определений «коротких» и «длинных».

Когда я слышу, как кто-то говорит «напишите короткие методы», я немедленно реагирую плохо, потому что я наткнулся на слишком много спагетти. написано людьми, которые считают, что идеальный метод состоит из двух строк: одна строка для выполнения минимально возможной единицы работы, за которой следует одна строка для вызова другого метода. (Вы говорите, что длинные методы - зло, потому что «их трудно понять»? Попробуйте войти в проект, где каждое тривиальное действие генерирует стек вызовов глубиной в 50 методов, и попытайтесь выяснить, какой из этих 50 слоев тот, который вам нужно изменить. ...)

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

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

Чтобы расширить ответ rvanider, выполнение цикломатического анализа сложности кода сделало чудеса, чтобы привлечь внимание к большим метод выпуска; Когда я ушел, работа по принуждению людей к изменениям все еще продолжалась (слишком большое стремление к большим методам).

Переломный момент наступил, когда мы начали связывать цикломатическую сложность с базой данных ошибок. CC из более чем 20, не являющийся заводом, гарантированно содержал несколько записей в базе данных ошибок, и часто эти ошибки имели «родословную» (исправление ошибки A вызвало ошибку B; исправление ошибки B вызвало ошибку C и т. Д.). На самом деле у нас было три CC более 100 (максимум 275), и на эти методы приходилось 40% случаев в нашей базе данных ошибок - «вы знаете, может быть, эта функция 5000 строк не является»

Это было более очевидно в проекте, который я вел, когда начинал там. Цель заключалась в том, чтобы поддерживать CC на максимально низком уровне (97% были меньше 10), и конечным результатом был продукт, который я практически прекратил поддерживать, потому что 20 ошибок, которые у меня были, не стоили исправлять.

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

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

Это было более очевидно в проекте, который я вел, когда начинал там. Цель заключалась в том, чтобы поддерживать CC на максимально низком уровне (97% были меньше 10), и конечным результатом был продукт, который я практически прекратил поддерживать, потому что 20 ошибок, которые у меня были, не стоили исправлять.

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

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

Цель заключалась в том, чтобы поддерживать CC на максимально низком уровне (97% были меньше 10), и конечным результатом был продукт, который я практически прекратил поддерживать, потому что 20 ошибок, которые у меня были, не стоили исправлять.

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

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

Цель заключалась в том, чтобы поддерживать CC на максимально низком уровне (97% были меньше 10), и конечным результатом был продукт, который я практически прекратил поддерживать, потому что 20 ошибок, которые у меня были, не стоили исправлять.

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

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

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

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

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

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

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

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

Попросите его написать модульные тесты для методов.

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

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

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

Просто затмите кого-нибудь.

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