Ответы на вопросы

[andrzejn]

Итак, ответы на программистские вопросы, которые я считаю правильными. Я постарался сформулировать их так, чтобы поняли непрограммисты.

1. Сложная форма ввода.
б) Лучше собрать все проверки и логику в одном месте и исполнять последовательно. Лучше делать на каждый чих сотни лишних проверок (которые пользователь всё равно не заметит), чем безуспешно искать ошибки и побочные эффекты в сотнях отдельных кусочков, которые связаны в неизвестном порядке.

2. Регулятор реактора.
б) Редкими коррекциями удерживать процесс в допустимой "зелёной зоне" куда лучше, чем непрерывно сражаться за недостижимый оптимум. Куда меньше износ аппаратуры и куда меньше шансов, что от непрерывной работы что-нибудь заглючит и поломается. А "зелёной зоны" субоптимальных результатов нам вполне достаточно.

3. Расчистка сомнительных мест.
а) Если есть время, любые проблемы лучше расследовать немедленно. Просто потому, что вы сейчас в контексте, помните все подробности и держите в голове все нужные модели. Если отложить разбирательство, потом потребуется куда больше времени на возврат к теме. Исправлять результаты расследования, кстати, можно и не немедленно, если окажется, что чинить придётся слишком сложные и отдалённые куски. Такой масштабный ремонт можно и отложить (записав все найденные подробности). Но перещупать подручные сомнения нужно сейчас, пока они под руками.

4. Синхронизация параллельных процессов.
б) Пока возможно (пока производительность не начинает из-за этого заметно падать), лучше держать одну общую блокировку на все разные критические ресурсы сразу: так не будет ни одного шанса, что несколько процессов захватят по ресурсу, потянутся за следующим и заблокируют друг друга.
Аналогия из реальной жизни: лучше сделать один общий замок на двери туалета, чем отдельные ширмы с замками на унитазе, умывальнике, коробочке с мылом и сушилке для рук.

5. Большая сложная программа.
б) Простые посредственные решения в долгосрочном масштабе лучше безупречно сложных, потому что их куда легче поддерживать. За десять лет команда частично сменится, а оставшиеся забудут старые подробности. В сложном коде они будут слишком долго исправлять найденные ошибки, слишком медленно добавлять новые возможности и сажать в процессе слишком много новых ошибок, так что новые версии будут слишком редки и полны проблем.
А надоедливые, но не критичные ошибки юзерам пофиг, лишь бы критические ошибки исправлялись, а важные возможности добавлялись быстро.

Как видите, решения выходят за рамки чисто программистских задач и вполне годятся для реальной жизни.

Comments

[pouce.livejournal.com]

В пятом случае я, пожалуй, выбрал бы другой вариант.

[amigofriend.livejournal.com]

Makes sense.

программистские ответы на вопросы 8)

[neo-der-tall.livejournal.com]

А Вам не кажется, что надо для начала бы определить критерий "правильности".

Пример, поведение выбранное в вопросе 3 приведет к увольнению человека, как тормоза и префекциониста в куче фирм работающих по критерию цена-качества. Т.к. а) трудозатраты на расследование и исправление, там где надо, очень труднопроверяемы б) расследовать можно до бесконечности с) программер сам выстроит приоритеты возможностей, не имея ни полномочий, ни представления о картине в целом.

По прочим ответам можно выдать аналогичные "фи"

[guns-linger-24.livejournal.com]

я правильно понимаю, что все ответы суммируются в "не будь перфекционистом"?)

Re

[granite-golem.livejournal.com]

Пропустил в своё время. В общем, однозначно соглашусь только по 2-му вопросу. А по поводу 3-го - программер имеет связь с тестерами? Может, просто указать тестерам эти возможно проблемные места, чтобы они проверили их вне очереди?

[beldmit.livejournal.com]

Ага! Ура, я программист :-)

[gouriev.livejournal.com]

я бы не поступил к вам на работу... наверное это и правильно.
не всем же писать "простые и очевидные для программистов реализации"

и вообще, ответ, который Вы хотите услышать,
явно подсказывается формой вопроса. но истина
в том, что все ситуативно. правильно, на хрен
нам логарифмическая сортировка, если и так
все ОК. А вот когда ОК не так все, вопрос решается
в точности противоположным образом.

кроме того, бывают сложные задачи, для которых
"простые" решения либо не существуют, либо
очень ограничивают... и отрицательно сказываются
на поддержке.

А еще бывают часто используемые задачи/функции,
"усложнение" которых может существенно упростить
решение соседних задач. например,

Вам как больше понравится, если одна функция сможет
переписывать блок информации из файла в файл, из
файла в сетевой поток, из памяти в файл, из одного
потока в другой, или если на каждый случай надо
будет иметь отдельную функцию?...

---
к жизни, ИМХО, эти соображения не все приложимы.
#1 и #4 - очень любят наши чиновники.
вот так создаются "очереди на таможне".
но это worst practice.

*взволнованно* у меня проблемы со здравым смыслом???

[portzia-breda.livejournal.com]

Практически уверена: верный ответ на первый вопрос - под буковкой "а".

Поясняю на ситуации...

