Дребните проблеми

Всички сме се сблъсквали с т.нар. features - проблеми, които не са достатъчно големи, за да бъдат наречени бъгове, но все пак съществуват. Понякога поправянето им е тривиално, понякога - не много, а понякога извън възможностите ни - примерно, защото използваме чужда библиотека.

Как смятате, струва ли си да се опитваме да ги решаваме, или е по-добре да се концентрираме в развитието на софтуера по-нататък? Има ли смисъл да търсим съвършенство, благодарение на което хората спокойно ще използват продуктите ни, без да мислят, че това, това и това не работи или е по-добре да им кажем да стиснат зъби и да чакат новите хубавини в следващия ни продукт, а с това да се примирят?

Темата ми дойде в главата, след дискусия в Linux, където Митко (знаете кой) твърди, че добрият мениджър избягва потенциално опасните практики, а не решава проблемите, поради които тези практики са опасни. Доводите можете да ги видите сами в постинга му.

Според мен е прав човека, трябва да се предвиждат и избягват потенциални проблеми. Това си е част от задълженията на ръководството на проекта.
В даден порект времето и ресурсите са разпределени и са в предварително определено количество. Не е разумно да се разчита на допълнителни ресурси само за да се поправи някакъв незначителен faeture...

Ръководството трябва да реши в зависимост от важноста на проблема какво да предприеме...

Ако има свободни ресурси, ще се поправи(заобиколи или замаже).
Ако няма, ще се напишат 2 реда в "ReadMeFirst.txt"...
Ако няма, но проблема е важно да се премахне - намират се допълнително ресурси...

В отговор на:

---

добрият мениджър избягва потенциално опасните практики, а не решава проблемите, поради които тези практики са опасни.

---

Мдам затова имаме толкова "добри" мениджъри в България. Е не казвам, че трябва да се втурваме с главата напред и да оправяме всяка неправда, но пък да се водим основно от страх от някакви потенциални проблеми е глупаво.

Много добър подход, който се опитвам да използвам: виждам глупав проблем, виждам няколко варианта за решаването му - всичките степенувани по количество усилия, качество на решението и т.н. Харесвам си най-хубавия за мен и почвам. Предварително слагам таймаут - ако до определено време нямам решение или поне индикация за успех дърпам ръчката за катапулта и правя най-лесния workaround, че все пак да не застрашавам крайната цел. Опитвам се да не вграждам workaround-ите с бетон в програмата, така че после да мога да ги разкарам когато остане време или се появи реална нужда за сериозно решение.

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

е че винаги проблемът може да изкочи пак.

Конкретно в случая обсъждахме дали може да се използва # в име на share, при положение, че # е начало на коментар и еди-каква си реализация не се справя с това, че e escape-нат. Та човекът мисли, че този бъг и да го оправиш тук, може пак да се появи в друга реализация, следователно не трябва да се използва # изобщо.

Обяснявам всичко това, защото може би не съм изложил ясно проблема, та да се знае.

Лично моето мнение е, че човек трябва да се стреми към чист код, тоест да има задача с по-нисък приоритет да се оправят всички известни бъгове. Почти винаги се намират програмисти, които са свободни в даден момент и може да се отдели време. Освен че клиентите ще са доволни в крайна сметка, нещо, което е ценно, хората ще свикнат да внимават и да не допускат такива грешки в бъдеще.

Добрия мениджър избягва проблемите, а не се втурва с главата напред да разбива стената. Предварително се постарава да избегне препятствията, а ако в процеса на работа се натъкне на проблем се справя по начина който си описал...

Прочетох оригиналния пост и видях за какво е бил разговора. Наистина в оня случай май е по-добре да не се кръщават директории с #, щото не знаеш къде ще ти върви програмата. По-добрия вариант май е да проверяваш и да се оплакваш на потребителя, че # е лош символ и не го поддържаш.

Аз подкрепям идеята за чист код, но искам да ида до по-големи крайности. Оправянето на дефекти не трябва да е с нисък ами с най-висок приоритет. В елиминирането на дефект включвам възможността за просто решение докато не потрябва сложното, разбира се. Това е в основата на Total Quality Management идеята, която, в кратки думи, твърди, че дефектите трябва да се елиминират веднага и на всяко ниво от производството. Отделите за контрол на качеството на края на процеса не са достатъчни.

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

В отговор на:

---

не се втурва с главата напред да разбива стената

---

И аз се опитах да кажа нещо такова. Просто исках да спомена, че крайността, да си ръководим всяко действие от страх няма да ни доведе до никъде.

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

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

Нека допуснем че говорим за бъг, в който при изтриване на редове от дадена таблица не се изтриват съответните им с Foreign Key от друга (т.е. забравили сме да реализираме referential integrity).

Вариант А - бъгът е на административна форма която се ползва веднъж от администратора при началното уснановяване на системата и след това я се пипне я не. Ще останат 2-3 осиротели записа. Приоритет - нисък.

Вариант Б - бъгът е на форма която се ползва постоянно от потребителите, осиротелите записи са 10 000 на ден и постоянно запълват таблицата, индексите растат, прозиводителността намалява, има опасност от свършване на дисковото място. Приоритет - висок.

