Проектирование и рефакторинг *

Привет всем, меня зовут Юра.
Сегодня я хотел бы поделиться с вами своим опытом и идеями в сфере проектирования и разработки ПО, развеять некоторые предрассудки и пролить свет на текущее состояние SOA решений в нашем, не совсем "реактивном", мире. О том, как писать меньше кода, получать меньше недовольных клиентов, седины, и больше профита. Реализовывать полностью реюзабельные решения без побочных эффектов, и почему до сих пор этого никто не сделал ⊙.☉

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

Представление данных

До этого мы обращали много внимания на поведение и общую структуру кода, но забиывали про на данные, с которыми имеем дело. Сейчас у нас все является строками, включая возвращаемое значение CatApi::getRandomImage(). То есть вызывая этот метод, мы «знаем», что получим строку. Говорю «знаем», так как PHP может вернуть все — объект, ресурс, массив и т.д. Тем не менее, хоть в случае с RealCatApi::getRandomImage() мы и можем быть уверенны, что нам придет строка, так как мы явно приводим значение к ней, мы не можем точно сказать, что эта строка будет «полезна» (валидна) для того, кто вызвал этот метод: это может быть и пустая строка, строка, которая не содержит URL (типа «I am not a URL») и так далее.

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

Сейчас уже сложно вспомнить тот момент, когда я впервые осознал, что выделять функции из больших кусков полезного кода, вообще-то, хорошая идея. То ли я получил это знание из “Совершенного кода”, то ли из “Чистого кода” — сложно вспомнить. В целом, это не особенно важно. Мы все знаем, что должны разносить бизнес-логику по хорошо проименованным функциям. Самая длинная функция, которую я когда-либо видео в жизни была длиной в 5к строк. Я лично знаком с тем “программистом”, что написал тот код. Помню, как впервые встретил эту функцию. Не сложно предсказать, что моей первой реакцией было: “Какого чёрта!!! Кто произвёл на свет этот кусок дерьма???”
Да, представьте себе, этот “программист” до сих пор слоняется тут в офисе, где я сейчас работаю над текущими проектами. Не хочу углубляться в эту историю, но хочу упомянуть, что та функция длиной в 5к строк была ядром программы, размером примерно в 150к строк. Разработка программы в конце концов зашла в тупик, из-за той ужасной функции, которая крайне негативно влияла на архитектуру приложения. В конце концов было принято решение о переписывании приложения с нуля.

Этот перевод является продолжением цикла статей про рефакторинг от Matthias Noback.

Мир не так надежен, чтобы на него опираться

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

Как можно было заметить в прошлой статье, оба класса (CachedCatApi и RealCatApi) зависят от внешних факторов. Первый из них записывает файлы в файловую систему, второй — делает реальные HTTP запросы, в то время как эти моменты довольно низкоуровневые и для них не используются правильные инструменты. Более того, в этих классах не учитывается большое количество пограничных случаев.

Оба класса могут быть лишены подобных зависимостей и для этого достаточно того, чтобы новые классы инкапсулировали все эти низкоуровневые детали. Например, мы запросто можем убрать вызов file_get_contents() в другой класс с названием FileGetContentsHttpClient.

class FileGetContentsHttpClient
{
    public function get($url)
    {
        return @file_get_contents($url);
    }
}

Сегодня будем говорить о некоторых возможностях замечательной IDE PhpStorm. Программисты из компании Jetbrains вкладывают огромные силы в создание своего продукта, в результате мы имеем мощную и одну из лучших IDE для языка программирования php. Думаю времена, когда хотелось выделиться программированием в Notepad++, практически ушли. Разрабатывать на коленке современные большие проекты с множеством файлов крайне затруднительно без хорошего инструмента.

В последние несколько недель я активно занимался доработкой Code Contracts, исправлением некоторых неприятных ошибок и добавлением поддержки VS2015. А поскольку VS2015 только что увидела свет, то подобная поддержка будет весьма кстати. Теперь обо всем об этом по порядку, да еще и с рядом технических подробностей.

