Developers 02.03.2006 TeodorGig 1785 прочитания

Високо качество на програмния код - наистина ли се нуждаем от него?

Съвсем на скоро, в един от български форуми се появи мнение под заглавие: “Сега разбрах за нечитаемия код:))” [1]. Още с първото изречение авторът излага малко шеговито своята теза: “Хватката е, че така се битонираш във фирмата.” Въпреки че това твърдение не звучи сериозно при първото прочитане изглежда в него има определена доза истина.
В своят уеб блог Frank Sommers [2] ни разказва за някои от митовете свързани с качеството на програмния текст при създаването на софтуерни продукти. Позицията му е ясна и точна: Качеството на програмния текст не оказва пряко значение за качеството на крайния продукт. В основата на тази теза е заложено твърдението, че крайният продукт (под формата на изпълним код) преминава една финална технологична преработка, а именно компилация или интерпретация.
Важно е да направим уточнение, че под качество на програмния текст разбираме стила на писане, именоване на отделните елементи в текста и структурирането на кода, а не наличието да дефекти в програмата (бъгове). Базирайки се на това важно уточнение съвсем спокойно можем да кажем, че за крайният потребител и всички останали, с изключение на програмистите подържащи продукта, е напълно без значение по какъв начин е написан кода, стига продуктът който получават да отговаря на изискванията и очакванията им.
В подкрепа на твърдението, че качеството на програмния текст не оказва директно влияние за качеството на крайния продукт, можем да отбележим, че клиентите получават не самият програмен текст, а изпълнимия код. Съвременните среди за разработка многократно оптимизират програмните текстове при превръщането им в изпълним код. Компилаторите и интерпретаторите могат да създадат еднакво добре работещ изпълним код, независимо дали програмният текст е бил с високо качество или не.
Кой всъщност се интересува от качеството на изпълнимия код? Единствените пряко засегнати са самите програмисти. Добре написания код улеснява тяхната работа по поддръжката или разширяването на функционалността в системата. Въпреки това, високото качество на програмния код не води до директно повишаване на печалбата. Често мениджърите, притиснати от стриктните крайни срокове и жестоката конкуренция на пазара, оказват влияние върху програмистите, принуждавайки ги да създадат готов продукт в кратки срокове, пренебрегвайки нуждата от добре написан програмен текст.
От своя страна, маркетингът се интересува единствено от това да разполага с готов продукт, продуктът да бъде на пазара в подходящия момент и по възможност дефектите в продукта да бъдат по-малко или относително незабележими.
До колко програмистите пишат труден за разбиране код, с цел да направят труда си уникален и труден за разбиране от техните колеги, е въпрос на личен морал. Въпреки това, добрите програмисти се стремят да създават лесен за разбиране и поддръжка код, защото това улеснява и собствената им работа.
До каква степен трудния за поддържане код може да запази работата ни зависи единствено от мениджърите на средно и висше ниво, които би трябвало да се предпазват от създаването на “незаменими” служители, носещи повече усложнения за целите на организацията, отколкото ползи.
Тодор Балабанов - teodorgig@mail.ru

Информационни източници:
1. “Сега разбрах за нечитаемия код:))”, Dir.bg Клубове
2. Frank Sommers, “The Code Quality Myth”, Artima Developer

 

Реклама

Коментари

rammstein4o
rammstein4o преди 20 години и 2 месеца

За съжаление аз се сблъсках челно със точно този проблем... Преди мен във фирмата в която работя е имало един хубусник който така хубаво е оплел един проект че няма накъде повече...

Наследявал е класове на 5-6 нива само за да получи някъква си там функционалност на най-горното... Хардкод-вал е разни неща от сорта на "Ако id-то на еди кво си е 3 начи правиш еди кво си..."
Познайте ако недай си боже тва нещо престане да е с id = 3 кво става... 

На мен ми трябваше месец и нещо само за да открия някаква, макар и минимална логика в този код. За радост сега вече (около 3 месеца по късно) работя почти без да се замислям със него и кадето имам възможност и време го оправям...

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

Terkoto
Terkoto преди 20 години и 1 месец
Тази статия е пълна глупост поради следните няколко прости причини: 1) Много фирми пишат код, който смятат да поддържат, използват и (дай боже) продават дълго време след това. 2) В много фирми (в чужбина, не у нас) има стриктни ограничения върху времето, което един програмист може да прекара на дадена позиция във фирмата. След това или го повишават, или му прекратяват договора. 3) От (1) и (2) следва, че кодът ще се поддържа от много програмисти в течение на времето, и не всички от тях ще са достатъчно опитни. 4) Изискванията за стил на кода, периодичните прегледи на кода (code review-та), QA контролът и т.н. не са измислица на синдикатите за откриване на повече работни места, а точно добре обмислена методика за справяне с проблемът, който може да се появи в (3), ако някой пише спагети код или нечетими и некоментирани шифрограми. 5) В много случаи правилата за писане на код спестяват и време. Елементарен пример: добра практика е сравняванията в C/C++ да се пишат така, че константните изрази да са от лявата страна на оператора за сравняване ==, а не от дясната. Така се изключва възможността някой да изтърве едното равно и да превърне оператора за сравнение в оператор за присвояване, който (както всички сигурно знаем) връща резултат и напълно безпроблемно може да се ползва в условни конструкции и други места, където се изисква rvalue. Последното често води до труднооткриваеми логически грешки, които за разлика от синтактическите не прекъсват процеса на компилация и могат спокойно да "живеят" в крайния продукт и търпеливо да дочакат момента, в който да съсипят цялата привидно работеща система. 6) Да, наистина за компилаторът "if (a == 5)" и "if (5 == a)" са едно и също (въпреки, че може да генерират малко по-различен асемблерен код в зависимост от оптимизацията), но "if (a = 5)" е напълно валидна (макар и грешна от гледна точка на целта й) C/C++ конструкция, докато "if (5 = a)" е синтактична грешка във всички C-подобни езици. Виж (5) 7) Ако пишеш програма от рода на Notepad наистина няма значние колко четлив ти е кодът. Когато обаче пишеш нещо от рода на MS Office значението е очевидно. Ако набързо напраскаш някакъв "пач", колкото да пробуташ кода на клиента, то след това се почва едно роене на версии: в едната пача превърнат в "хубав" код, но пък допълнен от нови 10 пача; в друга първите 3 пача превърнати в четлив код, но последните 6 пача не; в трета пачовете са пачнати допълнително поради недостиг на време за превръщането им в "хубав" код... 8) Добрите менаджери много добре знаят за (1)-(7) и не позволяват на подчинените им да пишат бози и спагети. Добрите менаджери обаче са твърде малко :(