четверг, 1 июня 2017 г.

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

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

ORM - это обидно




четверг, 25 мая 2017 г.

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

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

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

В то время как инъекция зависимостей (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. Какой из них правильный? Обычно я ненавижу говорить это, но в этом случае я должен - это зависит от точки зрения.

Определение ошибки программного обеспечения в Википедии неверно

Вот что говорит Википедия на момент написания этой статьи:

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

Я думаю, что это неполно. Это определение полностью исключает «непоследовательные» дефекты, связанные, например, с ремонтопригодностью и возможностью повторного использования.

API RESTful и веб-сайт на одном URL-адресе

Посмотрите, например, на GitHub RESTful API. Чтобы получить информацию о репозитории, вы должны сделать запрос GET для api.github.com/repos/yegor256/rultor. В ответ вы получите документ JSON со всеми подробностями репозитория yegor256 / rultor. Попробуйте, URL-адрес не требует никакой аутентификации.

Чтобы открыть тот же репозиторий на хорошей HTML + CSS-странице, вы должны использовать другой URL-адрес: github.com/yegor256/rultor. URL-адрес отличается, серверная сторона определенно отличается, но характер данных точно такой же. Единственное, что меняется - это слой представления.

В первом случае мы получаем JSON; Во втором - HTML.

Как насчет их объединения? Как использовать тот же URL-адрес и тот же механизм обработки на стороне сервера для обоих из них? Как насчет переноса всей задачи рендеринга на сторону клиента (браузер) и предоставления серверу возможности работать исключительно с данными?

Составное имя - это дурнопахнущий код

Вы называете переменные, такие как textLength, table_name или current-user-email? Все три являются составными именами, которые состоят из более чем одного слова. Хотя они выглядят более описательно, чем имя, длина или адрес электронной почты, я настоятельно рекомендую их избегать. Я считаю, что имя переменной, более сложное, чем существительное, является запахом дурного кода. Почему? Потому что мы обычно даем переменной составное имя, когда его область настолько велика и сложна, что простое существительное будет звучать неоднозначно. И большой, сложный объем - очевидный запах кода.

Избегайте конкатенации строк

«конкатенация строк», и это плохая практика:
// bad practice, don't reuse!
String text = "Hello, " + name + "!";
Некоторые могут сказать, что это медленный процесс, главным образом потому, что части результирующей строки копируются несколько раз. Действительно, для каждого оператора + класс String выделяет в памяти новый блок и копирует все, что в нем есть; Плюс присоединяемый суффикс. Это верно, но здесь дело не в этом.

Типичные ошибки в коде Java

Эта страница содержит наиболее типичные ошибки, которые я вижу в Java-коде людей, работающих со мной. Статический анализ (мы используем qulice) не можем поймать все ошибки по очевидным причинам, и поэтому я решил перечислить их все здесь.

Как неизменяемый объект может обладать состоянием и поведением?

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

среда, 24 мая 2017 г.

Пустая строка - признак дурно пахнущего кода

Может звучать как шутка, но это не так. Пустая строка, используемая в качестве разделителя инструкций в объектном методе, является дурным запахом. Почему? Короче говоря, потому что метод не должен содержать «частей». Метод всегда должен делать одно, а его функциональная декомпозиция должна выполняться языковыми конструкциями (например, новыми методами), а не пустыми строками.

Анти паттерны

Как мы пишем видение продукта

Каждый программный проект, с которым мы работаем, запускается из документа Vision. Мы создаем его во время фазы Обдумывание. Несмотря на то, что документ короток, две страницы текста, его разработка является самой кропотливой задачей во всем проекте.

Как срезать углы и оставаться в порядке

У вас есть задание, назначенное вам, и вам оно не нравится. Вы просто не в настроении. Вы не знаете, как исправить эту чертову ошибку. Вы не представляете, как был спроектирован этот чертов модуль, и вы не знаете, как это все работает. Но вам нужно решить проблему, о чем сообщил кто-то важный, кто вообще не представляет, как работает это программное обеспечение вообще. Вы расстраиваетесь и обвиняете этого глупого менеджера проекта и программистов, которых уволили два года назад. Вы тратите часы только на то, чтобы узнать, как работает код. Потом еще несколько часов пытаетесь это исправить. В конце концов, вы упускаете крайний срок, и все обвиняют вас. Было такое?

Существует, однако, альтернативный подход, который обеспечивает профессиональный выход из этой ситуации. Вот несколько советов, которые я рекомендую своим сверстникам, которые пишут со мной в проектах teamed.io. Короче говоря, я собираюсь объяснить, как можно срезать углы и оставаться профессионалом, 1) защищая свои нервы, 2) оптимизируя расходы вашего проекта и 3) повышая качество исходного кода.

