Skip to main content

Requirement of The Arhitect

– Proven experience as software architect
– Experience in software development and coding
– Excellent knowledge of software and application design and architecture
– Excellent knowledge of UML and other modeling methods
– Familiarity with UX/UI design
– Understanding of software quality assurance principles
– A techical mindset with great attention to detail
– High quality organizational and leadership skills
– Outstanding communication and presentation skills
– MSc/MA in computer science, engineering or relevant field

Responsibilities of The Architect

– Collaborate with team to draft functional and non-functional requirements
– Use tools and methodologies to create reprentation for functions and UIs
– Develop high-level product specification
– Define all aspects of development
– Communicate all concepts and guidelines to development team
– Oversee techical guidance and coaching to developers and engineers
– Ensure software meets all requirements
– Approve final product before launch

Responsibilities of Solution Architect

– Responsible for Technology
– Converts Functional Requirements to Technical Architecture
– Carefull balances Patterns/Requirements/Elegance/Concepts
– Researches Key Technologies
– Has deep understanding of Design Patterns
– Motivates and guides development team
– Ensures that the Lead Developer is successful

RxJS Essentials. Part 1: Basic terms

Today, I’m starting a series of articles about programming with reactive extensions. This series is about the JavaScript RxJS library, but in the future, I’m planning to write a similar series about the RxJava – one of the Java versions of reactive extensions.

The first library of reactive extensions (Rx) was created by Erik Mejier in 2009. Rx.Net meant to be used for the apps written with the Microsoft’s .Net technology. Then the Rx extensions were ported to multiple languages, and in the JavaScript world, RxJS 5 is the current version of this library.

Read More

Everest

— Джим, каково это – стоять на вершине Эвереста?
— Понимать, что полпути пройдено, — просто, не красуясь, отвечает он.

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

Мрачный Скрам

Давайте поговорим о так называемом «Мрачном Скраме». Слишком часто, по меньшей мере в разработке ПО, создаётся впечатление, что Скрам угнетает людей. Слишком часто Скрам не приносит результата так быстро, надёжно и постоянно, как должен был бы. В результате – все страдают. И  чаще всего сильнее чем все остальные страдают разработчики.

 

В последнее время я часто размышляю над следующим:

Мой первый aджальный ментор Кент Бек (Kent Beck) как-то раз сказал, что изобрёл Extreme Programming, чтобы сделать мир более безопасным для программистов. Получается, что мир всё ещё небезопасен для прграммистов. Цитируя Кена Швабера (Ken Schwaber), одного из соавторов Скрама, но в другом контексте: «Это меня огорчает».

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

 

К сожалению, так можно утверждать только о Скраме как концепции, Скраме как идеале, правильно реализованном Скраме. Как и с любой хорошей идеей, при реализации могут возникнуть сложности. Я называю такой результат « Мрачным Скрамом»*.

 

* Мне кажется, что это хорошее название для описания неправильных форм Скрама. Если вы согласны, предлагаю вам начать использовать этот термин. Если пожелаете, буду вам благодарен за указание моего авторства этого термина для описания важной темы в истории Agile и Scrum.

Мрачный Скрам: несколько типичных злоупотреблений Скрамом

Давайте рассмотрим, как всё может пойти под откос в Мрачном Скраме, совсем скоро после начала. В этой части статьи мы рассмотрим, как команда окажется в плену Мрачного Скрама. Намерения у лидеров, внедряющих Мрачный Скрам, добрые, они просто делают всё неправильно.

Самоорганизация — дело медленное

Очевидно, что для того, чтобы освоить Скрам, нужно время. В нём есть новые роли и активности. И, что особенно тяжело, он требует принятия новых ценностей. Нам предстоит дать возможность нашим девелоперам организоваться самим, чтобы выполнить работу. Легко созывать Скрам митинги и называть друг друга новыми Скрам ролями. Но по сути очень нелегко по-настоящему делать Скрам.

 

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

 

