Библиотека

Д. Нильссон. Применение DDD и шаблонов проектирования (скачать)
Книга о разработке корпоративных программных приложений в среде .NET с применением шаблонов проектирования. В ней описаны: как строится четкая и удобная, с точки зрения сохраняемости, модель предметной области (Domain Model), рассматриваются вопросы проектирования, ориентированного на предметную область (DDD, или Domain-Driven Design), разработки посредством тестирования (TDD, или Test-Driven Development), объектно-реляционное преобразование, т.е. методы, которые относятся к ключевым технологиям разработки программного обеспечения. По мере развития и усложнения технологии все большее значение приобретают вопросы правильного применения методов проектирования, которые налаживают взаимосвязь между пользователями и разработчиками, предметной областью и программным обеспечением, логикой и хранением информации, проектировщиками баз данных и программистами.
Большинство примеров кода, в книге, представлено на языке C#, но материал окажется полезным и пользователей платформы Java.
Книга адресована опытным разработчикам архитектуры и прикладного программного обеспечения уровня предприятий, в том числе и в среде .NET.
Р. Мартин, Д. Ньюкирк. Быстрая (гибкая) разработка программ: принципы, шаблоны, практика (скачать)
Книга рассказывает о различных методиках быстрого (и даже экстремального) программирования. Изложение начинается с обзора основных понятий экстремального программирования и завершается готовыми программами, применяемыми на практике. В каждой главе приведены примеры кода на языках программирования Java и C++. Книга будет полезной руководителям групп программистов, нацеленных на быструю разработку коммерческих программных проектов, характеризующихся высоким уровнем качества и минимальной себестоимостью.

Комментарии в коде

Все мы не раз слышали, что код нужно комментировать, чтобы в нём потом можно было разобраться. Неопытные программисты часто возражают : "Это мой код, и я знаю, что он делает, и не забуду даже через полгода, что значит переменная k в выражении empS += k*arr[i] + bon[i]!" И при этом совершенно не учитывается, что кроме них, этот код могут править другие программисты - те бедолаги, которым придется сопровождать этот код. Но, опять же, комментарии, написанные, лишь бы написать, чтоб не цеплялись, - это еще хуже, чем отсутствие комментариев.

При плохом выполнении комментирование является пустой тратой времени и иногда причиняет вред.
С.Макконнелл

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

int k = getKoeff(m); /*инициализируем переменную k значением, возвращаемым методом getKoeff */
double empS = 0.0; //инициализируем переменную empS нулем
for(int i=0; i<getWNub(m); i++)
{
empS +=k*arr[i] + bon[i]; //вычисляем сумму в цикле
}

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

Хороший код сам является самой лучшей документацией. Если код настолько плох, что требует объемных комментариев, попытайтесь сначала улучшить его.
С.Макконнелл

Я не призываю отказаться от комментариев в коде, я призываю к написанию ясного кода, который легко понять и модифицировать даже по прошествии длительного периода времени.
Что в моем понимании "ясный код"? Это, конечно же, самодокументирующийся код. Например, предыдущий кусок кода можно переписать так:

int koefficient = getSalaryKoefficient(monthNumber);
double employeeSalary = 0.0;
int workingDaysInCurrentMonth = getWorkingDaysNumber(monthNumber);
for(int dayNubmer=0; dayNumber<workingDaysInCurrentMonth; dayNubmer++)
{
employeeSalary +=koefficient*workingHours[dayNubmer] + dayBonus[dayNubmer];
}

Что изменилось в коде? Всего лишь имена переменных и методов, но этот код, в отличие от первого его варианта, понятен без комментариев. Имена переменных и методов говорят сами за себя, им не нужны никакие комментарии. Такими же должны делать имена классов, интерфейсов, констант, перечислений, элементов перечислений и т.д. О том, насколько важно правильно выбирать имена и как это делать, можно почитать в книге "Совершенный код" С. Макконнелла.

Почувствовав потребность написать комментарий, попробуйте сначала изменить структуру кода так, чтобы любые комментарии стали излишними...
М.Фаулер

Как менять структуру кода и когда это нужно делать, можно почитать в книге Мартина Фаулера "Рефакторинг. Улучшение существующего кода". Но, конечно же, есть несколько случаев, когда следовать вышеприведенной цитате не нужно. Во-первых, когда код делает не очевидные вещи, например (пример взят из книги "Совершенный код" С.Макконелла):

