9 стъпки: Избор на технологичен стек за вашето уеб приложение

Планирането на новото ви уеб приложение може да бъде трудно (Снимка на Luca Bravo на Unsplash).

Вие сте основател, главен изпълнителен директор, технически директор, консултант или друг заинтересован участник, който трябва да реши как да изгради софтуерен продукт? Имате проблеми с решаването на технологичния стек за вашето уеб приложение? Трябва ли да използвате Python или Java като език? Правилен избор за уеб рамката е node.js или Flask / Django? Какъв е най-добрият преден вариант: Angular, React или VueJS? Какво ще кажете за базата данни - MySQL, Postgres или MongoDB? Трябва ли да се хоствате с Apache или Nginx на DigitalOcean или просто да отидете с Amazon AWS? Може би предпочитате да работите с PaaS като Heroku?

Ако имате милион въпроса и не знаете откъде да започнете, тази статия може да ви помогне да вземете своето решение.

1. Дръжте го просто. Върви пъргаво!

Често технологията, която сте избрали, никога няма да доведе до значение, защото самият продукт се проваля. Много стартиращи компании работят с технология за мащабиране и харчат време и енергия за стабилна конструкция, само за да разберат, че няма пазар за техния продукт.

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

Веднага щом разберете, че вашата концепция ще работи, можете да продължите напред с изграждането на продукта. Бъдете пъргави по време на тази фаза. Никога не трябва да прекарвате няколко месеца за компилиране на системна спецификация на 100 страници („Pflichten-und Lastenheft“ на немски език) за разработчиците, особено ако са необходими 6 или 12 месеца за реализация на продукта. Вероятно това ще доведе до продукт, който е или остарял, или доставен твърде късно.

Помислете: първо първо. Пуснете основна страница, след това първата си функция, а след това втората. Предимствата да правите нещата по този начин са, че можете да оцените напредъка в реално време и да промените посоката според нуждите. Минимизирате риска, защото системата ви вече работи. Може още да нямате всички функции, които сте си представяли, но те работят!

2. Помислете за личните си изисквания

Имайте предвид проблемното си пространство. Избраната от вас технология трябва да зависи от проблема, който искате да решите. Някои неща са по-добри на един език, отколкото на друг - например Python е чудесен за изчисления и статистика.

Потребители преди технологията

Продуктите трябва да бъдат изградени за техните потребители. Какъв продукт искате да изградите? Как можете да създадете най-доброто потребителско изживяване? Помислете кой ще използва вашата система. Ще работят ли на настолни компютри или таблети? Ще имат ли достъп до нещата чрез мобилна връзка (както правят 60% от всички потребители в момента)? Трябва ли да има приложение за настолен стил? Какви браузъри ще се използват най-често?

Скорост и производителност

Имате ли (без) критерии? Ще се стартира ли софтуерът във вашата интранет? Ако е така, първоначалното време за зареждане може да бъде по-малко от оптималното.

Отново, винаги мислете пъргаво, когато е възможно. Действителността наистина ли е проблем, с който трябва да се справите в момента? Ако възнамерявате да бъдете големи, винаги можете да започнете с платформа като услуга (като Heroku), преди да подобрите производителността със собствената си инфраструктура. Вместо да харчите време и пари, когато все още сте много малки, можете да се притеснявате за ефективността, след като преминете подходящия праг за размер.

Миграции и наследени системи

Имате ли бази данни и / или данни, които трябва да бъдат мигрирани? Имате ли наследени системи, които трябва да бъдат прехвърлени към новата система? Тези и подобни съображения трябва да бъдат разгледани и оценени.

Сигурност

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

3. Преминете към технологии с отворен код

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

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

Друг важен въпрос: как екипът зад технологията се справя с проблемите на сигурността? Има ли имейл адрес за докладване на уязвимости в сигурността?

4. Проверете екосистемата

Всяка технология има екосистема, съставена от хора и инструменти.

Колко голяма е екосистемата зад езика или рамката? Колко въпроси за Stackoverflow има, конференции и онлайн уроци (например Udemy)? Какво казва Google Trends? Интересът към софтуера продължава ли да расте? Колко пакета (npm, PyPi и т.н.) има и имат ли лицензи, с които можете да работите?

Знаете ли за страхотните страхотни списъци? Те ви помагат да се ровите в екосистемата на език или рамка. Можете да проверите уроци, статии и важни пакети, свързани с дадена технология. Има списъци за Django, node.js, React, Angular и много други.

Също така важно: общността приема ли нови членове и колко активна е тя? Как е поддръжката за потребителите и разработчиците? Има ли пощенски списък, чат канал, слаба стая или система за билети? Ходят ли блогове за технологията?

5. Дългосрочни тенденции и подкрепа

Пазарни жизнени цикли

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

Друга идея е да проверите любимите технологични стекове с stackshare.io или techstacks.io. Вижте какво използва Airbnb или какво харесват хората от AngularJS и кой го използва. Ако не сте сигурни в технологията, можете да потърсите алтернативи. Ето списък с алтернативи на Angular JS на alternativeto.net.

Дългосрочна поддръжка на доставчика

