Хабрахабр / Проектирование и рефакторинг / Захабренные http://habrahabr.ru/rss/blog/refactoring/ ru editor@habrahabr.ru habrahabr.ru Sat, 11 Feb 2012 11:20:21 GMT http://habrahabr.ru/ http://habrahabr.ru/i/logo.gif Хабрахабр <![CDATA[Проектирование и рефакторинг / [Перевод] Прагматичный подход к производительности]]> http://habrahabr.ru/blogs/refactoring/135484/ http://habrahabr.ru/blogs/refactoring/135484/
Эти вопросы не имеют четких ответов, тем не менее, в этой статье я постараюсь описать мой собственный подход к производительности. Что я делаю для того, чтобы мои системы работали с приличной скоростью, но не нарушали прочих требований, таких как модульность, сопровождаемость и гибкость.
Читать дальше →
]]> Thu, 29 Dec 2011 09:13:35 GMT unconnected оптимизация кодаразработка игрпрофилирование <![CDATA[Проектирование и рефакторинг / Объектно-ориентированная разработка инсталлятора Gin]]> http://habrahabr.ru/blogs/refactoring/135310/ http://habrahabr.ru/blogs/refactoring/135310/ Ссылка на первую часть
Ссылка на вторую часть
Ссылка на третью часть

Ввод данных



Любой инсталлятор должен давать пользователю возможность вводить некоторые стартовый параметры, например, путь к папке, куда будет инсталлирована программа, строка подключения к базе данных, и т.д. Причем, хотелось бы, чтобы это были не просто текстовые поля, а поля, дающие возможность удобного вода данных. Если это путь установки программы, то помимо текстового поля должна быть кнопка «Browse…», если это строка подключения к БД, то пусть рядом будет кнопка для выбора или создания источника данных и т.д.
Читать дальше →
]]> Mon, 26 Dec 2011 11:09:17 GMT vgrinin ООПпроектированиерефакторингразработкаинсталлятор <![CDATA[Проектирование и рефакторинг / Объектно-ориентированная разработка инсталлятора Gin]]> http://habrahabr.ru/blogs/refactoring/134876/ http://habrahabr.ru/blogs/refactoring/134876/ Ссылка на первую часть
Ссылка на вторую часть

Контентные и контейнерные команды


Некоторые команды подразумевают работу с файлами, изначально хранимыми на компьютере разработчика пакета. Понятно, что эти файлы нужно вместе с пакетом (а желательно, прямо внутри пакета) доставить к потребителю пакета. Попробуем для начала представить себе как это будет работать.
У нас есть экземпляр класса PackageBuilder, которому при конструировании мы указываем аргумент PackageBody, содержащий в себе, помимо всего прочего, команду Command, которая представляет собой корневой узел дерева команд пакета. Метод SaveResult() экземпляра класса PackageBuilder должен рекурсивно обойти все дерево, и для тех команд, которые используют контентные файлы, расположенные на компьютере разработчика, включить в тело пакета содержимое всех этих файлов. В тело пакета он также должен включить xml-файл, в который будет сериализован сам PackageBody с полным описанием пакета и выполняемых им команд.
Читать дальше →
]]> Mon, 19 Dec 2011 12:17:39 GMT vgrinin ООПпроектированиерефакторингразработкаинсталляторконтейнер <![CDATA[Проектирование и рефакторинг / Объектно-ориентированная разработка инсталлятора Gin]]> http://habrahabr.ru/blogs/refactoring/134512/ http://habrahabr.ru/blogs/refactoring/134512/ Ссылка на первую часть

Транзакции.


Напомню, что я собирался реализовать механизм транзакций, позволяющий откатывать блоки операций при возникновении ошибки внутри блока, защищенного транзакцией. Сначала надо решить вопрос с ответственностью за сохранение состояния и за откат операции. Скажу сразу, что архитектура, которую я приведу ниже вырисовалась у меня не сразу, а только после нескольких попыток проектирования и реализации макета, пока у меня не получилось то, что получилось.
Для того, чтобы архитектура транзакций была легко наращиваемой, воспользуемся как и ранее наследованием. При этом возложим ответственность за сохранение состояние и откат к сохраненному состоянию на саму команду. Учтем при этом, что не все команды являются по сути транзакционными. Например, чтение из реестра не может быть частью транзакции, потому что оно ничего не изменяет в системе. А вот запись в реестр – это уже часть транзакции. И создание файла – это часть транзакции.
А поэтому объявим еще один абстрактный класс TransactionalCommand, унаследуем его от класса Command.
Читать дальше →
]]> Wed, 14 Dec 2011 05:44:31 GMT vgrinin ООПпроектированиерефакторингразработкаинсталлятортранзакции <![CDATA[Проектирование и рефакторинг / [Из песочницы] Объектно-ориентированная разработка инсталлятора Gin]]> http://habrahabr.ru/blogs/refactoring/134439/ http://habrahabr.ru/blogs/refactoring/134439/ Введение
У предлагаемого вашему вниманию цикла статей есть несколько основных целей:
  1. Создать полезное программное обеспечение – инсталлятор программ и обновлений.
  2. Показать преимущества объектно-ориентированного подхода к разработке ПО и научить создавать легко расширяемые программные архитектуры.

