День 1288. #TypesAndLanguages 6. Запрещать или Разрешать при Разработке ПО Дискуссии в области разработки ПО довольно часто касаются личных предпочтений. Несмотря на то, что все участники дебатов спорят, основываясь на своих знаниях, навыках или опыте, их дискуссии довольно часто сводятся к вопросу вкуса и цвета. Одним из примеров является спор «Открытое Наследование или Разрешённое Наследование» Мартина Фаулера. Вопрос в том, должны ли мы по умолчанию разрешать наследование класса или блокировать его. Мы можем привести множество аргументов за и против, но нет единого показателя, показывающего, какой подход лучше. То же самое относится к тому, чтобы сделать методы виртуальными или запечатанными по умолчанию. Или о том, насколько всё делать приватным или открытым. Эти дискуссии, как правило, основаны на личном ощущении участников дебатов, и может быть довольно занимательно узнавать аргументацию, стоящую за каждым из вариантов. Возьмем отрешённый пример. Представьте, что вы возвращаетесь домой ночью, в темном переулке, и тут появляются какие-то люди, бьют вас, забирают телефон и исчезают. Как правило, после такой ситуации вы можете использовать три разных подхода: 1. Вы решаете избегать таких встреч, насколько это возможно. Вы не возвращаетесь домой ночью, избегаете темных переулков или даже остаётесь дома. По сути, вы заставляете себя избегать проблемы. 2. Вы утверждаете, что такой ситуации быть не должно, что полиция должна быть ночью на улице, чтобы помочь вам в таком случае. Вы заставляете других сделать так, чтобы такая ситуация больше не повторилась. 3. Вы также можете пойти в спортзал, научиться боксу или боевым искусствам или носить оружие, чтобы в следующий раз быть готовым и не дать им забрать ваш телефон. По сути, вы заставляете себя принять ситуацию. Вам решать, какой вариант вы выберете. Хотя вы можете возразить, что некоторые из них невыполнимы в вашем случае или нежелательны. То же самое относится и к разработке ПО. Допустим, вы нашли ошибку в длинной функции, меняющей состояние приложения. Что вы сделаете? Варианты: 1. Вы решаете, что вы и ваша команда больше не будете так писать. Вы делаете акцент на обзорах кода, чтобы не пропускать такие функции. 2. Вы решаете, что такие функции вообще нельзя разрешать. Вы меняете свой стек на использование чистых функций (например, на F# или Haskell). 3. Вы просто улучшаете свои навыки, чтобы лучше поддерживать длинные функции, меняющие состояние приложения. Похоже, что индустрия обычно выбирает первый вариант. В сети можно много прочитать о «чистом коде». Такие принципы, как «метод должен иметь не более двух параметров», подкрепляются такими утверждениями, как «Я работаю в отрасли уже 30 лет, поэтому я знаю лучше». Однако в итоге это просто вопрос личных предпочтений. На предпочтение могут влиять когнитивные навыки, окружающая среда, опыт, мастерство, риск, стоимость и, возможно, многие другие причины. Однако нет метрик, показывающих, что «контейнеры DI — это плохо» (как говорят Java-программисты, в то время как .NET-программисты получают поддержку DI «из коробки» в .NET Core), «функции должны иметь длину не более 10 строк» ​​(а затем вы видите, что пул реквесты в коде ядра Linux делают совершенно по-другому), или «чистые функции лучше, чем нечистые» (а затем вы заворачиваете свой код в морской узел, чтобы создать конечный автомат без состояния в нём). Должны ли мы запрещать или разрешать? Я склоняюсь к последнему. Но опять же, это вопрос предпочтений. Источник: https://blog.adamfurmanek.pl/2022/07/16/types-and-programming-languages-part-15/