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

[andrzejn]

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

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

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

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

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

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

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

Comments

[pouce.livejournal.com]

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

[amigofriend.livejournal.com]

Makes sense.

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

[neo-der-tall.livejournal.com]

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

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

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

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

[andrzejn]

В 3 дано условие, что времени достаточно для проверки.

Насчёт выбора критериев - можно в ответах добавлять недостающие условия, это же не ЕГЭ.

условие типа "если Вы - бог" 8)

[neo-der-tall.livejournal.com]

ну ок, согласен. Из развернутых ответов, или даже из развернутых отказов от ответов, можно многое вытянуть. Но вот на сколько это много будет иметь дело к тем качествам, что необходимы хорошему программеру...8)

[guns-linger-24.livejournal.com]

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

[andrzejn]

Угу. Или традиционно: "Keep it simple, stupid!"

Re

[granite-golem.livejournal.com]

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

Re: Re

[andrzejn]

Это вариант ответа "Отложить разбирательство на потом". Если программист ограничен во времени - да, так и надо. Но суммарные затраты времени в этом случае будут больше.

Re: Re

[beldmit.livejournal.com]

Вариант, да. По факту, кстати, контекст может быть и не тот.

[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 НЕ ПЕРЕСЕКАЮЩИХСЯ ЛЕЖАЩИХ ОТДЕЛЬНО кусочков???

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

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

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

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

[andrzejn]

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

Затем, если он правильный программист (см. вопрос 3), он просматривает процедуру и исправляет свои аналогичные косяки везде, не дожидаясь новых багрепортов.

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

Альтернатива с сотней процедур: исправляя баг в 37, программист включает логику (ранее ошибочно не работавшую), которая изменяет значения в (уже проверенных тестером) полях 10, 11 и 15. Теперь там начнут стрелять баги, но тестер их не заметит, пока не пойдёт перетестировать все поля заново. А с общей процедурой - заметил бы сразу.

(Да, я согласен, подобная форма - в любом случае угробище, но иногда клиенты настаивают именно на угробище.)

Мои пять вопросов - они ведь не умозрительные, а из опыта, пробовали так и эдак, наступали на разные грабли...

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

[portzia-breda.livejournal.com]

по-го-ди-те.

если я верно улавливаю смысл происходящего, в формате "вся сотня проверок на каждый чих" для КАЖДОГО поля сообщение об ошибке индивидуальное - иначе описываемый вами алгоритм был бы невозможен (в самом деле, иначе откуда, не делая стоп-кадр на каждой проверке последовательно, программер видит СРАЗУ, что падает именно 37 поле, а не какое-то иное??)

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

второе.
А если в этой чудо-форме имеется Х полей, не допускающих оставления их пустыми.
получается, программер должен изобретать способ определять, когда это условие проверять, а когда нет?? Это будет очень сложное, длинное условие, наиболее вероятно, что в первую очередь ошибки полезут именно из него, и стоит ли раздувать код на это самое заковыристое условие, а время на отладку тратить на его проверку??


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

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

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

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

[al-zatv.livejournal.com]

в подобном случае из практики я выбрал тоже одну общую проверку. На то оно и окно ввода, что все значения взаимозавязаны друг с другом, иначе накой 100 полей ввода в одном окне? А проверки, размазанные по всему коду - душераздирающее, мерзкое зрелище.

Re:

[portzia-breda.livejournal.com]

*радуется, что свалила из рядов программистов*

*чешет в затылке*

[portzia-breda.livejournal.com]

Альтернатива с сотней процедур: исправляя баг в 37, программист включает логику (ранее ошибочно не работавшую), которая изменяет значения в (уже проверенных тестером) полях 10, 11 и 15. Теперь там начнут стрелять баги, но тестер их не заметит, пока не пойдёт перетестировать все поля заново. А с общей процедурой - заметил бы сразу.

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

Или таки это сотня проверок, которые ВСЕ взаимосвязаны друг с другом?? Вот прямо все, без точек разрыва???

простите, если так - я ОЧЕНЬ хочу увидеть эту форму. ОЧЕНЬ. У меня просто нездоровое любопытство, шило в одном месте, и реально я ХОЧУ ВИДЕТЬ ЭТОТ ШЕДЕВР ... кхм... ладно, промолчу чего

//а что повторно начнут стрелять баги - таки а регрессионное тестирование на что? а тестирование бизнес-юзерами?

и кстати!! кстати, о птичках!! Каким это местом тестер тестирует данную форму, если он НЕ ЗНАЕТ алгоритма проверок?? Не программерского, разумеется, а бизнес-алгоритма, но все же из которого следует, что баг в 37 может повлиять на 10, 11 и 15??? Как это он тестирует данный шедевр?? И кому надо просветляться в случае, если дело у него именно так поставлено? Как бы не уже его тим-лиду, а?

Re: *чешет в затылке*

[andrzejn]

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

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

Да, это из реального опыта. Сотен полей у нас не было, но десятков семь-восемь - бывало. Более-менее кластеризовались, но с отдельными связями между кластерами, так что один чёрт.

Re: *чешет в затылке*

[portzia-breda.livejournal.com]

:)

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