Итак, первое, что нужно знать о Code Contracts, что эта штука жива. Код лежит в открытом доступе на гитхабе (https://github.com/Microsoft/CodeContracts) и есть ряд людей, которые активно занимаются наведением там порядка. Я являюсь owner-ом репозитория, но занимаюсь этим в свое свободное время. Помимо меня есть еще несколько человек, которые наводят порядок в Code Contracts Editor Extensions (@sharwell) и в некоторых других областях.

Code Contracts можно разделить на несколько составляющих:

• ccrewrite – тул, который занимается «переписыванием» IL-а, выдиранием утверждений (Contract.Requires/Ensures/Assert/Assume/if-throw) и заменой их на нужные вызовы методов контрактов, в зависимости от конфигурации.
• cccheck — тул, который занимается статическим анализом и формальным доказательством во время компиляции, что программа является корректной.
• Code Contracts Editor Extensions – расширение к VS, которое позволяет «видеть» контракты прямо в IDE.

Есть еще ряд тулов, например, для генерации документации, а также плагин к ReSharper, который упрощает добавление предусловий/постусловий и показывает ошибки ccrewrite прямо в IDE.

Я занимаюсь двумя составляющими – ccrewrite и плагином, но сейчас хочу остановиться именно на ccrewrite и на сложностях, с которыми я столкнуться при добавлении поддержки VS2015.

Все началось 20.06, когда я увидел в твиттере популярного блогера Варламов этот твит:


В тот же момент я подумал: ведь мессенджер вообще и Telegram в частности это идеальный способ взаимодействия с клиентом. Зачем нам приложение, чтобы доставлять последние новости если это можно просто прислать их в чат?

Зачем вам приложение для заказа такси, когда вы можете написать в чат любимому оператору такси «хочу такси в Домодедово от м. Южное через 35 минут» — и такси заказано. Зачем вам приложение для заказа из кафе, когда можно написать в чат «хочу двойной эспрессо и бейгл с осетром» — и осталось только послать свой адрес. Таких примеров использования чата может быть огромное множество.

В тот же день я написал небольшой пост в клубном новостном сообществе TJournal, где предложил в рамках предстоящего хакатона AngelHack написать продукт и создать демонстрационного бота: для подписки на новости и уведомления из этого сообщества. Через четыре дня Павел Дуров официально запустил поддержку ботов, а еще через две недели мы победили на AngelHack в номинации от IBM с проектом Leecero. Под катом большая история…

Добрый день, Хабровчане!

Продолжаю совмещать развитие навыков перевода c английского и изучение интересных, с моей точки зрения, материалов по программированию и делюсь с вами слегка адаптированным переводом первой части из небольшого цикла статей про рефакторинг от голландца Matthias Noback, который живет в городе Зейст что вблизи Утрехта.

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

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

Здравствуйте, меня зовут Дмитрий Карловский и я… очень стар. Годы уже не те, чтобы с лёгкостью разбираться в хитросплетениях мудрёных интерфейсов. Хочется чего-то относительно простого, но и достаточно мощного, чтобы не чувствовать себя калекой, который еле-еле пишет простейшую программу.

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

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

Далее вы узнаете, как я избавился от геморроя путём смены городского минивена на спортивный велосипед :-)

Синдре Сорхус — автор более, чем 600 модулей npm (666, Карл!). В недавнем AMA (кто не знает, это такой формат, когда кто-либо известный/интересный предлагает позадавать ему вопросы, например, в виде тикетов к гит-репозиторию, хотя, конечно, известнее /r/AMA и фуршет у Лебедева) он пояснил свою позицию по поводу модулей-однострочников, которые зачастую вызывают критику в адрес node.

Я собирался написать пост в блоге на эту тему, но, к сожалению, в этом я не так продуктивен, как в написании кода.

tl;dr Небольшие специализированные модули нужны для повторного использования и для того, чтобы делать большие и сложные штуки, которые легко понять.

Люди слишком озабочены количеством строк кода. LOC вообще не имеет никакого значения. Не важно, состоит модуль из одной строчки, или из сотен. Все дело в сокрытии сложности. Думайте о модулях node как о кубиках лего. Вас не интересует, из чего и как они сделаны. Все, что вам требуется знать — как использовать эти кубики для постройки своего лего-замка. Делая маленькие и специализированные модули, вы можете легко строить большие и комплексные системы без контроля за тем, как каждая отдельная деталь работает. Наша кратковременная память конечна. Эти модули могут повторно использовать другие люди и каждое улучшение и исправленный баг получат все из них.

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

Всем привет!

В нашей компании, помимо разработки собственной СУБД, также занимаются заказными разработками по самым разным направлениям, от суровых java-энтерпрайз приложений до небольших мобильных приложений. Наши команды стараются использовать передовые технологии и фреймворки. И как раз я являюсь представителем одной из таких команд. Сегодня хочу поделится опытом разработки на AngularJS и парой мыслей о проектировании веб приложения с использованием этого фреймворка.

