Високо качество на програмния код - наистина ли се нуждаем от него?
Съвсем на скоро, в един от български форуми се появи мнение под заглавие: “Сега разбрах за нечитаемия код:))” [1]. Още с първото изречение авторът излага малко шеговито своята теза: “Хватката е, че така се битонираш във фирмата.” Въпреки че това твърдение не звучи сериозно при първото прочитане изглежда в него има определена доза истина.
В своят уеб блог Frank Sommers [2] ни разказва за някои от митовете свързани с качеството на програмния текст при създаването на софтуерни продукти. Позицията му е ясна и точна: Качеството на програмния текст не оказва пряко значение за качеството на крайния продукт. В основата на тази теза е заложено твърдението, че крайният продукт (под формата на изпълним код) преминава една финална технологична преработка, а именно компилация или интерпретация.
Важно е да направим уточнение, че под качество на програмния текст разбираме стила на писане, именоване на отделните елементи в текста и структурирането на кода, а не наличието да дефекти в програмата (бъгове). Базирайки се на това важно уточнение съвсем спокойно можем да кажем, че за крайният потребител и всички останали, с изключение на програмистите подържащи продукта, е напълно без значение по какъв начин е написан кода, стига продуктът който получават да отговаря на изискванията и очакванията им.
В подкрепа на твърдението, че качеството на програмния текст не оказва директно влияние за качеството на крайния продукт, можем да отбележим, че клиентите получават не самият програмен текст, а изпълнимия код. Съвременните среди за разработка многократно оптимизират програмните текстове при превръщането им в изпълним код. Компилаторите и интерпретаторите могат да създадат еднакво добре работещ изпълним код, независимо дали програмният текст е бил с високо качество или не.
Кой всъщност се интересува от качеството на изпълнимия код? Единствените пряко засегнати са самите програмисти. Добре написания код улеснява тяхната работа по поддръжката или разширяването на функционалността в системата. Въпреки това, високото качество на програмния код не води до директно повишаване на печалбата. Често мениджърите, притиснати от стриктните крайни срокове и жестоката конкуренция на пазара, оказват влияние върху програмистите, принуждавайки ги да създадат готов продукт в кратки срокове, пренебрегвайки нуждата от добре написан програмен текст.
От своя страна, маркетингът се интересува единствено от това да разполага с готов продукт, продуктът да бъде на пазара в подходящия момент и по възможност дефектите в продукта да бъдат по-малко или относително незабележими.
До колко програмистите пишат труден за разбиране код, с цел да направят труда си уникален и труден за разбиране от техните колеги, е въпрос на личен морал. Въпреки това, добрите програмисти се стремят да създават лесен за разбиране и поддръжка код, защото това улеснява и собствената им работа.
До каква степен трудния за поддържане код може да запази работата ни зависи единствено от мениджърите на средно и висше ниво, които би трябвало да се предпазват от създаването на “незаменими” служители, носещи повече усложнения за целите на организацията, отколкото ползи.
Тодор Балабанов - teodorgig@mail.ru
В своят уеб блог Frank Sommers [2] ни разказва за някои от митовете свързани с качеството на програмния текст при създаването на софтуерни продукти. Позицията му е ясна и точна: Качеството на програмния текст не оказва пряко значение за качеството на крайния продукт. В основата на тази теза е заложено твърдението, че крайният продукт (под формата на изпълним код) преминава една финална технологична преработка, а именно компилация или интерпретация.
Важно е да направим уточнение, че под качество на програмния текст разбираме стила на писане, именоване на отделните елементи в текста и структурирането на кода, а не наличието да дефекти в програмата (бъгове). Базирайки се на това важно уточнение съвсем спокойно можем да кажем, че за крайният потребител и всички останали, с изключение на програмистите подържащи продукта, е напълно без значение по какъв начин е написан кода, стига продуктът който получават да отговаря на изискванията и очакванията им.
В подкрепа на твърдението, че качеството на програмния текст не оказва директно влияние за качеството на крайния продукт, можем да отбележим, че клиентите получават не самият програмен текст, а изпълнимия код. Съвременните среди за разработка многократно оптимизират програмните текстове при превръщането им в изпълним код. Компилаторите и интерпретаторите могат да създадат еднакво добре работещ изпълним код, независимо дали програмният текст е бил с високо качество или не.
Кой всъщност се интересува от качеството на изпълнимия код? Единствените пряко засегнати са самите програмисти. Добре написания код улеснява тяхната работа по поддръжката или разширяването на функционалността в системата. Въпреки това, високото качество на програмния код не води до директно повишаване на печалбата. Често мениджърите, притиснати от стриктните крайни срокове и жестоката конкуренция на пазара, оказват влияние върху програмистите, принуждавайки ги да създадат готов продукт в кратки срокове, пренебрегвайки нуждата от добре написан програмен текст.
От своя страна, маркетингът се интересува единствено от това да разполага с готов продукт, продуктът да бъде на пазара в подходящия момент и по възможност дефектите в продукта да бъдат по-малко или относително незабележими.
До колко програмистите пишат труден за разбиране код, с цел да направят труда си уникален и труден за разбиране от техните колеги, е въпрос на личен морал. Въпреки това, добрите програмисти се стремят да създават лесен за разбиране и поддръжка код, защото това улеснява и собствената им работа.
До каква степен трудния за поддържане код може да запази работата ни зависи единствено от мениджърите на средно и висше ниво, които би трябвало да се предпазват от създаването на “незаменими” служители, носещи повече усложнения за целите на организацията, отколкото ползи.
Тодор Балабанов - teodorgig@mail.ru
Информационни източници:
1. “Сега разбрах за нечитаемия код:))”, Dir.bg Клубове
2. Frank Sommers, “The Code Quality Myth”, Artima Developer
За съжаление аз се сблъсках челно със точно този проблем... Преди мен във фирмата в която работя е имало един хубусник който така хубаво е оплел един проект че няма накъде повече...
Наследявал е класове на 5-6 нива само за да получи някъква си там функционалност на най-горното... Хардкод-вал е разни неща от сорта на "Ако id-то на еди кво си е 3 начи правиш еди кво си..."
Познайте ако недай си боже тва нещо престане да е с id = 3 кво става...
На мен ми трябваше месец и нещо само за да открия някаква, макар и минимална логика в този код. За радост сега вече (около 3 месеца по късно) работя почти без да се замислям със него и кадето имам възможност и време го оправям...
Моето мнение е че лошо написания код е нож със 2 остриета... наистина при някой фирми може да те "битонира" на работа, но при сериозните фирми в които работят добри програмисти най-много да спечелиш подигравки и уволнение...