Вот список вариантов, которые у вас есть, в порядке предпочтения. Я бы рекомендовал вам начать с первого пункта и продолжать по мере необходимости.

Создание фиктивных объектов

Хотя фиктивные объекты являются совершенными инструментами для модульного тестирования, насмешки над макетными фреймворками могут превратить ваши юнит-тесты в бесполезный беспорядок. 

How Much Do You Cost?

Я получаю несколько электронных писем каждый день от программистов, заинтересованных в работе с Teamed.io удаленно. Первый вопрос, который я обычно задаю, это «какая ваша ставка»? (по часам). Меня удивляет, как часто люди неправильно оценивают себя.

unit test scaffolding

Когда я начинаю повторять себя в модульных тестах, создавая одни и те же объекты и подготавливая данные для запуска теста, я разочарован в своем дизайне. Длинные методы тестирования с большим количеством дублирования кода просто не выглядят правильно. Чтобы упростить и укоротить их, есть по существу два варианта, по крайней мере в Java: 1) частные свойства, инициализированные через @Before и @BeforeClass, и 2) частные статические методы. Они оба выглядят для меня анти-ООП, и я думаю, что есть альтернатива. Позвольте мне объяснить.

maven-jcabi

Maven - инструмент автоматизации сборки, в основном для Java-проектов. Это отличный инструмент, но у него есть один важный недостаток, который мотивировал создание подобных инструментов, таких как Gradle и SBT. Эта слабость - это многословность конфигурации. Maven получает все параметры сборки проекта из pom.xml, XML-файла, который может быть очень длинным. Я видел файлы POM с 3000 строк. Принимая во внимание 1) недавний гул DSL и 2) страх перед XML, логично, что многие люди не любят Maven из-за его pom.xml verbosity.

Но даже если вы поклонник XML, который пользуется своей строгостью и элегантностью (как и я), вам не понравится необходимость повторять себя в pom.xml для каждого проекта. Если вы работаете над несколькими проектами, дублирование кода будет огромным. В среднем веб-приложении Java используется несколько десятков стандартных плагинов Maven и почти такое же количество довольно общих зависимостей, как JUnit, Apache Commons, Log4J, Mockito и т. Д. Все они имеют свои версии и конфигурации, которые необходимо указать, если вы Хотите сохранить проект стабильным и избегать предупреждений Maven. Таким образом, как только новая версия плагина будет выпущена, вам придется пройти через все файлы pom.xml в проектах, над которыми вы работаете, и обновить их там. Очевидно, вы понимаете, что такое дублирование кода. Это катастрофа. Однако есть решение.

Software architect responsibilities

Архитектор программного обеспечения является ключевым человеком в программном проекте, который я объяснил в статье «Что делает архитектор программного обеспечения?». Пост несколько месяцев назад. Архитектор лично отвечает за техническое качество разрабатываемого нами продукта. Независимо от того, насколько хороша команда, насколько сложна технология, насколько запутанны требования или хаотична спонсор проекта, мы обвиняем архитектора и никого больше. Конечно, мы также вознаграждаем архитектора, если нам это удастся. Вот что я, как руководитель проекта, ожидаю от хорошего архитектора.

Дураки не пишут юнит-тесты

«У нас нет времени писать модульные тесты» или «У нас нет бюджета для модульного тестирования». Иногда это может звучать так: «Мы не используем TDD, поэтому у нас нет модульных тестов», или даже «TDD для нас слишком дорого». Я уверен, вы слышали это или даже сказали это сами. Я не понимаю логики. По моему мнению, модульное тестирование не является продуктом; Это инструмент. Вы используете тесты для разработки продукта быстрее и лучше. Как вы можете сказать, что у вас нет времени использовать инструмент, который ускоряет вашу работу? Позвольте мне показать вам, как это сделать.

вторник, 23 мая 2017 г.

re-throwing

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

Что вы делаете с InterruptedException?

InterruptedException - постоянный источник боли в Java, особенно для младших разработчиков. Но этого не должно быть. Это довольно простая и легкая для понимания идея. Позвольте мне попытаться описать и упростить ее.

