Вибір технологій для великих і не дуже великого веб-проекту

За роки роботи я часто чую питання про вибір технологій для того чи іншого веб-проекту. Хтось запитує в нас, як у розробників, як правильно, а хтось приходить і просить зробити на якійсь конкретній технології. Проблема в тому, що більшість вибирають технології з суб'єктивних причин, і поки я не чув гідного і зрозумілого міркування, яке дозволило б вибрати технологію об'єктивно, спираючись на факти, а не бажання. Навіть деякі итишники можуть правильно вибрати технологію, адже для цього потрібно розуміти специфіку проекту, мати багаторічний досвід розробки на декількох мовах, знати, як влаштовані подібні проекти і т. д.

Але перш, ніж щось вибирати, давайте подивимося, які технології бувають, чим вони відрізняються і в яких випадках яку технологію вибрати.

Як найчастіше вибирають технологію зараз:
  1. Вона мені подобається
  2. Знайомий порадив
  3. Прочитав в Інтернеті
  4. На цій технології зроблений аналогічний сайт
В чому тут проблема:
  1. Подобається. Дуже суб'єктивно. А що, якщо по вимогам вона не підходить? Або на ній працюють дуже дорогі і рідкісні фахівці? Чи вмирає вона взагалі?
  2. Знайомий. Зазвичай це той знайомий, який «трохи краще» розбирається в ІТ, ніж той, кому він радить. І навіть якщо він програміст з досвідом, він не може знати всіх рішень на всіх популярних мовах. Адже ніхто не питає, за якими критеріями обирав цей знайомий. Якщо цей знайомий не CTO Google, я б так просто не довіряв такої рекомендації.
  3. Прочитав. Тут вже краще: можна знайти різні порівняння і аргументацію. Але знову ж, щоб розібратися у всіх рішеннях людині, нехай навіть з міцними знаннями в розробці, потрібно час. А без знань в розробці всі прочитані технічні огляди нічого не варті.
  4. Аналог. Більшість популярних сайтів написані на тих чи інших технологіях, тому що так «історично склалося». Якби Facebook зараз обирав технологію для себе, я сумніваюся, що він взяв за основу PHP. А ще може бути, що технологія вже застаріла, її продавили на основі минулих 3-х пунктів, вибрали якусь розрекламовану технологію, а не дійсно ефективну і т. д. Ви навряд чи можете знати реальні причини вибір технологій в інших проектах. Оптимальні технології використовуються вкрай рідко в аналогічних проектах.
Таким чином, жоден з перерахованих вище методів вибору технологій розробки не відповідає критеріям об'єктивності. Тому варто спочатку визначити ці критерії, а вже потім підбирати з ним технічну платформу. Нижче я спробую виділити дійсно важливі для проекту критерії, на яких ми і будемо ґрунтуватися.

Важливі критерії при виборі технологій:

  1. Розмір та тип проекту
  2. Складність проекту
  3. Швидкість розробки
  4. Вартість фахівців
  5. Доступність фахівців
  6. Доступні інструменти розробки
  7. Наявність готових рішень
  8. Гнучкість рішення
  9. Наявність широкого співтовариства
  10. Відмовостійкість рішення
  11. Тренд його розвитку
  12. Наявність докладної документації
  13. Вартість підтримки
  14. Вимоги до навантажень
  15. Вимоги до безпеки
  16. Кросплатформеність
  17. Можливості інтеграції з іншими рішеннями
Вибираючи технологію по таким критеріям, ми зможемо домогтися об'єктивного вибору і тим самим заощадити собі час і гроші.

Які бувають проекти
До технологіям ми ще повернемося, а поки давайте розберемося, які бувають проекти. Часто тип проекту говорить сам за себе, і можна відразу сказати, що підійде: або вже готове рішення, або хоча б в яку сторону потрібно рухатися.

