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