Checked vs. Unchecked Exceptions

Нужны ли вообще проверяемые исключения? Дискуссия окончена, не так ли? Но, не для меня. В то время как большинство объектно-ориентированных языков вообще не имеют их, и большинство программистов считают, что исключения являются ошибкой Java, я верю в противоположное: непроверенные исключения - это ошибка. Более того, я считаю, что несколько типов исключений - тоже плохая идея.

много возвращаемых значений - плохая идея в ООП

Эти дебаты очень старые, но у меня есть, что сказать. Вопрос заключается в том, может ли метод иметь несколько операторов return или всегда один. Ответ может удивить вас: в чистом объектно-ориентированном мире метод должен иметь один оператор return и ничего больше. Да, просто заявление о возврате и все. Других операторов нет. Просто return. Все аргументы в пользу нескольких операторов возврата идут вразрез с самой идеей объектно-ориентированного программирования.
 

Избыточные переменные - чистое зло

Избыточная переменная - это та, которая существует исключительно для объяснения ее значения. Я твердо верю, что такая переменная - это не только чистый шум, но и зло, что очень негативно сказывается на читабельности кода. Когда мы вводим избыточную переменную, мы намерены сделать наш код более чистым и более удобным для чтения. В действительности, однако, мы делаем его более многословным и трудным для понимания. Без исключения любая переменная, используемая только один раз, является избыточной и должна быть заменена значением.

Fail Fast

В любом проекте программного обеспечения целью является создание чего-то стабильного. Мы не хотим, чтобы он сломался перед пользователем. Мы также не хотим, чтобы наш веб-сайт отображал «внутреннюю ошибку приложения» вместо веб-страницы. Мы хотим, чтобы наше ПО работало, а не на провал. Это вполне обоснованное и логичное желание, но для этого мы должны сделать наше программное обеспечение как можно более хрупким. Это может показаться противоречащим интуиции, но так оно и есть. Чем более хрупким является ваше приложение в разработке, тем более надежным он будет в производстве.
Хрупкой, я имею в виду философию Fail Fast, которая является противоположностью Fail Safe.  


Почасовая оплата - современное рабство

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

Когда вы прекращаете тестирование?

Существует программное обеспечение для тестирования. Есть команда тестеров. В бюджете есть деньги. В расписании есть время. Мы начинаем прямо сейчас. Тестеры пытаются взломать продукт, найти ошибки, сообщить об ошибках, пообщаться с программистами, когда это необходимо, сделать все возможное, чтобы найти, что не так. В конце концов они останавливаются и говорят «мы закончили». Как они знают, когда остановиться? Когда будет достаточно для прекращения тестирования? Это очевидно - когда больше не осталось ошибок и продукт может быть отправлен! Если вы так думаете, у меня плохие новости для вас. Вы в корне не правы.

Марсианин - фальшивая реальность

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

Временная связанность

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

понедельник, 22 мая 2017 г.

Бросать исключение без надлежащего контекста - это плохая привычка

Я повторяю одну и ту же ошибку снова и снова. Итак, пришло время остановиться и сделать правило, чтобы этого больше не происходило. Ошибка не фатальна, но очень раздражает. Когда я смотрю на производственные журналы, я часто вижу что-то типа «Файл не существует», и я спрашиваю себя: Какой файл? Где он должен существовать? Что сервер пытался с этим сделать? Что происходило за секунду до того, как он упал? В журнале ошибок нет ответа, и я полностью виноват. Я либо 1) не перебрасываю, либо 2) перебрасываю без предоставления контекста.

JSON vs XML

JSON или XML? Какая из них лучше? Какой из них быстрее? Какой из них я должен использовать в своем следующем проекте? Прекратите! Эти вещи не сопоставимы. Это похоже на сравнение велосипеда и AMG S65. Серьезно, какой из них лучше? Они оба могут отвезти вас из дома в офис, не так ли? В некоторых случаях велосипед сделает это лучше. Но означает ли это, что их можно сравнить друг с другом? То же самое относится к JSON и XML. Это очень разные вещи с их собственными областями применения.

Single Statement Unit Tests

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

Как избежать проблем с аутсорсингом программного обеспечения