Очень часто современные носители власти* считают, что их работа заключается в определении того, что людям нужно делать, донесении это до исполнителей и слежении, чтобы люди это выполняли. Скрам же учит другому: объясните людям, что именно ожидается на выходе, а потом отойдите в сторону и дайте людям самостоятельно организоваться для выполнения поставленной цели.

 

* Я буду использовать собирательный термин «носители власти» или «власть имущие», чтобы описать людей, особенно в Мрачном Скраме, у которых есть какая-то власть над девелоперами или полномочия, которыми они активно пользуются. У всех этих людей добрые намерения. Однако, в Мрачном Скраме использование власти обычно ошибочно. И неважно, кто её применяет: тим лид, девелопмент менеджер, владелец продукта или даже Скрам-мастер. У всех этих людей есть полноправная роль в настоящем Скраме. В Мрачном Скраме они просто пока не нашли своё место.

 

Невозможно одномоментно переключить сознание людей на новую операционную парадигму Скрама. Людям нужно время, чтобы отучиться от старых подходов. Должно пройти время, чтобы научиться новым привычкам, время, чтобы научиться доверять команде – если можно выделить главный посыл этой статьи, то вот он. Для тех, кто попадёт на тренинг по Скраму, обучение Скраму является началом процесса обучения доверию к команде.

 

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

Отлично, мы можем помогать команде каждый день!

Ежедневно команда должна собираться и планировать свою работу на день. Эта практика (Daily Scrum) навязывается любой команде. Возможно, в комнате есть один человек — Скрам-мастер — которому рассказали, как эту встречу нужно проводить. Программистам ничего не рассказывали. Довольно часто даже Владельцу Продукта тоже ничего не рассказали. И почти наверняка ничего не рассказали никому из власть имущих в компании.

 

Но носители власти уже знают, как выполнять свою работу. Их задача: быть в курсе всего, что делают другие люди; следить, чтобы они делали именно то, что нужно; а также направлять тех, кто делает не то. Как удобно, что каждый день есть обязательная для всех встреча, на которой они, собственно, и будут солировать!

 

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

 

Мрачный Скрам угнетает команду каждый день. Самоорганизации неоткуда появиться.

У нас также есть удобное частое планирование!

Каждый спринт Владелец Продукта в Скраме, по идее, должен встречаться с командой, чтобы рассказать, что нужно бизнесу. Команда, в свою очередь, прикидывает, что они могут сделать, чтобы удовлетворить запрос, и приступает к разработке. Ну, по крайней мере так должно быть в теории. На практике же, может случиться, что нет Владельца Продукта от бизнеса, а, если и есть, то этот человек не научен, как исполнять эту роль*.

 

* На сентябрь 2016 в мире насчитывается около 388,000 сертифицированных Scrum-мастеров, 82,000 сертифицированных Scrum Владельцев Проукта, что означает, что порядка 80% команд работают без владельца продукта, который прошёл обучение. Эти данные также говорят о том, что порядка двух миллионов программистов работают “под началом” этих Скрам-мастеров. В мире сейчас от 10 до 15 миллионов профессиональных программистов. Нам предстоит ещё долгий путь, чтобы все они могли работать в безопасной среде.

 

Что же, возможно, власть имущие и только начинали разбираться в Скраме, но они точно знают много о том, как решать такую проблему. Каждые пару недель они приходят и рассказывают программистам, что им нужно разработать. О, эти программисты будут возражать! Они ленивые и с гонором. Но власть имущие не поддадутся и будут давить дальше, ведь именно так и нужно управлять людьми. Итак, они говорят команде, что нужно сделать и лучше бы тем подчиниться.

 

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

 

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

 

В конце спринта результаты не будут соответствовать изначальным запросам. Чуда опять не произошло. Разработчики опять облажались. К счастью, у нас есть отличная возможность их исправить — Sprint Review!

Критикуй всё: и то, что было сделано, и то, что не было!

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

 

На практике мрачного Sprint Review начинается с того, что кто-то напоминает всем об «обещаниях» команды. (Имеется в виду то, что требовалось от команды перед тем, как они ответили: «Мы постараемся». Это же обещание, да?) После мы переходим к рассмотрению жалкой картины, которую принесла команда.

 

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

 

