![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Ответы на вопросы
Итак, ответы на программистские вопросы, которые я считаю правильными. Я постарался сформулировать их так, чтобы поняли непрограммисты.
1. Сложная форма ввода.
б) Лучше собрать все проверки и логику в одном месте и исполнять последовательно. Лучше делать на каждый чих сотни лишних проверок (которые пользователь всё равно не заметит), чем безуспешно искать ошибки и побочные эффекты в сотнях отдельных кусочков, которые связаны в неизвестном порядке.
2. Регулятор реактора.
б) Редкими коррекциями удерживать процесс в допустимой "зелёной зоне" куда лучше, чем непрерывно сражаться за недостижимый оптимум. Куда меньше износ аппаратуры и куда меньше шансов, что от непрерывной работы что-нибудь заглючит и поломается. А "зелёной зоны" субоптимальных результатов нам вполне достаточно.
3. Расчистка сомнительных мест.
а) Если есть время, любые проблемы лучше расследовать немедленно. Просто потому, что вы сейчас в контексте, помните все подробности и держите в голове все нужные модели. Если отложить разбирательство, потом потребуется куда больше времени на возврат к теме. Исправлять результаты расследования, кстати, можно и не немедленно, если окажется, что чинить придётся слишком сложные и отдалённые куски. Такой масштабный ремонт можно и отложить (записав все найденные подробности). Но перещупать подручные сомнения нужно сейчас, пока они под руками.
4. Синхронизация параллельных процессов.
б) Пока возможно (пока производительность не начинает из-за этого заметно падать), лучше держать одну общую блокировку на все разные критические ресурсы сразу: так не будет ни одного шанса, что несколько процессов захватят по ресурсу, потянутся за следующим и заблокируют друг друга.
Аналогия из реальной жизни: лучше сделать один общий замок на двери туалета, чем отдельные ширмы с замками на унитазе, умывальнике, коробочке с мылом и сушилке для рук.
5. Большая сложная программа.
б) Простые посредственные решения в долгосрочном масштабе лучше безупречно сложных, потому что их куда легче поддерживать. За десять лет команда частично сменится, а оставшиеся забудут старые подробности. В сложном коде они будут слишком долго исправлять найденные ошибки, слишком медленно добавлять новые возможности и сажать в процессе слишком много новых ошибок, так что новые версии будут слишком редки и полны проблем.
А надоедливые, но не критичные ошибки юзерам пофиг, лишь бы критические ошибки исправлялись, а важные возможности добавлялись быстро.
Как видите, решения выходят за рамки чисто программистских задач и вполне годятся для реальной жизни.
1. Сложная форма ввода.
б) Лучше собрать все проверки и логику в одном месте и исполнять последовательно. Лучше делать на каждый чих сотни лишних проверок (которые пользователь всё равно не заметит), чем безуспешно искать ошибки и побочные эффекты в сотнях отдельных кусочков, которые связаны в неизвестном порядке.
2. Регулятор реактора.
б) Редкими коррекциями удерживать процесс в допустимой "зелёной зоне" куда лучше, чем непрерывно сражаться за недостижимый оптимум. Куда меньше износ аппаратуры и куда меньше шансов, что от непрерывной работы что-нибудь заглючит и поломается. А "зелёной зоны" субоптимальных результатов нам вполне достаточно.
3. Расчистка сомнительных мест.
а) Если есть время, любые проблемы лучше расследовать немедленно. Просто потому, что вы сейчас в контексте, помните все подробности и держите в голове все нужные модели. Если отложить разбирательство, потом потребуется куда больше времени на возврат к теме. Исправлять результаты расследования, кстати, можно и не немедленно, если окажется, что чинить придётся слишком сложные и отдалённые куски. Такой масштабный ремонт можно и отложить (записав все найденные подробности). Но перещупать подручные сомнения нужно сейчас, пока они под руками.
4. Синхронизация параллельных процессов.
б) Пока возможно (пока производительность не начинает из-за этого заметно падать), лучше держать одну общую блокировку на все разные критические ресурсы сразу: так не будет ни одного шанса, что несколько процессов захватят по ресурсу, потянутся за следующим и заблокируют друг друга.
Аналогия из реальной жизни: лучше сделать один общий замок на двери туалета, чем отдельные ширмы с замками на унитазе, умывальнике, коробочке с мылом и сушилке для рук.
5. Большая сложная программа.
б) Простые посредственные решения в долгосрочном масштабе лучше безупречно сложных, потому что их куда легче поддерживать. За десять лет команда частично сменится, а оставшиеся забудут старые подробности. В сложном коде они будут слишком долго исправлять найденные ошибки, слишком медленно добавлять новые возможности и сажать в процессе слишком много новых ошибок, так что новые версии будут слишком редки и полны проблем.
А надоедливые, но не критичные ошибки юзерам пофиг, лишь бы критические ошибки исправлялись, а важные возможности добавлялись быстро.
Как видите, решения выходят за рамки чисто программистских задач и вполне годятся для реальной жизни.
*чешет в затылке*
эти все сто полей проверками прямо вся сотня лавинообразно связаны?? какой-то вариант странный. Скорее всего, там поля на кластеры можно поделить, так, чтобы проверки из одного кластера никак не затрагивали проверки в другом кластере. И тогда уж, если совсем-совсем прямо никак проверить каждое поле по отдельности - проверять покластерно, но не все сто полей за раз, это слишком усложняет процесс. В том числе и "просветления" все эти программеру нужно именно из-за этого получать.
Или таки это сотня проверок, которые ВСЕ взаимосвязаны друг с другом?? Вот прямо все, без точек разрыва???
простите, если так - я ОЧЕНЬ хочу увидеть эту форму. ОЧЕНЬ. У меня просто нездоровое любопытство, шило в одном месте, и реально я ХОЧУ ВИДЕТЬ ЭТОТ ШЕДЕВР ... кхм... ладно, промолчу чего
//а что повторно начнут стрелять баги - таки а регрессионное тестирование на что? а тестирование бизнес-юзерами?
и кстати!! кстати, о птичках!! Каким это местом тестер тестирует данную форму, если он НЕ ЗНАЕТ алгоритма проверок?? Не программерского, разумеется, а бизнес-алгоритма, но все же из которого следует, что баг в 37 может повлиять на 10, 11 и 15??? Как это он тестирует данный шедевр?? И кому надо просветляться в случае, если дело у него именно так поставлено? Как бы не уже его тим-лиду, а?
Re: *чешет в затылке*
Разница между одной большой общей процедурой и сотней специализированных только в том, что в большой процедуре каждый раз исполняется вся логика и в чётко указанном порядке, а мелкие процедурки вызываются в неопределённом порядке и ещё каскадно-косвенно вызывают друг друга, когда логика одного поля меняет значения нескольких других, те отрабатывают свою логику, затрагивают следующие...
Да, это из реального опыта. Сотен полей у нас не было, но десятков семь-восемь - бывало. Более-менее кластеризовались, но с отдельными связями между кластерами, так что один чёрт.
Re: *чешет в затылке*
это как раз тот момент, когда мне хочется взять сигарету и изобразить из себя эдакую "светскую задумчивую даму" ))) не потому, что никотин, в целом-то я не курю, а больно уж образ привязчивый...
всякие выверты на свете бывают, вот что точно