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

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

Недавно я столкнулся с проблемой коллизий имен из разных пространств имен. В C# есть возможность ввести синонимы для пространств имен, т.е. вместо использования полного имени класса ввести префикс, с помощью которого можно обращаться к данному пространству имен.

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

Мы часто экспериментируем с архитектурой, кодом, производительностью. Постоянно добавляем новый функционал. Мы постепенно обвязываем Yii своей “архитектурной” прослойкой — шардинг, работа с временно недоступными данными, разнообразные кеши и многое другое. Да, плод нашей работы, когда он будет заврешен, пойдет в Open Source.

Задача применяемой у нас Непрерывной Интеграции (Continuous Integration, CI) — не тестирование. Задача CI — обезопасится от разрушительных изменений в следствие рефакторинга, добавления нового функционала, изменений архитектуры. Также мы защищаемся от “плохого кода”, часто повторяющихся багов, “кривых” merge.

Для своего CI мы используем Jenkins под Debian. Время на развертку CI я затратил 12 часов — до полностью рабочего состояния. На поддержку CI я не трачу ни минуты в день — я не пишу тесты на каждую мелочь, не практикую TDD. Тем не менее, CI работает и спасает нас от глупых ошибок.

“Давайте будем внимательней”/”Давайте не делать ошибок” — взывал я к разработчикам, но это помогало лишь временно и то не на все 100%. Людям свойственно ошибаться, забывать, совершать оплошности. Нет, я не изобрел “серебряную пулю” для web-проектов и даже маленьку пульку для Yii — я придумал как стабилизировать свое приложение. Ваше приложение отличается от моего и мои методы у Вас могут не работать, да и не должны — я же делал их не для Вашего приложения, если мои методы работаю у Вас — примите это как чудо или как везение. Зато идея такого CI будет работать везде. Всего лишь идея.

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

Model-View в QML:

1. Model-View в QML. Часть нулевая, вводная
2. Model-View в QML. Часть первая: Представления на основе готовых компонентов
3. Model-View в QML. Часть вторая: Кастомные представления
4. Model-View в QML. Часть третья: Модели в QML и JavaScript
5. Model-View в QML. Часть четвертая: C++-модели

3. Прототипное наследование

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

Далее в игру вступает наследование. Оно лучше разделяет понятия, когда объекты наделяются своими методами на основе методов других объектов.

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

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

Привет, Хабр!

К сожалению, на данном этапе развития веб-программирования в нашей стране рефакторинг проекта чаще воспринимается как работа программиста в режиме «все плохо» и проводится только в тот момент, когда сайт уже находится в критическом состоянии. С подобной ситуацией нам пришлось столкнуться в 2012 году, когда к нам на обслуживание пришел один крупный российский интернет-магазин со следующей проблемой: начиная с 10 утра сайт каждые полчаса падал на 5-10 минут и поднимался или с большим трудом, или после жесткого ребута. После ребутов сайт немного работал, а затем падал опять. Особую остроту проблеме придавал тот факт, что приближался Новый год, высокий сезон для всех продающих сайтов, и в данном случае фраза «за 10 минут компания теряет десятки тысяч долларов» была не шуткой.

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

Было:

class Service {
  public void longJob(Object arg) {...}
}
...
Service s=new Service();
...

s.longJob(arg);

Стало:

class Service {
  public void longJob(Object arg) {...}
}
class ServiceWrapper extends Service {
...
}
...
Service s=new ServiceWrapper() ;
...

s.longJob(arg);

Введение

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



Я настроятельно рекомендую книгу Russ Olsen — Design Patterns in Ruby. Наш цикл постов будет черпать вдохновение оттуда и будет чем-то вроде краткой выжимки. Таким образом, если вам понравится то что вы читаете (а я надеюсь на это!), книга будет отличным продолжением.

Мы рассмотрим различные паттерны проектирования и научимся их применять. Сегодняшняя тема — Шаблоный метод, простейший паттерн проектирования.

При разработке/создании web-сайта, мобильного приложения, WEB-сервиса – иными словами Информационной системы (ИС) встает вопрос о требующих аппаратных ресурсах – количестве серверов (виртуальных машин).

Приведённая методика описывает расчет количества пользователей и «оборудования» для территории Российская федерация.

Исходные данные

• Веб сайт «Визитка»;
• WEB-сервис для мобильных приложений, работающий по протоколу http/https, взаимодействующий с Базой данных;
• База данных SQL (NOSQL);
• WEB-клиент – реализующий функционал мобильного приложения для web пользователей, также взаимодействующий с Базой данных.

Изменять код
В процессе разработки программного обеспечения нет такого понятия, как «стагнация». Все, что вы разрабатываете сейчас — просто очередная версия компонента, который вероятно будет меняться в будущем. Изменение является самым распространенным явлением в мире разработки программного обеспечения и вам лучше принять это как факт. Рассчитывайте на возможные изменения всего, что вы разрабатываете и поэтому проектируйте ваш код более модульным. Это упрощает изменения и в тоже время увеличивает качество кода. Старайтесь придерживаться концепций DRY и YAGNI. Вы часто будете в ситуации, когда вы смотрите на ваш код и представляете, что вы могли бы сделать это лучше. Так пусть эта мысль не мешает вам спать. Садитесь сразу за дело и рефакторинг! Если не сделаете это сейчас, вы возможно никогда этого не сделаете. Чем дольше ждете, тем сложнее и дороже это будет. И это может вырасти в лишнюю головную боль, с которой не захочется связываться.
«Хороший код — это код, который легко изменять. Код стремится измениться до момента, когда его уже не легко изменять. Весь код становится плохим кодом». Неизвестный автор.

