Что-то мне в последнее время не нравится make...

Что-то мне начал надоедать make. А так хочется быть гибким, хочется применять всякие новостные методики, но make мешается.

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

Да, я, как всегда, занимаюсь велосипедостроением, но давайте обо всем по порядку.

Если не strcmp...

Опять встретилась проблема в коде. Не то, чтобы очень уж страшная проблема, некоторые даже думают что тем самым они наоборот вносят ясность в код. Но я, как обычно, против.

Давайте посмотрим на следующий код, который я для примера выдрал из ядра linux:

if (!strncmp(name, p, k) && p[k] == '=') {
 	p += k + 1;
	...

Давным давно, в одном редко вызываемом модуле...

Нет, все действия происходят в настоящее время. Наткнулся на интересный кусок кода:

	boost::format value("%s:%s");

	value % head;



	BOOST_FOREACH(value_type &item, container) {

		if (item.valid()) {

			value % item.value();

		}

	}



	return 0;

}

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

Семь раз отмерь...

Интересно, откуда пошла поговорка? Но речь не об этом.

Если жить в соответствии с дао, я имею ввиду TDD и рефакторинг, то методы надо делать меньше. Как сказал Роберт Мартин - 'нет, методы надо делать еще меньше'. И классы в соответствии с SRP надо делать меньше.

Я никогда не встречал проектов, которые бы разрабатывались в полном соответствии с этой концепцией, но чувствую проблемы. Проблемы заключаются в том, что количество таких объектов может уйти далеко за рамки 7+-2, которые человек в состоянии эффективно анализировать.

Использование исключений

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

Исключения надо применять исключительно в исключительных ситуациях. Тогда, когда ты не можешь даже предугадать как обработать ту или иную ситуацию. И даже тогда надо десять раз подумать - а нет ли способа проще. может быть просто вернуть пустое значение, которое удовлетворит вышестоящие уровни? Это будет реально проще, чем бросать исключения.

fastdb query

Существует такая библиотека, fastdb. Это объектная in-memory база данных. Мы используем ее в своем проекте, чтобы хранить конфигурацию сервера. Администратор вносит изменения в конфигурацию, при этом программа управления - весьма тонкий клиент, не обладающей собственной логикой. Вся логика находится на сервере, который должен проверить, что то, что сделал администратор не противоречит функционированию системы в целом.

Для проверки в основном использовались dbQuery. Мне всегда казалось это неудобным, поскольку в Query не так то просто подсунуть программные константы. Кроме того мучили сомнения относительно эффективности данного подхода, которые и сподвигли меня на измерение производительности.

Эволюционный Agile

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

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

Мы от SCRUM пришли к удобному для себя формату и это является генеральной линией гибкости. Все так делают. И возникла мысль - а почему ту же гибкость мы не используем при внедрении Agile?

mbuf overrun

Наткнулся на интересную проблему...

Не буду винить команду FreeBSD, как я люблю, ибо в стандартной комплектации FreeBSD-6 вообще не поддерживает данный адаптер. Нам, для поддержки необходимого оборудования пришлось взять самый последний драйвер от Intel. Драйвер изначально ориентирован на FreeBSD-7, но нам удалось прикрутить его к шестерке. Оригинальные драйвера от Intel используются во FreeBSD практически без изменений. Только фря старая, и драйвер седьмой версии в нее не втащить. До сего дня использовался 6.9.12

Понять ветвления

Централизованные системы контроля приучили нас к единому репозиторию. Ветвления осуществляются между каталогами, или депотами, как их не назови. Ну CVS мы за систему контроля (поддерживающую ветвления) вообще не считаем. Во всех остальных, насколько я знаю - деревья.

Own build system

Наш проект издавна был прикручен к BSD build system. Это набор скриптов, которые располагаются в /usr/share/mk и BSD make с ними. Что-то я от них устал. Они совершенно не подходят для гибкой разработки.

Например, если попытаться практиковать TDD - для качественной сборки необходимо будет всегда делать make depend, иначе изменения в инклюдах не будут отслеживаться. И один раз сделать make depend - совершенно недостаточно. Всегда надо забивать себе голову мыслями о том, не изменил ли я в коде что-то, что могло повлиять на зависимости...

boost::serialization hell

Никогда не используйте boost::serialize! Никогда...

Ну нельзя так работать, ну честное слово! Или может быть у них какие колебания в проекте, нехорошие? Не знаю...

Мы используем сериализацию...

"Мыши плакали, кололись, но продолжали есть кактус!.."

Относительность и поиск

Иногда появляются мысли, достаточно далекие от программирования. Что с этим поделать?

Последнее время я стал совершенно невыносим. Я стал задавать очень много вопросов. Мне очень многое непонятно. Мне непонятно например зачем мы собираемся тащить в проект возможности, которые совершенно никому не нужны, не только нашим пользователям, но даже в рекламных проспектах от этого не холодно не горячо. Но нам зачем-то надо... Зачем???

В жизни у меня возникает масса всяческих вопросов. Может быть дети на меня так влияют?

Триггеры perforce

Наша разработка ведется очень демократично. Мы пишем под FreeBSD (исторически и лицензионно сложилось), используем кодировку koi8-r (тоже исторически сложилось, FreeBSD не очень то дружит с UTF-8 и по сей день).

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

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

ISO9660 FILESYSTEM

Мне не нравится FreeBSD. эта антипатия старая и взаимная. Я ее даже не хочу ставить в тэги.

Началось все это давно (2001 кажется год), когда она отказалась читать с fd0 блок по размеру некратный 512 байт. Да вы слышали что нибудь про абстракцию вообще???

Я тогда некоторое время возился с ней, патч имени меня можно найти во FreeBSD. Но это было давно. Сейчас я опять работаю с ней, и она не перестает меня радовать.

Назначенные инициализаторы

Есть такая замечательная штука, как Designated Initializers. Эта возможность описана в стандарте ISO C99.