За складністю проекти поділяються:

  1. Прості (візитки, лендінгем, прості інтернет-магазини, прості програми) — такі рішення зазвичай робляться на тематичних коробкових рішеннях, CMS або шаблонах.
  2. Середні (складні інтернет-магазини і маркетплейсы, портали національного масштабу, різноманітні сервіси, просунуті програми) — такі рішення зазвичай робляться на фреимворках.
  3. Складні (величезні портали, соціальні мережі, інноваційні та нетипові рішення) — ядро таких проектів зазвичай розробляється на чистому (нативному) мовою програмування.
За тематикою: інтернет-магазини, дошки оголошень, соціальні мережі і т. д. Для більшості популярних тематичних рішень вже давно є коробкові продукти, і, якщо ми не намагаємося зробити якогось монстра, то правильніше буде вибрати саме їх. Рішень дуже багато, всі в одній статті описати неможливо.

Мови програмування
У технологіях я б виділив 3 рівня абстракції:

  1. Чистий мова — це матеріал, з якого можна зробити все, що завгодно. Обмежують нас тільки можливості мови. Чистою мовою, зроблені всі найбільші сайти світу з відвідуваністю в сотні мільйонів і мільярдів користувачів, такі як: Instagram, YouTube, Pinterest, Tumblr, Dropbox, Twitter, Facebook, Amazon, Digg, LinkedIn та інші. Більше того, найбільші проекти в світі навіть створюють нові технології для себе, так як вже існуючі їх не влаштовують.

  2. Фреимворк — це певне середовище розробки для програміста з готовими правилами та інструментами. Фреимворк, з одного боку, допомагає і прискорює розробку, а з іншого, накладає певні обмеження. На фреимворках робляться проекти середньої складності з відвідуваністю в мільйони.

  3. CMS — це вже готове рішення, конструктор, в якому ми по частинах збираємо потрібний проект. Його скоріше не програмують, а налаштовують. Обмежень тут величезна кількість, вийти за межі коробки важко і неефективно. На CMS робляться прості сайти з відвідуваністю до мільйона користувачів в місяць.
Найчастіше один рівень абстракції базується на іншому. Тобто чистою мовою роблять фреимворки, а на фреимворках роблять CMS. Для кожного популярного мови є багато різних фреимворков і CMS, але про це пізніше.

Сьогодні є величезна кількість різних мов програмування, на яких роблять сайти. І, більш того, на всіх популярних мовах є приклади величезних сайтів. Якщо 10 років тому, говорячи про технології великих сайтів, всі говорили переважно про Java, то сьогодні це може бути майже будь-яку мову, і стверджувати, що сайти робляться на якомусь конкретному мовою, — стереотип. Це пов'язано з розвитком самих мов, за останнє десятиліття багато сильно просунулися в розвитку і отримали широкі можливості. Звичайно, кожен мову чимось відрізняється, і вибираючи ми знову ж повинні керуватися об'єктивними критеріями з огляду на завдання проекту.

Чистою мовою, без використання фреимворков і коробкових рішень, пишуться величезні проекти з підвищеними вимогами гнучкості, навантажень і безпеки. Для таких величезних проектів часто бюджет не грає такої ролі, як ефективність. Чим більше проект, тим більше вимог щодо гнучкості і навантажень, а значить, простіше писати все з нуля, виділяючи на це кращих фахівців, ніж якщо брати якісь готові рішення, які незрозуміло ким писалися і незрозуміло які проблеми у них приховані. Приміром, коли йдеться про невеликому проекті з відвідуваністю в 10 тис. чоловік в день, то нам буде дешевше зробити його на CMS, яка буде споживати в 3 рази більше ресурсів сервера, поставити додатковий сервер за 50$ / міс., і він буде працювати. Коли ж ми говоримо про сайт з відвідуваністю 100 млн. користувачів в день, вартість додавання серверів у нас буде просто космічної, тому нам простіше і дешевше вкласти гроші в розробку рішення на чистому мовою, яке буде оптимальним для конкретного проекту.

