The Joy of Programming

"Как войти в профессию?!" - Это самый популярный вопрос среди начинающих программистов. И знаете, прежде чем на него отвечать... на самом деле, нужно проработать другой, и пожалуй более важный: "Как в ней удержаться?!". Ибо стакан без дна много не удержит, а свою жизнь каждый хотел бы сделать осмысленной и наполненной. У Егора Бугаенко есть рецепт на этот счет.

Zerocracy

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

По мотивам интервью:

FRONTEND WEEKEND #68 Егор Бугаенко о том, как и почему нужно выделять себя из толпы других программистов

Как именовать множество классов

Каждый раз Егора Бугаенко спрашивают, если мы последуем твоему совету, то у нас будет огромное количество маленьких классов. В конечном итоге их станет так много, что это только усложнит программирование, а не упростит его.

ActiveRecord даже хуже, чем ORM

Вероятно, вы помните, что я думаю об ORM, очень популярном паттерне. Если кратко, это побуждает нас превращать объекты в DTO - в результате, вся парадигма программирования переходит от объектно-ориентированного подхода к процедурному. Я попытался объяснить это в JPoint и JEEConf в этом году. После каждого разговора несколько человек сказали мне, что то, что я предлагаю, называется шаблонами ActiveRecord или Repository.

ORM - это обидно

Композиционные декораторы против императивных вспомогательных методов

Шаблон декоратора является моим фаворитом среди всех других моделей, которые я знаю. Это очень простой и в то же время очень мощный механизм, который делает ваш код очень когезивным и слабосвязанным. Однако я считаю, что декораторы не используются достаточно часто. Они должны быть везде, но это не так. Самое большое преимущество, которое мы получаем от декораторов, заключается в том, что они делают наш код составным. Вот почему заголовок этой статьи - это композиторы-декораторы. К сожалению, вместо декораторов мы часто используем императивные методы утилит, которые делают наш код процедурным, а не объектно-ориентированным.

Контейнеры для вставки зависимостей загрязняют код

В то время как инъекция зависимостей (aka, «DI») - естественный метод создания объектов в ООП (известный задолго до того, как термин был введен Мартином Фаулером), Spring IoC, Google Guice, Java EE6 CDI, Dagger и другие структуры DI превращают его в Анти-шаблон.

Я не собираюсь обсуждать очевидные аргументы против «инъекций сеттера» (например, Spring IoC) и «инъекции полей» (как в PicoContainer). Эти механизмы просто нарушают основные принципы объектно-ориентированного программирования и побуждают нас создавать неполные, изменяемые объекты, которые заполняются данными в ходе выполнения приложения. Помните: идеальные объекты должны быть неизменными и не должны содержать сеттеров.

Вместо этого давайте поговорим о «введении конструктора» (как в Google Guice) и его использовании с контейнерами инъекции зависимостей. Я попытаюсь показать, почему я рассматриваю эти контейнеры как избыточность.

Инкрементное выставление счетов

Когда вы нанимаете разработчика программного обеспечения (индивидуального или коллективного), существует в основном два типа контрактов: фиксированная цена или время&материал. Они принципиально разные, но правда в том, что в любом случае вы проигрываете.

 
В методологии eXtremely Distributed Software Development (XDSD) все по-другому, включая способ выставления счетов нашим клиентам. Давайте посмотрим, что происходит в традиционных контрактах и ​​какие изменения в XDSD, которые мы практикуем в Teamed.io.

Семь смертных грехов программного проекта

Ремонтопригодность является наиболее ценным достоинством современной разработки программного обеспечения. Ремонтопригодность в основном можно измерить как рабочее время, необходимое новому разработчику для изучения программного обеспечения, прежде чем он может начать вносить в него серьезные изменения. Чем дольше время, тем ниже ремонтопригодность. В некоторых проектах это требование времени близко к бесконечности, что означает, что оно буквально недостижимо. Я считаю, что есть семь фундаментальных и смертельных грехов, которые делают наше программное обеспечение неосуществимым. Вот они.

Сколько объектов инкапсулируется?

Какая строка вам нравится больше, первая или вторая:

new HTTP("http://www.google.com").read();
new HTTP().read("http://www.google.com");

В чем разница? Первый класс HTTP инкапсулирует URL-адрес, а второй ожидает его как аргумент метода read (). Технически оба объекта выполняют одно и то же: они читают содержимое домашней страницы Google. Какой из них правильный? Обычно я ненавижу говорить это, но в этом случае я должен - это зависит от точки зрения.