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-старонкавай спецыфікацыі сістэмы ("патрабаванні і тэхнічныя характарыстыкі") для распрацоўшчыкаў, асабліва калі рэалізацыя прадукту займае 6 ці 12 месяцаў. Гэта можа прывесці да прадукту, які састарэў альбо дастаўлены занадта позна.

Падумайце: спачатку ўсё. Запусціце асноўную старонку і запусціце асноўную старонку, потым першая функцыя, потым другая. Перавага гэтага падыходу ў тым, што вы можаце ацаніць прагрэс у рэжыме рэальнага часу і пры неабходнасці змяніць кірунак. Вы мінімізуеце рызыку, таму што ваша сістэма ўжо працуе. Магчыма, у вас няма ўсіх функцый, якія вы ўяўлялі, але гэта працуе!

2. Падумайце пра свае асабістыя патрабаванні

Майце на ўвазе вашу праблемную вобласць. Выбраная тэхналогія павінна залежаць ад праблемы, якую вы хочаце вырашыць. Некаторыя рэчы прасцей зрабіць на адной мове, чым іншую - напрыклад, Python выдатна падыходзіць для разлікаў і статыстыкі.

Карыстальнікі тэхналогіі

Прадукты павінны быць створаны для сваіх карыстальнікаў. Які прадукт вы хочаце пабудаваць? Як вы можаце стварыць лепшы карыстацкі досвед? Падумайце, хто будзе выкарыстоўваць вашу сістэму. Вы працуеце на працоўных сталах ці планшэтах? Яны атрымліваюць доступ да рэчаў праз мабільнае злучэнне (як 60% усіх карыстальнікаў у цяперашні час)? Ці павінна быць прыкладанне для працоўнага стала? Якія браўзэры выкарыстоўваюцца найбольш часта?

Хуткасць і прадукцыйнасць

Ці ёсць у вас (эксклюзіўныя) крытэрыі? Праграмнае забеспячэнне працуе на вашай інтранет? У гэтым выпадку пачатковыя часы загрузкі могуць быць не аптымальнымі.

Заўсёды будзьце спрытныя, калі магчыма. Няўжо прадукцыйнасць сапраўды праблема, з якой трэба справіцца зараз? Калі вы хочаце быць вялікімі, вы заўсёды можаце пачаць з платформы як сэрвіс (напрыклад, Heroku), перш чым павысіць прадукцыйнасць уласнай інфраструктуры. Замест таго, каб укладваць час і грошы, калі вы зусім маленькія, вы можаце пачаць турбавацца аб прадукцыйнасці, як толькі вы перавышаеце адпаведны памер парога.

Міграцыі і спадчынныя сістэмы

Ці ёсць у вас базы дадзеных і / або дадзеныя, якія трэба перанесці? Ці ёсць у вас старыя сістэмы, якія трэба перанесці ў новую сістэму? Гэтыя і падобныя меркаванні неабходна вывучыць і ацаніць.

Бяспека

Бяспекай ніколі не варта грэбаваць. У залежнасці ад тыпу дадзеных, з якімі вы працуеце, бяспека можа быць нават самым важным фактарам. Вызначце, чаму вам трэба стварыць рэзервовую копію, перш чым вырашыць, як вам стварыць рэзервовую копію. Аднак майце на ўвазе, што тэхналогія - гэта не ўсё. Звярніце ўвагу, што бяспека залежыць у першую чаргу ад навыкаў вашых распрацоўшчыкаў, умоў працы і палітыкі, якую вы рэалізуеце.

3. Абярыце тэхналогіі з адкрытым зыходным кодам

Пры стварэнні новага праграмнага забеспячэння вы павінны шукаць рашэнні з адкрытым зыходным кодам. Яны перашкаджаюць вам будаваць усё з нуля. Гэта эканоміць шмат часу і, напэўна, надзейней (многія галавы лепш некалькіх). Вы таксама можаце засяродзіцца на бізнес-баку і вылучыць свой прадукт. Памятайце, каб вярнуць што-небудзь супольнасці з адкрытым зыходным кодам!

Пасля таго, як вы абралі патэнцыйную тэхналогію, вам варта прайсці кантрольны спіс. Што за ліцэнзія? Ці ўтрымліваецца мова ці асновы функцый, якія патрэбны вам або вашым распрацоўшчыкам? Колькі такіх асноўных распрацоўшчыкаў? Вы можаце прагледзець удзельнікаў і зорак у сховішчы Github і іх эвалюцыю з цягам часу. Ці лёгка зыходны код зразумець, калі вам трэба больш уважліва паглядзець на алгарытм? Ці з'яўляецца дакументацыя вычарпальнай, ці была дбайна праверана тэхналогія і ці ёсць стартавыя катлы, з якімі можна хутка пачаць працаваць?

Яшчэ адно важнае пытанне: як каманда, якая стаіць за тэхналогіямі, вырашае праблемы бяспекі? Ці ёсць адрас электроннай пошты, каб паведамляць пра ўразлівасці?

4. Праверце экасістэму

У кожнай тэхналогіі ёсць экасістэма людзей і інструментаў.

Наколькі вялікая экасістэма за мовай ці асновай? Колькі пытанняў, канферэнцый і навучальных дапаможнікаў па сетцы (напрыклад, 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).

Ці лёгка навучыцца тэхналогіі? Просты мова дапаможа вам знайсці і навучыць маладых распрацоўшчыкаў, а ўся экасістэма можа прыцягнуць больш людзей.

І апошняе, але не менш важнае месца: выдатным рэсурсам у аддзеле кадраў з'яўляецца апытанне распрацоўшчыкаў Stackoverflow. Гэта дае выдатны агляд тыпаў распрацоўнікаў, выкарыстаных тэхналогій і справаздач аб заробках. Паглядзіце!

7. Ці будзеце вы досыць гнуткімі?

Дэталізацыя паслуг

Рэчы мяняюцца значна хутчэй, чым 20 гадоў таму. Доўгі час людзі працавалі ў асноўным на настольных кампутарах і з Windows. Магчыма, гэта не будзе ў наступныя 10 гадоў. Тэхналогія, якую вы абралі, хутчэй за ўсё, застанецца з вамі ад 5 да 10 гадоў. Гэта доўгі час, і вы не можаце быць упэўнены, як будуць развівацца справы. Па гэтай прычыне трэба быць гатовым змяніць тэхналогіі пры неабходнасці.

Падумайце дэталёва, невялікімі пакетамі і аддзяліцеся ад праблем. Вы павінны падзяліць службы, заднія і пярэднія канцы на больш дробныя прыкладанні і мікрасэрвісы. Вы павінны мець магчымасць лёгка абменьвацца тэхналогіямі, калі існуючыя ўжо не працуюць для вас. Праверце такія паняцці, як архітэктурна-арыентаваная архітэктура (SOA) і дызайн на аснове даменаў (DDD).

Вы можаце пайсці пад падпіску аб нявыездзе? Ці будзе маштаб?

Ці заўсёды ў вас ёсць доступ да дадзеных? Ці заўсёды можна экспартаваць вашыя дадзеныя, калі трэба мяняць тэхналогіі? Ці ёсць у тэхналогіі API, які дазваляе гнуткасць з іншага боку? Магчыма, вы хочаце адкрыць сваё прыкладанне сваім кліентам або кліентам, альбо вы хочаце стварыць мабільныя прыкладанні, настольныя прыкладанні або іншыя сістэмы па абранай тэхналогіі.

8. Як гэта адчуваеш?

Дазвольце сваім распрацоўшчыкам заняцца гэтай тэхналогіяй альбо зрабіць гэта самастойна: якія вашы першыя ўражанні? Зрабіце невялікую пілотную канфігурацыю, паспрабуйце існуючыя пласціны катла або правядзіце невялікі выпрабавальны праект (па магчымасці). Калі вы выбіраеце дэталёвыя паслугі, вы можаце выкарыстоўваць пэўную тэхналогію, каб стварыць новы невялікі сэрвіс і паглядзець, як ён працуе.

Таксама ёсць прыкладання ў рэальным свеце, якія могуць дапамагчы вам лепш зразумець адрозненні. TodoMVC - выдатны праект - простае дадатак Todo рэалізуецца з выкарыстаннем розных рамак Javascript, і вы можаце праверыць архітэктуру зыходнага кода. Ёсць усялякія прыклады, і вы можаце параўнаць угловую з React або Vue з Эмбер.

Вялікі праект RealWorld ідзе яшчэ далей: гэта дадатак поўнага стэка сярэдняга памеру, які выкарыстоўвае альбо Django, альбо node.js для задняга канца і Angular або React для пярэдняга. Пра гэта вы можаце прачытаць уступную артыкул Эрыка Сіманса.

9. Пачатак

Калі вы маленькі стартап, запуск больш важны, чым дасканалая тэхналогія. Засяродзьцеся на сваім бізнесе і маркетынгу, а не папярэдне аптымізаваць усе тэхналогіі, неабходныя для кіравання колькасцю карыстальнікаў Facebook. Вы, верагодна, не маеце ўсіх неабходных ведаў, але вы можаце наладзіць яго альбо змяніць тэхнічныя патрабаванні па меры росту (і ў вас ёсць бюджэт).

У кампаніі ўсё можа быць інакш. Звычайна рашэнне звычайна будзе палітычным - людзі ў вашай кампаніі павінны пагадзіцца з вашым рашэннем. Кіраванне (і, спадзяюся, унутраныя / будучыя распрацоўшчыкі), верагодна, найбольш важныя зацікаўленыя ўдзельнікі.

Важна памятаць, што якасць заключаецца ў правільным наладжванні. Важнае значэнне мае не адзінае: патрэбны правільны дызайн, правільныя патрабаванні, правільныя працэдуры выпрабаванняў і гэтак далей. Самае галоўнае, што ў будучыні вы не будзеце абмяжоўваць сябе абмежаваннем памеру або пераходам на іншую тэхналогію.

Дадатковыя рэсурсы:

  • Як правільна выбраць тэхналогіі для вашага праграмнага праекта (выразны спіс ключавых слоў)
  • Як выбраць правільны набор тэхналогій для вашага прыкладання (добры артыкул, які абмяркоўвае рашэнне ў залежнасці ад памеру / статусу кампаніі)
  • 5 саветаў па выбары тэхналагічнага стэку для запуску (прыемны спіс і папярэджанне пра тэхнічныя мешалкі)

Дзякуй за цікавасць. Хіба я забыў нешта важнае? У вас іншае меркаванне? Я заўсёды цаню водгукі.

Сачыце за мной на Twitter для абнаўленняў і многага іншага: @jensneuhaus -