Архитектурные шаблоны вторичны

Не знаю как дела обстоят сейчас, но лет 5-7 назад на собеседованиях было ультра-модно спрашивать про архитектурные шаблоны. Абстрактные фабрики, синглтоны, вот это все. Возможно это и хорошая разминка для ума, но ведь архитектурные шаблоны - не самоцель. Они - средство. А цель - это адекватная архитектура приложения. Не супер-сложная (чтобы коллеги не приходили в ужас от количества реверансов и условностей при чтении/написании кода), не полное ее отсутствие (никто не любит big ball of mud катающийся в тарелке со спагетти), а сбалансированная (т.е. с умеренным использованием абстракций и инкапсуляции), симметричная (все компоненты примерно одного размера, нет god objects и армии анемичных недо-компонентов) и обладающая слабым зацеплением (aka loose coupling, обожаю российскую терминологию) структура программы.

Читать дальше

Мастерить!

Есть два типа языков: языки, где есть только один очевидный/правильный путь реализовать что-либо (Python, Java), и языки, где одну и ту же фичу можно закодить тысячей и одним способом (C++, JavaScript, Ruby). Первые больше похожи на детские конструкторы, вторые - на пластелин.

Подробнее LEGOs, Play-Doh, and Programming и инфографика.

И если для первой группы языков имеет смысл перерывать StackOverflow в поисках единственно-истинного решения отсортировать массив, то для второй группы обычно существует сразу множество "верных" решений. Зачастую, эти решения даже не являются компромиссными. Т.е. с точки зрения скорости выполнения, используемой памяти, поддержки кода и других аспектов абсолютно все равно, какое из решений выбрать.

Читать дальше