for(element = 0; element<elementCount; element++)
{
/*Для деления на 2 используется операция сдвига вправо. Это сокращает время выполнения цикла на 75% */
elementList[element] = elementList[element] >>1;
}

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

//Цвет фона по умолчанию - белый
itemBgColor = Color.FromAGB(255,255,255);

Этот код лучше будет даже переписать следующим образом:

const Color DEFAULT_BG_COLOR = Color.FromAGB(255,255,255);
...
itemBgColor = DEFAULT_BG_COLOR;

Кроме того, следует комментировать использование недокументированных возможностей или исправление обнаруженных ошибок - ведь в следующих версиях системы этих возможностей может и не быть, а ошибки могут быть исправлены :)
Полезным может оказаться документирование ограничений, если они не заданы константами с говорящими именами, а используются в коде как есть - в виде чисел. Но с таким настоятельно советую бороться :)
В своей практике кроме всего выше перечисленного я предпочитаю давать краткое описание методу перед началом его кодирования, при этом использую очень замечательную возможность документирования кода в Visual Studio. Это выглядит так:

/// <summary>
/// Возвращает следующий по номеру ваучер по отношению к номеру текущего ваучера
/// </summary>
/// <returns>VoucherItem</returns>
public VoucherItem GetNextVoucherItem()
{
return VoucherRepository.GetNextVoucher(this.VoucherNumber);
}

Клиентский код, использующий методы моего класса, получает возможность использовать IntelliSense, что очень удобно.
И напоследок приведу такую цитату:

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

Регулярные выражения

Для облегчения работы с регулярными выражениями я использую бесплатную утилиту от Rad Software - Regular Expression Designer.


Среди фич можно выделить следующие:

Удобное отображение результата выполнения выражения - строится многоуровневое дерево для Matches, Groups и Captures. При клике на ветку дерева в исходном тексте выделяется фрагмент, соответствующий результату.

Очень удобно сделано окно "Language Element" - справочник по регулярным выражения всегда под рукой. Но для не владеющих английским (о_О) он может оказаться не очень полезным.

Найти более подробное описание программы и скачать ее можно на сайте разработчика - http://www.radsoftware.com.au/regexdesigner/

Mpress VS Avira

Недавно к своему сожалению обнаружила, что некоторые антивирусы, в особенности Avira, распознают exe-файлы, запакованные с помощью пакера Mpress, о котором упоминалось ранее в этом блоге, как вирус.

О колбасе :)

Понравился анекдот о колбасе и яйцах :)

Жена посылает мужа-программиста в магазин:
- Дорогой, купи, пожалуйста, палку колбасы, и если будут яйца, то купи десяток.
Через полчаса программист возвращается с десятью палками колбасы.
Жена:
- Что это?! Зачем ты купил столько колбасы?
Программист:
- Ну так яйца-то были...

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

Ошибки в требованиях к разработке ПО никогда ничего хорошего не приносили. Если ошибка обнаружена на ранней стадии разработки, то все может обойтись малой кровью, но если зловредную ошибку удается обнаружить только на стадии завершения проекта или сдачи его в эксплуатацию... малой кровью тут не обойтись... Чем ближе дело к завершению разработки, тем жесче остов приложения, тем сложнее даются изменения. По аналогии со строительством, после того, как вы залили фундамент дома, и начали возводить стены, а тут вдруг говорят, что кто-то не доглядел план и надо бы северную сторону дома сделать не округлой, а треугольной... Стоимость таких ошибочек огромна, результаты - удручающи :( В примере с колбасой все проще - колбасу можно съесть :), а вот в жизни получаются шестиколесные велосипеды...

Из-за чего получаются такие ошибки? Как они закрадываются в спецификации? Есть несколько ответов на эти вопросы: от банального не доглядели до несогласованности требований. Всем известно, что требования в процессе разработки меняются, и после каждого изменения или дополнения нужно проверять, не получилось ли так, что часть новых требований не согласуется со старыми. Так же есть такие факторы, как взаимонепонимание и "требования по умолчанию". Разработчики, которые не являются специалистами в предметной области разрабатываемого продукта, могут не знать некоторых деталей, а для заказчика (или эксперта, учавствующего в разработке спецификации) данные детали являются делом обыденным, само собой разумеющимся. "Требования по умолчанию" - это опасные требования. Их даже может и не быть в спецификации, потому что это "само собой разумеющиеся" вещи, о них просто забывают. А для разработчиков эти вещи далеко не очевидны, так же как и для обычного человека не очевидно то, что для разработчика ясно как 0 и 1.

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