Как стать автором
Обновить
44.82

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

Реорганизация кода

Сначала показывать
Порог рейтинга
Уровень сложности

Эффект второй системы

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

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

Синдром рефакторинга

Время на прочтение5 мин
Количество просмотров9.5K
image
Бытует мнение, что программные системы, будучи объектом не совсем материальным, не поддаются старению. И если говорить о старении физическом, то действительно, шансы на то, что буковка “o” в имени класса вдруг от старости ссохнется и превратится в букву “c” – действительно малы. Но вместо старения физического, программные системы стареют морально.  Со временем накапливается груз ошибок за счет неточностей в исходных требованиях, непонимания требований самим заказчиком, архитектурных ошибок или неудачных компромиссных решений; да и ошибки поменьше, типа слабопонятного кода, его высокой связности, отсутствия юнит-тестов и комментариев делают свое черное дело. Все это приводит к накоплению технического долга (о котором шла речь в прошлый раз), из-за которого при добавлении новой возможности в систему приходиться платить «проценты» в виде более высокой стоимости реализации и более низкого качества получаемого результата.
Читать дальше →

Технический долг

Время на прочтение6 мин
Количество просмотров25K
Будь вы простым программистом, матерым лидом, архитектором или даже ПМ-ом, вы наверняка в своей нелегкой работе сталкивались с проблемой выбора при добавлении в систему новой возможности. Одно решение гораздо проще реализовать в сжатые сроки и успеть к очередному очень важному релизу, однако оно будет более затратное в сопровождении, менее расширяемое или менее надежное. Другое решение может не обладать всеми этими недостатками, однако обладать другим, в некоторых случаях более важным недостатком – на его реализацию потребуется значительно больше времени.
Читать дальше →

Рефакторинг проекта в SVN с помощью ANT

Время на прочтение5 мин
Количество просмотров2K
В статье описывается способ разделения логики и реализации логики в ant-скриптах, примененный для решения одной практической задаче по рефакторингу большого проекта в SVN-репозитории.

Предыстория

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

Задача

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

Сложности

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

Результат

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

Читать дальше →

Построение отказоустойчивой (fault tolerant) системы

Время на прочтение8 мин
Количество просмотров48K
В разработке банковского ПО данному аспекту системы уделяется наибольшее внимание. Часто, описывая отказоустойчивую систему, используют слова: Fault Tolerance, Resilience, Reliability, Stability, DR (disaster recovery). Данная характеристика — суть способность системы продолжать корректно работать при падении одной или нескольких подсистем, от которых она зависит. Я кратко опишу какие подходы могут применяться в данной области и приведу пару примеров.
Читать дальше →

Интеграция информационных систем

Время на прочтение6 мин
Количество просмотров117K
Ни для кого не секрет, что «уже все сделано до нас». Осталась всего-то малость «собрать фрагменты» для решения поставленной задачи. И тут оказывается, что интегрировать разобщенные части не редко сложнее, чем их написать. Почему же так происходит? Что можно с этим сделать?
Читать дальше →

Keep API simple

Время на прочтение2 мин
Количество просмотров779
Я хочу рассказать об одном случае, когда нам удалось придумать простой API, когда поначалу задача казалось сложной.


Недавно мы получили задачу. Нам надо было логировать каждое действие пользователя, которое он может совершать на нашем веб-сайте. Другими словами, нам нужно было создать какой-то класс (API), который легко можно было бы использовать практически во всех контроллерах в нашей системе. Сложности добавляло то, что в зависимости от действия надо логировать разные дополнительные параметры.

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

Одержимость красивым кодом, синдромом рефакторинга

Время на прочтение2 мин
Количество просмотров4.1K
В последнее время распространилась одержимость рефакторингом. Доходит до того, что некоторые программисты ставят ему больший приоритет, чем более важным вещам, таким как:
  • Корректность
  • Надежность
  • Отслеживаемость
  • Поддерживаемость

Если это доходит до крайности, и все, о чем заботится программист, является красота кода, он может попасть под синдром рефакторинга.
Читать дальше →

Основы правильного проектирования баз данных в веб-разработке

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

Читать дальше →

Вторая нормальная форма (в терминологии SQL)

