в половине вопросов непонятен критерий оптимизации: а) мы хотим быстро выпустить хоть что-то б) мы хотим быстрый код в) мы хотим поддерживаемый код
Соответственно, оптимальности будут разными.
1а - чуток проверить и забить 1б - разбить это дикое уёжище на пачку независимых форм, отпрофилировать. как-то декларативно (make-образно) описать зависимости мелких кусочков кода. 1в - опять же отрефакторить, чтоб не было такого монстра. Например, сделать визард с логически сгруппированными зависимыми подгруппами.
2а - тупо реагировать на любое отклонение попытками его минимизации. 2б,в - уточнить зависимости этих параметров. Если они вполне независимы и нет нехороших лагов по времени, то держать каждый параметр, например, в пределах половины допустимого отклонения. 2б - необходимо ортогонализировать задачу. То есть, выбрать некий базис независимых управляющих операций и по каждому вектору отклонений выдавать ровно одну линейную комбинацию воздействий.
3 - пропущен вариант 'подсказать тестерам как именно проверить именно эту часть кода'. Скорее всего, там будут низкоприоритетные баги. Если мы хотим быстро выпустить проукт -- то на них забить, если мы хотим вылизанный продукт, то, пока контекст в голове, надо заняться именно этими багами.
4 - в случае 'в' надо делать очереди запросов и отдельные 'сервера' на диск, базу, консоль итп. Иначе при малом шевелении алгоритмов этих тредов мы скатимся до внезапных и трудноуловимых взаимоблокировок, особенно в случае 4б.
ответ 5а - это джоуэльсофтваре, 5б - обычный виндоус. тут, кстати, надо написать подробное техописание, как вся этаа система должна работать и почему. Потом разбить на независимые черные ящечки, потом написать быстрогрязно, потом долго профилировать.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
momijizukamori
no subject
Date: Saturday, 12 September 2009 09:40 (UTC)а) мы хотим быстро выпустить хоть что-то
б) мы хотим быстрый код
в) мы хотим поддерживаемый код
Соответственно, оптимальности будут разными.
1а - чуток проверить и забить
1б - разбить это дикое уёжище на пачку независимых форм, отпрофилировать. как-то декларативно (make-образно) описать зависимости мелких кусочков кода.
1в - опять же отрефакторить, чтоб не было такого монстра. Например, сделать визард с логически сгруппированными зависимыми подгруппами.
2а - тупо реагировать на любое отклонение попытками его минимизации.
2б,в - уточнить зависимости этих параметров. Если они вполне независимы и нет нехороших лагов по времени, то держать каждый параметр, например, в пределах половины допустимого отклонения.
2б - необходимо ортогонализировать задачу. То есть, выбрать некий базис независимых управляющих операций и по каждому вектору отклонений выдавать ровно одну линейную комбинацию воздействий.
3 - пропущен вариант 'подсказать тестерам как именно проверить именно эту часть кода'. Скорее всего, там будут низкоприоритетные баги. Если мы хотим быстро выпустить проукт -- то на них забить, если мы хотим вылизанный продукт, то, пока контекст в голове, надо заняться именно этими багами.
4 - в случае 'в' надо делать очереди запросов и отдельные 'сервера' на диск, базу, консоль итп.
Иначе при малом шевелении алгоритмов этих тредов мы скатимся до внезапных и трудноуловимых взаимоблокировок, особенно в случае 4б.
ответ 5а - это джоуэльсофтваре, 5б - обычный виндоус.
тут, кстати, надо написать подробное техописание, как вся этаа система должна работать и почему. Потом разбить на независимые черные ящечки, потом написать быстрогрязно, потом долго профилировать.