Аутсорсинг программного обеспечения - это катастрофа, ожидающая своего решения; мы все это знаем. Во-первых, вы обнаружите компанию, которая обещает вам все, что вы пожелаете: по времени и в рамках бюджета, высочайшее качество, красивый пользовательский интерфейс, передовые технологии и беспроблемную пожизненную поддержку. Итак, вы отправляете первый платеж, и ваше путешествие начинается. Команда почти не понимает ваши потребности, качество ужасное, все ваши сроки  и бюджетные ожидания серьезно нарушаются, и уровень разочарования стремительно растет. И «лучшая» часть заключается в том, что вы не можете уйти, иначе все деньги, которые вы потратили, будут уничтожены, и вам придется начинать с нуля. Вы должны оставаться «женатым» на этой команде, потому что вы не можете позволить себе «развод». Есть ли способ сделать аутсорсинг программного обеспечения безопасным?

Может быть только один первичный конструктор

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

Сколько стоит разработка программного обеспечения

«Вот спецификация, сколько будет стоить создание этого программного обеспечения?» Я слышу это почти каждый день от клиентов Teamed.io и потенциальных клиентов, которые планируют стать нашими клиентами и передать нам аутсорсинг разработки программного обеспечения. Мой лучший ответ: «Я не знаю, это зависит». Кажется странным ответом для человека, который утверждает, что знает, что делает, не так ли? «Вот 20-страничная спецификация, которая объясняет все функции продукта: почему вы не можете оценить стоимость?» Я могу, но не буду. Вот почему.

Почему значение NULL это плохо?

Простой пример использования NULL в Java:
Public Employee getByName (String name) {
  Int id = database.find (name);
  If (id == 0) {
    Return null;
  }
  Return new Employee (id);
}
Что не так с этим методом?

Он может возвращать NULL вместо объекта - это то, что неправильно. NULL - ужасная практика в объектно-ориентированной парадигме, которой следует избегать любой ценой. Уже было опубликовано несколько мнений об этом, включая Null References, презентацию ошибки миллиардного доллара Тони Хоара и книга Дэвида Уэста «Вся мысль».

Здесь я попытаюсь обобщить все аргументы и показать примеры того, как использование NULL можно избежать и заменить правильными объектно-ориентированными конструкциями.

Constructors Must Be Code-Free

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

Оборонительное программирование посредством проверки декораторов

Проверяете ли вы входные параметры своих методов на достоверность? Я нет. Раньше да, но больше нет. Я просто позволяю своему коду вылетать с нулевым указателем (null pointer) и другими исключениями, когда параметры недействительны. Это может показаться нелогичным, но только в начале. Я предлагаю вместо этого использовать декораторы.

воскресенье, 21 мая 2017 г.

Аутсорсинг программного обеспечения не работает ... Больше

Я хочу создать приложение для iPhone для своего веб-сервиса, но у меня нет программистов. Ну, у меня нет программистов для iOS. И у меня нет денег. Звучит знакомо? Что я делаю? Верно, я иду в Google Upwork и нахожу удивительную компанию в Бангалоре, которая рада работать со мной ни за какие разумные деньги. Через несколько месяцев и после нескольких тысяч долларов я понимаю, что это не совсем то, чего я ожидал. Спустя еще несколько месяцев я клянусь Богом, что никогда не буду передавать кому-либо любую разработку программного обеспечения. Только я такой? На самом деле, нет.

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

Ten mistakes in specs

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

Try. Finally. If. Not. Null.

Существует очень типичная ошибка в сценарии «try / finally» до Java7, который я продолжаю видеть во многих обзорах кода. Я просто должен написать об этом. Java7 представила решение, но оно не охватывает все ситуации. Иногда нам приходится иметь дело с неавтоматизированными ресурсами. Давайте откроем и закроем их правильно.

Java Annotations Are a Big Mistake

Аннотации были введены в Java 5, и мы все были в восторге. Такой замечательный инструмент, чтобы сделать код короче! Больше файлов конфигурации Hibernate / Spring XML! Прямо там, где нам нужны эти аннотации. Нет больше  marker interfaces, просто, runtime-retained reflection-discoverable annotation! 

Я тоже был воодушевлен. Более того, я сделал несколько библиотек с открытым исходным кодом, которые используют аннотации в значительной степени. Возьмем, например, jcabi-аспекты. Однако теперь я больше не воодушевляюсь. Более того, я считаю, что аннотации - большая ошибка в дизайне Java.

Методы тестирования не должны ничем делиться друг с другом

Константы ... Я писал о них некоторое время назад, в основном говоря, что они плохие, если они публичные. Они уменьшают дублирование, но вносят связь. Более эффективный способ избавиться от дублирования - создать новые классы или методы - традиционный метод ООП. 

