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

софтуерно

Книга: Програмистите

Софтуерно инженерство - Разпределено програмиране

Софтуерно инженерство - Разпределено програмиране

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

Ние разпространяваме програмиране по същите причини, по които разпространяваме всякакъв вид обработка: наличност, едновременност и специализация.

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

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

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