Софтуерно инженерство

Една идея, на която времето ѝ дойде и изтече?“. Така озаглавява своя доклад от 2009 Том ДеМарко, бащата на идеята за “Софтуерно инженерство“. Въпросите, от които Том се вълнува особено много, са изцяло свързани с управлението на софтуерни проекти, или по-точно – “Как се контролира един софтуерен проект?”. В тази връзка, в своята книга от 1982 г. “Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982)” разглежда три от основните точки за контролиране разработката на софтуерни проекти:

Като защитава тезата, че разработването на софтуер трябва да се управлява във всеки един от изброените аспекти. Но 30 години по-късно в своя последен доклад отново поставя същия въпрос – “Дали наистина е задължително всеки софтуерен проект да бъде стриктно управляван, добре измерван и правилно преценен времево?”. Отговорът този път според Том ДеМарко е твърдо НЕ.

I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.

Същия отговор дава Jeff Atwood в своя пост- “Software Development: Dead?“, както и съоснователят на stackoverflow.com и негов партньор Joel Spolsky в статията за списание Inc. – “The Unproven Path“. Ако приемем този отговор за верен, то той ни дава и ясен отговор на въпроса “Дали всъщност разработването на софтуер е инженерна дисциплина, или е по-скоро занаят?”. Няма как една инженерна наука да не може да бъде стриктно управлявана, добре измервана и правилно оценена времево. Следователно разработването на софтуер е по-скоро занаят?

По-скоро занаят

Разбира се, няма как и да кажем, че разработката на софтуер е “просто” занаят. Това е един адски сложен процес, който изисква голямо желание за разработване на точно този софтуер от страна на програмистите, както и огромни знания по темата и инженерни умения за самата разработка. Ключовото условие един проект да бъде успешен е именно желанието на програмистите да “създадат” този софтуер. Да ги изгаря отвътре да го създадат. Но също и да имат желание да го напишат добре и да го направят професионално. Да следват утвърдени добри практики. И може би най-важното условие е да го направят успешен, като го направят лесен и удобен за ползване от клиента. Но за колко време? Дали ще бъде създаден по най-добрия или поне “достатъчно добър” начин? Не мисля, че някой програмист може да отговори на тези въпроси, преди да е създал вече софтуера. Така се получава, защото даден проблем може да бъде решен по десетки и стотици различни начина и всичките да са “правилни”. Но едни решения ще станат за няколко дена, други – за няколко седмици, а трети – за няколко месеца. И въпросът кое решение да имплементира е изцяло в ръцете на програмиста и един мениджър трудно може да му вмени, че друго решение е “по-правилно”. Според мен това отново твърдо противоречи на идеята за “Софтуерното инженерство”. Едва ли един авиоинженер например има същата свобода да проектира самолет, както на него му “се струва”, че е най-добре, и да стане готов тогава, “когато стане”.

Сложен занаят

Но ако класифицираме програмирането като занаят, то това може би ще е най-трудният занаят на света. Занаят, който изисква много умения и много учене цял живот. Дори бих си позволил да кажа, че науката за създаването на софтуер е безкрайна и още по-лошото е, че с всеки изминал ден става все по-обширна. Ако даден програмист спре да учи и да се развива дори за момент, то той вече ще е изостанал от новите технологии. Да не говорим за сложността на основите на програмирането и десетките супер важни и трудни предмети, които учим в университетите. Затова, програмисти, учете здраво, учете много. И преди да се наречете “софтуерни инженери”, се замислете дали наистина сте такива. Това, което най-често прави един софтуер успешен, е желанието ни да го направим, а не науката и инженерните ни умения. А ето и как всъщност изглежда процесът по разработка на софтуер онагледено. (Натиснете върху изображението, за да го видите в цял размер.) Софтуерно Инженерство