Но одна вещь по-прежнему беспокоит меня: модульные тесты. Большинство программистов, кажется, думают, что, когда статический анализ говорит о том, что в одном файле слишком много похожих литералов, лучший способ избавиться от них - с помощью частного статического литерала. Это просто неправильно.

Object Behavior Must Not Be Configurable

Использование свойств объекта в качестве параметров конфигурации является очень распространенной ошибкой, которую мы продолжаем делать главным образом потому, что наши объекты изменяемы - мы их настраиваем. Мы меняем свое поведение, вставляя в него параметры или даже целые настройки / объекты конфигурации. Должен ли я сказать, что это оскорбительно и неуважительно с философской точки зрения? Я могу, но давайте посмотрим на это с практической точки зрения.

суббота, 20 мая 2017 г.

Twelve Mistakes in Agile Manifesto

В настоящее время Agile Manifesto - это библия из 12 принципов, изобретенных в 2001 году, которые показывают нам, как должна быть организована разработка программного обеспечения. Вообще, я люблю их соглашаюсь со всеми из них. Однако на практике большинство команд на самом деле не понимают их. Вот краткое изложение того, что происходит, и моя интерпретация каждого принципа.

пятница, 19 мая 2017 г.

Design Patterns and Anti-Patterns, Love and Hate

Шаблоны проектирования ... Мы любим их, потому что они позволяют нам писать код, не задумываясь. Мы ненавидим их, когда видим код того, кто привык писать код, не задумываясь. Я ошибаюсь? Теперь, позвольте мне показать вам, как я люблю или ненавижу каждого из них. 

среда, 17 мая 2017 г.

Все еще дебажите?

Отладка - это «процесс запуска программы / метода в интерактивном режиме, прерывающий выполнение после каждого оператора и показывающий ...» В двух словах это очень полезная техника ... для плохого программиста или для старого программиста, который все еще пишет процедурный код на C. 

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


Проектный деспотизм

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

Слишком много маленьких классов

Почти во всех презентациях, в которых я объясняю свой взгляд на объектно-ориентированное программирование, есть кто-то, кто разделяет такой комментарий: «Если мы последуем вашему совету, у нас будет так много маленьких классов». И мой ответ всегда один и тот же: «Конечно, будем, и это здорово!» Я искренне верю, что даже если вы не можете считать «много классов» добродетелью, вы не можете назвать это недостатком действительно объектно-ориентированного кода. Однако может наступить момент, когда классы становятся проблемой; Давайте посмотрим, когда, как и что с этим делать.

вторник, 16 мая 2017 г.

How Does Inversion of Control Really Work?

IoC, по-видимому, стала краеугольным камнем многих фреймворков и объектно-ориентированных проектов, так как это было описано Мартином Фаулером, Робертом Мартином и другими десять лет назад. Несмотря на свою популярность, IoC неправильно понимается и слишком усложняется.

Кто такой объект?

Существуют тысячи книг по объектно-ориентированному программированию и сотни объектно-ориентированных языков, и я считаю, что большинство (читайте «все») из них дают неправильное определение «объекта». Вот почему весь мир ООП настолько полон заблуждений и ошибок. Их определение объекта ограничено аппаратной архитектурой, с которой они работают, и поэтому очень примитивно и механично. Я хотел бы представить более подходящий вариант.


Закон (однойТочки) Деметры

Неверно понятое ограничение одной точкой, чтобы получить нужное, весьма ограничивает объектно-ориентированное мышление. 

book.textOfNumPage() //кажется верным

и

book.page().text() //кажется не верным


Действительно, глупо перебирать столько сущностей чтобы добраться до нужного: "Шарик. Собака. Ко мне. Передвигай лапы"

Вы хакер или дизайнер?

Двадцать лет назад лучшим программистом был тот, который мог подогнать все приложение в файл 64 КБ .COM. Те, кто смог извлечь максимальную производительность из бедного Intel 80386. Они были звездами программирования.

Это потому, что двадцать лет назад компьютеры были дорогими, а программисты - дешевыми. Это было время «хакерской ментальности». Это время закончилось. Этот менталитет уже не ценится, потому что рыночная ситуация полностью противоположна.

Сегодня компьютеры дешевы, а программисты дорогие. Это эпоха «дизайнерского мышления», когда читабельность нашего кода намного важнее его производительности.