Чим більше проект, тим більше стек технологій, який в ньому використовується. У величезних порталах може використовуватися відразу декілька мов програмування. Знову ж таки, ми приходимо до об'єктивним критеріям вибору технологій. Часто одна мова може добре вирішувати одне завдання, а інший — іншу. Такі проекти можуть бути настільки величезними, що їх частини можуть працювати на різних серверах, з різними доменами (поддоменами) і різними технологіями. Не слід боятися вінегрету технологій у великому проекті, хоча і допускати його потрібно тільки, коли це дійсно необхідно, а також пам'ятати, що далеко не всі технології сумісні. Найяскравіший приклад використання різних технологій — Google. Він на стільки великий, щоб різні його частини написані на C/C++, Java, Python, PHP та інших мовах. Більш того, Google активно створює нові технології, як, наприклад, популярний нині AngularJS.

Спробую дати коротку характеристику кожному з популярних мов:

  1. PHP — його використовують в основному для простих і середніх проектів. Дуже багато коробкових рішень. Відносно дешеві програмісти. Антитренд останніх років, хоча з виходом останньої версії мови під номером 7, він отримав дійсно потужні можливості.
  2. Python — сучасна мова, розробка на ньому швидка і якісна. Використовують його для середніх і великих проектів. Програмістів знайти проблематично, і коштують вони не дешево.
  3. Ruby — сучасна мова, розробка на ньому також швидка. Його використовують в основному для розробки простих і середніх проектів, часто розробляють стартапи. Програмістів також мало і вони дорогі.
  4. Java — розробка на ньому дуже довга і дорога. Його використовують в основному для великих проектів зі специфічними вимогами.
  5. C# — аналог Java, також використовують для великих проектів, частина у сфері FinTech.
  6. JS — дуже швидко розвивається, тренд останніх років. Величезна кількість напрацювань, і можна писати все, що завгодно, навіть ігри. Його використовують для середніх і великих проектів, але дійсно потужні можливості цю мову отримав недавно, тому прикладів великих проектів поки мало, фахівці найдорожчі, і знайти їх складніше всього.
Я описав найпопулярніші мови, які сьогодні використовуються під веб. Є багато нових мов, які дуже швидко ростуть, зокрема Scala і деякі інші. Але поки вони досить молоді і сирі. Я б не рекомендував бігти за модою і писати на них, поки вони не розвинуться у щось більше.

Приклади великих сайтів:

  • PHP: Facebook, Вконтакте, КиноПоиск
  • Python: Instagram, Pinterest, Reddit
  • Ruby: 500px, Groupon, Airbnb
  • Java: Ebay, Amazon, Alibaba
  • C#: Guru, Stack Overflow, Bank of America
  • JS: LinkedIn, Walmart, PayPal
Ці приклади відмінно показують, що великі сайти можуть бути на різних мовах, і це нормально. Знову ж таки, приходимо до того, що вибирати технологію потрібно під вимоги, керуючись об'єктивними причинами.

Фреймворки та платформи
Це якась середовище розробки для програмістів, де є готова інфраструктура і ряд готових функцій зі стандартними рішеннями типових завдань. Такий собі напівфабрикат, з якого можна зробити цукерку. На кожній мові є багато різних фреймворків. Є як загальні, які створювалися для розробки будь-яких рішень, так і спеціалізовані, під вузькі завдання. Наприклад, Sylius — спеціалізований E-commerce фреймворк на основі Symfony. Також є ті, на яких робляться великі і складні рішення, а інші для цього не призначені. Нижче я опишу популярні фреймворки для кожної з мов, на яких можна писати великі і складні рішення.

На фреймворках розробляються досить великі і складні сайти з унікальним функціоналом. Це значно швидше й дешевше, ніж на чистому мовою, але при цьому таке рішення дозволяє розробляти дійсно складні речі і оптимізувати все це під навантаження. Крім того, це майже завжди більш безпечно, ніж будь-яка коробкова CMS.

Популярні фреймворки і платформи:

  1. PHP: Symfony, Laravel
  2. Python: Django
  3. Ruby: Ruby On Rails
  4. Java: Spring
  5. C#: .NET
  6. JS: Node.js, AngularJS