Така става ли?

Моето мнение е че в определен момент един "програмист" трябва да се лиши от манията си за "чист код". Иначе се почва един тъп спор от рода на:
Разумно мислещ човек: "Ама клиентите го искат това fix-нато. ТРЯБВА ИМ!"
"Програмист": "Мнее. Това ще ми развали кода. Те не знаят какво искат."
???
Ами ще развали кода. И?
За да не изкочи пак проблема трябва да има нормални тестови процедури. Дори те да са само в главата на този, който е променил кода. Severity-то на проблема винаги определя какво трябва да се fix-не първо.
10 request-а за един проблем - severity high.
1 request - low
Не е казано, че всички приблеми трябва да се решат в един fix.
Както и да е. Май се отплеснах. Идеята ми е, че "чист код" и fix-ване не проблеми е trade-off и е по-логично да се fix-не проблема вместо да се измислят излишни оправдания за пред клиента.

/*
Through counter-intelligence it should be possible to
pinpoint potential trouble-makers... And neutralize them,
neutralize them, neutralize them
*/

В отговор на:

---

Това ще ми развали кода.

---

Ако дефинираме качеството за кода като свойството му бързо да изпълнява изискванията на клиента и лесно да задоволява промените в горните какво ще получим? Искам да постулирам, че код, който може да се "развали" от промяна на изискване всъщност е с ниско качество -- бил е развален преди много време.

Искам да кажа, че е възможно да се правят компромиси само във функционалността. Колко пъти съм се ядосвал, че съм свалил стандарта за качество заради някой изтичащ срок и в края на краищата нещата стават и по-бавно и по-зле.
Напълно подкрепям Боб Мартин в апела "We will not ship shit!" [линк]

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

Т. нар. малки проблеми наистина са много интересна тематика, най-малкото защото твърде често прерастват в проблеми от огромни .
Нямаме кой знае колко избор за това дали да ги има или не - винаги ги има... Най-добрия подход да се справяме с тях, според мен е:
- Мениджъра завършва план за проекта от гледна точка на време/качествени характеристики.
- След това заедно с някой ( до ко наречем тим лидера ), разпределят тази работа в задачи и "човеко-часове".
- Въпросния тим лидер, като човека който има както ръководни задължения, така и техническото познаване, анализира задачите като отделни такива и като всързани в едно части - с цел да предвиди колкото в възможно повече такива проблеми - тук обаче нещата тепърва започват...
- После тим лидъра, приоритизира тези проблеми и прави опит да преразпредели (не изоснови) задачите, и да "имъкне" от мениджъра още малко ресурс за да се елиминира риска на някой от тях (колкото повече - толкова по-добре).
- Разбира се мениджъра си има негови приоритети и "главни цели" и това се превръща в нещо като "следвоенно разпределение на Блаканите".
- Хванал под мишница това което е успял да изкопчи от мениджъра, тим лидера си преструктурира задачите "до колкото е законно".
- И така над 85% от тази проблеми все стоят нерешени.
- Големия принос на тим ледера, е че в този момент той изолзва екипа си (програмистите) като:
- - Обръща се към по-опитните в екипа и им споделя потенциалните опасности, като алармира програмистите по този начин да изпозват на "рисковите места" както-те-си-знаят нужните дизайн патерни, за да може да се минимизира потенциалната вреда от тези проблеми (вж. Design Patterns).
- - Обръша се към по-неопитните от тима, като им предлага 1-2 дисайн патерни, които да-използват-за-да-решат дадена задача.

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

Може да се използва добрия пример койото човека даде - Да се използва ли # във шерове; - От една страна това може да доведе до технически проблем затова че # в началото на реда може да е коментар, и т.н. => ще загубим време да решим този проблем => сме "назад".
В горния сценарий, тимлидера 1-во се опитва да имоли от мениджъра да не се използва изобщо # във шерове. Но да предположим че мениджъра - отсече, НЕ - хората са свикнали от еди коеси така, а и вече има такива шерове.
Тогава това се превръща в потенциална заплаха. Тим лидера хем трябва да разреши #, хем да не се забави като възникне проблема.
Тук идва "гамблинг-а", когато той изисква решаването на задачата с изплзване , обръщения и т.н към имената нашера да се "капсулова колкото може по-добре" (т.е. Пешо като проверява нещо си да НЕ може да тръгне да търси '#' в името на шера), този проблем се разпростира в съсзаването, промяната и т.н на иметата нашеровете, и след като е обърнато внимание, програмиста решава адекватно проблема (вж. Design Patterns).
След което като се "наниже" екипа на това "ами сега с това #", само един човек за малко време ще имплементира - даречем заложения като полиси клас.
И софтуера ще работи.

Доста добро и точно описание... Само пустия мениджър да не беше толкоз отделен от процеса...

> Искам да постулирам, че код, който може да се "развали" от промяна на изискване всъщност е с ниско качество -- бил е развален преди много време.