В данном цикле статей я хочу поделиться историей создания программного обеспечения, позволяющего производить установку и обновление программных продуктов компании при помощи пакетов. Необходимость создания собственного инсталлятора(с отказом от использования готовых решений) вызвана специфичностью требований к инсталлятору. Я не буду углубляться в обоснование необходимости разработки, так как тема цикла статей другая.
Основными требованиями к разрабатываемой архитектуре будут:
  1. Реализация механизма транзакций, причем транзакции могут включать в себя не только SQL-транзакции, но и файловые, а также транзакции, связанные с изменением любых других ресурсов ОС, таких как записи в реестре, изменения конфигурационных файлов и т.д.
  2. Расширяемость операционной базы инсталлятора, то есть, добавление новых типов команд(операций), как с поддержкой транзакций, так и без нее.

Читать дальше →
]]> Mon, 12 Dec 2011 10:12:30 GMT vgrinin ООПпроектированиерефакторингразработкаинсталлятор <![CDATA[Проектирование и рефакторинг / Идеальная архитектура]]> http://habrahabr.ru/blogs/refactoring/133287/ http://habrahabr.ru/blogs/refactoring/133287/
Другие, наоборот, считают, что «думать уже поздно» и давным-давно пора «делать», поэтому они кидаются на баррикады с криками «Ура», выдавая на гора тонны никому не нужного кода. Как и любая крайность, такой подход не приводит ни к чему хорошему. Но, как и во многих других случаях, существует промежуточный вариант, когда проектированию и архитектуре уделяется должное внимание, когда они не ставятся во главу угла, а используются для выявления правильных абстракций и поиска компромиссов в противоречивых требованиях заказчика.

Читать дальше →
]]> Wed, 23 Nov 2011 21:01:43 GMT SergeyT принципы проектированияархитектура приложений <![CDATA[Проектирование и рефакторинг / Библия проектирования. Часть вторая. Костыли, изгнание из рая, Каин, Авель, и снова с чистого листа]]> http://habrahabr.ru/blogs/refactoring/132254/ http://habrahabr.ru/blogs/refactoring/132254/

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

Из последних сил и отбросив такт, ты начинаешь свой рассказ.

Читать дальше →
]]> Wed, 09 Nov 2011 14:04:15 GMT crmMaster речьпрограммистышоковая терапия <![CDATA[Проектирование и рефакторинг / Библия проектирования. Часть первая. Создание мира]]> http://habrahabr.ru/blogs/refactoring/132179/ http://habrahabr.ru/blogs/refactoring/132179/

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

Читать дальше →
]]> Tue, 08 Nov 2011 16:35:24 GMT crmMaster проектированиесистемамир <![CDATA[Проектирование и рефакторинг / [Из песочницы] Нормализация отношений. Первая и вторая нормальные формы]]> http://habrahabr.ru/blogs/refactoring/129195/ http://habrahabr.ru/blogs/refactoring/129195/ Предисловие
Нормализация отношений (таблиц) — одна из основополагающих частей теории реляционных баз данных. Нормализация имеет своей целью избавиться от избыточности в отношениях и модифицировать их структуру таким образом, чтобы процесс работы с ними не был обременён различными посторонними сложностями. При игнорировании такого подхода эффективность проектирования стремительно снижается, что вкупе с прочими подобными вольностями может привести к критическим последствиям.

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