Время на прочтение4 мин
Количество просмотров13K
Поскольку первый пост уже сорвал крышу нескольким хабражителям вообще и пошатнул карму мне в частности, решил написать перевод статьи в терминах языка SQL. Будет полезно мне и, возможно, не только мне. Вообще с детских лет я стремлюсь приземлять теорию к практике с помощью различных средств, среди которых был и алкоголь, и, мне кажется бесполезно тратить время на изучение чегото, к чему нельзя придумать пример из реальной жизни.

Забавно лишь, что вся эта белиберда под катом родилась в уме Кодда еще до возникновения SQL как языка, а теперь вот в терминах SQL все подавай…


Что же такое вторая нормальная форма или 2NF? Так чтоб трехлетний ребенок действительно понял…
Для начала разберемся в целях, которые преследует нормализация. Под катом нету терминов дискретки…
Читать дальше →

Вторая нормальная форма в примерах

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

Что же такое вторая нормальная форма или 2NF? Так чтоб трехлетний ребенок понял…
Для начала разберемся в целях, которые преследует нормализация. Под катом немного терминов из дискретки.
Читать дальше →

Идиомы Pimpl и Fast Pimpl – указатель на реализацию

Время на прочтение5 мин
Количество просмотров54K
Другие названия: Bridge, Compilation Firewall, Handle/Body
Допустим, нам необходимо написать кроссплатформенное сетевое приложение с использованием сокетов. Для этого нам необходим класс GeneralSocket (“Видимый класс”), который будет инкапсулировать в себе детали реализации конкретной платформы (“Скрываемый класс”). Часто требуется скрыть детали реализации от пользователей или других разработчиков:
Читать дальше →

Ситуации, когда может пригодиться статический анализатор кода

Время на прочтение3 мин
Количество просмотров2.1K
Метод статического анализа кода заключается в поиске тех мест в тексте программы, которые с высокой вероятностью содержат ошибки. Для поиска таких мест используются инструменты, называемые статическими анализаторами кода. Получив список подозрительных строк, программист осуществляет обзор кода и исправляет найденные ошибки.

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

Ближайшие события

Конфигурябельность

Время на прочтение6 мин
Количество просмотров1.2K
Повествование в художественном или разговорном стиле на компьютерную тематику дело не новое. Наверное, одним из первых и самых известных представителей этого жанра является Том ДеМарко со своей замечательной книгой «Deadline. Роман об управлении проектами». Вот и я решил опробовать этот стиль на себе и посмотреть, что из этого выйдет.

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

На очередном стендапе я стою себе в сторонке, никого не трогаю, народ в это время обсуждает куски какого-то проекта, и тут Славка (лид наш) вспоминает о моем существовании, поворачивается ко мне и говорит:
— Серега, ты же сейчас ни чем особым не занят?
— Да вроде бы нет, — осторожно отвечаю я. — Мне Мэт еще на той неделе обещал подогнать какое-нибудь разумное задание, но так и не подогнал, вот я сижу и дурью маюсь помаленьку.
— Отлично, — говорит Славка, — У меня как раз к тебе заданьице есть. Возьмешься?
— Ну, а чего ж не взяться-то, раз оно есть-то. Давай, конечно.
— Вот смотри, ты же в курсе, что мы переписываем этот Loader с плюсов на шарп? Так вот, заказчик аж кипятком исходится, так хочет, чтобы он был конфигурабельный. Ну, типа, мы в конфиге чего-то прописали, и оно уже как-то по-другому работает.
— Ну, ладно, — говорю. — Идея-то разумная, а что сильно часто им приходилось правки вносить? — спрашиваю.
— Да, х его з, — отвечает Славка, — Народ говорит, что запросов на изменения, дескать, вообще не было, ибо они в этот г#$@о-код даже лезть боялись. Так что я не в курсе, насколько это на самом деле пригодится, но точно знаю, что без конфигурябельности они никуда не хотят.
— Оки, дай мне денек, я поразбираюсь в коде старой системы и в том, что вы уже успели наваять для новой версии, да покумекаю, стоит ли прикручивать сюда эту конфигурабельность аль нет.
Читать дальше →

Отличная статья о сборке продуктов промышленного уровня

Время на прочтение3 мин
Количество просмотров782
Добрейшего.

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

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