Они не оправдали ожиданий, а то, чего они успели сделать – сделано неудовлетворительно. Команда залажалась. Опять.

 

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

Мы расскажем им, как стать лучше…

По идее, на ретроспективе спринта команда рассматривает предыдущий спринт и учитывает весь накопленный ранее опыт. Они отмечают, что вышло хорошо, а что — не очень. Они думают над тем, как улучшить процесс на будущее.

 

На практике, лидеры Мрачного Скрама придут и здесь на помощь. Они напомнят команде обо всех неудачах, и неважно, что сами микро-менеджерили команду весь спринт. Лидеры постараются донести до разработчиков, что их неудача — а это несомненно неудача — наступила исключительно из-за их лени и некомпетентности.

 

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

 

Иногда команда выступает с какими-то предложениями. Позвольте мне подготовить всех нас – лидеров Мрачного Скрама к работе с возражениями команды. Ниже приведены часто встречающие предложения от команд, а также наши аргументированные ответы на них:

 

— Разработчики: Нам нужно больше тестов, чтобы снизить количество багов.

— Власть имущий: Нет. Вы и так уже не успеваете выпускать фичи. Вам нужно писать код лучше. Прекратите вписывать в код баги, тогда вам не придётся от них избавляться. Нам нужны фичи, а не тесты!

 

— Разработчики: Архитектура становится неработоспособной. Нам нужен рефакторинг, чтобы её улучшить.

— Власть имущий: Нет. Зачем вы изначально сделали такой плохой дизайн? Никто не говорил вам делать плохой дизайн. Прекратите делать плохой дизайн и исправьте то, что не работает. Скоро выходные, как раз всё и исправите.

 

— Разработчики:  Требования нечёткие. Нам никто их не объясняет, поэтому то, что мы делаем, не принимается в последнюю минуту.

— Власть имущий:  Мы наняли вас, потому что вы умные и можете сами разобраться. Вы должны самоорганизоваться и решить эти проблемы самостоятельно. Хватит рассиживаться и ныть, делайте то, что мы просим!

 

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

У… это печально

Безусловно, Скрам пытается это всё поменять. Но пока не поменяется содержимое голов и сердец в организации, слишком часто будут случаться приступы менеджмента «старой школы»: сейчас это случается каждые пару недель, а зачастую даже и каждый день!

Так а что же делать нам, девелоперам?

Вещи, которые случаются в Мрачном Скраме — это злоупотребления властью, противоположные тому, чему Скрам пытается нас научить. Ни один эксперт по Скраму в здравом уме не предложит вам их использовать. Люди, которые практикуют подобное, делают всё неправильно. И тут не может быть альтернативных мнений. Я считаю, что злоупортеблений не избежать, если люди действительно не поймут принципы и ценности Скрама.

 

Может показаться, что команде разработки не остаётся ничего кроме как смириться с неизбежным угнетением. К счастью, это не так. Хорошо, что в наших руках есть очень мощное оружие. Плохо, что сделать это непросто. Но, опять же, хорошо, что в основном нужно будет программировать, а это мы делать умеем.

 

Основной причиной давления со стороны Владельца Продукта и/или других носителей власти является то, что они не видят чётко, над чем мы работаем, что конкретно мы делаем. Если мы сможем наглядно показать наш кристально-чистый (извините за каламбур – здесь не имеется в виду agile-метод “crystal”) прогресс, мы можем изменить отношение к нам.

  • Если в продукте имеется много известных дефектов, руководство испугается, что их там на самом деле ещё больше. Из-за страха они станут давить ещё сильнее. А так как страх часто сопряжён со злостью, они будут злиться на нас. Как показывает жизнь, очень сильно злиться.
  • Если мы примемся за разработку дизайна и инфраструктуры перед тем, как начнём разрабатывать фичи, сложится ощущения, что мы затягиваем выпуск продукта. Это поселит страх среди руководства, что мы опоздаем к релизу или вообще его зафейлим. Опять же, весь страх и злость будут направлены на нас.
  • Если мы замедлимся из-за того, что не успеваем с архитектурой, мы будем выпускать меньше фич. Меньше фич, больше страха, больше злости, больше давления.

