Защитное программирование

Чтобы не забыть и чтобы было куда посылать...

Часть мыслей честно утащена у Эккеля и других авторов, здесь сведено в одну таблицу и отражена суть что и где применять. Вопрос “когда применять” не рассматривается, ибо не корректен – применять надо всегда.

Есть 3 вида конструкций для защитного программирования: исключения, assert’ы и проверки. Применять при:

	Исключения	assert’ы	логические проверки
взаимодействия с внешними системами и сторонними модулями	да	нет	да
создание новых объектов	да	нет	нет
своя логика	нет	да	да
проверять юнит тестами поведение?	нет	да	да
оставлять в релиз версии	да	?	да

Взаимодейстие с внешними системами/модулями – не известно, что там может произойти, как организован код сообщающий о ошибочных результатах и насколько безопасно сторонний код написан, потому лучше закрыть try/catch блоками для безопасности. Иногда для проверки результата действий может хватить и кода ошибки. Хотя проверять, что тебе отдали валидные данные, всё равно надо.

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

Своя логика – проверять что ты ничего вредного или чудного не передаёшь внутрь.

С юнит тестами связан следующий момент: 
все три конструкции должны проверять только важное на данном этапе, а не всё подряд – иначе это может привести к сложностям при написании юнит тестов. Подробней смотреть link.

Оставлять в релиз версии – а вот тут есть разные мнения. Начиная от сравнения “ходить по суше в спасжилете, а перед выходом в море снимать его” и заканчивая “не нужно нам неконтролируемое падение системы”. Пмм, на этапе тестирования лучше иметь ассерты – более заметны, а соответственно лучше стимулируют исправление; а вот на этапе установки у заказчика лучше иметь логические проверки с логированием.

Новый Qt

Вышел новый Qt/Qt Creator...

По функционалу стремительно догоняет Visual Studio/Eclipse/NetBeans. А учитывая возможность интеграции в 1-е 2 упомянутых продукта, то появляется реально хорошая альтернатива Visual Studio и Eclipse при кросплатформенной разработке на C++.

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

Навязывание MVC/MVP как базового шаблона при построении архитектуры уже даёт большой плюс в усилении скилов сообщества разработчиков.

А наличие биндингов для явы и питона ещё и приманивает соседей :)

Интересно, ещё у кого-то остались сомнения о полезности покупки TrollTech Nokia'ей?

Оценки времени выполнения задачи

У Брюса Эккеля в его "Философии C++" натолкнулся на замечательную оценку времени необходимого для выполнения задачи:

"Прикиньте, сколько времени потребует ваш проект, затем удвойте это число и прибавьте еще 10 %. Скорее всего, ваше внутреннее ощущениевас не подводит; вам действительно удастся получить нечто работоспособное за это время. Еще столько же времени уйдет на то, чтобы привести это «нечто» к более или менее приличномувиду, а последние 10 % уйдут на шлифовку и всякие мелочи...

В последнее время мнение автора по этому вопросу изменилось. Удвоение и прибавление 10 % дает довольно точную оценку (при небольшом количестве непредсказуемых факторов), но чтобы уложиться в это время, необходимо прилежно работать. Если вы захотите сделать программу элегантной и получить удовольствие от своей работы, лучше умножать на 3 или на 4."

Собственно это классическая оценка с помощью числа Pi : "возьмите вашу оценку времени выполнения задачи и умножьте её на Pi, при этом Pi в зависимости от опыта может колебаться от 1,5 до 4"... :) Просто не ожидал её встретить у “самого Брюса”.

Хотя для понимания откуда берётся это Pi в реальной оценке, лучше посмотреть следущее сообщение с rsdn.ru. Оно как-то более точно позволяет оценить время на выполнение задачи. Сам уже начал пользоваться этими пунктами :)

…

Теперь разберем из чего состоит задача.
1. Если код незнакомый, знакомство. Понимание через отладку. Если нужно рефакторинг. Понимание через рефакторинг.
2. Проектирование нового функционала. Подробное. А не в уме, как на совещании было.
3. Подготовка кода к внесению изменений. Опять рефакторинг.
4. Собственно кодирование. Говорит неделя, ну так 40 часов и запишем. И это только на пункт 4. А вы говорите 16-32.
5. Интеграция с остальным кодом. Это то что в пункте 3 делали, но теперь уже начисто.
6. Тестирование (в это время можно программеру дать другое задание), либо дать на проверку код
соседа, попросить отревьювить код и т.д. Опять же старые баги есть наверно.
7. А теперь откровение. Оказывается после тестирования надо баги поправить. Иначе зачем тестировать-то. А потом снова на тестирование и снова баги.

