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

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

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

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

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

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

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

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

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

Добрейшего.

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

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

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

Что же так порадовало?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(прим. перев. Перевод немного вольный, но я попытался максимально точно сохранить смысл текста, в то же время отыгравшись на некоторых некритичных моментах, просьба не судить строго :)
Должен также отметить, что я не по всем пунктам согласен с автором (в конце он уже начинает зарываться) и, разумеется, обзоры кода — это не серебряная пуля, но, тем не менее, очень и очень полезная практика.)

Я затвитил эту статью о 5 причинах проводить обзоры кода на CIO.com на прошлой неделе и понял, что на самом деле причин гораздо больше, чем те пять, о которых там написано. Так что к концу дня у меня их было уже больше 20. Это коллекция тех твитов с некоторыми подробностями, описанными здесь.

Причина №1. Достаточно быстрая ответная реакция, чтобы подстегнуть разработчика.
Так как обзор кода производится после кодирования и перед интеграционными и системными тестами, разработчикам не надо ждать столько же, сколько и ответа от отдела по качеству кода (QA). Обеспечив конкретный, своевременный ответ, разработчики могут подстраивать свои навыки кодирования для избежания общих ошибок.

Спасибо небу за то, что в субботу шел дождь, и я это прочитал (а вы скажите спасибо за то, что перевел). В воскресенье, однако, светило солнце и форматирование текста было отложено.

Отдельное спасибо автору, за разрешение отдельной публикации.

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

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

А как делать этот самый рефакторинг, если даже неизвестно, с чего начать? Как осушить болото кода и не утонуть нем?

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

Хочу представить свой перевод статьи «Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews».

Я ненавижу тебя: твой код – хлам!
Взаимоотношения участников ревизий кода

Джонатан Лэндж (Jonathan Lange), 15.09.2008

Обзор

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

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

Анти-паттерны — полная противоположность паттернам. Если паттерны проектирования —
это примеры практик хорошего программирования, то есть шаблоны решения определённых задач. То анти-паттерны — их полная противоположность, это — шаблоны ошибок, которые совершаются при решении различных задач. Частью практик хорошего программирования является именно избежание анти-паттернов. Не надо думать, что это такая непонятная теоретическая фигня — это конкретные проблемы, с которыми сталкивался практически каждый разработчик. Кто осведомлен, тот и вооружён! Рассмотрим же несколько расрпотранённых анти-паттернов в программировании.

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

#include <iostream>

int test(int x) {
  static const int y = test(x + 1) * 2;
  return x + y;
}

int main() {
  std::cout << test(42) << std::endl;
  std::cout << test(0) << std::endl;
}

Вопросы:
1. Для какой версии GCC будет работать эта программа?
2. Что она выведет на экран?
3. Как отрефакторить функцию test() чтобы она стала совместима со стандартом (и с GCC 4.2, соответственно)?

Ну и парочка более простых примеров (примерно как задачка номер два там):
4. Как описать внутри класса функцию классу не принадлежающую (то есть не являющуюся ни статическим, ни динамическим методом класса)?
5. Зачем эта возможность нужна в C++?

Ну и напоследок вопрос: а стоит ли задавать подобные вопросы на собеседовании?

P.S. Подсказки пишите белым по белому, как обычно…

Behold, people. Свершилось. Язык программирования D — очередная попытка сделать из любимого C нормальный объектно-ориентированный язык — окончательно перестал быть частной инициативой его автора, Волтера Брайта (Walter Bright), и компании Digital Mars. Теперь и GNU предлагает собственную реализацию. Работы, начатые GNU в прошлом году, наконец привели к созданию компилятора, который способен пройти все тесты в The Computer Language Benchmarks Game.

D — это, если можно так выразиться, причёсанный вариант C++, который многое наследует от Java и Eiffel, но при этом остаётся полностью компилируемым в машинный код и хорошо оптимизируемым языком. О производительности и эффективности можно судить по тестам The Computer Language Benchmarks Game. И выглядит он при этом довольно симпатично, примеры программ можно посмотреть в статье на wikipedia — D (programming language).

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

Вот. Happy coding.

P.S. Прямые ссылки, к сожалению, указать не удаётся. Хабру глючит, но чрезе Google они быстро находятся.

Многие «знают», что программирование на C/C++ позволяет получить программы, которые работают почти так же быстро, как программы, написанные на языке Assembler, а уж те, в свою очередь, быстры настолько, насколько это вообще возможно в теории.

На самом деле, конечно, это не совсем так (а в редких случаях — и совсем не так), но в целом программы на C/C++ действительно быстры, требуют немного памяти и запускаются мгновенно. Если их правильно написать.

Вот о том как правильно писать на C/C++ я и хотел бы немного поговорить. Сегодня я хочу обсудить вопрос о наборах строк. То есть о процедурах, позволяющих из числа получить строку, а из строки — число.

Где подобные списки встречаются? Ну, например, это могут быть списки токенов html, с которыми работает ваша программа. Или список команд, которые принимает ваш командный интерпретатор. Но, конечно, наиболее часто такие наборы возникают как списки всевозможных ошибок: strerror, gai_strerror, regerror и т.д. Думаю каждый программист встречался с подобной задачей хотя бы раз.

Хочу оговориться что дальнейшее описание впрямую применимо только к операционным системам, использующим формат ELF: Linux, MacOS, etc. В Windows или встраиваемых системах ситуация может быть слегка иной. Плюс я в этот раз ограничусь только прямой задачей (по числу получить строку) ибо она во-первых проще, а во-вторых многие решения обратной задачи содержат в себе прямую задачу как часть решения.

Иногда от посторонних людей достаются большие процедуры, от которых появляется большая головная боль.
Например, когда мне досталась на переработку километровая процедура 1С. В целом, она выглядела

В свое время я прибывал в уверенности, что код
js обычно не нужно писать так, чтобы он был
наиболее оптимальным. «Клиентская часть» — говорил я, — «на сервер никак не
повлияет, а посему, можно забить». К сожалению, оказалось, что это не совсем
так.

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