1. Обычно такого не бывает, потому что 4-5 человек всегда участвовали в разработке, и ещё 3-4 слышали краем уха. Иногда случается, что забывается, как оно было сделано, но и тут есть решения — первое — почитать тесты, второе — покопать код. Так как эти действия тоже совершаются парно, скоро память восстанавливается :)
2. Не совсем поняла вопроса. Вместе мы обычно работаем вначале каждой истории, при написании тестов. Аналитики и программисты сидят рядом, а из-за того, что программеры парятся, даже если аналитик не в паре, он слышит все обсуждения и при надобности, вставляет свои 5 копеек, лезет в код или начитает что-то объяснять.
3. Архитектора нет, ни формального, ни неформального. Некоторые немного лучше разбираются в некоторых вопросах, чем другие. Нередко возникают горячие дискуссии, идём спрашивать у клиента, привлекаем кого-то их другой команды, но в итоге приходим к решению.
4. Ой… пишем на Java… (ушла строки считать)
5. До погружения, конечно, зависит от способностей. 3 недели назад присоединился новые инжинер, уже в полном порядке и с кучей отлчных идей. Испытательный срок длится 3 месяца.
6. База есть, но очень простая — в основном для аудита и прочих логов. Практически все операции происходят в памяти. Для тестирования у нас разработана спецальная библиотека, и при надобности она делает запросы в БД. Я тольком не знаю, как она работает — если когда разберусь, напишу отдельно.
ПС. Строк около 1 000 500, из них тестов около 133 000.
Да, аналитики отлично разбираются в предметной области, а так же неплохо — в коде.
Требования от клиентов фильтруются сначала просто продажами-маркетингом (если мы это сделаем, кто ещё извлечёт от этого выгоду? Стоит ли игра свеч? Совпадает ли это с нашим направлением?), а позже — всеми остальными. У нас нет барьеров — и если инженер, проходя мимо беклога, или, после встречи планирования, решает, что требование бессмысленно, или трудновыполнимо, его мнение обсуждается и учитывается.
Новых сотрудников сначала обучают системе — один из опытных программистов проводит с ним полдня, рисуя на доске архитектуру системы и поясняя решения. Потом он начинает «париться» наравне с остальными — начиная задачами попроще.
Ещё у нас серьёзный испытательный срок — бывает, человек не приживается.
В основном — да, на доске.
Если функциональность немного более серьёзная, аналитик продумает всё заранее, но в итоге, опять-таки, «задокументирует» это на доске. В случае если решение сложное или черезчур оригинальное, фото доски выкладывается на корпоративную вики…
Качественный код достигается благодаря способным программистам :) и постоянному спариванию. Каждый принимает ответственность за свой кусок, и старается его сделать как можно лучше. Временами оказывается, что не всё было учтено, и приходится делать рефакторинг в середине итерации. При спаривании такой рефакторинг сложнее смести под ковёр.
Jira+GreenHopper звучат знакомо. У нас все процессы планования малотехнологичны :)
Этот фреймворк можно использовать не только для такой системы, а для любой другой где важна низкая латентость, высокая скорость и предсказуемое поведение.
Я не .NETчик и не JAVAчик, поэтому точно ответить не смогу.
Но у нас проблема в том, что некоторые операции должны происходить в чётком порядки FIFO — ведь система «играет» с настоящими деньгами. А если потоки начнут произвольно там что-то выполнять, клиенты от нас очень скоро смотаются.
Возможно неясно из моего поста, но данная система не находится в стадии прототипа, а была запущена год назад(октябрь 2010), и успешно функционирует, обрабатывая тысячи транзакций в секунду.
Сами буфферы весьма немаленькие — 20М слотов для входящего буффера и по 4М слотов для исходящих. Система буффера рестартуется ночью, во избежание дорогостоющего Garbage Collection.
А вы не в курсе, куда можно внести даты начала и конца каждой итерации? Я вчера полдня искала, и вроде никуда кроме экселя (iteration backlog, product planning) они не ставятся. А хотелось бы!
Система работает чуть более года, а разработка длилась около 3х лет.
Так же там хранилище финансовых процессов и требований регурирующей организации…
2. Не совсем поняла вопроса. Вместе мы обычно работаем вначале каждой истории, при написании тестов. Аналитики и программисты сидят рядом, а из-за того, что программеры парятся, даже если аналитик не в паре, он слышит все обсуждения и при надобности, вставляет свои 5 копеек, лезет в код или начитает что-то объяснять.
3. Архитектора нет, ни формального, ни неформального. Некоторые немного лучше разбираются в некоторых вопросах, чем другие. Нередко возникают горячие дискуссии, идём спрашивать у клиента, привлекаем кого-то их другой команды, но в итоге приходим к решению.
4. Ой… пишем на Java… (ушла строки считать)
5. До погружения, конечно, зависит от способностей. 3 недели назад присоединился новые инжинер, уже в полном порядке и с кучей отлчных идей. Испытательный срок длится 3 месяца.
6. База есть, но очень простая — в основном для аудита и прочих логов. Практически все операции происходят в памяти. Для тестирования у нас разработана спецальная библиотека, и при надобности она делает запросы в БД. Я тольком не знаю, как она работает — если когда разберусь, напишу отдельно.
ПС. Строк около 1 000 500, из них тестов около 133 000.
Если бездилинговая обработка напрямую — им пипсовщики выгодны.
Если есть вопросы — задавайте.
Требования от клиентов фильтруются сначала просто продажами-маркетингом (если мы это сделаем, кто ещё извлечёт от этого выгоду? Стоит ли игра свеч? Совпадает ли это с нашим направлением?), а позже — всеми остальными. У нас нет барьеров — и если инженер, проходя мимо беклога, или, после встречи планирования, решает, что требование бессмысленно, или трудновыполнимо, его мнение обсуждается и учитывается.
Новых сотрудников сначала обучают системе — один из опытных программистов проводит с ним полдня, рисуя на доске архитектуру системы и поясняя решения. Потом он начинает «париться» наравне с остальными — начиная задачами попроще.
Ещё у нас серьёзный испытательный срок — бывает, человек не приживается.
У нас половина народу на великах на работу добирается, они стройны, спортивны и красивы.
Тортами мы вообще грешим — последние 2 недели каждый день по несколько тортов, пирогов, коробок конфет…
Если функциональность немного более серьёзная, аналитик продумает всё заранее, но в итоге, опять-таки, «задокументирует» это на доске. В случае если решение сложное или черезчур оригинальное, фото доски выкладывается на корпоративную вики…
Качественный код достигается благодаря способным программистам :) и постоянному спариванию. Каждый принимает ответственность за свой кусок, и старается его сделать как можно лучше. Временами оказывается, что не всё было учтено, и приходится делать рефакторинг в середине итерации. При спаривании такой рефакторинг сложнее смести под ковёр.
Jira+GreenHopper звучат знакомо. У нас все процессы планования малотехнологичны :)
Disruptor — это новый подход к старым проблемам.
Но у нас проблема в том, что некоторые операции должны происходить в чётком порядки FIFO — ведь система «играет» с настоящими деньгами. А если потоки начнут произвольно там что-то выполнять, клиенты от нас очень скоро смотаются.
Сами буфферы весьма немаленькие — 20М слотов для входящего буффера и по 4М слотов для исходящих. Система буффера рестартуется ночью, во избежание дорогостоющего Garbage Collection.
Смысл партнёрки — это единственный ресурс на русском о LMAX
И частично перевод, да.
Правда, статья Фаулера и в оригинале плоховато читается.