Чувствуете ли вы себя игроком в Дженгу (игра, в которой игроки попеременно добавляют по одному элементу к возводимой конструкции, проигрывает тот, чье действие приведет к её разрушению), когда программируете? Насколько легко вносить изменения в ваши программные системы? Опасаетесь ли вы, что после внесения изменений ваш код неожиданно перестанет работать? Если вы утвердительно ответили на один из этих вопросов — это явный признак некачественно спроектированного кода, который приводит к замедлению вашей работу уже на следующий день после его появления. А приходилось ли вам когда нибудь разрабатывать код, который сложно было понять уже на следующий день? Мне посчастливилось присутствовать на многих презентациях Боба Мартина (Uncle Bob) и мне очень нравится та часть его выступления, где он спрашивает слушателей, сталкивались ли они с существенным замедлением скорости разработки из-за плохого кода. Когда большинство слушателей поднимали руки, он спрашивал: «Так зачем же вы его так написали?».

Прочитав хабратопик Столпы KDE4. Solid., я решил проверить, а так ли удобен этот фреймворк для разработчиков и что он собственно умеет?

 

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

 

Если вам интересны новинки, лучшие практики в разработке на NET и ASP .NET и просто общение с коллегами — все это сможете увидеть и услышать и активно принять участие во время Ciklum .Net Субботника, который состоится 12 ноября (уже в эту субботу) в минском офисе Ciklum.

Напомним, что в наших офисах как по всей Украине, так и в Беларуси постоянно проходят Ciklum Saturdays, собирающие разработчиков по различным технологиям

Обмен опытом, новинками, лучшими практиками и просто неформальное общение — становится все больше популярным. Так, недавно мы проводили .NET Субботник в Минске, а еще немного раньше в Киеве. В этот раз в Харькове 10 декабря на Ciklum .NET Субботник соберутся крутые подкастеры и спикеры по .NET с огромным опытом, которым всегда рады во всех городах Украины. Приглашаем всех, кому интересна разработка в .NET на мероприятие с уникальной возможностью посмотреть и послушать их всех в один день!

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

В этой короткой заметке я хотел бы систематизировать (а именно, расположить в иерархию) многие популярные принципы проектирования программных приложений (test-driven development, ООП, SOLID и т. д.), а также рассмотреть следствия из этой иерархии.

В частности, такая иерархия (я надеюсь) позволит лучше расставлять приоритеты в разработке и профессиональном росте, лучше понимать старые технологии и быстрее изучать новые. При появлении новой парадигмы разработки (a la test-driven development) вы сможете быстро включить ее в эту иерархию и, следовательно, быстрее понять, из каких принципов исходили создатели парадигмы и как правильно ее использовать. Новичкам в программировании статья может быть полезна как обзор существующих принципов.

И в качестве самого базового я полагаю разумным считать принцип «управления сложностью/минимизации технической сложности» МакКоннела. А самыми важными срествами минимизации сложности являются модульность и абстракция.

Тема SOLID-принципов и в целом чистоты кода не раз поднималась на Хабре и, возможно, уже порядком изъезженная. Но тем не менее, не так давно мне приходилось проходить собеседования в одну интересную IT-компанию, где меня попросили рассказать о принципах SOLID с примерами и ситуациями, когда я не соблюл эти принципы и к чему это привело. И в тот момент я понял, что на каком-то подсознательном уровне я понимаю эти принципы и даже могут назвать их все, но привести лаконичные и понятные примеры для меня стало проблемой. Поэтому я и решил для себя самого и для сообщества обобщить информацию по SOLID-принципам для ещё лучшего её понимания. Статья должна быть полезной, для людей только знакомящихся с SOLID-принципами, также, как и для людей «съевших собаку» на SOLID-принципах.

Для чего выдумывать все эти паттерны проектирования, принципы и методики? Разве не было бы проще обойтись без всего этого, а просто научить разработчиков хорошему дизайну? Или почему бы не формализовать этот процесс и ввести четкие количественные метрики, которые бы говорили, что одно решение однозначно лучше другого?

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

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

Эта статья — продолжение статьи C#: коллекции только для чтения и LSP. Сегодня мы посмотрим на интерфейс IEnumerable с точки зрения принципа подстановки Барбары Лисков (LSP), а также разберемся, нарушает ли этот принцип код, имплементирующий IEnumerable.

«Any magic, sufficiently analyzed is indistinguishable from technology.»

Артур Кларк
(эпиграф в официальной wiki проекта Typhoon Framework)

Цикл «Управляем зависимостями в iOS-приложениях правильно»

