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

Добрый вечер Хабранарод!

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

В качестве примечания, использовал Visual Studio 2010 (крэкнутый, конечно) и скачал PVS-Studio из официального сайта, нажимая «Download and Try» и следуя инструкциям. Все это я пишу потому, что у меня вопросы на счет данной утилиты и требуется ваша, так сказать, помощь.

Первым делом прогоняем тесты из предудущей статьи, и так:

Тест 1:

int main()
{
	vector<int> v;
	v.reserve(2);
	assert(v.capacity() == 2);
	v[0];
	v[0] = 1;
	v[1] = 2;
	cout << v[0] << endl;
	v.reserve(100);
	cout << v[0] << endl;
	return 0;
}

VS2010: ничего
PVS-Studio: ничего

Анализ следующих утилит:

• RATS (Rough Auditing Tool for Security)
• Cppcheck
• Graudit

Все необходимое можно найти пройдя по ссылкам, а мы сразу перейдем к делу.

Тест 1:

int main()
{
	vector<int> v;
	v.reserve(2);
	assert(v.capacity() == 2);
	v[0];
	v[0] = 1;
	v[1] = 2;
	cout << v[0] << endl;
	v.reserve(100);
	cout << v[0] << endl;
	return 0;
}

Введение

Долгое время считалось, что динамический анализ программ является слишком тяжеловесным подходом к обнаружению программных дефектов, и полученные результаты не оправдывают затраченных усилий и ресурсов. Однако, две важные тенденции развития современной индустрии производства программного обеспечения позволяют по-новому взглянуть на эту проблему. С одной стороны, при постоянном увеличении объема и сложности ПО любые автоматические средства обнаружения ошибок и контроля качества могут оказаться полезными и востребованными. С другой – непрерывный рост производительности современных вычислительных систем позволяет эффективно решать все более сложные вычислительные задачи. Последние исследовательские работы в области динамического анализа такие, как SAGE, KLEE и Avalanche, демонстрируют, что несмотря на присущую этому подходу сложность, его использование оправдано, по крайней мере, для некоторого класса программ.

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

Еще одной метафорой, или скорее принципом разработки, является «принцип самурая», призванный описать «контракт» между функцией и вызывающим ее кодом и заключается в следующем. Любая функция, реализующая некоторую единицу работы должна следовать тому же кодексу чести «бусидо», по которому живет любой самурай. Так, самурай не будет выполнять никаких заданий, противоречащих его «кодексу чести» и если к нему подойти с «непристойным» предложением, то он снесет вам башку раньше, чем вы успеете глазом моргнуть. Но если уж самурай возьмется за дело, то можно быть уверенным в том, что он доведет его до конца (**).

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

Как-то раз сидел в аудитории с ноутом около розетки, а в это время на соседней парте принимался зачет по программированию. Я не сильно вникал в суть вопросов на которые общались студент и преподаватель, назовем его Иван Ивановичем. Разговор был довольно спокойный и тихий, но у меня получилось выхватить часть. Преподаватель говорил о комментариях (видимо сдавалась программа, в которой не было ни строчки комментариев). Меня этот момент заинтересовал и я начал прислушиваться. Было замечено, что мне тоже интересно, преподаватель начал импровизированную лекцию. Ниже представлен тот небольшой кусок знаний который я тогда вынес с этой 5ти минутной лекции.

Данным постом постараюсь описать протокол с помощью которого можно повысить надежность ВЕБ-приложения при возникновении проблем соединения с сервером. Постараюсь описать абстрагируясь от технологий однако в тексте будут приведены примеры серверного Java кода и JavaScript/SmartClient на UI для наглядности описуемого и по причине того что данный протокол был реализован в рамках существующего проекта с использованием данных технологий.

(Эта заметка является завершением серии постов, в которую вошли «Технический долг», «Синдром рефакторинга» и «Эффект второй системы»)

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

«Технический долг», «синдром рефакторинга» и «эффект второй системы» — это типовые ситуации, с которыми периодически сталкивается команда разработчиков. И главная польза от них как раз и заключается в том, чтобы увидеть проблему и доказать ее существование нужным людям. Если вы сами поняли, что технический долг проекта слишком велик, то используя денежную метафору будет уже значительно проще доказать важность этой проблемы менеджеру или заказчику. А затем взвешенно показать ему альтернативные пути развития событий: (1) оставить все, как есть; (2) уменьшить технический долг путем разумного рефакторинга или (3) переписать все нафиг.

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

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

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

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

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

Предыстория

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

Задача

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

Сложности

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

Результат

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

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

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

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


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

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

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

• Корректность
• Надежность
• Отслеживаемость
• Поддерживаемость
• …

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

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

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

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


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

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

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

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