Vertical vs. Horizontal Decomposition of Responsibility

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

Gradients of Immutability

Хорошие объекты являются неизменяемыми, но не обязательно постоянными. Я попытался объяснить это здесь, здесь и здесь, но теперь пришло время сделать еще одну попытку. Фактически, чем больше я думаю об этом, тем больше я понимаю, что неизменность не является только черной или белой - есть еще несколько градиентов; Давайте взглянем.

понедельник, 15 мая 2017 г.

Наследование - это процедурный способ повторного использования кода

Мы все знаем, что наследование плохо, а композиция - хорошая идея, но действительно ли мы понимаем, почему? В большинстве статей, которые я читал по этой теме, авторы говорили, что наследование может нанести вред вашему коду, поэтому лучше его не использовать. Означает ли это, что иногда наследование имеет смысл?

Несколько недель назад я интервьюировал Дэвида Уэста (автора Object Thinking, моей любимой книги о ООП), и он сказал, что наследования  в объектно-ориентированном программировании вообще не должно быть. Возможно, доктор Уэст прав, и мы должны полностью забыть ключевое слово extends в Java.

Могут ли объекты быть друзьями?


Как обсуждалось ранее, правильная инкапсуляция приводит к полному отсутствию «голых данных». Однако остается открытым вопрос: как объекты могут взаимодействовать между собой, если они не могут обмениваться данными? Думаю, у меня есть решение, которое сохраняет и инкапсуляцию на месте, и позволяя объектам взаимодействовать.


Инкапсуляция скрывает голые данные


Инкапсуляция - это основной принцип объектно-ориентированного программирования, который делает объекты надежными. Но что же такое инкапсуляция? Защищает ли она только от доступа к private атрибутам из вне? Я думаю, она намного больше. Инкапсуляция данных в принципе приводит к отсутствию голых данных на всех уровнях и во всех формах.

Рецепты Elegant Object:

В статье собраны большинство рекомендаций Егора Бугаенко касающиеся постижения дзен стиля Elegant Object.

if-then-else

В большинстве случаев (возможно, даже во всех) if-then-else может и должен быть заменен декоратором или просто другим объектом. 


воскресенье, 14 мая 2017 г.

Егор Бугаенко

Основа критики по отношению к Егору Бугаенко - это сопротивление той жесткой дисциплине, которую он предлагает добровольно принять для борьбы с накопившимися проблемами отрасли.

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

суббота, 13 мая 2017 г.

Continuous Integration is Dead

Несколько дней назад статья Егора Бугаенко «Почему непрерывная интеграция не работает» была опубликована на DevOps.com. Почти в тот же день были получены несколько негативных критических замечаний в Twitter. Вот ответ Егора на заданный вопрос: "Почему, непрерывная интеграция мертва, ведь это такая блестящая и популярная идея"?

Why Continuous Integration Doesn’t Work

Непрерывная интеграция проста. Загрузите Jenkins, установите, создайте задание, нажмите кнопку и получите красивое электронное сообщение о том, что ваша сборка нарушена (я предполагаю, что ваша сборка автоматизирована). Затем почините неисправные тесты (я предполагаю, что у вас есть тесты), и получите гораздо более привлекательную электронную почту, говорящую о том, что ваша сборка чиста. Затем напишите об этом, заявив, что ваша команда использует непрерывную интеграцию. 

Я видел его несколько раз в нескольких проектах. Начало всегда яркое и гладкое. Проблемы начнутся позже, когда сборка снова сломается, и мы просто не успеем ее исправить. Мы просто заняты чем-то другим, и несколько сломанных юнит-тестов не должны отвлекать нас. В конце концов, мы все знаем, что модульное тестирование не для команды, работающей со сроками, правильно? Неправильно. Непрерывная интеграция может и должна работать. Последняя сборка всегда должна быть чистой. Всегда.

8 + 2 Уровни зрелости непрерывной интеграции

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

Существует ряд компонентов, которыми должен обладать, качественная непрерывная интеграция

TDD

Продолжаем разбираться в концепции Егора Бугаенко об Элегантном и по-настоящему Объектном Программировании в Java. 

В частности, Егор предлагает переоценить актуальность концепции TDD (Test-Driven-Development) и, как обычно его выводы парадоксальны. Заниматься тестированием до того, как код забажен(bug) не особо денежно.
нам не нужно тестировать код, пока он не сломается