Ошибки и правила оценки программных проектов

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

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

http://www.ozon.ru/context/detail/id/3115179/

Но кому лень искать, покупать или читать - на Хабре встретился кратенький пост, с пересказом - http://habrahabr.ru/blogs/pm/75903/

UPD
Встретилось еще близкое к теме - “Статистические ошибки планирования”. Очень интересное выступление, с примерами, "на пальцах".

Как нужно делать выступления

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

Стянуто у http://soldatenko.livejournal.com/74040.html
Перевод (удобно открыть в отдельном окне и туда подглядывать) - http://www.subguru.ru/2008/01/blog-post_01.html



Кусочки:

Не бойся поляризовать людей (polarize people). Классные продукты поляризуют людей. Если вы попытаетесь создать продукт, который понравится всем группам клиентов – от 18 до 25, от 25 до 35, от 35 до 50, от 50 до 75, от 75 до смерти – если вы попытаетесь создать такой продукт, получится посредственность.

Большинство предпринимателей верит в то, что им в первую очередь нужно работать на уровне топ-менеджмента. «Мне нужно говорить с исполнительными директорами, директорами по развитию, президентами и председателями компаний (CIO, CTO, CMO или CEO)». За время своей карьеры я понял, что чем выше ты поднимаешься в большой организации, тем разреженнее воздух. А чем разреженнее воздух, тем меньше он дает возможности для поддержания разумной жизни.

Третий важный момент - найти соратников. Концепцию «предпринимателя-одиночки» сильно переоценивают, она неверна. У Стива Джобса был Стив Возняк. У Билла Гейтса – Стив Балмер. Вам нужны соратники – люди, которые будут вас дополнять. Если ты великий инженер, тебе потребуется великий специалист по маркетингу. Если ты совмещаешь в себе то и другое, тебе нужен будет операционный менеджер. Если ты гениальный провидец – тебе понадобится присмотр кого-нибудь взрослого.

...правило 10/20/30. В вашей презентации должно быть 10 слайдов.... И эти десять слайдов вы должны представить за 20 минут. ... И самый маленький размер шрифта, который вы можете использовать в презентации – 30.

Риски использования распределенных систем управления версиями

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

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

Встретилось вот еще пара интересных статей на эту тему:

Риски распределенного контроля версий
Контроль версий и «правило 80 процентов»

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

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

Да, я знаю, что DVCS может имитировать работу централизованной системы; но поведение по-умолчанию имеет значение.

А поведение по-умолчанию — «ветвить», а не сотрудничать!

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

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

Про новую архитектуру Firebird - SuperClassic

Несколько раз с коллегами начинали разговоры о ней, и каждый раз удивлялись зачем она нужна. В качестве памятки кусочек обсуждения в fb-devel:

SuperServer:

• один процесс ОС на все соединения/базы
• общий кеш страниц для всех баз
• централизованный(central) менеджер блокировок
• блокировки работают на базы, а не соединения - т.е. все операции с базой выстраиваются в одну очередь.
• для версии <>
• не поддерживает многопроцессорность, т.к. ОС не может распаралелить один процесс по нескольким процессорам

Classic:

• отдельный процесс на каждое соединение с БД
• отдельный кеш страниц на каждое соединение
• внешний менеджер блокировок(в 2.5. он уже внутренний)
• хорошая поддержка многопроцессорности
  
• накладывает некоторые ограничения в следствие ресурсоемкости процессов, в сравнении с потоками

SuperClassic:

• один процесс на все соединения (в перспективе - отдельный процесс на каждую базу)
• используется пул потоков ОС для обработки запросов от соединений - т.о. каждое соединение работает в отдельном потоке управляемом ОС, а неактивные соединения не отъедают ресурсы потоков
• централизованный менеджер блокировок, который может обрабатывать как внутренние, так и внешние обращения(одна и таже база может быть доступна как посредством СУБД из процесса А, так и через FB Embeded из процессов B, C и т.д.)
• теоретически этот менеджер блокировок позволяет организовывать кластеризацию используя готовые распределенные движки блокировок
• кеш страниц на соединение
• хорошая поддержка многпроцессорности, т.к. потоки ОС легко распараллеливаются

В v3.0 планируются такие доработки:

• общий кеш страниц на уровне базы
• кеш подготовленных запросов
• общий кеш метаданных

Как итог - SuperClassic это промежуточный шаг(насколько я понял изначально родившийся в RedSoft) к следующей основной архитектуре FB, появившийся в следствии крупного рефакторинга внутренностей движка.

Пока для пользователей практический выигрыш лишь в экономии на процессах и, как следствие, чуть более быстрой синхронизации. Хотя если верить документации, то совокупный выигрыш - до 15-20% на TPC-С тестах в сравнении с классиком.

Подробнее можно посмотреть в Firebird 2.5 Release Notes

UPD: Презентация от Дмитрия Еманова - Firebird 2.5 Architecture

Динамически загружаемые bpl , их выгрузка и интерфейсы

Очевидная, но съевшая кучу времени ошибка.

Если в проекте используются динамически загружаемые/выгружаемые bpl, следует помнить, что при выгрузке информации о классах, реализованных в этих bpl в памяти не остается.

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

Если оставить разрушение этих объектов на совести основного кода, что при использовании интерфейсов довольно очевидно, но делать это _после_ выгрузки bpl с кодом класса реализующего интерфейс, например в секции finalization, - будем получать маловразумительные AV.

Интерфейсы должны быть интерфейсами!

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

Есть объект, унаследованный от TComponent и поддерживающий какой-то интерфейс. Временем жизни этого объекта управляет некая фабрика, честно убивающая его при закрытии приложения вручную, как обычный объект - т.е. посредством вызова Free.

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

А при завершении работы - фабрика все честно чистит и умирает сама, выполняется весь пользовательский код. И начинают финализироваться модули, обнуляя интерфейсы и соотв. дергая TComponent._Release у давно умершего объекта...

Обнаружить сию неприятность удалось только благодаря FastMM, который заполняет память под разрушенными объектами по специфическому шаблону:

Q: My program used to work fine, but if I enable "FullDebugMode" and run it I get an access violation at address $8080xxxx. Why?
A: You are attempting to access properties of a freed object. When you free a block in "FullDebugMode", FastMM fills the freed memory area with a pattern of $80 bytes. If there were any pointers, long strings or object references inside the freed object they will now point to $80808080 which is in a reserved address space.

Все плохое в FB от Windows :)

Проглядывая презентацию Алексея Пешкова о прошлом, настоящем и будущем безопасности в Firebird наткнулся на интересную информацию:

Тот громкий "зашитый" пароль politically/correct был введен для коннекта сервером к своей базе паролей, которая в свою очередь была введена для порта сервера на .... Win3.X в 92-93г., у которой в то время не было свой подсистемы пользователей.

Как любит говорить один мой друг, коммерческий дух win-платформы пересилил здравый смысл :)