Консолидация стилей кодирования: функции, закрытый метод, классы с одним методом

Question

В настоящее время у нас есть 3 разработчика с несколькими противоречивыми стилями, и я ищу способ принести мир в королевство ...

Кодеры:

Foo 1 : Любит использовать Func's & Action внутри public-методов. Он использует действия для псевдонимов длинных вызовов методов и Func для выполнения простых задач, которые могут быть выражены в 1 или 2 строках и будут часто использоваться в коде

Плюсы: Основная часть его кода лаконична и очень удобочитаема, часто с одним или двумя открытыми методами на класс и редко с любыми закрытыми методами.

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

---

Foo 2: Любит создавать приватный метод для (почти) всего, что должен делать публичный метод.

Плюсы : Открытые методы остаются маленькими и удобочитаемыми (для всех разработчиков).

Минусы : частных методов множество. С частными методами, которые вызывают в другие частные методы, которые вызывают в ... и т. Д., И т. Д. Сложность навигации по коду.

---

Foo 3: Любит создавать открытый класс с единственным открытым методом для каждой нетривиальной задачи, которую необходимо выполнить, а затем вводить их в зависимости от других объектов.

Плюсы : Легко тестируемый, простой для понимания (один объект, одна ответственность).

Минусы : проект напичкан классами, открывая несколько файлов классов, чтобы понять, что делает код, делая навигацию неудобной.

---

Было бы здорово использовать все эти техники ...

Foo-1 Имеет действительно хороший, читаемый (почти dsl-подобный) код ... по большей части, за исключением всех лямбда-махинаций Action и Func, объединенных в начале метода.

Foo-3 Имеет хорошо тестируемый и расширяемый код, который для некоторых решений кажется просто «поясом и скобками», а также имеет некоторые недостатки навигации по коду (постоянно нажимая F12 в VS и открывая 5 других файлов .cs, чтобы узнать что делает один метод).

И Foo-2 ... Ну, я не уверен, что мне что-то нравится в одном огромном файле .cs с 2 открытыми методами и 12 закрытыми, за исключением того факта, что юниорам легче копаться.

Признаюсь, я сильно упрощал объяснения этих стилей кодирования; но если кто-то знает какие-либо закономерности, практики или дипломатические маневры, которые могут помочь объединить наших трех разработчиков (не просто сказав никому из них просто «остановить это!»), это было бы здорово.

С точки зрения осуществимости:

• Стиль Foo-1 встречает наибольшее сопротивление из-за того, что некоторые разработчики считают, что лямбда и / или Func плохо читаются.
• Стиль Foo-2 встречается с меньшим сопротивлением, так как в него так легко попасть.
• Стиль Foo-3 требует самого дальновидного мышления, и его трудно реализовать, когда времени мало.

Есть какие-нибудь идеи по поводу некоторых стилей или соглашений кодирования, которые могут сделать эту работу?

Answer 1

Не совсем понятно, почему вам не нравятся приватные методы для Foo-2.

Вы жалуетесь на "огромный" файл .cs - но почему он будет значительно больше, чем стиль Foo-1? Там такое же количество кода, просто действия разбиты на методы, а не выражены как лямбды.

Foo-2 кажется лучшим вариантом для меня, если честно. Держите ваш публичный API только на том, что вы хотите раскрыть, а затем реализуйте его самым простым способом. Хотя лямбды определенно подходят в некоторых ситуациях, стиль Foo-1 звучит так, будто доводит его до крайности - за пределы, где это действительно разумно.

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

Аналогично, вы говорите о частных методах, вызывающих частные методы ... несомненно, эквивалентным кодом Foo-1 будут лямбда-выражения, вызывающие лямбда-выражения, что вряд ли лучше!

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

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

Answer 2

Для моих 2 центов у них всех есть свое место, но ни один стиль не должен использоваться исключительно, особенно 1 и 3. Стиль 1 имеет код, который трудно понять, а стиль 3 приводит к объектной модели, которую трудно работатьout.

Соберитесь и попытайтесь решить это.Это на удивление сложно сделать, и зачастую это скорее компромисс, чтобы получить последовательность, чем делать то, что «правильно».Компромиссеры здесь - незамеченные герои.:)

Foo 1

Я должен признать, что иногда мне нравится использовать лямбда-выражения и функции для программирования в стиле "совместной процедуры".Тем не менее, это редко и используется только тогда, когда альтернативы не были бы такими аккуратными, или выражать намерение дизайна так четко.по крайней мере, в C #), так как многим другим программистам приходится играть компилятором, чтобы понять, что происходит, - не очень хорошо.Однако это, безусловно, имеет свое место.

Foo 2

Это звучит как разумный стиль кодирования.Тот факт, что между частными методами существуют зависимости, является просто СУХОЙ работой в малом масштабе (если она выполняется хорошо).

Foo 3

Использование DI не требуетиспользуя этот стиль, т.е. один публичный метод на класс.Этот стиль в худшем случае является симптомом забывания о том, что в ОО мы на самом деле пытаемся моделировать «вещи».Склеивание огромного количества методов без заметной объектной модели не очень хорошо, обнаруживаемость - отстой.Однако создание хороших объектных моделей сложно .

Answer 3

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

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

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

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

Самое главное: постарайтесь, чтобы все слушали (в том числе и вы).

Answer 4

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

Answer 5

Для разработчиков очень сложно следовать строгим правилам, особенно когда появляются новые языковые функции, особенно разработчик Foo-1 хочет использовать лямбду.

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

Как и в вашей команде, основным языком разработки является C #, который в основном является объектно-ориентированным, поэтому вы должны попытаться привнести более объектно-ориентированный подход к разработке и убедитьих использовать классы / объекты для повторного использования кода.Одним из приемов является то, что экспертная проверка также может помочь членам вашей команды, она не требуется для каждой строки кода, но может помочь пара начальных сессий, и вам следует сначала проконтролировать / запустить эти обзоры, а затем дать им это сделать.