Найбільше фреймворків на PHP, і на цій мові є, з чого вибирати, але дійсно функціональних не так багато. Менше на інших мовах, а на деяких дійсно якісних фреймворків взагалі всього один, як у мови Ruby. У Java дуже багато різних фреймворків для різних цілей, і не тільки для сайтів. Всі ці фреймворки щорічно розвиваються, виходять все нові й нові версії, одні фреймворки обганяють інші. Наприклад, Laravel тільки в останні кілька років вийшов на перше місце за популярністю, хоча найскладніші сайти досі робляться на Symfony.

.NET і Node.js — це цілі самостійні платформи, які базуються на певних мовах, але мають дуже широкі можливості.

CMS і CMF
Це готове програмне забезпечення, яке потрібно тільки налаштувати, рідше — дописати / переписати якусь з частин. Таких рішень дуже багато на будь-якій мові, але історично так склалося, що в основному всі популярні CMS зроблені на PHP. Тут справа у розвитку мов, раніше прості сайти, для яких і створювалися CMS, писалися на PHP. Я ще застав ті часи, коли CMS майже не було, були скрипти — окремі готові частини різних сайтів. Пізніше ці скрипти збирали в коробковий продукт, який був покликаний вирішити потреби 90% простих сайтів. Так і вийшло, що основні CMS зроблені на PHP. Сьогодні CMS на інших мовах розвиваються слабо, тому що вже є сильні конкуренти на PHP, а для простого сайту мову не грає великої ролі, тому всі дивляться на можливості цих готових продуктів.

CMF, якщо говорити простою мовою, — це щось середнє між CMS і фреймворком по можливостям. Зазвичай CMF використовують для найбільш складних сайтів з цієї категорії. Цей підхід дозволяє позбутися від зайвих частин CMS, які не потрібні конкретного проекту.

CMS бувають різні за призначенням: загальні, для інтернет-магазинів, для блогів і т. д. Різні за умовами використання: платні і безкоштовні. Для кожної популярної CMS є багато різних платних і безкоштовних модулів, які легко підключати і використовувати.

Маленькі сайти, які в основному потрібні для малого бізнесу, майже завжди використовують CMS. Це дозволяє дуже сильно економити час на розробку. Крім того, для налаштування таких рішень не потрібні дорогі програмісти, зазвичай це можуть робити новачки в програмуванні, принаймні саму настройку, якщо вже потрібно писати код, тут складніше.

Саме в роботі з CMS виникає найбільше нерозуміння серед кінцевих замовників таких рішень. Будь-яка CMS — це тонни готового програмного коду, на всі випадку життя. В одній поставці йдуть десятки і сотні модулів. Все це дуже сильно обмежує фахівців. Такі рішення сильно «гальмують», вони абсолютно не гнучкі, їх дуже легко зламати, особливо безкоштовні CMS. Ще часто зламують CMS через модулі сторонніх розробників, в яких є критичні уразливості, тому що ми ніколи не знаємо, якого рівня програміст писав той чи інший модуль. Тобто будь-яка CMS НЕ розрахована для великого і складного сайту. Вона не може витримати великі навантаження. Це рішення небезпечно, щоб не говорили розробники конкретної CMS.

