Извините за занудство, но кажется вы изобрели git-flow опять :)
nvie.com/posts/a-successful-git-branching-model

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

Это легко решается:
1. статус в jira разраб после in-progres (ну или после review) переводит в статус ready-for-test
2. вам нужны динамические тест окружения — это когда задача FEATURE-123 автоматически выливается на хост feature-123.your.domian.com — и тестировщик тестит ее — все баги виливаются тудаже — делается автоматически без участия разраба или тестировщика (ну или одной кнопкой в CI) — по хуку в task-менеджере, при переходе в статус ready-for-test

Я увидел DPE
D — description — краткая формулировка
P — plan — полан действий, даже для опытных кодеров, они, этот план могут сами для себя написать
E — exit — use cases, короткий кейс тестирования, который может провести кодер сам, чтобы убедится, что задача завершена и ее можно отдавать в тестирование

и все сложилось :)

Мы реализовали тоже самое :)
https://github.com/t4web/EventSubscriber/ — конфигуратор обработчиков событий — это для того, чтобы все собития в системе были описаны в конфиге и было видно какие именно обработчики (и в каком порядке) выполняются на определенное событие.
https://github.com/t4web/DomainModule — Доменная модель, с репозиторием
https://github.com/sebaks/zend-mvc-controller — а еще создали абстракцию над контроллерами зенда (по сути паттерн Команда), что позволило абстрагировать обработчик URI от его окружения
https://github.com/sebaks/view — есть еще конфигуратор view, который позволяет описывать повторяющиеся html-блоки и использовать их повторно (с возможностью замены логики отображения ViewModel)

+ еще куча модулей — https://github.com/t4web

Наверно в моем случае правильнее использовать CQRS :)
Но всеравно есть агрегаты, которые тяжело восстанавливаются (Ну например, зачем восстанавливать аггрегат заказа с 1000 строк в заказе? везде и всегда)

Спасибо за статью, но
во-первых:

$client = $builder->setId($id)
    ->setName($name)
    ->setGeneralManagerId($generalManager)
    ->setCorporateForm($corporateForm)
    ->setAddress($address)
    ->buildClient();

зачем? почему? есть много способов использовать это не правильно. Почему не

$client = $builder->buildClient($id,
    $name,
    $generalManager,
    $corporateForm,
    $address);

ну или именованный конструктор.

во-вторых: Скорее всего Менеджер — это отдельная сущность, Адрес хоть и Value object, но хранится в отдельной табличке. Не дорого ли, ради DDD? клиентов, к примеру, вы можете восстанавливать из базы в 20 разных местах бизнесс-логики, но Менеджер используется в одном, Адресс используется в другом, и в итоге в 18 местах вы восстанавливаете из хранилища «консистентного» клиента с 2мя дополнительными запросами (ну или джойнами). Это мне никак не понять в DDD, как-будто это несущественные затраты, но нам, например, при отдаче REST запроса, оч важно сэкономить и 10ms (есть требование, чтобы ответы были в пределах 100ms) и вот эти лишние данные в клиенте в 80% случаях не нужны, но по DDD сущность нужно восстанавливать из хранилица тоже консистентной, даже если вы не пользуетесь всей сущностью.

Мы у себя в компании используем вот такой репозиторий: https://github.com/t4web/DomainInterface/blob/master/src/Infrastructure/RepositoryInterface.php

Вот, например, его реализация для ZF2: https://github.com/t4web/Infrastructure/blob/master/src/Repository.php

А вот, например, то как мы им пользуемся: https://github.com/t4web/Mail/blob/master/src/Listener/LogSending.php

Блин, было бы супер, если бы его можно было приспособить для browser-less консольной прогонки тестов UI. Сейчас это phantomjs — но он ужасно медленный.

Какое-то негативное к себе отношение у меня оставило TDD после использования. На одном из больших проектов писали активно юнит-тесты, было их 1800 штук, так вот больше всего убивало, что добавление маленькой логики (типа: а давайте юзеру добавим поле phone) по сути должно было реализовываться за 2ч — ломало 10-15 тестов… (т.к. изменялся интерфейс ключевой энтити проекта, а это и валидации, и сохраняторы, отображаторы и еще куча мест, где мог использоваться пользователь) и реализация была уже 3-4ч.

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

Согласен, например у меня впринципе не возникает такких проблем, какие возникают у соседнего отдела, т.к. я принял другое решение на каком-то раннем этапе, хотя задачи похожие. И теперь та команда борется с ветрянными мельницами… а я могу лишь говорить «а я ведь говорил!» :) но формально тогда у меня небыло доказательств.

да, статья хорошая, но есть пару «но»
как бы заказчик не менял ТЗ, и как бы не пришлось менять бизнесс-логику — думать нужно всегда и пытаться писать идеальный код, можно писать тяп-ляп и это может работать, но написанный хорошо код будет легче саппортиться и он легче будет принимать капризы заказчика.

Жать на практике это доказать практически нереально. У меня часто возникают споры с другими синьерами -но нет времени проверить ту, либо другую архитектуру — заказчик никогда не заплатит за это, нужно просто что-то принять и работать дальше. Лишь спустя пол-года (зависит от частоты изменений и проекта) будет видно — правильное ли было принято решение. Так вот хороший программист отличается от посредственного тем, что он правильных решений принимает больше — его проект не скатывается в спагети через пол года, а остается более-менее читабельным, понятным.

Трудно понять что ты ошибся (или не ошибся) в момент анализа проблемы и реализации решения — на это нужен опыт (+, возможно, везение :))

чувствуется влияние pivotaltracker'а на Вас :)

а на kermo.ua сервис подсчитывает примерную стоимость авто при продаже.
В добавлении авто если выбрать марку\модель\год

можно и так:
usort($objectSetForSort, array ($this, "_sortByStartTime"));

а объект $objectSetForSort должен содержать метод:
private function _sortByStartTime ($el1, $el2) {
return ($el1->start_time > $el2->start_time)? +1: -1;
}

и не нужны замыкания.

не совсем понятен вопрос.
PDO+SQLite в класическом исполнении медленее ровно настолько, насколько медленнее обращение к диску чем к памяти.
если же PDO+SQLite (in MEMORY only) тогда надо придумывать механизмы сохранения данных на диск, дабы не потерять данные при краше.

упс, рано
function getAllItems() {
$items = array();

$dbconn = redis_pool::getConn();

$iids = $dbconn->get_members('items.set');

foreach($iids as $iid) {
$item = $dbconn->get('items.'.$iid);
if (!empty($item)) {
$items[] = $item;
}
}

return $items;
}
где в ключе «items.ID» сериализированный масив полей айтема.

переписал часть своего сервиса под редис — не могу нарадоваться :) Долго не мог привыкнуть к нерелеационному мышлению :) но в итоге теперь думаю нафиг этот монстр МуСКуЛ надо вообще!?

Пример «SELECT * FROM table»: