Как избираме технология?

Понякога ни се налага да направим избор. Да използваме ли React или Angular? Cordova или Swift? Ruby или Node.js? Jenkins или GitLab CI? Rails или Sinatra? Да използваме ли Promise-и или Observable-и? Да има ли Redux или не?

Как правим този избор? Има страшно много фактори, които могат да бъдат взети под внимание, от които често само малка част са спецификите на определен език, библиотека или фреймуърк.

Контекст

Всеки такъв избор е съпътстван от контекст. Притиснати ли сме от времето? Колко голям ще е проектът? Използвали ли сме някои от възможните опции? Трябва ли ни съвместимост със съществуваща система? Все неща, които хвърляме в котела с отварата за решението. Няма технология подходяща за всичко. Дори JavaScript. Всеки, който твърди, че X трябва да се използва винаги, или има недоизказано продължение “за нещата, за които си мисля, че ще го използвате”, или ни лъже.

Обективни фактори

Има някои обективни фактори, които можем да използваме като аргументи. Започваме да си задаваме въпроси.

• Колко поддържана е технологията? Има ли скорошни версии? Колко звезди има в GitHub? Какъв е размерът на таба с issue-тата? Ами този с pull request-ите? Има ли активни maintainer-и? Подкрепена ли е от голяма компания като Google, Facebook, Microsoft? Не, Oracle не важи.
• Колко стабилна е технологията? Гледаме changelog-а. Често ли има чупещи промени? Няма changelog? Значи не я пипваме, освен ако не е нещо достатъчно дребно и нямаме алтернатива - бъдещото ни “аз”, което ще ъпдейтва, ще ни благодари.
• Взаимодейства ли добре с останалите библиотеки? Ами с другите технологии на проекта?
• Колко качествена е документацията? Съществува ли изобщо? Включва ли реални примери или е пълна с прост код, който в реален проект би изглеждал по съвсем различен начин?
• Колко време е необходимо за качествено научаване? Заслужава ли си или избраният подход е ненужно сложен?
• Мислено ли е за error handling или никъде не се споменава какви грешки могат да се получат?
• Мислено ли е за сигурност? Има ли история на уязвимости? Били ли са закърпвани своевременно?
• Какво е качеството на екосистемата? Има ли много библиотеки? Изглеждат ли качествени? Има ли много материали по темата? Ами StackOverflow постове?
• Какъв лиценз има и подходящ ли е за нас?

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

Мнението на запознати хора

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

Много сме. Не сме толкова специални, колкото ни се иска да мислим. Намираме хората с нашите възгледи и с нотка на съмнение им се доверяваме.

Малки експерименти

Мнението на другите е важно, но това, което ни интересува е нашето … ахъм … това на нашия екип. Когато имаме време си правим експеримент - микро проектче с избрана от нас представителна функционалност. От това виждаме неща, които ни допадат, както и такива, които ни дразнят. Експериментираме с 2-3 технологии и често самият процес на сетъп и начално запознаване ни кара да харесваме една опция повече от другите. Също както в живота.

Просто на пръв поглед, не достатъчно сложно на втори

Внимаваме да не попаднем на нещо достатъчно просто за експеримента, но прекалено просто за големината на реалния проект. JavaScript библиотеките са всеизвестни със свойството си да изглеждат добре в примери, след което да се превръщат в каша от ранга на спагетеното чудовище, когато биват приложени в средноголям проект. MongoDB ни примамва с удобството на json-и без схема, след което ни изяжда с неочаквано грешни документи, тонове изписан код за ръчни join-ове и неконсистентност. Отново започваме да си представяме удобството на миграциите. А до обещаната скалируемост така и не се стига. В един момент започваме да гледаме подозрително на всичко, чийто най-изтъкван плюс е бързина.

Да отидем на ресторант или да си сготвим сами?

Предпочитаме ли да си сготвим сами архитектурата на проекта? Да си изберем рутер и моделен слой, да си подредим папките, да си настроим webpack-а? Или искаме нещо, което ни казва къде какво да сложим? И в двата подхода има смисъл.

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

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

Имаме бюджет

Не, не този вид бюджет. Имаме бюджет от виртуални техно-койни (криптовалута, понеже е модерно). Всеки път, когато изберем технология, непозната за някого от екипа, харчим от тях. Не можем да вземем кредит (не разполагаме с техно-койн банка). Не можем и да ги копаем.

По-големите технологии (нов фреймуърк, нов език), естествено, са по-скъпи. Похарчим ли прекалено много, рискуваме проектът да потръгне бавно и да се влачи. Междувременно клиентът иска резултати. Изпускаме срокове. Превръщаме се в БДЖ. Появяват се проблеми, които не сме предвидили, понеже не сме били достатъчно запознати с инструментите си. Отхапваме повече, отколкото можем да сдъвчем. И започва да си личи.

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

Цената на всяка технология зависи и от естеството на екипа. По-опитни хора ще похарчат по-малко от имагинерната криптовалута (каква тавтология само). Те ще разпознаят в нея вече познати шаблони (не “онези” шаблони) и на втората седмица ще са достатъчно продуктивни, за да помагат на по-малко опитните.

Още по-малко плащаме ако човек от екипа е запознат с избраното нещо. Печелим и знание, придобито от опит, което е най-ценно в подобни ситуации.

Има ли изобщо значение?

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

Това, което се харесва на един човек, не се харесва на друг. Дори това, което се харесва на сегашното ми аз, вероятно няма да се харесва на вече различното “аз” година по-късно.

Спираме да го мислим и скачаме

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

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