Статья не имеет своей целью подробное и точное изложение принципов нормализациии, поскольку это, очевидно, невозможно в рамках блога в силу больших объёмов информации, необходимых для публикации при таком подходе. Кроме этого, для такой цели существует большое количество литературы, написанной прекрасными специалистами. Моя же задача, как я считаю, заключается в том, чтобы популярно продемонстрировать и объяснить основные принципы.
Читать дальше →
]]> Mon, 26 Sep 2011 18:59:00 GMT ngfrolov реляционные базы данныхнормализация отношенийнормальные формыпервая нормальная форма1НФвторая нормальная форма2НФ <![CDATA[Проектирование и рефакторинг / Принцип самурая]]> http://habrahabr.ru/blogs/refactoring/128397/ http://habrahabr.ru/blogs/refactoring/128397/
Еще одной метафорой, или скорее принципом разработки, является «принцип самурая», призванный описать «контракт» между функцией и вызывающим ее кодом и заключается в следующем. Любая функция, реализующая некоторую единицу работы должна следовать тому же кодексу чести «бусидо», по которому живет любой самурай. Так, самурай не будет выполнять никаких заданий, противоречащих его «кодексу чести» и если к нему подойти с «непристойным» предложением, то он снесет вам башку раньше, чем вы успеете глазом моргнуть. Но если уж самурай возьмется за дело, то можно быть уверенным в том, что он доведет его до конца (**).
Читать дальше →
]]> Tue, 13 Sep 2011 20:03:21 GMT SergeyT Принципы проектирования <![CDATA[Проектирование и рефакторинг / Эпидемия в данных]]> http://habrahabr.ru/blogs/refactoring/125719/ http://habrahabr.ru/blogs/refactoring/125719/
Читать дальше →
]]> Fri, 05 Aug 2011 12:30:00 GMT dbratus архитектурапроектирование <![CDATA[Проектирование и рефакторинг / [Из песочницы] Обеспечение бесперебойного клиент-серверного взаимодействия(WEB)]]> http://habrahabr.ru/blogs/refactoring/124410/ http://habrahabr.ru/blogs/refactoring/124410/
Читать дальше →
]]> Mon, 18 Jul 2011 21:43:47 GMT PaulGauguin webjavajavascripthttp 404http 503smartclientstablereliability <![CDATA[Проектирование и рефакторинг / Паттерны поведения]]> http://habrahabr.ru/blogs/refactoring/123070/ http://habrahabr.ru/blogs/refactoring/123070/ «Технический долг», «Синдром рефакторинга» и «Эффект второй системы»)

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

«Технический долг», «синдром рефакторинга» и «эффект второй системы» — это типовые ситуации, с которыми периодически сталкивается команда разработчиков. И главная польза от них как раз и заключается в том, чтобы увидеть проблему и доказать ее существование нужным людям. Если вы сами поняли, что технический долг проекта слишком велик, то используя денежную метафору будет уже значительно проще доказать важность этой проблемы менеджеру или заказчику. А затем взвешенно показать ему альтернативные пути развития событий: (1) оставить все, как есть; (2) уменьшить технический долг путем разумного рефакторинга или (3) переписать все нафиг.
Читать дальше →
]]> Wed, 29 Jun 2011 20:48:21 GMT SergeyT проектированиепаттерны поведенияантипаттерны <![CDATA[Проектирование и рефакторинг / Эффект второй системы]]> http://habrahabr.ru/blogs/refactoring/121213/ http://habrahabr.ru/blogs/refactoring/121213/ технический долг команды потихоньку начинает превышать все мыслимые и немыслимые границы, то у команды появляется как минимум два способа его погашения: отрефакторить систему таким образом, чтобы стоимость будущих изменений была не столь высокой или оставить текущую версию системы в покое и переписать все заново. В первом случае легко столкнуться с синдромом рефакторинга, когда изменения делаются не с расчетом уменьшения стоимости будущих изменений, а вносятся просто ради изменений. Во втором же случае может возникнуть «эффект второй системы», когда развиваются и совершенствуются уже никому не нужные функции системы, а мысль «а не переписать ли все нафиг» является первой и единственной, которая приходит в голову команде, как только она сталкивается с чужим кодом.

