Ответ на это прост.
Последовательность имеет первостепенное значение.
но это идет с оговоркой ...
Вы и ваш коллега, вероятно, зациклены на неправильной последовательности
Реализации одноразовые. Они могут быть полностью пересмотрены с различной степенью легкости в зависимости от качества и полноты набора тестов. Беспокоясь о таких вещах, как «Должно ли это быть свойство?», «Разве тонкий код не должен использовать LINQ вместо конструкции более низкого уровня?» имеет сомнительную ценность Его сложно привязать к каким-либо измерениям к значению согласованности на уровне реализации. Гораздо лучше задать вопрос на этом уровне: «Работает ли этот код так, как рекламируется?». TL; Последовательность реализации DR - это то место, где «маленькие умы» надевают хобгоблинов.
Почему последовательность не так важна здесь? Реализации обычно имеют небольшое количество участников. Большинство методов написаны и никогда больше не затрагиваются. Из оставшегося кода количество методов, которые имеют два участника, почти наверняка составляет большинство. Эта модель продолжается до бесконечности . В этом контексте последовательность не так важна. Если срок годности кода довольно мал ( несколько лет ), выигрыш от агрессивной согласованности, вероятно, не является фактором.
Это не значит, что вы должны сходить с ума в своих реализациях. Скорее стоит сказать, что хороший, чистый, простой дизайн будет на порядок ценнее для вашего гипотетического будущего сопровождающего, чем для метода глупой консистенции котельной пластины. Это подводит нас к реальной точке ...
API не являются одноразовыми.
Это все уровень кода API, веб-сервисы, SDK и т. Д. Они должны, ДОЛЖНЫ, быть согласованными. Повышение производительности от такого разнообразия согласованности огромно по ряду причин:
Интеграционные тесты:
Если вы поддерживаете свой API, вы можете создавать наборы интеграционных тестов. Это позволяет разработчикам свободно обмениваться деталями реализации и добиваться немедленной проверки. Хотите поменять вашу совместную работу на LINQ? Проводятся ли интеграционные тесты? Он также обеспечивает проверку при подготовке к производству. Поскольку компьютеры работают быстро, один ноутбук может выполнить работу тысячи тестеров, выполняющих повседневные задачи. Это равносильно значительному увеличению численности персонала вашей организации.
производительность
Когда API согласованы, вы можете догадаться, как использовать API, просто следуя тому, что вы узнали об использовании других частей API. Это потому, что API обеспечивает естественный, последовательный «внешний вид». Это означает, что ваш клиент тратит меньше времени на просмотр документации. Посадка проще и дешевле. Меньше вопросов задают людям, которые разработали API. Последовательность делает каждого победителем
Почему последовательность важна в этом сценарии? Потому что API имеют прямо противоположную проблему реализаций. Количество людей, использующих их, обычно намного больше, чем количество людей, участвующих в их реализации. Небольшие выгоды от небольшой последовательности умножаются, а затраты на поддержание этой последовательности амортизируются.
Заключение
Консистенция дорогая. На первый взгляд это снижает производительность. Это ограничивает разработчиков и делает их жизнь сложнее. Это накладывает ограничения на способы решения проблемы, иногда вынуждая их решать ее неоптимальным образом. Это часто происходит по причинам, которые они не понимают, плохо понимают или не имеют к ним отношения (контракты, более широкие организационные или межорганизационные политики).
Рэймонд Хеттингер (Raymond Hettinger) в своем выступлении на Pycon 2015 отметил несколько отличных моментов, касающихся использования руководства по стилю PEP8 для команд программистов на python. Он показал, что одержимость стилистической последовательностью фрагмента кода заставила рецензентов пропустить серьезные недостатки логики и дизайна. Его гипотезу можно резюмировать так, как легко найти стилистические несоответствия; определить реальное качество фрагмента кода сложно
Дело здесь быть критическим. Определите, где важна последовательность, и защищайте ее агрессивно. Где это не важно, не тратьте свое время. Если вы не можете предоставить объективный способ измерения ценности согласованности (в приведенных выше случаях «эффективная численность персонала», затраты как функция производительности) и не можете доказать, что отдача является существенной, то вы, вероятно, оказываете медвежью услугу ваша организация.