Я си признайте колко пъти сте се карали с колеги за код който вие сте написали, знаете че е грешен, но не ви стиска да признаете от гордост?

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

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

Пример: Едно малко сайтче с около 200 страници и десетина форми. Има кредитни карти, малко лична информация, регистрация, тук-там малко информацийка, абе сравнително проста работа с едното изключение че трябва да е на два езика: френски и английско понеже в Канада всичко трябва да е на двата езика да не би кебекарите да се обидят прекалено много.

Един руски програмистки гений решава да направи следното: Всички страници и форми, включително и статичните страници, които иначе биха могли да бъдат и най-обикновен HTML се наблъскват в User Control-и, общо около 100 на брой, предефинира всички стандартни уеб контроли на .НЕТа за да може да въведе отделни пропъртита за английски и френски текст. Всички тези контроли се зареждат в ЕДНА ЕДИНСТВЕНА страница, която показва контролите в зависимост от QueryString параметри. Това обаче не е всичко понеже лудостта продължава с пълна пара. Оказва се че текстовете в тези User контроли се зареждат като се вика един глобален обект, който чете от една база данни ВСИЧКИ страници. Понеже зареждането на тази информация отнема около 4-5 секунди дори при ненатоварен сървър и не може да се прави при зареждането на всяка страница, голяма част от тази каша се кешира, при което на сървъра му се разкатава фамилията. Добре че сайтчето почти не се посещава. Другата простотия примерно е че човека прочел че има такова нещо като наследяване. И решава че трябва да се наследява яко. Прави един обект CTable и всичките му обекти се наследяват от там. Този обект всъщност чете и пише редове в една база данни, като пропъртитата на обекта съответстват на колоните в някоя таблица. Т.е. трябва ти обект CUser, правиш си таблица tblUser и колоните отговарят на пропъртитата. Отклонения от тази гениална архитектура не се допускат, понеже всичко е наследено от CTable. Майтап. Голямата полза от тази работа доколкото разбрах е че се спестява конструктора, който би трябвало да зареди информацията от различни места в общия случай
.

Та така. На момчето проектите му не вървят, сървъри гърмят със страшна сила, постянно му трябват яки пренаписвания дори при малки промени, абе трагедия. Обаче понеже има много работа му назначават помощници, вдига се шум, началството гледа и вижда че кипи труд. Но понеже все пак накрая трябва и работа да се свърши началството се почесва по там където би трябвало да има нещо като глава и мъдро решава че трябва да ме пренасочи за около 6 месеца да помогна на групата им да решат проблемите си.

Ебаси. Седя и се чудя как бих могъл да убедя началството че единствения начин да се оправят нещата е да изгонят цялата тази пасмина и да се пренапише всичко.

Засега не сме стигнали до караница, обаче явно е предстоящо. Такива ми ти работи.

Направи в свободното си време опростен или намален модел на този сайт.

След което го представи на началството като скромно подчераеш, че ти е отнело (примерно) 10-20 работни часа, за да го направиш сам, без чужда помощ.

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

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

Алтернативата е да тръгнеш да убеждаваш шефовете си без доказателства, разчитайки на авторитета си.

Ти си решаваш

П.П.

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

Това, което е важно е резултата. Е, твоят резултат ще убеди и най-невярващите.

Понякога седя и си мисля, а понякога само си седя ...

Редактирано от Mackлин на 24.03.05 12:20.

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

Ако искаш кой да е шеф да получи инфаркт, то кажи му някакво изречение, каквото и да е, в което участват думите "пренаписване" и "всичко".

Мда, оттам и подхода "egoless programming".

Браво, точно така, прототипче, като максимално избягваш конфронтация (накрая ще си я получиш де, това е ясно).

Редактирано от Nero на 24.03.05 12:39.

Работата е там, че пренаписването наистина отнема много повече време и усилия отколкото изглежда на пръв поглед. На пръв поглед е ясно какви са проблемите и как да го направиш по-добре. Но се забравя че ще имаш и нови бъгове, време за оправянето им, тествания, нагласяне и т.н. Да не говорим че често се въвеждат и нови функционалности по хрумване на програмиста, които не са непременно полезни (това че програмиста мисли за даден feature, че би бил полезен, не значи че потребителя ще мисли съшото), но си носят своите бъгове, време за оправянето им и т.н....
Джоел има много добра статия по въпроса - мнението му е че решението на Нетскейп да пренапише навигатора наново е довело до фатално забавяне от няколко години, в резултат на което губи и доминиращия си дял.

наистина лайната трябва да се чистят едно по едно, а не да се изрине всичко и да почне да се сере отново.

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

Мога да ти дам пример. Имахме един проект, който маследихме от друга фирма. Кодът беше голяма боза. След известен анализ беше оценено, че за 3 месеца, колкото ни бяха дали да съживим този код, ние можем да го пренапишем отначало и да стане много по-добре. Тогава аз не бях девелопер, а консултант, но можах да преценя, че и двете оценки са грешни. По-скоро смятах, че пренаписването можеше да стане не за 3, а за 6 месеца. В крайна сметка ни беше наредено да ползваме съществуващия код, защото шефовете и клиентите се страхуваха ужасно, че това, в което са инвестирали цяла година преди това, ще бъде захвърлено на боклука. Те, обаче, не можеха да предположат, че това тяхно решение, ще доведе до работа повече от 2 години и многократно по-скъп и по-некачествен продукт, отколкото ако го бяхме пренаписали.

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