Изглежда, че доставчикът на технологии изглежда така, сякаш ще ги има известно време? Големите компании спонсорират ли разработването на въпросната технология? Google стои зад Angular, а Facebook стои зад React. Това означава, че трябва да има известен напредък, докато компанията в крайна сметка реши да откаже подкрепата си (да, това може да се случи). Но колкото по-голяма е общността, толкова по-голям е шансът нещата да се задържат от доста време.

Някои приложения имат версии с дългосрочна поддръжка. След това посочените версии се предоставят с корекции на грешки за определен период от време. Трябва също да проверите уеб страницата на технологията: как се обработват актуализациите? Колко лесен е процесът на актуализиране / миграция? Имало ли е особено несъвместими версии (като Angular 1 & Angular 2)?

6. Човешки ресурси и набиране на персонал

Какви разработчици имате на ваша страна? Ако трябва да вземете решение за предната технология и имате три силни ъглови разработчици, вероятно трябва да работите с тях. Бързото движение може да бъде важно и е доста предимство да има хора, които са в тяхната зона на комфорт, вместо да учат нова технология. Освен това съществуващите познания за екосистемата са допълнителна полза.

Относно наемането на работа, не забравяйте да проверите следното: можете ли да намерите достатъчно качествени разработчици за желаната технология? Колко трябва да ги платите? Големите компании работят ли със същите технологии и грабват всички добри разработчици? Разработчиците, които намирате най-вече за утвърдени професионалисти, или е трудно да разграничите тях и децата от сценария? Един добър разработчик на Java може да бъде по-лесно да се намери от добрия Ruby on Rails или PHP разработчик. За вашето изследване можете да проверите XING, LinkedIn или портали за търсене на работа. Можете също така да проверите за тенденциите в работата (например сравняване на Angular с React).

Лесно ли се усвоява технологията? Един лесен език може да ви помогне да намерите и обучите младши разработчици, а цялата екосистема може да привлече повече хора.

Не на последно място: чудесен ресурс в HR е проучването на Stackoverflow Developer. Той предоставя страхотен преглед на типовете разработчици, използваните технологии и отчетите за заплатите. Погледни!

7. Ще бъдете ли достатъчно гъвкави?

Специфичност на услугите

Нещата се променят много по-бързо, отколкото преди 20 години. Дълго време хората работеха предимно на настолни компютри и с Windows. Вероятно няма да е така през следващите 10 години. Избраната от вас технология вероятно ще остане с вас от 5 до 10 години: това е дълго време и не можете да сте сигурни как ще се развият нещата. Ето защо трябва да сте готови да променяте технологиите, когато възникне нужда.

Мислете подробно, мислете в малки пакети и мислите за отделяне на проблемите. Трябва да разделите услугите, задните и предните части на по-малки приложения и микро услуги. Би трябвало да можете лесно да разменяте технологии, когато съществуващите вече не работят за вас. Разгледайте концепции като ориентирана към услуги архитектура (SOA) и дизайн, ориентиран към домейн (DDD).

Можете ли да спасите? Ще мащабира ли?

Имате ли винаги достъп до данните? Винаги ли е възможно да експортирате данните си, ако трябва да промените технологиите? Технологията има ли API, за да позволи гъвкавост в другия край? Може би искате да отворите приложението си за вашите клиенти или клиенти, или искате да изградите мобилни приложения, настолни приложения или други системи на върха на избраната технология.

8. Как се чувствате?

Накарайте разработчиците си да проучат технологията или направете това сами. Какви са първите ви впечатления? Направете малко пилотна настройка, изпробвайте съществуващите котелни или (ако е възможно) имайте малък тестов проект. Ако отидете с подробни услуги, можете да изградите нова малка услуга с дадена технология и да видите как тя работи.

Има и приложения в реалния свят, които могат да ви дадат по-добро разбиране на разликите. TodoMVC е страхотен проект - обикновено приложение Todo се реализира с различни рамки на Javascript и можете да разгледате архитектурата на изходния код. Има всякакви примери и можете да сравните Angular с React или Vue с Ember.

Страхотният проект RealWorld отива още повече: това е средно прилично приложение, използващо или Django или node.js за задния и Angular или React за предния край. Можете да прочетете встъпителна статия за него от Ерик Симонс.

9. Започнете

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

Като предприятие нещата могат да бъдат различни. Решението най-вече ще бъде политическо така или иначе - хората във вашата компания трябва да са добре с вашето решение. Ръководството (и да се надяваме, че вътрешните / бъдещите разработчици) са може би най-важните заинтересовани страни на борда.

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

Повече ресурси:

  • Как да изберете правилните технологии за вашия софтуерен проект (бърз за четене списък с точки от куршуми)
  • Как да изберем подходящия технологичен стек за приложението си (хубава статия, обсъждаща решението в зависимост от размера / състоянието на компанията)
  • 5 съвета за избор на технологичния стек от стартиране (приятно изброяване и предупреждение на Tech Stirrers)

Благодаря за проявения интерес. Забравих ли нещо важно? Имате ли различно мнение? Винаги се радвам да получа отзиви.

Следвайте ме в Twitter за актуализации и още: @jensneuhaus -