Когда руководство не видит работающего ПО, они начинают беспокоиться о будущем — и небезосновательно. Они проявляют свой страх неконструктивно и, безусловно, это неприятно. Но разработчики могут это прекратить. Я знаю только один путь — выпускайте ПО. Настоящее, работающее, “задеплоенное”  ПО. И с внятными фичами!

Сила инкремента

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

 

Большая часть страха улетучится сама собой, потому что руководство увидит реальные результаты. Однако, часть страха останется, потому что реальные результаты будут несколько отставать от надежд и мечтаний. Все мечтают о спортивной машине, но иногда нам достаётся только велосипед. Возможно мечты были о пони, но подарили тебе кошку, даже не собаку – её-то хоть можно было бы уважать. (Что-то я отвлёкся.)

 

Всё же, имея на руках полноценный, протестированный, интегрированный инкремент продукта с основными фичами, которые просили сделать, тон разговора изменить проще:

 

— Власть имущие: Вы мало делаете, вы должны делать больше.

 

— Разработчики: Мы делаем всё, что можем. И мы стараемся совершенствоваться. Что же касается продукта: всё, что в нём есть работает и всем можно пользоваться. Будет также мудро использовать для планирования и прогнозирования нашу реальную скорость разработки. Также логично было бы работать сначала над самыми приоритетными элементами беклога. Давайте попробуем их чуть облегчить и уменьшить, чтобы выпускать самое важное ещё быстрее.

 

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

 

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

Но есть загвоздка

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

 

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

 

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

Приёмочное тестирование

Довольно часто в конце спринта идут бурные осуждения, разработала ли команда именно то, что «хотел» Владелец Продукта. Эти обсуждения обычно бесполезны и разводят Владельца Продукта и разработчиков по разные стороны баррикад. Мы же хотим, чтобы они активно работали вместе, а не воевали.

 

Очень важной практикой для Владельцев Продуктов и разработчкиов является согласование конкретных и исполняемых приёмочных тестов для каждой истории. Полезно о них думать, как о «примерах».

 

— Команда: OK, мы хотим, чтобы система показывала всех клиентов с задолженностью в 30 дней, а также общую сумму задолженности. Вот список с клиентами, попадающих под этот критерий, с указанием суммы.
— PO: Нет, это не совсем так. Мы не хотим видеть клиентов с  задолженность в 30 дней, только больше 30.

— Команда: OK, вот так?
— PO:  Точно! Дерзайте!

 

Каждый маленький пример станет приёмочным тестом для истории или элемента беклога, о котором идёт речь. Договоритесь, что, пока история не протестирована, она не считается законченной. В противовес этому, если тестирование было произведено, Владелец Продукта и команда соглашаются, что было сделано то, что просили.

 

Вполне вероятно, что Владельцу Продукта не понравится результат. Но риторика уже изменилась. Владелец Продукта не может просто сказать: «Это не то, что я хотел!». Это именно то, что он хотел, когда соглашался. Скорее всего он узнал что-то новое и теперь хочет что-то другое. И это хорошо, потому что задачей Владельца Продукта является создание наилучшего продукта. Совместная работа над конкретными приёмочными тестами помогает нам понять, что именно требуется, когда мы этого достигли, а также совершенствует наше понимание изменений и учит правильно составлять запросы на изменения.

 

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

Инкрементальный дизайн архитектуры

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

 

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

 

«Просто» — самое опасное слово в разработке ПО*. Разрабатывать архитектуру во время разработки не просто, это требует мастерства в дизайне, тестировании и рефакторинге. Мы рассмотрим их вкратце ниже и также в других статьях.

 

Почитайте ещё об опасных выраженях при разработке ПО.

 

Но непреложная истина остаётся неизменной: если мы хотим выпускать инкремент продукта каждый спринт, нам нужно научиться делать хороший дизайн архитектуры инкрементально.

Рефакторинг

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

 

