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

Обичам софтуерните метафори. Правят процеса на разработване по-разбираем. Любимата ми: разработването на софтуер сравнено със строенето на сгради. Много общи неща. А и архитектурата е ужасно близка (философски) до програмирането. Но започвам да си мисля, че сравнението е лошо. Строителното инженерство работи със стомана и бетон. Веднъж като положите основите, не може да преместите сградата 20 метра вляво. Когато вдигнете „скелета“, нова подредбата на стаите би отнела много време и пари. Ако ми построите къща, която не ме устройва, няма да е тривиално да я преправите. В софтуера и строителстовто има обща черта – промените са скъпи. Затова и метафората е популярна.

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

И тъй – мисля си, че не трябва да прекаляваме с тази метафора. Софтуера е като строене на сгради, но само донякъде. Имаме редица инструменти, с които един строителен инженер не разполага по дефиниция. Не бива да се лишаваме от тях психологически.

Уви, нямам по-добра метафора. Чувал съм за градинарство, писане и шофиране, но всички улавят само малък аспект, влачейки премного грешни импликации. Толкова уникално ли е това, което правим?

8 thoughts on “Софтуерно и строително инженерство

  1. В книгата „Code Complete 2“ още втората глава (първата бидейки въвеждащата) Steven McConnell разнищтва различните метафори, които използваме в нашия бранш и също както ти (и аз) намира това сравнение за неуместно.

  2. Да ти пусна една муха – може да се сравни с композиране на музика, поради липсата на ‘материя’? Ти си по музиката, мисли… Там обаче пък отсъства екипния момент ;). Всъщност, кому е нужно да го оприличава на нещо?

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

    При софтуера (и архитектурата) искаш да показваш минимална индивидуалност. На нейно място трябва да блести най-доброто и логично решение на проблема. Според Ward Cunningham, „чист код“ е „когато отвориш една рутина и тя изглежда както си очаквал“.

    Точно обратното на музиката и индивидуализма в нея. За това не харесвам сравнението.

  4. Съгласен с горното, приликите се изчерпаха до липсата на ‘материя’.

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

  5. На свой ред ще се съглася. Ще допълня с две малки предимства на метафорите.

    Първото е комуникация. Лесно можеш да обясниш (на клиент или на начинаещ разработчик) защо промените са скъпи, ползвайки строителната метафора. Или на майка си къде е предизвикателството в разработване на софтуер.

    Второто е „креативно мислене“. Ако направиш паралел с друга област, можеш да се опитваш да превеждаш нейни идеи в твоята. Можеш да ползваш това като генератор на идеи. Но трябва да филтрираш, понеже много ще са лоши, както ти сам каза.

  6. Всъщност ако под музика разбираме камерен или баш оркестър… има я екипната работа и на места липсва индивидуализма. Като се замисля, на базата на музикалната полугрешна метафора може да се измъдри някаква методология, в която всеки се специализира до божественост единствено в неговата област… и тук вдъхновението ми секва. Всъщност погледнато наопаки, можем ли да метафоризираме нещо с разработването на софтуер? Така май ще е по-лесно…

  7. Според мен е много по-важнен самия процес на сравнение на софтуера с реален предмет, от това точно с какъв предмет ще го сравниш. При софтуера не е толкова лесно да определиш подходящия размер и форма, колкото при реалните предмети- затова софтуерната метафора е безценна. Например ако мобилният ти телефон тежи 2.3кг, веднага ще разбереш, че това е абсурдно; докато при форма за обратна връзка с 12 полета това не е толкова очевидно. Иначе май програмирането е най-близо до шиенето. И двете използват материал (плат – език); понякога се изисква креативност, а понякога не; промените понякога са лесни (да подгънеш ръкав) или много трудни…

  8. Аз бих се съгласил че метафорите понякога са полезни, но честно казано във изгледа за програмирането като цяло повече клоня към гледната точка на Дийкстра. Той защитава идеята, че програмирането е VLSAL, very large-scale applications of logic, ето ти статията: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1041.html

    Ще ти дам пример. 90% от работата, която ти трябва да свършиш в една програма в момента се пише от framework девелъпърите. То не е гарбиджа, то не са Spring, Hibernate, JDBC, ала-бала… Де-факто работата на програмиста в момента е да навърже тези конструкции в подходящ ред, за което много по-добра метафора е математическата теорема…

    Елитистко? Много ясно! Преувеличено? Не съвсем.

Вашият коментар

Вашият имейл адрес няма да бъде публикуван.