И хотя в классическом понимании «эффект второй системы» немного отличается от паталогической нелюбви к чужому коду и постоянному его переписыванию, оба эти случая имеют и что-то общее, так что имеет смысл оба эти симптома рассмотреть совместно.
Читать дальше →
]]> Mon, 13 Jun 2011 07:17:14 GMT SergeyT проектированиебрукс <![CDATA[Проектирование и рефакторинг / Синдром рефакторинга]]> http://habrahabr.ru/blogs/refactoring/120000/ http://habrahabr.ru/blogs/refactoring/120000/
Бытует мнение, что программные системы, будучи объектом не совсем материальным, не поддаются старению. И если говорить о старении физическом, то действительно, шансы на то, что буковка “o” в имени класса вдруг от старости ссохнется и превратится в букву “c” – действительно малы. Но вместо старения физического, программные системы стареют морально.  Со временем накапливается груз ошибок за счет неточностей в исходных требованиях, непонимания требований самим заказчиком, архитектурных ошибок или неудачных компромиссных решений; да и ошибки поменьше, типа слабопонятного кода, его высокой связности, отсутствия юнит-тестов и комментариев делают свое черное дело. Все это приводит к накоплению технического долга (о котором шла речь в прошлый раз), из-за которого при добавлении новой возможности в систему приходиться платить «проценты» в виде более высокой стоимости реализации и более низкого качества получаемого результата.
Читать дальше →
]]> Thu, 26 May 2011 05:19:14 GMT SergeyT рефакторингантипаттерны <![CDATA[Проектирование и рефакторинг / Технический долг]]> http://habrahabr.ru/blogs/refactoring/119490/ http://habrahabr.ru/blogs/refactoring/119490/
Читать дальше →
]]> Wed, 18 May 2011 04:24:23 GMT SergeyT Проектирование <![CDATA[Проектирование и рефакторинг / [Из песочницы] Рефакторинг проекта в SVN с помощью ANT]]> http://habrahabr.ru/blogs/refactoring/119013/ http://habrahabr.ru/blogs/refactoring/119013/
Предыстория

Имеется проект в SVN из 15 000 файлов и 5 000 папок. Проекту почти 10 лет, на нем поработало несколько поколений разработчиков разной квалификации. В какой-то момент, пару-тройку лет назад, а может и раньше, архитектура проекта «потекла». Разные модули и слои стали писаться в разных стандартах организации кода, возникли циклические зависимости между модулями. В итоге в SVN за долгие года образовалась свалка. Проект собирается, но совершенно шаманским способом.

Задача

Привести код к единому формату хранения. При этом сохранить историю изменений по каждому файлу и не останавливать процесс разработки.

Сложности

Сохранить историю по одному файлу или папке в SVN довольно просто с помощью команды svn copy. При небольшом количестве файлов все можно сделать вручную.
С разбором большого проекта сложно. Пока будешь вручную разбирать 15 000 файлов, разработчики накоммитят новых изменений и их тоже нужно будет копировать. Замкнутый круг.
Нужна автоматизация. Скриптик, который раз! — и переводит проект в новую структуру.

Результат

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

Читать дальше →
]]> Wed, 11 May 2011 05:13:47 GMT qwazer antsvnrefactoringsubversionрефакторинг <![CDATA[Проектирование и рефакторинг / Построение отказоустойчивой (fault tolerant) системы]]> http://habrahabr.ru/blogs/refactoring/118496/ http://habrahabr.ru/blogs/refactoring/118496/
Читать дальше →
]]> Tue, 03 May 2011 03:39:17 GMT javaspecialist отказоустойчивостьfault toleranceresiliencereliabilityDR <![CDATA[Проектирование и рефакторинг / [Из песочницы] Юнит тесты в ASP.NET WebForms]]> http://habrahabr.ru/blogs/refactoring/118409/ http://habrahabr.ru/blogs/refactoring/118409/ Про юнит тесты
Юнит тесты, как известно, это таблетка от головной боли разработчика ПО. Если использовать правильно и по инструкции, то здоровый цвет лица и блеск в глазах обеспечен и без стимулирующих средств. Про юнит тесты говорят по разному: с придыханием те кто прочитал о них в MSDN журнале, с восхищением те кто уже окунулся в мир прекрасного, и с сожалением те кто волею судеб вынужден работать в среде категорически неприемлющей эту ману небесную. Первым я могу лишь пожелать решительности, вторым апплодирую, а вот третим и адресована эта статья.

Кому это? О чем?


Данная статья посвящается таким же как и я, разработчикам корпоративных сайтов на C#/ASP.NET WebForms. Людям которые, как и я, доросли до осознания факта, что ASP.NET WebForms это классно, но не совсем. Не совсем, потому что вебформы не поддерживают юнит тесты, а следовательно и TDD. И единственный практический способ написания стойкого кода это вдумчивое чтение оного. Так я мучался последние несколько лет развивая существующие асп.нет проекты, пока наконец не прозрел. О прозрении и пойдет речь.
Читать дальше →
]]> Fri, 29 Apr 2011 18:14:43 GMT rroyter asp.netunit testingюнит-тестыc-sharp <![CDATA[Проектирование и рефакторинг / Интеграция информационных систем]]> http://habrahabr.ru/blogs/refactoring/117468/ http://habrahabr.ru/blogs/refactoring/117468/
Читать дальше →
]]> Thu, 14 Apr 2011 22:42:31 GMT MarcusAurelius архитектураинтеграциясервисыинформационные системывзаимодействие