Рефакторить не значит переписывать. Безусловно, если у программы плохой дизайн архитектуры, мы можем написать новую программу, используя лучшую идею дизайна. И, пожалуй, я мог бы вам сказать: «просто написать», так как такой трюк редко работает, скажем так: в теории это можно было бы сделать. Но это заняло много времени, которого в Скраме у нас нет. Так что вместо переписывания нам нужен улучшенный дизайн до конца спринта.

 

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

 

Если мы сможем правильно пользоваться рефакторингом, мы будем инкрементально улучшать наш дизайн по ходу разработки. Ударение на слово «правильно», именно этому нам придётся научиться.

 

Улучшение инкрементального дизайна необходимо. Рефакторинг — это то, как мы этого добиваемся.

Тестирование программистом

Помимо приёмочного тестирования, нам нужны тесты, которые нужна автоматические тесты кода, которые будут писать разработчики.  Каждая фича, которую мы разрабатываем, состоит из множества шагов программирования. Мы можем допустить ошибку в любом из них. Хорошим примером автоматизации тестирования является разработка через тестирование (Test-Driven Development, TDD), которая проходит следующим образом:

  1. Подумайте о следующем маленьком шаге на пути к нашей фиче. Напишите тест, который должен проходить, когда этот шаг реализован.
    Удостоверьтесь, что тест не работает (красный).
  2. Напишите код, чтобы реализовать этот шаг.
    Удостоверьтесь, что тест работает (зелёный).
  3. Проверьте, что код читаем и чист. Если нет, проведите рефакторинг.
    Запустите тест ещё раз, чтобы удостовериться, что он всё ещё работает (зелёный).
  4. Повторяйте пока не закончите фичу.

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

 

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

Непрерывная интеграция (CI)

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

 

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

 

Итак, мы пришли к тому, что автоматизация сборки с прогоном всего набора тестов, является неотъемлемой частью процесса разработки любой Скрам команды. В большинстве случаев, чем чаще команда готовит билд, тем лучше для проекта. А ещё лучше проводить сборку «постоянно», именно поэтому эта практика и называется Непрерывной Интеграцией.

Как пережить времена Мрачного Скрама?

  • Существует распространённый, возможно неизбежный этап Мрачного Скрама на пути внедрения Скрама
  • Все случаи Мрачного Скрама неуникальны, обычно они развиваются по одинаковому сценарию
  • Команда разработки может улучшить ситуацию для себя и помочь организации перейти от этапа Тёмного Скрама к Скраму Реальному – более счастливому месту для существования.

source

Integration Spaghetti

I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”.

(A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.)

In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ :

Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disaster – both in terms of the time and people required to resolve it and in the business impact of it.

Even as the spaghetti bound application is nearly impossible to replace, as the current state continues it continues to grow worse as additional connections are made to these key applications and derivative copies of the data are taken from it, or clones created to avoid it (and thereby creating another synchronization and connection point).

Such spaghetti takes multiple forms but often involves ALL forms with multiple generations of technology connections, including excessive point to point connections, tightly coupled connection technologies, database triggers, business logic embedded in EAI process steps, many batches in and out from and to many destinations, ETL loads and extracts to/from other databases, multiple services providing nearly (but not exactly) identical data sets, and the involvement of many message queues.

Anything is done to avoid dealing with the giant plate of spaghetti.

Systems will integrate with systems that integrate with it, piggybacking existing connectivity and putting a burden on the subsidiary system, to avoid directly connecting into the spaghetti.  They’ll go to a secondary or tertiary data source to avoid going direct.  Everyone knows avoid the spaghetti if at all possible and will spend double to triple the integration effort to do so.

If the primary system is replaced, it’s not unusual that the new system won’t be integrated into all the old connections – this would require actually understanding each existing connecting, extracting it and redirecting/reconnecting it to the new system – rather the OLD SYSTEM will stay around to act as the connection point for all the existing spaghetti connections and the new system will become an integration, taking data feeds or a regular ETL load, off the old system!  Meaning the old system lives forever!