Issues and Challenges with Industrial-Strength Product Composition (Проблемы и спорные вопросы сборки продуктов промышленного уровня). Докладчики — потомки суровых викингов, Лар Бендикс (адъюнкт-профессор из Lund University) и Андреас Горансон (сотрудник Sony-Ericsson).

Что же так порадовало?
Читать дальше →

Взаимодействие звеньев и их изоляция. Часть 2

Время на прочтение4 мин
Количество просмотров1.8K
Продолжение статьи «Взаимодействие звеньев и их изоляция.» часть 1

Хочу извиниться перед общественностью за то, что разбил статью на две части. Но в последнее время большие тексты перестали приниматься Хабром. Если кто-то подскажет как с этой напастью справиться: буду благодарен.
Читать дальше →

Взаимодействие звеньев и их изоляция. Часть 1

Время на прочтение5 мин
Количество просмотров4.7K
Логические звенья в n-звенных системах должны проектироваться так, чтобы они взаимодействовали и подвергались влиянию только соседних звеньев. Данное ограничение зачастую нарушается, что негативно влияет на систему. В этой статье я расскажу почему так обычно случается, о последствиях, и почему следует уделять большое внимание изоляции слоев.

Статья посвящена основам и является детальным их описанием. Следующие статьи с подробными примерами будут основываться на ней. Данная статья построена на принципах, которые мы обсуждали в «Где наша бизнес-логика, сынок?» («Dude, where's my business logic?»).
Читать дальше →

Singleton (Одиночка) или статический класс?

Время на прочтение6 мин
Количество просмотров196K
Статья будет полезна в первую очередь разработчикам, которые теряются на собеседованиях когда слышат вопрос «Назовите основные отличия синглтона от статического класса, и когда следует использовать один, а когда другой?». И безусловно будет полезна для тех разработчиков, которые при слове «паттерн» впадают в уныние или просят прекратить выражаться :)

Что такое статический класс?


Для начала вспомним что такое статический класс и для чего он нужен. В любом CLI-совместимом языке используется следующая парадигма инкапсуляции глобальных переменных: глобальных перменных нет. Все члены, в том числе и статические, могут быть объявлены только в рамках какого-либо класса, а сами классы могут (но не должны) быть сгруппированы в каком-либо пространстве имен. И если раньше приходилось иммитировать поведение статического класса с помощью закрытого конструктора, то в .NET Framework 2.0 была добавлена поддержка статических классов на уровне платформы. Основное отличие статического класса от обычного, нестатического, в том, что невозможно создать экземпляр этого класса с помощью оператора new. Статические классы по сути являются некой разновидностью простанства имен — только в отличие от последних предназначены для размещения статических переменных и методов а не типов.

Готовимся к собеседованию дальше?

Плохие и хорошие Singleton'ы

Время на прочтение2 мин
Количество просмотров2.6K
О паттерне проектирования Singleton банды четырёх уже сказано много всяких гадостей. О разных нарушаемых Singleton'ом принципах можно почитать, например, здесь. И, похоже, мне есть что добавить.

Первопричина всех бед с GoF Singleton'ом, в том, что для подавляющего большинства классов «Singleton'овость» – это деталь их реализации. Просто эти классы так удобнее реализовать, если вся система будет работать с одним единственным объектом каждого. GoF советует эту деталь реализации для всех Singleton'ов выносить наружу, в виде метода getInstance().
Читать дальше →

5 советов по проведению хорошего обзора кода

Время на прочтение3 мин
Количество просмотров2.7K
Обзор кода является одной из самых ценных инженерных практик.

   1. Обзоры кода улучшают качество кода: одна голово хорошо, а две — лучше.
   2. Обзоры кода — это прекрасный инструмент для изучения разработчиками тех частей приложения, которые они в дальнейшем могут сопровождать.
   3. Обзоры кода помогают узнавать лучшие практики от других разработчиков.
   4. Обзоры кода могут использоваться для проверки понятности и простоты всего приложения в целом.

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

   1. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью поиска ошибок.
   2. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью проверки соблюдения стандартов кодирования.

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

Исходя из этой точки зрения, позвольте вам дать 5 советов по проведению хорошего обзора кода.
Читать дальше →