Но и проблемы остались.
— Разработчики тратили время на оповещение тестировщика о готовности задачи, отвлекались и теряли контекст задачи при необходимости выкатки на тест.
Это легко решается:
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)
Наверно в моем случае правильнее использовать CQRS :)
Но всеравно есть агрегаты, которые тяжело восстанавливаются (Ну например, зачем восстанавливать аггрегат заказа с 1000 строк в заказе? везде и всегда)
во-вторых: Скорее всего Менеджер — это отдельная сущность, Адрес хоть и Value object, но хранится в отдельной табличке. Не дорого ли, ради DDD? клиентов, к примеру, вы можете восстанавливать из базы в 20 разных местах бизнесс-логики, но Менеджер используется в одном, Адресс используется в другом, и в итоге в 18 местах вы восстанавливаете из хранилища «консистентного» клиента с 2мя дополнительными запросами (ну или джойнами). Это мне никак не понять в DDD, как-будто это несущественные затраты, но нам, например, при отдаче REST запроса, оч важно сэкономить и 10ms (есть требование, чтобы ответы были в пределах 100ms) и вот эти лишние данные в клиенте в 80% случаях не нужны, но по DDD сущность нужно восстанавливать из хранилица тоже консистентной, даже если вы не пользуетесь всей сущностью.
Блин, было бы супер, если бы его можно было приспособить для browser-less консольной прогонки тестов UI. Сейчас это phantomjs — но он ужасно медленный.
Какое-то негативное к себе отношение у меня оставило TDD после использования. На одном из больших проектов писали активно юнит-тесты, было их 1800 штук, так вот больше всего убивало, что добавление маленькой логики (типа: а давайте юзеру добавим поле phone) по сути должно было реализовываться за 2ч — ломало 10-15 тестов… (т.к. изменялся интерфейс ключевой энтити проекта, а это и валидации, и сохраняторы, отображаторы и еще куча мест, где мог использоваться пользователь) и реализация была уже 3-4ч.
Плюс ко всему часто были ситуации, когда тесты работали, а бизнесс логика — нет. В итоге юнит-тестов стали писать меньше, больше ацептанс тестов, а позже вообще отказались — писали только ацептанс тесты. Да, они выполняются по 2ч, но! они написаны по кейсам бизнесс-логики и полностью отвечают спецификации, и в итоге не такие хрупкие, т.к. таким тестам всеравно как именно реализована фича — она просто должна работать, в тоже время TDD — заботится о том как именно реализовано что-то и не решает того, что это не работает вместе или не отвечает тркбованиям бизнесс логики.
Согласен, например у меня впринципе не возникает такких проблем, какие возникают у соседнего отдела, т.к. я принял другое решение на каком-то раннем этапе, хотя задачи похожие. И теперь та команда борется с ветрянными мельницами… а я могу лишь говорить «а я ведь говорил!» :) но формально тогда у меня небыло доказательств.
да, статья хорошая, но есть пару «но»
как бы заказчик не менял ТЗ, и как бы не пришлось менять бизнесс-логику — думать нужно всегда и пытаться писать идеальный код, можно писать тяп-ляп и это может работать, но написанный хорошо код будет легче саппортиться и он легче будет принимать капризы заказчика.
Жать на практике это доказать практически нереально. У меня часто возникают споры с другими синьерами -но нет времени проверить ту, либо другую архитектуру — заказчик никогда не заплатит за это, нужно просто что-то принять и работать дальше. Лишь спустя пол-года (зависит от частоты изменений и проекта) будет видно — правильное ли было принято решение. Так вот хороший программист отличается от посредственного тем, что он правильных решений принимает больше — его проект не скатывается в спагети через пол года, а остается более-менее читабельным, понятным.
Трудно понять что ты ошибся (или не ошибся) в момент анализа проблемы и реализации решения — на это нужен опыт (+, возможно, везение :))
… лять… ну почему же все так??
Вы этим топиком убили неколько убунту-пользователей, ожидающих от убунту доброжелательности и простоты.
З.Ы. нельзя установить плагин каким-то другим способом? более юзер френдли?
З.З.Ы. иммено это меня и беспокоит в опенсорсе — разработчкики пишут ДЛЯ СЕБЯ а не для пользователей… и им абсолютно пофиг кто и как это будет использовать: «м не нехватало, я написал для себя» и таким образом миллион полу рабочего софта в менджере пакетов синапсис… к чему я это: или пиши нормальный модуль, или пиши только ядл себя и никаму не показывай.
можно и так:
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) тогда надо придумывать механизмы сохранения данных на диск, дабы не потерять данные при краше.
переписал часть своего сервиса под редис — не могу нарадоваться :) Долго не мог привыкнуть к нерелеационному мышлению :) но в итоге теперь думаю нафиг этот монстр МуСКуЛ надо вообще!?
Автоп путает "асинхронность" и "паралельность" - это разные вещи.
Почему не прометей->grafana?
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
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
Но всеравно есть агрегаты, которые тяжело восстанавливаются (Ну например, зачем восстанавливать аггрегат заказа с 1000 строк в заказе? везде и всегда)
во-первых:
зачем? почему? есть много способов использовать это не правильно. Почему не
ну или именованный конструктор.
во-вторых: Скорее всего Менеджер — это отдельная сущность, Адрес хоть и Value object, но хранится в отдельной табличке. Не дорого ли, ради DDD? клиентов, к примеру, вы можете восстанавливать из базы в 20 разных местах бизнесс-логики, но Менеджер используется в одном, Адресс используется в другом, и в итоге в 18 местах вы восстанавливаете из хранилища «консистентного» клиента с 2мя дополнительными запросами (ну или джойнами). Это мне никак не понять в DDD, как-будто это несущественные затраты, но нам, например, при отдаче REST запроса, оч важно сэкономить и 10ms (есть требование, чтобы ответы были в пределах 100ms) и вот эти лишние данные в клиенте в 80% случаях не нужны, но по DDD сущность нужно восстанавливать из хранилица тоже консистентной, даже если вы не пользуетесь всей сущностью.
Вот, например, его реализация для ZF2: https://github.com/t4web/Infrastructure/blob/master/src/Repository.php
А вот, например, то как мы им пользуемся: https://github.com/t4web/Mail/blob/master/src/Listener/LogSending.php
Плюс ко всему часто были ситуации, когда тесты работали, а бизнесс логика — нет. В итоге юнит-тестов стали писать меньше, больше ацептанс тестов, а позже вообще отказались — писали только ацептанс тесты. Да, они выполняются по 2ч, но! они написаны по кейсам бизнесс-логики и полностью отвечают спецификации, и в итоге не такие хрупкие, т.к. таким тестам всеравно как именно реализована фича — она просто должна работать, в тоже время TDD — заботится о том как именно реализовано что-то и не решает того, что это не работает вместе или не отвечает тркбованиям бизнесс логики.
как бы заказчик не менял ТЗ, и как бы не пришлось менять бизнесс-логику — думать нужно всегда и пытаться писать идеальный код, можно писать тяп-ляп и это может работать, но написанный хорошо код будет легче саппортиться и он легче будет принимать капризы заказчика.
Жать на практике это доказать практически нереально. У меня часто возникают споры с другими синьерами -но нет времени проверить ту, либо другую архитектуру — заказчик никогда не заплатит за это, нужно просто что-то принять и работать дальше. Лишь спустя пол-года (зависит от частоты изменений и проекта) будет видно — правильное ли было принято решение. Так вот хороший программист отличается от посредственного тем, что он правильных решений принимает больше — его проект не скатывается в спагети через пол года, а остается более-менее читабельным, понятным.
Трудно понять что ты ошибся (или не ошибся) в момент анализа проблемы и реализации решения — на это нужен опыт (+, возможно, везение :))
В добавлении авто если выбрать марку\модель\год
Вы этим топиком убили неколько убунту-пользователей, ожидающих от убунту доброжелательности и простоты.
З.Ы. нельзя установить плагин каким-то другим способом? более юзер френдли?
З.З.Ы. иммено это меня и беспокоит в опенсорсе — разработчкики пишут ДЛЯ СЕБЯ а не для пользователей… и им абсолютно пофиг кто и как это будет использовать: «м не нехватало, я написал для себя» и таким образом миллион полу рабочего софта в менджере пакетов синапсис… к чему я это: или пиши нормальный модуль, или пиши только ядл себя и никаму не показывай.
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»:
Как люди могут хвалить столь ужасно написанный фреймворк/ЦМС ?!? под него же невозможно писать!
… или это только не программисты его хвалят? :)
Люди, старайтесь не юзать вордпрес, если планируете необычный (нереализованный) функционал :) а то это будет дорого стоить :)