Всички сме чували за правилото 80/20, това, което казва, че 80% от нашия успех (ефекти) идва само от 20% от нашите действия (причини). Е, тази универсална истина влияе и върху разработването на софтуер и в тази статия ще разкажем малко от основите на това твърдение.
BPM
Управлението на бизнес процеси, със съкращението си на английски език, е управленска дисциплина (наред с други неща), която ви позволява визуално да разберете процесите, които трябва да се извършват в даден бизнес (или на много други места). Сред основните му качества е фактът, че може да анализира сложни процеси и да ги прави „прости“.
Има много инструменти с отворен код, които ви позволяват да разработвате BPM диаграми, тази, която използвах за тази статия, е BonitaSoft. Ако искате да научите малко повече за управлението на процеса, има много уроци в интернет и книги по темата. Сега да се върнем към централната тема.
Софтуерни проекти
Днес има много методологии за разработване на проекти, има гъвкави, традиционни, смесени и т.н. и т.н. Общото между всички тях е подготовка. Какво имам предвид под това? Че 80% от вашия успех в този софтуерен проект ще се основава на първите 20% от целия процес, подготовката.
Подготовка на проект
Това е нещо логично, което в действителност се прилага много малко (както много други логични неща, които са нелогични на практика). Когато говорим за подготовка, трябва да разберем способността да разберем проблема, да разберем решението и преди всичко, процеса че решението се прилага. Едно от нещата, които най-малко се срещат в непрофесионалните софтуерни проекти, е липсата на документация по въпроса. Това обикновено се появява в частните компании, тъй като желанието за продажба надвишава процеса на създаване.
Тъй като много от тези, които четат тези статии, работят или са свързани с технологиите, заслужава да се спомене, че ако в даден момент от техния трудов живот те намерят компания / доставчик, която не отговаря на добра подготовка, това е почти 80% сигурно 😛 че проектът няма да се получи.
Абстракцията е ключът
Това е нещо, което научих от времето си, използвайки GNU / Linux, и това отново и отново се оказва ключово в процеса на създаване на софтуер. Капацитетът на абстрактно Проблемите с превръщането им в по-"прости" неща са жизненоважни, за да може да се генерира елегантен код и най-вече траен. И може би това е една от основните разлики на големи професионални проекти и проекти, които излизат извън контрол. Първите мислят, разбират и структурират процеса докато секундите държат работещи, без да е необходимо да го разбират.
ветеран
Това е името на проекта, който инсталаторът на Gentoo разработва, както можете да си представите, това е доста сложен процес, тъй като поддържа голям брой архитектури. Друг фактор, който трябва да се вземе предвид, е броят на поддържаните от него конфигурации, на ниво ядро, init система и т.н. И ви казвам всичко това, защото това е и моят дипломен проект, който трябва да завърша, преди да завърша следването. Очевидно не мога да направя програма, която да разглежда абсолютно всички възможни опции за толкова кратко време (до юли следващата година), но поне мога да генерирам такава, която позволява да се инсталира функционална система по много основен начин.
Разбиране на инсталационния процес
Благодарение на BPM инструментите може да се генерира диаграма на процеса, която ни позволява да разберем стъпките, необходими за успешната инсталация на Gentoo на компютър.
Собствен. Кристофър Диас Риверос
Въпреки че съдържа няколко процеса и подпроцеса, очевидно е доста обобщено и може да се види, че имаме 18 линейни стъпки. Това е важно, тъй като приложение, което има линейна структура, е лесно за изпълнение и в същото време паралелизъм може да се генерира в една или повече от нишките, ако е необходимо.
Друг важен фактор е, че ни позволява абстрактно набори от процеси по тип, например дефинирането на нишка на ядрото ни дава да разберем, че в нея има специфични задачи, които са пряко свързани с процеса на успешно инсталиране на ядрото.
Собствен. Кристофър Диас Риверос
По този начин всяка „сложна“ стъпка се превръща в „проста“ по глобален начин, без да се губят необходимите подробности. Това улеснява видимостта на сглобката, без да понижава нивото на спецификация, необходимо за успешно завършване на процеса. И не можем да отречем, че е по-лесно да видите изображението, отколкото да прочетете целия наръчник наведнъж 🙂
Спести време
Друго очевидно предимство е, че ако нямате директно свързан език за програмиране, е възможно да се извърши логически анализ, без непременно да се губи време за внедряване на езика. Това е предимство в сравнение с времето, което може да бъде изразходвано за внедряване на функция, само за да се разбере, че тя ще бъде изхвърлена, защото има по-ефективно решение. Като какви биха били решенията в псевдо-код (нещо, което също се пренебрегва от много "разработчици", но не бива да бъде).
Режисирането на проекти стана лесно
Вземайки предвид тези концепции, управлението на проекти (от всякакъв вид) става по-лесно, защото ние фокусираме усилията си там, където те наистина са необходими, и ако тази част е направена правилно, останалото пада под собствената си тежест. Надявам се, че това помага на вашето любопитство и ви мотивира да изследвате BPM, алгоритмиката и кой знае, може би ще ви насърчи да ми помогнете с моята дипломна работа very Благодаря ви много, че стигнахте тук и ще се видим скоро. Наздраве
Здравей Благодаря, че споделихте знанията си. Струва ми се, че това е вълнуваща тема, но че изисква много изследователска работа и прилагане на концепциите на практика, за да ги интернализира. Отначало въпросът е объркващ, тъй като човек има тенденция да го свързва повече от страна на идентифицирането на изискванията за дадена система, а не непременно с бизнес процесите на компанията, т.е. как работи компанията. В крайна сметка мисля, че става дума по-скоро за ролята, която играят разработчиците на софтуер при моделирането на бизнеса на компанията, за да направят работата на бизнеса по-ефективна и ефективна.
Здравей Александър, благодаря ти много за споделянето. Честно казано, малко сложна тема е да се опитам да обобщя всичко в толкова малко пространство, но ако мога да допринеса малко, за да се измъкна от объркването с вашия коментар, вярно е, че системите трябва да се опитват да решават изискванията, това е най-много възможна основна функционалност и в този момент е вярно, че разработчикът трябва да се съсредоточи върху по-високо ниво.
Познаването на процесите позволява на разработчиците да представят повече от достатъчно системи, разбирайки достатъчно като нещо, което отговаря на минимално възможните изисквания.
Елегантността на кода се състои в това да можете да разберете цялостния процес и да го генерирате по-дълбоко, където се прилага най-доброто възможно решение и това е възможно само чрез наистина разбиране на процеса, а не на изискването, както добре споменахте 🙂
Ако го моделираме малко около FOSS, това предполага не само познаване на софтуерното изискване, но и философията зад него, както и знанието как ще бъде поддържано, от кого и всички тези познания за процеса, които не само генерират ефективно решение. , но ще бъде възможно да се поддържа с течение на времето 🙂
Отново много благодаря и поздрави.