Комментарии 23
Альберт Эйнштейн не говорил того, что написано на картинке, по крайней мере об этом не осталось упоминаний.
И всё равно, когда другой программист начнет работать с вашим кодом, он спросит "Какой болван это написал?" :)
А если серьезно - красиво написано. Про удаление ненужного когда я аж всгрустнул - у нас всё комментируют. Но на практике всегда возникают вопросы.
Осмотреться как написан код в проекте - зачастую просто нет времени и смысла, т.к. там уже зоопарк. Обычно смотрят и берут первый попавшийся образец, а потом оказывается, что это был неудачный пример.
Короткие функции по 20 строк - здорово. Только теперь нужно скакать между функциями и держать несколько контекстов в голове.
Обычно смотрят и берут первый попавшийся образец, а потом оказывается, что это был неудачный пример.
Согласен, если недавно в проекте, то есть такой шанс. Но именно для этого тимлиды придумали код-ревью. И желательно, чтобы один из ревьюеров уже давно был знаком с проектом ну и был немного душнилой :)
Короткие функции по 20 строк - здорово. Только теперь нужно скакать между функциями и держать несколько контекстов в голове.
А тут уже должно вступать в силу правило именования функций: читаешь код функции, не погружаясь в вызываемые подфункции, и в хорошем проекте этого должно быть достаточно. Редко, конечно, такое бывает, но это не значит, что нам тоже надо поддаваться эффекту "разбитых окон" и писать непонятные функции с неожиданными side-effect-ами
Не могу не оставить это здесь:
Наследование — очень полезная вещь, позволяющая расширять и модифицировать поведение сходных объектов без дублирования кода.
Вообще, использование наследования чисто чтобы не дублировать код - это антипаттерн.
Ну почему же? Template method ("шаблонный метод") — это вполне себе паттерн, один из самых древних, кстати.
И использует он именно наследование, и именно чтобы не дублировать большую часть кода: она пишется один раз в корневом для иерархии классе.
Нет, я, конечно знаю, что для реализции специфического поведения, в принципе, вместо наследования и Template method часто можно использовать композицию и Strategy. Однако бывают случаи, когда наследлование+Template method явно лучше: когда для реализации специфического поведения требуются внутренняяя информация и вспомогательные, совершенно не нужные для внешних потребителей, внутренние методы.
При наследовании такие компоненты базового класса просто помечаются как доступные только наследникам (общепринятое ключевое слово — protected). А при композиции их нужно либо выводить на общедоступный интерфейс (public), нарушая тем самым инкапсуляцию, либо вводить понятие «дружественных» классов для доступа к ним (что в ряде языков — C# например — реализуется весьма неудобно). И вот в таких случаях наследование использовать предпочтительнее.
PS А вот интерфейсы (первая ваша ссылка) — это действительно полезное добавление к классическому ООП. Впрочем, в свое время в C++, куда их тогда не завезли, я успешно обходился вместо них абстрактными виртуальными классами, просто не используя излишнюю из функциональность.
PPS Я бы предпочел, чтобы вы свое мнение своими словами аргументировали, а не ссылками на тексты ваших авторитетов: мнение авторитета не всегда является истинным, особенно — для тех, кто не является его последователем.
Технически эти ситуации похожи, но логически разные. Отличие сложно описать словами, но обычно оно связано с вопросами "Как это код будет меняться в будущем? Действительно ли нам надо, чтобы при изменении в этом методе поведение менялось всегда для всех наследников? Могут ли эти 2 класса меняться независимо? Может ли один класс существовать без другого?".
Например, в каждой сущности есть поле id, но обычно мы не делаем родительский класс с одним полем id. В какой-то сущности может быть другой тип поля, в какой-то первичный ключ может называться по-другому, если в одной сущности переименовали, то это не значит, что надо переименовывать в других, и т.д.
Читал такое у дядюшки Боба, но ладно... Эйнштейн так Эйнштейн.
В проекте где я сейчас работаю, тимлид настаивает на соблюдении стиля write-only: один раз написал а дальше трава не расти. Поэтому 1000-строчные и 2000-строчные файлы, где серверный язык вперемешку с запросами к БД щедро сдобрен джаваскриптом и html, считаются единственно правильным стилем, а за новый модуль из локальных модели, контроллера и вьюхи меня даже как-то наказали.
Даже отбить пробелами проверку и присвоение считается чем-то плохим, а типичные имена функций и переменных выглядят так:
while (r=ab(q)) {
...200 строк кода без отступов и пробелов...
}
но тимлид непреклонен: "вот есть стиль и ты должен!"
Подход конечно правильный, но лопни мои глаза... Тут бы как-то убедить человека (младше меня!) что время перфокарт уже прошло, а не вот это вот все...
А зачем вам его убеждать? Если вы не желаете писать код в стиле настоящих программистов, то что вам мешает сменить проект и писать эстетически приятный для вас код?
Затем что код пишется один раз и для компилятора, а поддерживается годами и человеком?
Дык, пусть тимлид его и поддерживает дальше — сам или наймет на ваше место настоящего программиста (который не боится труднойстей, как в той статье описано). А вы будете писать красивый чистый код где-нибудь в другом месте. Что вас в таком варианте не устраивает?
PS Кстати, вы напрасно думаете, что этот код — он обязательно write-only. При прокачке соответсвующего навыка он вполне читаем: я, например, за свою жизнь такой код читал неоднократно. И можете, кстати, рассматривать свою нынешнюю работу как прокачку этого навыка: он по жизни время от времени пригождается.
Здесь стоит философски посмотреть на то, что качественный код - это не залог доходности бизнеса. Знаю, действительно, много проектов, которые успешны и при этом ужасны внутри.
Если подход тимлида устраивает бизнес: скорость разработки, качество проекта, прогнозируемость сроков - то его политика вполне оправдана. Здесь надо для себя просто решать, готов ли ты работать так, как тут заведено? Можно искать плюсы не в красивом коде, а в каких-то других показателях, например, пользы от твоего быстрого говнокода для бизнеса. А то что код пишешь в помойку, ну просто смириться, что твой код - это расходный материал в этом проекте.
Конкретно советы в этой статье я писал для тех проектов, которые стремятся к качественному коду. И мне больше нравится работать именно в таких проектах. Но выбор есть у каждого, особенно в наше счастливое для разработчиков время :)
Человекочитаемый код