Навык программиста в том, чтобы делать то, что хочется быстро и дёшево.
NB: Позже я придумал иначе: в том, чтобы наиболее выгодно переводить усилия в удобство (чьё-то, а в конечном счёте своё).
С опытом некоторые начинают думать, что хороший программист тратит время сейчас, сэкономив его в будущем. Это неправильный секрет. Часто это помогает, но нередко вредит. Новички, которые стараются решить поставленную задачу хоть как-нибудь, часто ближе к сатори.
Из этого заблуждения возникает архитектурная астронавтика и боязнь хардкода. "Что, если эти обстоятельства изменятся? А если эти? А те?" Такой образ мыслей существует до тех пор, пока человек замечает обстоятельства избирательно; пока он не окинет свой код взглядом и не увидит, что всё в нём – это обстоятельства. Программа это закодированное условие, ограничение на полный произвол. Делая её "универсальнее", вы убираете часть условий, перекладываете их на плечи пользователя.
Например, вы пишете интерфейс доступа к базе данных. Ваша цель конкретна: каталог фильмов, режиссёров, актёров. Что сделает начинающий программист? Запросы "getMovie", "getActor", "getDirector" и так далее.
Но это неуниверсально! Что, если завтра в базе появятся книги? Другой программист предлагает: сделаем "getWork", "getPerson", у work будет параметр type (movie, book), а person будет по отношению к work иметь relation (актёр, режиссёр, автор книги).
Хорошая это идея? Ну, нормальная. Реализовывать её сложнее. Пользоваться ей сложнее! API слегка неочевиднее. Но действительно, очень полезно для расширения.
Третий программист говорит: Кто знает этих заказчиков! Сегодня они хотят одни поля, а завтра другие. Предлагаю сделать ещё универсальнее: getTable(name), getRecord(table, index), getField(record, index). Обратите внимание, какая универсальность! Мы можем хранить внутри таблицы фильмов и актёров, а можем автобусов и маршрутов. Мы можем хранить данные на сервере, а можем кешировать локально. Может прозрачно вводить любые отношения и ограничения!
Но этот универсальный интерфейс по сути не предоставляет никакого интерфейса. Вся сложность, все обстоятельства задачи легли на плечи пользователя. Универсальный интерфейс стал просто интерфейсом доступа к базе данных.
Архитектурным астронавтам это в голову не приходит, но ведь можно пойти ещё дальше. Кто сказал, что нам нужны таблицы и поля? А если завтра это изменится? Можно предоставить интерфейс "readBytes()" или "executeCode()". В таком случае пользователь может сам написать любой код, который будет работать с любыми данными, как ему вздумается!
Колхозная доктрина:
https://eax.me/kolkhoz-doctrine/