четверг, 30 декабря 2010 г.

Feature List

Протестировать можно только реализованные вещи. Нет, строго говря, это не правда, и даже более того, вредная неправда. Тестировать надо бы начинать задолго до того, как чтото реализовано. Но сейчас не об этом. Сейчас о тестировании софта. Вот он, свеженький, только из билд-машины, еще тёплый, HEAD revision. И руки тянутся его помучить... А мучить мы будем фичи.

Все что реализовано я буду называть фичами. Слово это от англиццкого забугорного feature и обозначает "особенность" в самом грубом переводе. Нефункциональные требования тоже должны быть реализованы, согласны? И их реализация - тоже фича.

Пункто нумре два - фичи можно скучковать. Кучи фич ;) тоже можно сгруппировать при желании. Да и фича может состоять из подфич. Для каждого уровня названия придумывать замучаешься. Поэтому - просто фича. И эти фичи удобненько так складываются в дерево, не всегда правда, бывает что это граф с циклами, но не будем пока о плохом. Фича в данном случае может быть отдельным требованием, пользовательской историей, набором функций, удобством использования и даже цветовой гаммой или документацией пользователя. Важно только одно - она должна быть реализована.

Как водится - пример. Блокнот. У него есть фичи - редактирование, сохранение, чтение, сами продолжайте. У редактирования есть фичи копирование, вставка, удаление, набор текста... Сам блокнот тоже может быть фичей в каком либо приложении. Обращаю внимание, фичи, это не обязательно требования. Фича - это то чем пользователь, извините за тавтологию, пользуется. Вобщем, можно считать следующую фразу определением. Фича реализует потребность пользователя.

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

  1. Нам нужно знать набор фич, необходимый для решения пользовательской задачи (предусмотренный для реализации в софте).
  2. Нам нужно знать ожидания пользователя от этих фич. Замечу, некоторые ожидания пользователя могут быть зафиксированы как требования.
Хорошо, когда проект идет по канонам разработки, когда документируются требования, когда документация поддерживается в актуальном состоянии, когда всегда есть пиво в холодильнике... Наверное так бывает, но я не встречал. Поэтому, собственно, "некоторые" и "могут" выделены. Так что, первым делом, надо бы составить набор фич, которые в софте (будут) реализованы. Такой список серьёзно облегчит задачу планирования, ну и готовьтесь к тому, что этот список никогда не будет закончен. Это нормально, живой документ в живом проекте. Есть даже такой признак, если документ какое то время (не помню точно, кажется год) не меняется - он не работает.
Получив список фич можно начинать эти фичи приоретизировать, оценивать сроки их тестирования, разбирать и восстанавливать требования, готовить тесты, говорить тосты, и вообще, многое станет понятней. Так что удачи и
С наступающим новым годом, коллеги!

четверг, 9 декабря 2010 г.

PostgreSQL VS MySQL

Как то так сложилось, что большинство хостингов предоставляют связку LAMP для web, поэтому вопрос выбора базы данных для личного проекта передо мной не стоял. MySQL популярен, надёжен, удобен и ещё куча разных положительных эпитетов. Однако, с недавних пор, по роду работы, мне периодически  случается работать с  Postgre. И вот какие наблюдения я для себя сделал.
Postgre DML будет побогаче чем у MySQL. Это плюс. Например,

INSERT INTO table (id, name) VALUES (DEFAULT, 'qweqwe')    RETURNING id;

Вставка записи сразу же возвращает ID записи. В MySQL для этого требуется вызов LAST_INSERT_ID(). 

Еще пример: конструкция WITH в Postgre позволяет выполнять рекурсивные запросы. То есть ветку дерева можно вытащить одним запросом. В MySQL5 такого нет, к сожалению.

Вынесенные за пределы определения таблиц последовательности в PG сильно гибче чем AUTOINCREMENT в MySQL. Они могут быть цикличные, могут быть, эм… как сказать то… непоследовательные, в смысле с шагом. Они, что самое интересное, могут быть завязаны более чем на одну таблицу. Например, если мы хотим разнести функциональные и нефункциональные требования по разным таблицам (поскольку набор полей для них разный),  но хотим для них общее пространство идентификаторов, то в Postgre это решается очень даже элегантно. В MySQL придется городить, я даже пока плохо представляю что.

Обратная сторона медали тоже присутствует, куда ж без неё. 
Бесплатных, функциональных и удобных программ для администрирования MySQL пруд пруди. Может и для Postgre есть, но я не видел. Штатный PGAdmin, мягко скажем, корявка та ещё. Регистрозависимый синтаксис для имён таблиц в Postgre – это потенциальный источник багов. Кром того, таблицы, именованные в camelcase стиле требуют обрамления в кавычки, что требует их экранирования в коде, что требует недюжинного терпения. Да и в глазах рябит от подсветки синтаксиса каждой “заэскейпленой” кавычки.

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