От переводчика: с момента выхода популярной статьи Мартина Фаулера «Микросервисы» (перевод на Хабре) прошло уже достаточно времени, чтобы автор смог дополнить свои наблюдения свежим опытом проектирования и разработки микросервисов в различных компаниях, и рассказать о нем в новом посте, чей перевод представляется вашему вниманию.
Многие команды разработчиков нашли архитектурный стиль микросервисов подходом, превосходящим монолитную архитектуру; другие команды выяснили, что для них микросервисы — лишняя обуза, подрывающая производительность разработки. Как и у любого стиля архитектуры, у микросервисов есть свои плюсы и минусы. Для того, чтобы делать осознанный выбор, вы должны понимать эти свойства и уметь рассматривать их на фоне собственных конкретных условий.

Микросервисы дают преимущества…	…ценою издержек
Жесткие границы модулей Strong Module Boundaries Микросервисы усиливают модульную структуру, что особенно важно для больших команд разработчиков.	Распределённость Distribution Распределенные системы тяжелее программировать, поскольку удаленные вызовы медленные и всегда рискуют неудачей-отказом.
Независимый деплоймент Independent Deployment Простые сервисы проще деплоить, и, поскольку они автономны, меньше вероятность отказа системы в случае, если что-то идет не так.	Консистентность в конечном счете Eventual Consistency Поддержка cтрогой консистентности чрезвычайно сложна для распределённых систем, и это означает, что придется иметь дело с консистентностью в конечном счете.
Технологическое разнообразие Technology Diversity С микросервисами вы можете смешивать несколько языков, фреймворков и технологий хранения данных.	Эксплуатационная сложность Operational Complexity Вам потребуется опытная команда эксплуатации для управления множеством сервисов, которые будут регулярно редеплоиться.

Чаще всего deadlock описывают примерно следующим образом:
Процесс 1 блокирует ресурс А.
Процесс 2 блокирует ресурс Б.
Процесс 1 пытается получить доступ к ресурсу Б.
Процесс 2 пытается получить доступ к ресурсу А.
В итоге один из процессов должен быть прерван, чтобы другой мог продолжить выполнение.
Но это простейший вариант взаимной блокировки, в реальности приходится сталкиваться с более сложными случаями. В этой статье мы расскажем с какими взаимными блокировками в MS SQL нам приходилось встречаться и как мы с ними боремся.

В предыдущей статье цикла мы кратко рассмотрели основные принципы устройства и функционирования Typhoon Framework — Dependency Injection контейнера для iOS. Тем не менее, мало понимать, как устроен инструмент — важнее всего правильно его использовать. В первой части мы рассматривали различные примеры настройки конфигураций создаваемых зависимостей, то теперь разберемся с более высоким уровнем — разбитием на модули самих TyphoonAssembly и их тестированием.

Цель

Разделить взаимодействия пользовательского интерфейса между веб-клиентом и веб-приложением на три чётко определённые роли.

Предпосылки

Термин MVC испытывает некоторое семантическое размытие своего первоначального значения, особенно в контексте веба (см. видео Стефана Прибша для более подробного рассмотрения вопроса). В качестве средства устранения этого размытия предлагаю вашему вниманию описание паттерна Action-Domain-Responder, являющегося доработкой концепции MVC под нужды решения специфичных для веба задач.

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

Еще одной вскрывшейся проблемой является тот факт, что часто мы рассматриваем Представление (View) как шаблон (template), хотя в контексте веба, вероятно, более уместно было бы говорить о том, что Представлением является HTTP-ответ. Исходя из вышесказанного, я считаю, что ADR способен предоставить лучшее, чем MVC, разделение концепций для веб-приложений.

Перевод статьи «Core Frameworks Don’t Work (most of the time)» от Rudy Lacovara, в которой он критикует практику, когда компании создают собственные универсальные платформы для разработки ПО, на основе которых реализуют несколько совершенно не связанных проектов. На картинке изображен Борг из Стар Трека, это раса киборгов, которая ассимилирует все встречающиеся организмы в единый супер-организм.

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

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

Всем привет!

Две недели назад в Москве прошла очередная встреча CodeFreeze. Нашим гостем стал Евгений Кривошеев, признанный российский эксперт в области архитектуры программных систем, консультант из Scrumtrek/Skilltrek. Евгений прочитал офигеннейшую лекцию по архитектуре, как он любит и умеет.



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

• Точки зрения на систему, или Почему мы слепнем при проектировании
• Адресация ключевых рисков, или Гордыня убивает
• Учитываем контекст, или Как не долбиться в закрытую дверь

Абстракции? Кому нужны абстракции?
EF наикрутейшая ORM от MS. habrahabr.ru/post/157267 это действительно круто. Разработать такую систему очень затратно по всем направлениям. CodeFirs вещь, знания проектирования БД, да какой там! Не нужны сами знания SQL – и это круто. Но так ли все радужно?
Julie Lerman может много рассказать msdn.microsoft.com/en-us/magazine/ff898427.aspx

Ничего не напоминает?