Допустим.
Я - тестировщик. Мне приходит задание тестировать эту злосчастную форму со ста полями.
Как тестировщик, я обязана - без вариантов - протестировать каждое поле в этой форме. Желательно, с какими-нибудь извращенными вариантами входных данных и предшествующих ситуаций.

Предположим, проверка в поле за номером 37 дает внештатную ошибку, быть которой не должно.

Предположим, я вообще не трогаю поле за номером 37, зато залезаю в поле за номером, положим, 15. Сразу, с порога, потому что тестировщик я с фантазией и сначала наугад тыкаюсь, а потом уже смотрю недопрополотое скопом.

Итак, тыкаюсь я в это поле, и получаю свой родимый эксепшн.
Предположим, я тестировщик ленивый. В этом случае я завожу баг на поле за номером 15, потом тыкаюсь в другое поле, получаю тот же результат, завожу баг на него, и через пару итераций возвращаю всю форму взад со словами "не работает".

Предположим, я - тестировщик добросовестный. Тогда я сначала тыкаюсь в несколько полей подряд, а потом сразу возвращаю всю форму взад с комментарием "не работает ваапсче".

И все из-за проверки в поле за нумером 37. И предположим так же, что в этом поле за нумером 37 возникает незапланированная ошибка в таком положении, в которое программист всю эту форму ввода попросту не поставил, поскольку не его это, программистское, дело - ставить свою программу раком. В эту позу его программу тестировщик нагибает, профессия у него такая.

Внимание, вопрос: и таки сколько времени программист будет добираться до поля за нумером 37 при такой ситуации? Учитывая, что жалуются ему либо в формате "не работает поле номер 15", либо "вся ваша форма целиком дурная"?? А если ошибка в поле за нумером 57? А если - в связке 24, 63 и 98, и найдя только 24, программер еще два раза минимум обречен лицезреть ехидную рожу довольного жизнью тестера, возвращающего ему ВСЮ ФОРМУ ЦЕЛИКОМ взад??

Вопрос на засыпку: а вообще СКОЛЬКО ВРЕМЕНИ займет отладка ВСЕЙ формы целиком сначала самостоятельно, а потом еще при помощи въедливого тестера, если на любой чих в любом месте форма глючит В ЛЮБОМ ДРУГОМ, НЕ ПРЕДСКАЗУЕМОМ внешними эффектами месте?? Это правда, не та ситуация, когда "хотели как проще, а получилось на порядок дольше"???

И насколько было бы проще, если бы все эти проверки были разбиты на 100 НЕ ПЕРЕСЕКАЮЩИХСЯ ЛЕЖАЩИХ ОТДЕЛЬНО кусочков???

Вот честное слово, правда, как тестировщик говорю, работавший в свое время программером: ну не катит вариант "сложить все в кучу". Не катит. Разделять и властвовать надо, угу...

Или у меня таки проблемы в здравом смысле??? Я еще и в других ответах вижу тоже нестыковки, но лучше про них помолчу пока... Уж больно ЭТОТ вопрос меня волнует, право слово! Сойдемся если по его поводу мирно и тихо - тогда, может быть, про другие свои сомнения скажу... а может быть, и нет :) не знаю.

*ожидая ответа, заинтересованно-на-подъеме*, Алеф

[besm6.livejournal.com]

По 1 вопросу. Утверждение, что одна толстая проверка более управляема, чем сотня мелких, но грамотно запускаемых, мягко говоря, не очевидно. В приведенном условии зависимости по большей части локальны в том смысле, что _по условию_ от каждого изменения поползет конечное количество веток дальнейших изменений. Но расползаемость веток по тому же условию такова, что суммарная проверка крайне хреново линеаризуется (потрогали вот тут - поменялось там и здесь; по изменению "там" надо поменять еще вон там...). Зато хорошо ложится на модель триггера на изменение.

По 5 вопросу. Ага, "юзер обожает терпеть мелкие неудобства" (c) Витус Вагнер. Заложить в программу заметные человеку тормоза - это заложить в программу резкое снижение эффективности его работы. Если наша программа предназначена для имитации бурной деятельности - тогда, несомненно, вариант б), кто б сомневался...

[acode.livejournal.com]

Не согласен с 4-ым пунктом. Если кто-то из команды допустил возникновение дедлока, то это уже уровень начальной школы. А вот производительность программы падает от единой блокировки (особенно если там что-то связано с разбором событий и графикой) просто катастрофически.

[al-zatv.livejournal.com]

Вот с реактором - не соглашусь. Всё-таки не-оптимум для реактора - это может быть миллионы рублей прибыли, или солидный кусок богатства человечеству "за просто так". Я бы сделал двухуровневую систему. Пока реактор "в зелёной зоне", работает оптимизатор. При выходе в жёлтую - работает возвращатель в зелёную.

А вообще, ответы суммируют специфический опыт потокового производства софта для "лёгкой автоматизации" (офис, связь для офиса, утилитки). Суть этого опыта - "сделать быстро и просто, а затем улучшить если надо будет". Это работает, и у меня он такой же. Но думаю что в реакторы с этим "уставом" лучше не лезть:)