Does this problem every get resolved?  Yes.  When the other side of the connections gets replaced, the new systems on that side will be integrated with what replaced the core spaghetti bound system.  If the IT shop is lucky after a generation or so the spaghetti bound system can be shut down.

Unfortunately in major Enterprise IT shops finding some spaghetti integrations is not unusual.  IT management is loathe to acknowledge such a problem to the business and will continue work-arounds until it directly impacts business goals.  Otherwise it remains just another hidden IT enterprise IT expense.

source

 

Untitled

«– Слушай, это элементарно. Берешь с собой все свое и уносишь. Что не можешь унести – уничтожаешь. Но чтобы ничего твоего там не осталось. Вдруг ты завтра умрешь? Хочешь, чтобы твою чашку обвязали траурной ленточкой и выставили на всеобщее обозрение с гнусной надписью: «Мы помним тебя, о, заблудший брат наш»?» Шакал Табаки

Angular Production Builds

In this article I will discuss some of the alternatives for preparing an Angular application for production. I will look at several different approaches, and highlight the pros and cons.

I hope you will read the rest of the article, but In case you are a TLDR person, I will give you the results of this experiment right away.

The following table shows load times and bundle sizes for the different bundling approaches I will discuss in this article.

Bundler Bundle size (kb) Load time (seconds)
JiT SystemJS N/A 6
JiT SystemJS-builder 260 2
AoT Rollup 147 1.3
AoT Webpack no lazy loading 151 1.3
AoT Closure Compiler 97.4 1
AoT Webpack with lazy loading 104 1

When looking at static assets, the most important performance factors in Angular applications are compilation and bundling.

Compilation

Compilation in Angular refers to converting Angular specific syntax to plain JavaScript that the browser can understand. Think conversion of template syntax like ngFor, ngIf, etc to plain JavaScript.

Compilation comes in two different flavors; JiT (Just in time) and AoT (Ahead of time).

The difference between JiT and AoT is not related to what happens, but when it happens.

JiT compilation takes place in the browser, after the application has been downloaded. This means we have to do extra processing before the application can render. It also means we have to ship a compiler with our application runtime.

AoT addresses these issues by doing compilation at build-time. Not only does this remove runtime compilation, but equally important, we no longer have to include the compiler with the Angular runtime. This significantly reduces the size of the bundle since the compiler is a big dependency.

JiT is not really an option for production applications, but I am including a few JiT examples since it gives us a low end baseline to compare against.

The demo application we will use is a medium size application, consisting of a collection of some of my Angular samples.

Angular performance is mainly an issue on mobile devices, so for this demo, I will be using throttled “Good 3G” in Chrome to simulate a slow device.

To keep it simple, all reported load times are from the “Finish” value on Chrome’s network tab.

However, I have deployed versions of all samples, so feel free to try out different metrics as well.

JiT

As a low end baseline I have deployed the application as a standard JiT application.

The application is deployed here.

As you can tell, there is a very noticeable lag before we see the fully rendered application. If you open the browser’s network tab, you will see why.

The application makes 163 requests and takes about 6 seconds to fully load. This is way too slow by any standard.

JiT With Bundling

As I noted above, one of several problems with the JiT build is that it makes 163 individual requests to just load the application.

Let’s remove this issue by adding bundling with minification to the JiT build.

I have deployed this version here.

I am using a tool called SystemJS-Builder to do the bundling. SystemJS-Builder is a tool in the SystemJS family, but it’s a separate tool from the SystemJS module loader.

As you can tell, this results in noticeable improvement. We are no longer making 163 requests, and minification reduces the payload significantly (260kb). Still, the total time to load is more than 2 seconds.

Much better, but still a very noticeable rendering lag.

AoT

We have now taken the JiT build pretty much as far as we can take it. Unfortunately, performance is still not acceptable.

Luckily we are not out of aces. We can still improve performance by switching to AoT and more optimized JavaScript bundling.

Next we will look at more realistic production alternatives and see how they improve performance.

Bundling

AoT offers clear performance benefits, but there are important bundling considerations as well.

Rollup