Ну допустим у меня один баг в неделю на 20 коммитов. Но это в неторопливой обстановке. А ктоме того еще штук десять в неделю "not a bug" и половинка "a change request"

Далее пункты выполняемые совместно с остальными:
8. Покрытие тестами.
9. Документирование.
10. Коммуникации с коллегами по работе, совещание.
11. Коммуникации с начальством, отчеты, совещания.
12. Чтение проф литературы, блогов, RSDN и т.д.
13. Перерывы на отдых, чай, сигареты (кто курит), поболтать на различные темы.
14. Обязательно поболтать с любимой/любимым по ICQ.

А теперь начинаем думать. Я тут 14 пунктов перечислил, а программист (и я тож из таких) думает только про пункт 4.
Причем если вам пункты 12 - 14 не нравятся, то программистам, да и вообще здоровым людям, они необходимы. За пункт 14 вообще перегрызу горло

…

C++0x и NetBeans

Не совсем понравилось экпериментировать с возможностями нового стандарта С++ на Eclipse, а потому до сих пор искал альтернативу. Реальных причин для отказа было 2, хотя уже сейчас могу придумать значительно больше:

1. Неудачно выбраный порт с GCC: зачем выбрал Cygwin до сих пор понять не могу. Наверное сыграл инстинкт пользователя :), который долго воспитывали в Windows - "больше весит - значит лучше".
2. Глюки. Как-то непривык при входе в отладку простого приложения наблюдать креш среды разработки.
   

Ну и немного смущала заторможеность реакции среды на действия и слабая подсветка синтаксиса и подстановок по сравнению с Visual Studio/Visual Assist.

Сейчас вроде бы нашёл альтернативу, где смогу вволю поэкспериментировать. Инструкция для тех, кому, возможно, будет интересно поиграться с C++0x на NetBeans в Windows.

1. Скачать и установить NetBeans IDE у кого эта IDE ещё не стоит или добавить плагин C++ в уже установленую NetBeans IDE (http://www.netbeans.org/)
   
2. Скачать MinGW порт c GCC версии 4.4. Выбрал MinGW, потому что он действительно min - весит меньше, а работает быстрее. На официальном сайте MinGW к сожалению последняя стабильная версия GCC ещё 3.4.5, кандидат 4.3., а нам нужна 4.4, в которой и сделана основная реализация фич из C++0x. Можно с взять с http://www.tdragon.net/recentgcc/ уже собраное с windows installer, а можно в классическом unix-way собрать самому из исходников - тут уж у кого как душа поёт.
   
3. Также необходимо скачать и установить MSYS последней версии - сайт MinGW тут уже сможет помочь. Необходимо это, потому что NetBeans не дружит с MinGW make идущим в MinGW по умолчанию, да и на сайте MinGW настоятельно рекомендуется использовать make из MSYS.

Теперь займёмся настройкой IDE:

1. Запустить NetBeans IDE
2. Выбрать Tools/Options/C++
3. на закладке Build Tools настроить
   
4. 
5. На закладке Code Assistance для C Compiler и C++Compiler надо нажать Reset settings для того, чтобы NetBeans IDE подхватило последнюю версию g++, а не расположеную в корне инсталяции MinGW. Почему не подхватить эти пути сразу - не знаю, наверное надо выделяться как-то на фоне Microsoft.
   
6. 

Общие настройки IDE закончены - остались только изменения в проекте.

Теперь заголовки версии 4.4 подключаются в проект, но почему-то вся функциональность будущего стандарта не работает. Причина в том, что GCC требует включать эту поддержку дополнительной опцией, что в целом разумно, т.к. C++0x это ещё не утверждённый стандарт и работа с ним чревата изменениями, а потому строить production код на нём вряд ли кто-то будет. Выбрать настройки C++ проекта, перейти на группу C++ Compiler и поставить ввести "-std=gnu++0x" в Additional Options.