Како прећи из добра у Велико

Ово је увод у вишеделну серију, у којој истражујемо како напредни развојни процеси бити ефикаснији и скалабилнији - да би бржи производ био бољи.

„Група људи која размишља о лаптопу и листовима папира“ аутор Штефан Штефанчик на Унспласх-у

Изградња одличног производа често није самостални подухват. Најразвијенија подешавања би укључивала више тимова креативности, маркетинга, производа и технологије. Чак и ако сте компанија компаније, мораћете да комуницирате са својим корисницима како бисте прикупили њихове повратне информације о томе шта им делује. Овај итеративни оквир процеса цикличког дизајнирања ради побољшања квалитета и функције обично се назива Агиле Итератион Воркфлов.

Што је брже могуће поновити, бољи ће вам производ постати.
Смјерни лист „Агиле Итератион Воркфлов“

На СтасхАваи-у, када је предњи тим први пут почео да ствара веб-базиран производ, били смо по убрзаном року за лансирање, а процеси развоја и управљања производима били су мање строги. Сада када производ сазрева, а како се све више функција истражује и додаје, желимо да побољшамо и пооштримо наш процес изградње боље и скалабилније предње архитектуре производа. Наше тренутно постављање не би нам омогућило ефикасно скалирање у погледу понуде функција и проширења земаља.

Да бисмо направили одличан производ, морамо усавршити ток рада итерације. О томе постоји много литературе о управљању производима, а то није обим ове серије чланака. Оно што желимо да истражимо је како да будемо бржи с итерацијама у фази прототипирања и изградње, а да бисмо то постигли мораћемо да формализујемо интерне процесе развоја и одобрења нашег тима како бисмо ефикасније сарађивали са својим креативним и производним тимовима. . Ми мислимо да то можемо постићи употребом континуиране интеграције и протока испоруке у комбинацији са ширим током рада о итерацији производа како је раније изложено.

Коначно, циљ нам је да приступимо парадигми декларативног програмирања која изражава шта желимо да радимо у нашим апликацијама, уместо да императивно шифрирамо како. Да бисмо то постигли, мораћемо да поставимо темеље стварања наших грађевних блокова.

Започињемо ширењем бриге о корисничком сучељу и логици апликације, тако да развој компоненти корисничког сучеља постаје посебна активност. Имаће своје централно складиште, заједно са заједничким услужним програмима, свој пакет јединица, тестове прихватања и регресије. Наше компоненте УИ-а сада ће се моћи поново користити, моћи да компонују и тематски, за варијације веб локација и веб апликација. Када се користимо са Сторибоок-ом, можемо да створимо библиотеку интерактивних узорака.

Имаћемо поверење да ће наше компоненте УИ изгледати и понашати се онако како треба како бисмо се могли фокусирати на забаву и важне ствари - апликације и како се требају понашати. Можемо применити исти поступак са нашим компонентама корисничког сучеља на нашим пројектима специфичним за апликацију, са специфичнијим тестним пакетима да бисмо максимално покрили. Само помоћу ових пакета за тестирање можемо повећати поверење програмера у потискивање и примену кода, а заузврат ћемо повећати брзину понављања.

Помоћу овог централног складишта компоненти које могу да се саставе можемо да креирамо прототипове и идеје за тестирање корисника, па чак и да испоручујемо нове функције у повећаном темпу.

Нивои тестирања софтвера

Примијетили сте да смо кући дочекали поруку да је тестирање важно. Тестирање софтвера је велика тема у развоју софтвера, али фокусирајмо се на четири нивоа испитивања који су саставни део несметаног рада процеса континуиране испоруке - јединице, интеграције, система и прихватања.

Користимо јединице јединице за валидацију појединачних компоненти, најмањих тестних јединица, у софтверу. У нашем случају то су обично компоненте УИ или помоћне методе. Интеграцијско тестирање се дешава када се појединачне компоненте тестирају као група. На пример, ово може значити функцију као што је калкулатор, где ћете имати дугмад и екран, и осигурати да се тачан број прикаже као одговор на притискање дугмета. За АПИ би крајња тачка могла да успостави везу с базом података како би преузела скуп података.

Јединствена и интеграциона тестирања обично уклањају већину грозних грешака пре него што кренемо у постављање. То штеди време за унутрашње и екстерне тестере, који ће проценити комплетирани и интегрисани систем у складу са карактеристикама и пословним захтевима - доменама система и тестирањем прихватања. Након што софтвер прође четири нивоа тестирања, можемо се применити у производњи.

Ово је лукав поглед на то како планирамо да учинимо процесе нашег предњег тима ефикаснијим. Ми ћемо ући у више детаља о имплементацијама у наредним постовима о фронт-енд развоју на СтасхАваи-у. Будите у току!

Непрестано смо у потрази за великим технолошким талентом који ће се придружити нашем тиму - посетите нашу веб страницу да сазнате више и слободно нам се обратите!