In the JiT build I was transpiling to CommonJS modules. CommonJS is flexible, but it’s not a format optimized for bundling. Instead we should be using ES2105 modules.

ES2015 modules are much better suited for a technique called Tree shaking.

Tree shaking is the process of walking the trail of import and export statements in the application code.

Rollup offers a great implementation of Tree shaking, so it has become a very popular choice for application bundling.

I have deployed the Rollup version of the application here.

As you can tell, the Rollup version is much faster than the JiT builds. The load time is reduced to roughly 1.3 seconds and the bundle size is 147kb. This is a 43% reduction from the bundled JiT demo. The decrease comes from a combination of not including the compiler and enabling Tree shaking.

Webpack (no lazy loading)

Next we will repeat the experiment using Webpack as the bundler. Webpack is another popular bundler, but the approach is slightly different from Rollup.

Webpack will always produce bigger bundles than Rollup. This is a result of how Webpack wraps included modules in an internal module system. This means more overhead in the bundle from extra function wrappers.

Webpack does not support Tree shaking, so you will miss out on any opportunities to Tree shake as well. There is some confusion about Webpack and Tree shaking, but I have an article here that might help clear it up.

I have deployed the Webpack demo here.

As you can tell, the performance of the Webpack bundle is comparable to Rollup. We see a slightly bigger bundle (151k ~2.7% increase).

A difference of 4k is not really noteworthy, but Webpack bundles will always be bigger due to the extra overhead.

It’s also worth noting that the NgModule architecture in Angular is an hurdle to Tree shaking in Angular. This is likely one of the reasons we don’t see a bigger difference between Rollup and Webpack here.

I have more information bout this here, but basically the configuration arrays (declaration, providers, etc) in NgModules squander some Tree shaking opportunities.

You will also see an increase in Webpack bundle size if your code exports multiple classes from the same file. This is the worst use case for Webpack since it can’t Tree shake out unused exported classes.

Closure Compiler

The results so far have been pretty good, but there is still room for improvement.

Webpack and Rollup are both traditional bundlers. They offer very little in the way of code optimization beyond Tree shaking (Rollup) and minfication.

For more aggressive optimizations we can add the Closure compiler.

The main difference is that the Closure compiler will run a much deeper analysis of the application. It can drastically improve the bundle size through function inlining, function flattening, and other code removal approaches. This is much more effective than minifcation, which we will see from the Closure compiled bundle.

You can check out the application here.

As you can see, the Closure bundle is only 97.4kb. This is 35% smaller than Webpack, so pretty impressive! The total load time is about 1 second.

Closure compiler is amazing, but the aggressive optimizations come at a cost. The compiler makes several assumptions about your code. Unless you make sure your code is compatible with Closure, your application will likely break.

This has been made a little easier with Angular and its custom Typescript compiler though. Via the Angular Typescript compiler, certain conventions are ensured to make the code more compatible with Closure.

Webpack (with lazy loading)

So far we have only discussed single bundle applications. As the application grows, it may be impractical to serve the entire application as a single JavaScript bundle.

This is where Webpack offers more flexibility than most other alternatives. Webpack supports splitting the application into multiple files. This is perfect in cases where you use a router since you can create a bundle per route. This gives you lazy loading in its true sense.

In my final example I have converted the demo application to separate bundles per route.

You can see the result here.

As you can tell, separate bundles are loaded on demand as you navigate through the application. In addition to route specific bundles there is a “shared” bundle. The shared bundle is 101kb. The default route adds a 3.1kb bundle to the initial pay load.

Given that the total is only 104kb for the initial load, we are very close to the results from the Closure compiler sample. The load time is pretty similar as well – just over one second.

The key here is to spread the load across multiple requests instead of a single mother load. It doesn’t really matter that the sum of all the bundles exceed the size of the single Closure bundle. By loading small and fast bundles on demand, the application will be perceived as very fast.

I should mention that lazy loading is in theory possible with the Closure compiler as well, but it’s non trivial to set it up at the time of writing. Once we have lazy loading added to a Closure build, we can expect even better results though.

All the samples for this article can be found here.

(c) Torgeir Helgevold