Някак си не съм съгласен. Не се е родил нито перфектния project/product/program (whatever) manager, нито перфектния програмист, който да предвиди всички промени, които ще се наложат. Повечето програмисти вярват в "панацеята" - "перфектния project plan", който ще ги избави от всички нещастия и мъки. Аз не вярвам в него.

> Напълно подкрепям Боб Мартин в апела "We will not ship shit!"
На клиента обикновено се ship-ва краен продукт, не код. Т.е. него изобщо не го вълнува това, което става "отдолу". Ако е shit опакован в червен целофан и синя панделка той ще пита: "Колко трябва да платя?". Разбира се говоря за "работещ" shit все пак.

В отговор на:

---

Не се е родил нито перфектния project/product/program (whatever) manager, нито перфектния програмист, който да предвиди всички промени, които ще се наложат.

---

Май не съм се изразил подходящо. Не говоря за предвиждане на проблеми ами за писане на код, който може да се променя лесно. На това свойство pragmatic programmer-ите му викат ортогоналност.

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

На клиента обикновено се ship-ва краен продукт, не код. Т.е. него изобщо не го вълнува това, което става "отдолу". Ако е shit опакован в червен целофан и синя панделка той ще пита: "Колко трябва да платя?". Разбира се говоря за "работещ" shit все пак.

Косвено го вълнува, щото шитовете имат тенденцията да работят бавно и зле. И тази 'технология' работи основно за клиенти тип - "е..еш и хвърляш".
Ако ти се наложи по-дълго да поддържаш такова нещо, ти ще си се ровиш сам в шита и в един момент клиента ще попита - абе що толкова дълго време правиш толкова просто нещо - и ще е прав до голяма степен.

При цялото ми уважение към първата книга на Gamma и останалите (наистина мисля, че на всеки програмист би помогнала) не мога да не отбележа, че тия патърни са се превърнали в buzzword. Куцо и саката, чело-недочело, бичи патърни из кода като си мисли, че така го прави по-качествен, а често става точно обратното.

Да не забравяме, че патърна е просто конкретна инстанция на някакъв дизайн принцип. Принципа може да е приложим, може и да не е. Може да е приложим под друга форма и т.н.

Вместо pattern whoring подхода, аз бих предпочел следното ръководство[1] от старшия програмист:
1. Кода трябва да има тестове и те да минават постоянно
2. Кода не трябва да съдържа дупликация.
3. Кода трябва да е максимално ясен и да изразява намерението и идеята зад него.
4. Броя на класовете и методите да се сведе до минимум.

Който каквито иска дизайн патърни да ползва в постигането на тези цели. Ако не ползва -- здраве .

[1] Ръководството е почти 1:1 превод на Кент Бек от Extreme Programming Explained -- Embrace Change

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

Ами авторите на JUnit го бяха казали много точно - и мисля, че това трябва да се набие в главите на всички 'патернисти' -
код, който изобилства от патерни е код, който е към някакъв фреймуърк, който ще се използва от много хора, който е преминал няколко 'еволюции' на дизайн и т.н....
А не кода на Пешо, дето иска да впечатли коле(ж/к)ите си с думички като Абстрактна Фабрика , (Вълк) Единак и т.н.

Хм, аз не съм "патернист", не се извинявам за прекалено честото използване на "патерн" в предния пост, но гледната точка беше такава че "захапваше патерните".

Отностно патерните - те сами по себе си не предтавляват никаква стойност. Не съм и мислил че "готово решение".
Ако може да направя една аналогия, която често се среща - това е, ако вземем например образованието. Само образоване е ясно че не може да гарантира добър програмист (например), но определено е предпоставка за това. Иначе казано, патерните не са НДУ за решаването на проблеми, а НУ.

А иначе, защо ползваме патерни - за да не откриваме топлата вода отново, ако мениджъра разбере че ни плаща за да стигнем, след 3 месечно ходене по опит-грешка, до решение, което може със обмисляне на проблема да се реши адекватно и доста по-бързо...
И още нещо, относо:
4. Броя на класовете и методите да се сведе до минимум.
мисля че е по-правилно да се каже че, (броя на класовете и методите)/(кода приложен за решаването на задачите) триабва да -> към <<някаква>> константа, а не просто да се сведе до минимум броя на класове и мебъри.

Ако в един проект има 4-5 огромни класа (do-all) класа, със такива методи, то следваща версия просто няма да има

> Не говоря за предвиждане на проблеми ами за писане на код, който може да се променя лесно. На това свойство pragmatic programmer-ите му викат ортогоналност.

Хмм. Напълно възможно е. Въпреки че защо пък точно ортогонален. Ортогоналите не бяха ли височините в триъгълника? Може би по-скоро трябва да му викат "ортодоксален" (т.е. нещо като "общоприет"). Мисля, че това са по-скоро добри пожелания - "Ако пишеш добър код, ще е по-лесно после и да го променяш, ще си по-добър програмист и т.н. т.н.". Това естествено е вярно.
Може би наистина трябва да прочета някоя от книгите на този пич. Туко виж ми светнало най-накрая за какво точно става дума.