• Знакомство с Typhoon
• Устройство Typhoon
• Модульность Typhoon
• Typhoon Tips & Tricks
• Альтернативы Typhoon
• (Дополнительно) Rambler.iOS #3. Dependency Injection в iOS. Слайды
• (Дополнительно) Rambler.iOS #3. Dependency Injection в iOS. Видео

Введение

В рамках этого цикла статей я не буду углубляться в теорию, рассматривать Dependency Inversion Principle или паттерны Dependency Injection — примем за данность, что читатель уже достаточно подготовлен к тому, чтобы познать дзен, и перейдем сразу к практике (ссылки для знакомства с теорией даны в самом конце поста).

Typhoon Framework — это самая известная и популярная реализация DI-контейнера для Objective-C и Swift приложений. Проект достаточно молодой — первый коммит был сделан в самом конце 2012 года, но уже обзавелся большим количеством поклонников. Отдельного упоминания заслуживает активная поддержка проекта его создателями (один из которых, между прочим, живет и работает в Омске) — на большинство создаваемых Issue отвечают в течение десяти минут, а уже через несколько часов к обсуждению присоединяется вся команда.

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



Красноярск — далекий сибирский город и глухая it-провинция. Но 30 мая 2015 года нашей активности позавидуют соседи. В этот день состоится вторая конференция разработчиков программного обеспечения Dev2Dev, версия 2.0. Конференцию организует молодое одноименное it-сообщество, объединяющее спецов отрасли из компаний города. Нам менее года, но мы растем. С самого начала мы работали для того, чтобы в Красноярске наконец появилась круто сваренное местное событие с большой активной аудиторией и заезжими докладами.

Концепция событий сообщества Dev2Dev проста: свободный вход, качественный контент и много общения для участников и спикеров. Событие — это в первую очередь фан, знакомства и накачка энергией. Сильные доклады и интересные спикеры делают это возможным, но само событие создают участники. 30 мая мы ждем 200-250 человек. Новая конференция соберет доклады по enterprise разработке, функциональному программированию, проектированию, тестированию приложений, управлению проектами и командой. Докладчики едут со всей Сибири — Новосибирск, Омск, Кемерово. Специальный гость прилетит из Чикаго.

В прошлой части цикла мы познакомились с Dependency Injection фреймворком для iOS — Typhoon, и рассмотрели базовые примеры его использования в проекте Рамблер.Почта. В этот раз мы углубимся в изучение его внутреннего устройства.

Статья 1. Почему я не преподаю SOLID

Если вы разговариваете с кем-то, кому небезразлично качество кода, уже достаточно скоро в разговоре всплывёт SOLID — аббревиатура, помогающая разработчикам запомнить пять важных принципов объектно-ориентированного программирования:

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

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

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

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

У нас сотни программных проектов на поддержке, некоторые из них поддерживаются нами почти десять лет. Нетрудно догадаться, что понятие maintainable кода (переведу это понятие как код, легкий в поддержке) является у нас одним из основных. По счастливому стечению обстоятельств легкий в поддержке код также является и легким для (unit-)тестирования, легким для освоения новыми членами команды и т.д. Скорее всего, это связано с тем, что для создания maintainable кода приходится озаботиться хорошей архитектурой проекта и завести несколько хороших привычек.
В этой статье и поговорим о таких привычках, благодаря которым часто хорошая архитектура получается сама собой. Постараюсь также иллюстрировать все хорошими примерами.

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

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

В этой серии статей я соберу бОльшую часть своего опыта разработки на Ruby on Rails. Эти методики позволяют контролировать сложность и облегчают сопровождение проекта. Большинство из них придумал не я, и, по возможности, буду указывать источник.

Основная проблема проектов на RoR в том, что, как правило, всю логику пытаются уместить в модели, контроллеры и представления. Т.е. код находится только в моделях(ActiveRecord::Base), контроллерах, хэлперах и шаблонах. Такой подход приводит к печальным последствиям: код становится запутанным, долго делаются фичи, появляются регрессии, у разработчиков пропадает мотивация. В качестве примера можно посмотреть на исходники redmine.

Выход из данной ситуации довольно-таки очевидный. Будем делать проекты не на ruby on rails, а с использованием ruby on rails. Как это будет выглядеть: мы никуда не уходим от MVC и Rails, просто пересмотрим Model, View, Controller. Для начала расширим понятие модели. Модель — это не просто класс-наследник ORM. Модель — это вся бизнес логика приложения. Модель включает в себя: модели, сервисы, политики, репозитории, формы и другие элементы, которые я опишу далее. Так же расширим представления. Представления — это шаблоны, презентеры, хелперы, билдеры форм. Контроллеры — это все то, что связано с обработкой запросов: контроллеры, responders.