Я бачив рішення майже на всіх популярних CMS, з багатьма за більш, ніж 10 років роботи, довелося попрацювати особисто. Частина з них популярна в рунеті, а частина знають в основному на заході. На використовувані в них мови CMS розбивати немає сенсу, з причин, описаних вище. Краще сказати кілька слів про кожну популярну CMS:

  1. WordPress — колись блоговый движків, зараз на ній робляться майже будь-які сайти, включаючи магазини. Одна з найпопулярніших CMS в світі, є приклади досить відвідуваних сайтів. На ній часто роблять інформаційні сайти, в тому числі різні ЗМІ. Система безкоштовна.
  2. Joomla! — CMS загального призначення. Якістю особливо не відрізняється, на ній роблять дуже маленькі сайти, і зазвичай дешевше всіх інших варіантів, так як саме з цієї CMS починають вчитися багато починаючі програмісти. Система безкоштовна.
  3. Drupal — це вже CMF для загального призначення, з недавнього часу поставляється з вбудованих фреймворком Symfony. Досить потужна, на ній є відомі сайти, наприклад, офіційний сайт Білого Дому. Система безкоштовна.
  4. Magento — найпопулярніша система управління для інтернет-магазинів у світі. Досить потужна і складна. У рунеті використовується рідко, в основному на заході.
  5. PrestaShop — одна з найпопулярніших CMS для магазинів у світі. Теж досить потужна, використовують в основному на заході. Система безкоштовна.
  6. OpenCart — ще одна популярна система для інтернет-магазинів, але її, навпаки, більше використовують в рунеті, ніж на заході. В основному для маленьких і нескладних магазинів. Система безкоштовна.
  7. 1С-Бітрікс — дуже розпіарена CMS загального призначення, номер 1 в рунеті. Можливості дуже широкі. На ній часто намагаються робити великі і складні сайти, а після певного порогу в відвідуваності переписують їх на інших технологіях. Багато вважають, що тільки ця CMS може інтегруватися з 1С, що не є правдою, оскільки всі перераховані CMS з цього списку можуть інтегруватися з 1С, для цього у всіх CMS є спеціальні модулі. Система платна.
З усіма перерахованими CMS я працював. В основному з боку розробника. Точно НЕ рекомендую — Joomla, з рештою можна працювати. Для магазинів краще вибирати спеціалізовані, а не загальні CMS. Крім 1С-Бітрікс в рунеті є аналогічні комерційні CMS, вони багато в чому схожі. У кожної з систем має свої особливості, але всі вони не призначені для великих і складних проектів, головне це не забувати.

Шаблони
В останні 5 років дуже активно розвивають шаблонні рішення. Це ще на одну сходинку вище, ніж CMS. Якщо CMS — це конструктор, і його потрібно налаштовувати, шаблони — це вже готові рішення під типові випадки. Наприклад, у кожному місті є свої ресторани, таксі, клініки і т. д. Для всіх цих типів малого бізнесу потрібно приблизно одне і теж. Тому, можна просто вибрати готовий тематичний шаблон, замінити в ньому логотип, кольори і контент. При бажанні такі шаблони можна допрацьовувати на розсуд власника.

Переваги таких рішень у тому, що вони дуже дешеві і їх можна запускати моментально. Але при цьому такі рішення не враховують особливостей бізнесу і конверсія буде не дуже високою.

Є спеціальні каталоги шаблонів: TemplateMonster, ThemeForest та ін Часто зустрічаються онлайн-конструктори, в тому числі тематичні: Wix, PageCloud та ін

Мобільні додатки
У мобільних додатках останнім часом використовується два підходи: нативна розробка і кросплатформені технології. Нативна ведеться на оригінальних мовах програмування, зокрема Swift (для iOS, раніше був Objective-C) і Java (для Android). Кросплатформених технологій зараз досить багато, вони є на базі різних мов програмування, зокрема: Apache Cordova, React Native та ін Деякі краще, деякі гірше. У будь-якому випадку, складні програми пишуться завжди на нативних технологіях. З кроссплатформой часто виникають проблеми, аж до того, що деякі функції просто не реалізовуються на тих чи інших кросплатформених технологіях, сильно вантажиться оперативна пам'ять пристрою, швидко сідає батарея і т. д.

У цих двох підходах люди теж часто плутаються, намагаючись використовувати кросплатформені технології на всі випадки життя. Воно й зрозуміло, адже кроссплатформа дозволяє писати код один раз, який відразу працює на iOS, і на Android, в той час, як на нативних технологіях це виходить мінімум в два рази дорожче. Однак мало хто знає про можливі подальші проблеми в розробці. Я б рекомендував дуже ретельно вибирати технології, і кроссплатформу брати тільки для простих додатків, інакше доведеться переписувати. Втім, кросплатформені технології поступово розвиваються і стають все краще, а додатки, написані на них, все складніше.

