Как да преминем от Доброто към Великото

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

„Група хора мозъчна атака над лаптоп и листове хартия“ от Štefan Štefančík в Unsplash

Изграждането на страхотен продукт често не е самостоятелно начинание. Най-сложните настройки ще включват много екипи за творчество, маркетинг, продукт и технология. Дори и да сте компания на такава, ще трябва да общувате с потребителите си, за да съберете техните отзиви за това, което им работи. Тази итеративна рамка на цикличния процес на проектиране с цел подобряване на качеството и функциите обикновено се нарича Agile Iteration Workflow.

Колкото по-бързо можете да повторите, толкова по-добър ще стане вашият продукт.
„Agile Iteration Workflow“ от Smartsheet

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

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

В крайна сметка ние се стремим да подходим към декларативната парадигма за програмиране, която изразява какво искаме да направим в нашите приложения, вместо задължително да кодира как. За целта ще трябва да положим основите на създаването на нашите строителни блокове.

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

Ще имаме увереността, че нашите UI компоненти ще изглеждат и се държат точно както трябва, за да можем да се съсредоточим върху забавните и важни неща - приложенията и как трябва да се държат. Можем да приложим същия процес с нашите компоненти на потребителския интерфейс към нашите проекти, специфични за приложението, с по-специфични тестови пакети, за да увеличим максимално покритието. Само с тези тестови пакети можем да повишим доверието на разработчиците при натискане и разгръщане на код, а в замяна да увеличим скоростта на итерация.

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

Нива на тестване на софтуера

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

Използваме единични тестове, за да валидираме отделни компоненти, най-малките тествани единици, в софтуер. В нашия случай това обикновено са UI компоненти или помощни методи за помощ. Интеграционното тестване се случва, когато отделните компоненти се тестват като група. Например, това може да означава функция като калкулатор, където ще имате бутони и екран на дисплея и се уверете, че правилното число се показва в отговор на натискане на бутон. За API крайната точка може да осъществи връзка с база данни, за да извлече набор от данни.

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

Това е кратък поглед върху това как планираме да направим процесите на нашия преден екип по-ефективни. Ще разгледаме повече подробности за внедряването в следващите публикации за front-end разработката на StashAway. Следете се!

Непрекъснато сме в търсене на голям технологичен талант, който да се присъедини към нашия екип - посетете нашия уебсайт, за да научите повече и не се колебайте да се свържете с нас!