Скорость развития IT столь высока, что многие технологии и идеи не успевают пройти проверку временем и становятся де-факто стандартами. Порой мы следуем этим стандартам по стадному принципу – как все, так и я. Это очень легко и комфортно. А иногда эти идеи становятся настолько незыблемы, что мы следуем им фанатично, не пытаясь задумываться правильно это или нет.
1. Код метода должен вмещаться на экран монитора.
Не стоит воспринимать это слишком буквально. Я бы перефразировал это так: не стоит писать методы, которые делают больше чем одно чёткое конкретное действие с точки зрения логики приложения. Т.е. если обстоятельства складываются так, что ваш методе может быть меньше 300 строк, не стоит его дробить на отдельные методы. Названия таких методов ничего не скажут разработчику. Вы только создадите путаницу в коде. Ведь эти методы могут быть вызваны только в определённом порядке, образуя неизменяемую цепочку последовательности.
Однажды мне нужно было добавить несколько дополнительных перегрузок для метода логики приложения, которая затрагивала слой UI, public и admin части. С админским контроллером разобрался быстро. А вот с public'ом были проблемы.
Вызов метода, который мне, возможно, нужно было изменить. Находился в загадочном методе, в котором был лишь проход по циклу с набором действий, которые мне не о чём не говорили. Зато он был строчек 10! Чтоб понять что тут происходит, я поднялся на уровень выше, где этот метод вызывается… Тут меня возникло острое чувство дежавю – опять короткий загадочный набор операций в коротком безликом методе. И как на зло мой метод бизнес-логики вызывался в нескольких таких кодах. Спасибо автору сей реализации, за то, что уберёг меня от чтения одного чёткого и конкретного метода, пусть и не вмещающегося в экран монитора. Заменив его на пяток чёрт пойми чего.
2. Статика – это плохо!
Вокруг меня много программистов, которые в этом убеждены, среди вас я думаю тоже. Даже не знаю откуда растут ноги у этого стереотипа. Слышал только один сколько нибудь весомый аргумент – статику сложнее покрыть тестами. Только здравый смысл мне подсказывает что здесь не учитывается ключевой момент: что первично, а что вторично. Т.е. кто под кого должен подстраиваться. Это то же самое, что организм человека должен подстраиваться под одежду, которую мы покупаем в магазине.
Кстати, вот ещё интересная разновидность этого стереотипа: Статика — это плохо, а extension методы — это круто! <ирония>Не может быть...</ирония>.
3. Чем больше паттернов используется в моей реализации, тем я круче как программист.
Очень интересный способ самоутверждения. Оставьте своё ЧСВ, и пожалейте коллегу, который будет пытаться внести изменения в вашу реализацию, перелопачивая 5-ую обвёртку, скорее всего он будет думать: «По моему я заблудился… Воспользуюсь поиском по проекту, а ведь всего на всего нужно был заменить true на false, в очевидном функционале».
Используйте патерен не тогда когда он сюда подходят, а тогда когда видите конкретное преимущество в его использовании <ирония>или когда хотите сделать дополнительный уровень абфускации своего кода</ирония>.
4. IoC контейнер – это наше всё!
Предполагаю, что это ещё один способ самоутвердится среди коллег. Иметь возможность легко подменять одну реализацию на другую — это здорово! Это действительно здорово. Но только в том случае если вы видите ситуацию, при которой вам это может понадобиться. Например, замена одного движка на другой. Но это не значит, что этот механизм должен поддерживать весь ваш код. Доходит до абсурда. Видел коммерческий код, в котором была реализовано возможность быстрой подмены одних тонких сущностей на другие (классов в котором объявлены свойства без какой либо логики). Очень полезная возможность, не правда ли?
5. Мы любим Code first (речь о Entity Framework)!
Всегда считал Code first более мудрым подходом. Для меня код первичен. Мне важно как я буду манипулировать данными в коде. А БД лишь коробка для распараллеленого доступа к данным. Сегодня я использую одну коробку, завтра другую. Но признаюсь, 5 лет назад моя приверженность Code first была под запретом. Такой подход вызывал насмешки у коллег, или намёк на мою некомпетентность. Как это БД будет опираться на программный код, а не наоборот?!
Сейчас, когда Microsoft стала пропагандировать Code first, все стали резко её сторонниками. Т.е. мнение большинства поменялось на противоположное. Что-то изменилось в IT? Не считая рекламной компании Microsoft. Поменялся стереотип.
Итог: стереотипное следование трендам – это зло. И на мой взгляд, это самое большое зло в современном программировании. У каждого подхода, решения должно быть осязаемое, а не абстрактное обоснование. Если ваш пример использования тренда не чёткий или абсурдный для данных реалий, откажитесь от его использования. Иначе вы будете писать приложения, которые потом, вам же будет неприятно сопровождать.
Автор: Morten
