![[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. Большая сложная программа.
б) Простые посредственные решения в долгосрочном масштабе лучше безупречно сложных, потому что их куда легче поддерживать. За десять лет команда частично сменится, а оставшиеся забудут старые подробности. В сложном коде они будут слишком долго исправлять найденные ошибки, слишком медленно добавлять новые возможности и сажать в процессе слишком много новых ошибок, так что новые версии будут слишком редки и полны проблем.
А надоедливые, но не критичные ошибки юзерам пофиг, лишь бы критические ошибки исправлялись, а важные возможности добавлялись быстро.
Как видите, решения выходят за рамки чисто программистских задач и вполне годятся для реальной жизни.
Re: *взволнованно* у меня проблемы со здравым смыслом???
если я верно улавливаю смысл происходящего, в формате "вся сотня проверок на каждый чих" для КАЖДОГО поля сообщение об ошибке индивидуальное - иначе описываемый вами алгоритм был бы невозможен (в самом деле, иначе откуда, не делая стоп-кадр на каждой проверке последовательно, программер видит СРАЗУ, что падает именно 37 поле, а не какое-то иное??)
в то время как в формате "на каждое поле по проверке" мы можем спокойно написать всего одно сообщение об ошибке и вешать его к каждому полю. Все равно будет однозначно понятно, что угроблено.
Смысл раздувать код на сто разных сообщений об ошибке?
второе.
А если в этой чудо-форме имеется Х полей, не допускающих оставления их пустыми.
получается, программер должен изобретать способ определять, когда это условие проверять, а когда нет?? Это будет очень сложное, длинное условие, наиболее вероятно, что в первую очередь ошибки полезут именно из него, и стоит ли раздувать код на это самое заковыристое условие, а время на отладку тратить на его проверку??
(я понимаю, что вопросы не умозрительные, но в режиме мысленного эксперимента у меня получается, что вы как-то между возможностью сказать "я отвечаю, что эти, эти и эти куски работают, а эти - может быть, нет" и "я не могу отвечать ни за что, пока не заработает все"...
еще проще: проигрывая себе ситуацию в мысленном поле, я вижу предложение считать некое существо либо полностью жизнеспособным, либо полностью нежизнесопосбным, в то время как оно могло бы быть жизнеспособным частично и при этом удовлетворять нужным требованиям...
у меня ощущение, что вы защищаете случай из практики, в котором вы выбрали слишком сложный путь, прошли его и теперь считаете, что только так и надо... извините)
Re: *взволнованно* у меня проблемы со здравым смыслом???
Re: