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

Свойства и законы. Сценарии. Inversion of Control в Haskell.

Совсем немного теории

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

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

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

В этой статье я попробую сам разобраться в себе и в своих аргументах. Для начала попробую оппонировать автору статьи, перевод которой нашел на хабре Где наша бизнес-логика, сынок?. Её писал такой же идеалист, которым я был еще лет 10 назад. Поэтому по сути в этой статье я буду спорить сам с собой. Дело в том, что чем больше приложений я разрабатываю тем больше красивые теории перестают вписываться в идеальные схемы. Идеальные схемы хороши тем, что они просты. Вас спрашивают где бизнес слой? И ты легко можешь сказать на стороне клиента или на стороне сервера. Если смешенно многозначительно крутят носом и говорят «гавно-код». С этим я не согласен. Реальный мир не вкладывается в идеалистические концепции, точнее его можно туда запихнуть, но мы от этого скорее потеряем. Поэтому вначале подсознательно я понимал, что есть разные случаи. А теперь все более пытаюсь сформулировать, что влияет на то или иное решение по размещению бизнес логики. Здесь мы оставим красивые теории без аргументации молодым утопистам желающим простых решений.

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

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

Когда в приложении происходит ошибка, есть два диаметрально противоположных подхода к обработке этой ошибки:
Forgive! подход: приложение продолжает выполняться и старается минимизировать последствия ошибки.
Fail Fast! подход: приложение немедленно прекращает работу и сообщает об ошибке.

• Какой из подходов лучше?
• Какой подход стоит реализовать в своем приложении?

Доброго времени суток, хабравчане!

Следующий пост является изложением моих размышлений на тему природы классов и АТД. Эти размышления дополнены интересными цитатами из книг гуру разработки программного обеспечения

Введение

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

В конце 2012 мы с ребятами собрались сделать сумасшедшую штуку – засунуть в браузер RAW конвертер, фотошоп и добавить туда возможность совместной работы над фотографиями. С технической стороны мы практически все проверили: технологии, которые позволяли все это воплотить, были сырыми, иногда требовали включения их в настройках браузера… но они были. Мы назвали это Pics.io и начали.

У нас была пачка прототипов/proof-of-concept, простыни кода с огромным количеством хардкодов. Мы решили, что нужно все это объединить в один большой продукт, который будет полностью покрывать рабочий процесс фотографа: придумали архитектуру, написали каркас, начали делать функциональность.

Ура! Мы закончили работу над переводом замечательной книги об архитектуре JavaScript-приложения. Работать над переводом было очень приятно — мы получили около 40 пулл-реквестов от совершенно незнакомых нам людей, которые помогли исправить множество опечаток, неточностей и различных багов на сайте! Ссылка на наш перевод упоминалась в курсе «Фронтенд-разработка», читаемом во втором семестре Технопарка Mail.ru, а также в некоторых независимых подкастах.

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

Читать книгу можно на сайте перевода. Также можно скачать книгу в удобном формате: epub, mobi, fb2. Исходный код проекта доступен в репозитории на GitHub

Восходящее проектирование в ФП. Идея — основа хорошего дизайна. Антипаттерны в Haskell.

Немного теории

В прошлой части мы построили высокоуровневую архитектуру приложения. Мы определили подсистемы и их связи, а также разделили программу на три слоя: Application, Game Logic, Views. По логике, следующий этап — дизайн приложения. По важности этот этап не уступает предыдущему, так как именно в ходе дизайна мы должны поддержать все функциональные требования, определить фактическую структуру подсистем, описать основные технические проблемы, применить какие-либо типовые решения или придумать другие. Но прежде попробуем ответить на вопрос: каков он, хороший дизайн ПО? По каким критериям мы определяем «хорошесть» дизайна?

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

CREATE TABLE object (
  id NUMBER(11),
  parent_id NUMBER(11),
  type VARCHAR2(16) NOT NULL,
  name VARCHAR2(255) NOT NULL,
  CONSTRAINT pk_object PRIMARY KEY (id),
  CONSTRAINT fk_object_parent FOREIGN KEY (parent_id) REFERENCES object (id) ON DELETE CASCADE ENABLE
);

Наполним её какими-нибудь данными:

id  |  parent_id  |  type     |  name
------------------------------------------------------
1   |  NULL       |  country  |  Россия
2   |  1          |  region   |  Московская область
3   |  1          |  region   |  Новосибирская область
4   |  2          |  city     |  Москва
5   |  3          |  city     |  Новосибирск

При этом мы можем легко одним запросом получать нужные нам связи:

-- Выбрать все города России
SELECT *
  FROM object
    WHERE type = 'city'
    START WITH id = 1 CONNECT BY PRIOR id = parent_id;

-- Выбрать страну, в которой находится Новосибирск
SELECT *
  FROM object
    WHERE type = 'country'
    START WITH id = 5 CONNECT BY PRIOR parent_id = id;

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

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

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

Как правило, это происходит из-за плохо спроектированной схемы – изначально не рассчитанной на оперирование большими объемами данных.

Чтобы рост данных в таблицах не приводил к падению производительности при работе с ними, рекомендуется взять на вооружение несколько правил при проектировании схемы.

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

В данной статье не будет рассуждений на следующие тематики:

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

Вводную часть начну с моего ограниченного понимания места архитектора в крупной компании.

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

Об авторе:
Pavel Fatin работает над Scala plugin'ом для IntelliJ IDEA в JetBrains.

Введение

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

Содержание статьи составляет основу моего выступления на JavaDay конференции (слайды презентации).

Изучая планы развития CMS Joomla, для написания одной из своих предыдущих статей (укр.), я наткнулся на аббревиатуру HMVC. Не сложно было понять, что это как-то связано со ставшим стандартом паттерном MVC. Найденная расшифровка: «HMVC — иерархические модель-вид-контроллер» — мало что объяснила. Дальнейшие поиски информации тоже дали не много, в основном теоретические рассуждения о паттерне и почти ничего о том, как же его использовать на практике. Однако немного поразмыслив, я понял, что уже использовал его в своем предыдущем проекте на Symfony 2. Более того, оказывается, что частично этот паттерн используют очень многие даже не догадываясь об этом.

Введение

В мире функционального программирования есть один большой пробел, а именно почти не освещена тема высокоуровневого дизайна больших приложений. Я решил для себя изучить этот вопрос. Есть ли существенные отличия дизайна приложений в ФП-мире от оного в мире императивном? Что такое «каноничный ФП-код»? Какие существуют идиомы разработки, есть ли смысл вообще говорить о паттернах проектирования в применении к ФП? Эти и другие важные вопросы часто вспыхивают то там, то здесь, но покамест мне не известно ни одной книги, аналогичной книге Банды Четырех. Вероятно, мои изыскания уже кто-то повторил, однако тем лучше: схожие результаты подтвердят правильность, иные — укажут на место в теории, которое необходимо доработать.

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

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

Совсем недавно cppcheck помог найти уязвимость в проекте Xorg, которая существовала там почти 23 года! Он помог уже тысячам программистов по всему миру, на официальном сайте можно найти информацию о найденных с помощью cppcheck уязвимостях в программах, и этот список постоянно растёт. Итак, если вы хотите знать, почему нужно использовать cppcheck всегда и везде — прошу под кат.

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

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

Сайт перевода
Репозиторий на GitHub

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

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

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