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

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

• Управление на проекта (Project Managment)
• Измерване на проекта в различните му аспекти (Software Measurement)
• Оценяване нужното време за разработка на проекта (Software Development Effort Estimation).

Като защитава тезата, че разработването на софтуер трябва да се управлява във всеки един от изброените аспекти. Но 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“. Ако приемем този отговор за верен, то той ни дава и ясен отговор на въпроса “Дали всъщност разработването на софтуер е инженерна дисциплина, или е по-скоро занаят?”. Няма как една инженерна наука да не може да бъде стриктно управлявана, добре измервана и правилно оценена времево. Следователно разработването на софтуер е по-скоро занаят?

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

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

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

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