Стек технологій у великих проектах

Вище я описав різні мови і фреймворки, які використовуються у великих проектах, однак, якщо придивитися до дійсно великим проектам, там можна знайти цілий комплекс мов і технологій. Майже всі великі сайти використовують один основний мову і декілька додаткових. Теж саме з базами даних: для одних завдань можуть використовуватися реляційні, а для інших нереляційні бази. І все це органічно поєднується в рамках одного проекту.

Вибір технологій залежить від пропонованої архітектури проекту. Саме архітектор продумує основні блоки майбутнього сайту. Яку мову ляже на основу, чи буде він нативним або фреймворк, яку систему кешування вибрати, які бази даних, як все це буде пов'язано і т. д.

Для прикладу розглянемо технології Instagram (дані Insight IT):

  • Ubuntu Server 14.04 LTS — основна серверна операційна система
  • Python — основна мова програмування серверної частини
  • Django — фреймворк
  • nginx — другий рівень балансування входять HTTP-запитів
  • gunicorn — WSGI-сервер
  • HAProxy — балансування навантаження всередині системи
  • PostgreSQL — основне сховище даних
  • postgis — підтримка гео-запитів
  • pgfouine — звіти на основі логів
  • pgbouncer — створення пулу з'єднань
  • Redis — додаткове сховище даних
  • Memcached — кешування
  • Gearman — черга завдань
  • Solr — гео-пошук
  • munin, statsd, pingdom — моніторинг
  • Fabric — управління кластером
  • xfs — файлова система
І це цілком нормальний стек технологій. Сам Instagram не самий великий і складний сервіс у світі.

Вартість фахівців
Один з найважливіших факторів вибору технології є вартість і доступність фахівців, тому що саме це — найбільш витратна частина в будь-якому проекті. У рунеті є тільки одна пузомерка по зарплатах: https://jobs.dou.ua/salaries/ — я відфільтрував по Києву, рівень Senior, досвід 3-5 років. Порівняємо середні значення.

Зарплати:

  1. C# – 3072$
  2. Java – 3300$
  3. JS – 3500$
  4. PHP – 2780$
  5. Python – 3000$
  6. Ruby – 3000$
  7. Scala – 3900$
У США дещо інша картина:


Тепер переведемо цифри на людську мову. Java хоч і не новий мову, але фахівці на ньому завжди були одними з найбільш дорогих. PHP завжди був найдешевшим, так і фахівців на ринку дуже багато. У порівняння я вніс ще й Scala, як один з новітніх і трендових мов, з цієї причини він дорожче всіх. Ще дорогою JS, це пов'язано з його бурхливим зростанням в останні роки і зростаючою популярністю Node.js, а також AngularJS.

Таким чином: якщо ми хочемо економити, то краще дивитися на PHP — фахівці дешеві, а велике ком'юніті. А якщо хочемо саме якісне, то дивимося на Scala, який називають майбутньому веб-розробки, але, правда, на ньому знайти фахівців майже неможливо, і напрацювань просто немає.

Ще важливим параметром буде швидкість розробки. Адже важлива не тільки зарплата програмістів, але і швидкість розробки. Якщо не враховувати вже існуючі напрацювання, то одними з найшвидших у розробці будуть Python і Ruby, а самий повільний — Java. До речі, з цієї причини за останні 10 років майже не вийшло нових мегапроектів на Java, зате вийшло багато проектів на Python, про що я розповім нижче.

Тренди
Вибираючи технологію, нам потрібно дивитися вперед. Особливо, якщо мова йде про великий проект. Всі технології дуже швидко розвиваються, виходять все нові і нові версії. Мови сильно змінюються кожні 5-7 років, фреймворки — кожні 2-3 роки, а CMS — кожні 1-2 роки. Важливо вибрати не просто гарну технологію сьогодні, а передбачити тренди розвитку так, щоб залишитися на коні і через кілька років. Інакше, в кінцевому рахунку, доведеться переписувати проект, що завжди дуже проблематично.