Начиная с версии 5.4.0, в PHP появится новая конструкция языка — трейты (traits), реализующая возможность использования примеси (mix in). Механизм примесей является еще одним механизмом повторного использования кода и присутствует в том или ином виде в других языках, например, Ruby, Python, Common Lisp, etc.

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

Следует отметить, что реализации примесей в PHP существуют как минимум с версии 4.0.1, и в настоящее время присутствуют, чаще всего под именем behavior, в ряде популярных фреймворков, например, в Yii, Symfony, Doctrine, CakePhp, Propel.

Цель статьи — продемонстрировать и сравнить несколько основных подходов к реализации примесей в PHP до версии 5.4.0, базирующихся только лишь на функциях самого языка и не использующих сторонние расширения, как-то, например, функцию runkit_method_copy из PECL runkit.

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

Все основано на реальных событиях, но примеры были максимально упрощены, чтобы в них осталась лишь суть проблемы.

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

В этой части моего цикла статей про Model-View в QML мы начнем рассматривать представления и начнем с тех, которые делаются на основе готовых компонентов.

Model-View в QML:

1. Model-View в QML. Часть нулевая, вводная
2. Model-View в QML. Часть первая: Представления на основе готовых компонентов
3. Model-View в QML. Часть вторая: Кастомные представления
4. Model-View в QML. Часть третья: Модели в QML и JavaScript
5. Model-View в QML. Часть четвертая: C++-модели

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

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

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

Но при этом «быстро и просто» не значат «плохо».

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

И вот тут я хочу напомнить почему-то забываемый всеми момент.

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

Добрый день! Долго думал, писать пост или нет. Но буквально на днях появился утвержденный календарь ЧР по футболу 2013/2014, и вот под впечатлением сие текст…
Что мы видим, взглянув на расписание игр.
Тур 16: 2 ноября Краснодар-Кубань и Зенит — Амкар… Навскидку в Краснодаре +10, в СПб -5.
Тур 17: 9 ноября Урал-Ростов: в Екатеринбурге -10, в Ростове — на –Дону +10, Рубин – Краснодар, аналогично…
Также и 23, 30 ноября, 7 декабря, 8 марта, 15 марта, прогресс шагает семимильными шагами, но обходит руководителей российского футбола стороной… В тоже время в мае, июле, августе многие «северные» команды приезжают в гости на юг, в самую жару, для того чтобы получать «солнечные удары»…?! «Такой хоккей нам не нужен!»

Данный пост расскажет об уникальной фишке D — Voldemort типы. Типы, которые можно использовать, но нельзя назвать. Данное название не очень подходит им, но Walter Bright очень любит так их называть. Voldemort типы очень часто встречаются в стандартной библиотеке Phobos, особенно в модулях std.algorithm и std.array. Осваивающие D могут часами штудировать документацию в поисках типа, возвращаемого из splitter или joiner, а возвращают они именно Voldemort типы. После этого поста можно смело открывать исходники std.algorithm, ибо никакие Сами-Знаете-Кто вам будут не страшны.



Иногда, взаимодействие существующих возможностей может привести к неожиданным сюрпризам. Мне нравится считать, что мы изначально заложили Voldemort типы в D, но на самом деле они были найдены Андреем Александреску. Что это за Voldermort типы? Читайте дальше.

Одним из наиболее распространенных и эффективных приемов проектирования программ является использование шаблона программирования MVC (Model-View-Controller) — Модель-Представление-Контроль. MVC позволяет разделить части программы, отвечающие за хранение и доступ к данным, отображение данных и за взаимодействие с пользователем на отдельные слабо связанные модули. Подобное разделение ответственности упрощает структуру программы и позволяет вносить изменения в одну из этих частей не затрагивая остальные.

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

Model-View в QML:

1. Model-View в QML. Часть нулевая, вводная
2. Model-View в QML. Часть первая: Представления на основе готовых компонентов
3. Model-View в QML. Часть вторая: Кастомные представления
4. Model-View в QML. Часть третья: Модели в QML и JavaScript
5. Model-View в QML. Часть четвертая: C++-модели

Большинство фанатов ООП одновременно и фанаты полиморфизма. Многие хорошие книги (взять хотя бы «Рефакторинг» Фаулера) даже впадают в крайность и утверждают: если вы используете проверки типов во время выполнения (такие как операция instanceof в Java), то вы, скорее всего, в душе ужасный монстр. Из тех, что пугают маленьких детей операторами switch.

Вообще говоря, я признаю, что использование instanceof и его аналогов обычно является следствием недостаточных навыков ООП проектирования. Полиморфизм лучше проверок типов. Он делает код гибче и понятнее. Однако есть по крайней мере один распространенный случай, когда вы точно не сможете использовать полиморфизм. Причем случай этот распостранен настолько, что может уже считаться паттерном. Я бы с удовольствием применил в нем полиморфизм, честно. И если вы знаете как это сделать — расскажите мне. Но не думаю что это возможно. По крайней мере точно не в статических языках типа Java или C++.

Определение полиморфизма

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

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

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