всякие выверты на свете бывают, вот что точно

*прислонившись головой к стенке*

[portzia-breda.livejournal.com]

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


вот смотрите:

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

Затем, если он правильный программист (см. вопрос 3), он просматривает процедуру и исправляет свои аналогичные косяки везде, не дожидаясь новых багрепортов.

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

Альтернатива с сотней процедур: исправляя баг в 37, программист включает логику (ранее ошибочно не работавшую), которая изменяет значения в (уже проверенных тестером) полях 10, 11 и 15. Теперь там начнут стрелять баги, но тестер их не заметит, пока не пойдёт перетестировать все поля заново. А с общей процедурой - заметил бы сразу.

Я не помню точную формулу рассчета ошибок в программе исходя из размера кода. Она какая-то есть.
Допустим, всего в процессе кодинга на эти сто полей допущено 50 багов (я оптимист, да)

в варианте "на каждое поле проверяются все остальные поля" мы имеем следующий алгоритм:

- до тех пор, пока в каком-то (любом) поле имеется ошибка, тестер на каком-то (любом другом) поле на нее натыкается и не может продуктивно тестировать форму дальше, пока эта ошибка не будет исправлена

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

- программер исправляет все ошибки, которые он находит. В меру его фантазии. После чего возвращает программу тестеру.

- весь цикл повторяется до тех пор, пока из формы не будут вычищены ВСЕ ошибки. Если это произойдет за 10 итераций, это, пожалуй, будет КРУТО

- особая прелесть алгоритма в том, что любая ошибка на форме блокирует работу тестера до внесения исправлений программистом, и пока программер ползает по коду в поисках тараканов, тестер балду пинает.

- количество итераций практически не просчитываемо. И оно не зависит от мастерства программиста, сколько бы он ни получал по шапке: так устроен процесс и В ЭТОЙ СХЕМЕ иначе быть просто не может.

----------

и вот этот момент меня смущает больше всего. Я могу себе представить, что эта схема работает и оправдана при одном единственном варианте: отдела тестирования на фирме нет вообще. Как класса.

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

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

-----

если что, еще раз извините. Я не программер, да :) но пример задевает за живое тока так

[besm6.livejournal.com]

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

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

[portzia-breda.livejournal.com]

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

[andrzejn]

Триггеры (самый известный их вариант - в базах данных) тоже весьма хреново отлаживать и поддерживать, и чем сложнее логика - тем хуже. Пробов ли не раз. Слишком много вылезает непредвиденных каскадных зависимостей.

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

[besm6.livejournal.com]

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

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

Кстати, подумалось еще и про блокировки. Да, с виду кажется, что правильный вариант - б). Но на практике, конечно, выяснится, что реальная толстая база данных таки блокируется на время, недопустимо большое для блокировки интерфейса - и вот тут начнется... И чтобы тут не началось, надо продумывать раздельные блокировки заранее. Благо алгоритм предотвращения дедлоков - он тупой, только дисциплины требует. А так даже автоматизировать можно...

И кстати, аналогия из реальной жизни тут реально хороша, если вдуматься. Совмещенный санузел, наша прелесссть... Попробуйте пописать, когда надо бежать на работу, а теща принимает душ...

[acode.livejournal.com]

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

[al-zatv.livejournal.com]

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

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

[andrzejn]

Пример с реактором - реальный, нам его рассказывал преподаватель теории управления, чья лаборатория выиграла конкурс на исполнение этого регулятора. Правда, реактор был не ядерный, а химический.