Є різноманітні дослідження, які нам можуть підказати деякі статистичні викладки. Наприклад, дослідження TIOBE Index показує цікаву статистику:



За результатами різних досліджень можна виділити явних лідерів по зростанню — це JS (версія ES6 і вище) і мультипарадигмальные мови, зокрема Scala. До речі, саме Scala вважається наступником мови Java і багато в чому на нього схожий. Також не погано себе показує Python.

Антитренды тримають ряд старих мов і PHP. Правда, нещодавно вийшла 7я версія PHP, в якій виправлено багато серйозні недоліки. Так що, я думаю, ми скоро побачимо новий виток розвитку PHP. Також багато великі проекти переписуються з Ruby на інші мови, теж якийсь антитренд.

Для ілюстрації подивимося, яких фахівців не вистачає в США:



Саме це можна вважати реальною картиною трендів, які ми бачимо і у нас.

На чому робилися великі проекти за останні 10 років?

  1. Airbnb – Ruby
  2. Instagram – Python
  3. Pinterest – Python
  4. Foursquare – Python
  5. Groupon – Ruby -> JS
  6. Twitter – Ruby -> Scala
  7. Uber – JS
Це вже не теоретична статистика, а реальна практика. Python і JS дуже добре себе показують.

Вартість підтримки
Безумовно, важливий критерій вибору технології — це вартість підтримки, про яку мало хто замислюється на початку розробки. Зазвичай всі мислять категоріями вартості години підтримки, що в корені неправильно. Нам важливі кілька параметрів: вартість години, кількість годин, офіційна підтримка технології, доступність фахівців, правильний підхід до розробки і деякі інші.

Вартість години залежить від зарплати фахівці, з цим ми вже розібралися. А ось кількість годин залежить від самої технології і якості написання коду. Якщо коробкове рішення, то годині на нього може йти дуже багато. Тобто, з одного боку, ми можемо заощадити при розробці першої версії проекту, але після загрузнути в його постійній доопрацювання. Добре, коли рішення популярний, та є офіційна документація. Але часто вибирають маловідомі коробкові рішення без будь-якої документації — до таких рішень вартість підтримки буде у багато разів вище вартості самої коробки. Те ж стосується неякісної розробки: у нас чомусь повністю відсутня культура проведення технічних аудитів готових рішень або їхніх частин. В середньому за 20-40 годин можна перевірити майже будь-яке рішення і знайти його основні мінуси. Чим більш якісний код, тим легше, а отже, і дешевше його підтримувати.

Також слід дивитися на версію мови, фреимворка, CMS. Потрібно завжди використовувати останню стабільну версію, щоб вона не застаріла до виходу проекту в продакшн. При появі нової версії потрібно відразу розглядати можливість переводу проекту на цю версію. Тому що, якщо пропустити кілька версій, потім буде проблемно зробити різке оновлення.

Так що вибрати?
Підіб'ємо підсумок. Для простих сайтів найчастіше відмінно підходять коробкові рішення і шаблони. Складні сайти робляться тільки на фреимворках або навіть чистих мовах програмування. Робити можна на дуже різних мовах, мова вибирається під проект. Прості мобільні додатки можна робити на кросплатформених технологіях, а складні зазвичай робляться на рідних технологіях. Ну і, вибираючи платформу, завжди варто керуватися об'єктивними критеріями, які я описав в статті.

Нижче я зробив опитування з кращого мови програмування для великого проекту. Мається на увазі рівень проектів з відвідуваністю 100 млн. користувачів і більше. Якщо у вас є досвід розробки великих проектів, хоча б на кілька мільйонів користувачів, прошу не просто проголосувати, а й обгрунтувати свою думку в коментарях, так як у кожного різні досвід та уподобання. Розбавимо деяку частку суб'єктивізму статті думками інших членів спільноти :)

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.