"Как войти в профессию?!" - Это самый популярный вопрос среди начинающих программистов. И знаете, прежде чем на него отвечать... на самом деле, нужно проработать другой, и пожалуй более важный: "Как в ней удержаться?!". Ибо стакан без дна много не удержит, а свою жизнь каждый хотел бы сделать осмысленной и наполненной. У Егора Бугаенко есть рецепт на этот счет.
Elegant Objects
Объектно-ориентированное программирование и язык программирования EOlang
пятница, 16 августа 2019 г.
вторник, 28 мая 2019 г.
Zerocracy
Да, этот блог о коде, о "красивом коде" и тем более интересным будет добавление в него постов о том, как элегантный программистский подход позволяет элегантно структурировать окружающий мир и решать насущные управленческие задачи.
По мотивам интервью:
FRONTEND WEEKEND #68 Егор Бугаенко о том, как и почему нужно выделять себя из толпы других программистов
вторник, 20 февраля 2018 г.
Как именовать множество классов
Каждый раз Егора Бугаенко спрашивают, если мы последуем твоему совету, то у нас будет огромное количество маленьких классов. В конечном итоге их станет так много, что это только усложнит программирование, а не упростит его.
четверг, 1 июня 2017 г.
ActiveRecord даже хуже, чем ORM
Вероятно, вы помните, что я думаю об ORM, очень популярном паттерне. Если кратко, это побуждает нас превращать объекты в DTO - в результате, вся парадигма программирования переходит от объектно-ориентированного подхода к процедурному. Я попытался объяснить это в JPoint и JEEConf в этом году. После каждого разговора несколько человек сказали мне, что то, что я
предлагаю, называется шаблонами ActiveRecord или Repository.
четверг, 25 мая 2017 г.
Композиционные декораторы против императивных вспомогательных методов
Шаблон декоратора является моим фаворитом среди всех других моделей, которые я знаю. Это очень простой и в то же время очень мощный механизм, который делает ваш код очень когезивным и слабосвязанным. Однако я считаю, что декораторы не используются достаточно часто. Они должны быть везде, но это не так. Самое большое преимущество, которое мы получаем от декораторов, заключается в том, что они делают наш код составным. Вот почему заголовок этой статьи - это композиторы-декораторы. К сожалению, вместо декораторов мы часто используем императивные методы утилит, которые делают наш код процедурным, а не объектно-ориентированным.
Контейнеры для вставки зависимостей загрязняют код
В то время как инъекция зависимостей (aka, «DI») - естественный метод создания объектов в ООП (известный задолго до того, как термин был введен Мартином Фаулером), Spring IoC, Google Guice, Java EE6 CDI, Dagger и другие структуры DI превращают его в Анти-шаблон.
Я не собираюсь обсуждать очевидные аргументы против «инъекций сеттера» (например, Spring IoC) и «инъекции полей» (как в PicoContainer). Эти механизмы просто нарушают основные принципы объектно-ориентированного программирования и побуждают нас создавать неполные, изменяемые объекты, которые заполняются данными в ходе выполнения приложения. Помните: идеальные объекты должны быть неизменными и не должны содержать сеттеров.
Вместо этого давайте поговорим о «введении конструктора» (как в Google Guice) и его использовании с контейнерами инъекции зависимостей. Я попытаюсь показать, почему я рассматриваю эти контейнеры как избыточность.
Я не собираюсь обсуждать очевидные аргументы против «инъекций сеттера» (например, 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. Какой из них правильный? Обычно я ненавижу говорить это, но в этом случае я должен - это зависит от точки зрения.
Подписаться на:
Сообщения (Atom)