Визначення того, чи є мова / рамка / технологія "стійкою до майбутнього"

Я розробник PHP, і я нещодавно почав працювати з CodeIgniter. Здається, що коли я шукаю щось, пов’язане з CodeIgniter, повідомлення в блогах і те, що зазвичай не буває від '09 або '10, тому я задумався, чи CodeIgniter все ще актуальний і чи буде це в майбутньому? Чи є інша основа, яка займає це місце?

Те саме стосується і інших мов та рамок. У який момент ви відмовляєтеся вивчати певні мови чи рамки? Чи є якийсь простий спосіб знайти ті, що з’являються і які варто підібрати?

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

Але я б шукала все наступне:

• Встановлена ​​база - більша встановлена ​​база означає, що багато компаній будуть продовжувати інвестувати в технології та її обслуговування, а значить розробникам знадобиться працювати з цією технологією. Настає позитивний цикл. Наприклад, Java, як і COBOL до цього, не виходить дуже довго.
• Широка підтримка галузі - чи є кілька виробників великих виробників імен, які підтримують цю технологію? Лише один прихильний захисник є попереджувальним знаком - його можна будь-коли відмовитись або відкласти в сторону за допомогою однієї зміни стратегії.
• Open source - основні продукти з відкритим кодом виявились надзвичайно хорошими довгостроковими ставками (наприклад, подивіться Linux, Apache, Red Hat, JBoss, Eclipse ....). З іншого боку, власницька продукція дещо на примхах одного продавця, коли вам загрожує припинення / підняття цін / спроби змусити перейти до своєї "наступної великої речі".
• Якість - високоякісна продукція просто проживе довше, тому що люди захочуть використовувати їх, а не переходити на щось інше. І навпаки, від низької якості продукти відмовляться, як тільки щось краще вийде.
• Інновації - чи є технологія до передових інновацій? Якщо так, то, ймовірно, вийде прийняття та підтримка серед більш інноваційних компаній та користувачів. Це в кінцевому підсумку почне ставати мейнстрімом (я б сказав, що нові мови, такі як Scala і Clojure, наприклад, в цій категорії)
• Спільнота - це там позитивна, відкрита, прагматична, віддана, корисна спільнота навколо технології? Це люди, які в остаточному підсумку гарантують, що це майбутнє .....

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

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

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

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

"Майбутнє стійкість" - це стільки як сила волі та впертість, скільки й більш прагматичні проблеми.

Крайній приклад - це . Фільтр іскорень ВІДМОВИТИ ВІДМОВЛЕННЯ комп'ютера IBM 402 з кінця 40-х років як їх облікової системи. Це машина, яка запрограмована за допомогою електричних плагін, а не «файлів».

Я особисто мав досвід роботи з компанією, яка все ще підтримує машини на базі MS-DOS всередині спеціалізованих приладів, розроблених для роботи протягом десятиліть. Я навіть зняв оперативну PDP ще в 1997 році.

Я б сказав, що якщо ваша компанія відвідує музей комп'ютерної історії, як це зробили Sparkle Filters, це буде знаком того, що ви (або ваші предки) успішно "захищені майбутнім" системою!

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

Щоб відповісти на це запитання, вам потрібно буде додати ще деякі деталі до вимог. Наприклад:

• Про який часовий графік ми говоримо - 1 рік, 3 роки, 5+ років?
• Якою буде вартість вибору того, чого немає за 5 років?
• Які переваги ви отримаєте від вибору менш "безпечного" варіанту і чи переваги переваги перевищують ризики?

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

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

Коротше кажучи, з якою невизначеністю ви готові жити порівняно з вигодами, які ви збираєтеся отримати за рахунок очікуваного часу життя проекту.

Чим довше ви хочете заглянути в майбутнє, тим менше буде впевненості. Якщо вам подобається лише турбуватися, наприклад, про наступні 2 роки, наприклад, ваш вибір буде набагато простіше зробити (і залишити для вас набагато більше варіантів), ніж вибрати щось, що потрібно буде протягом наступних 10 років.

Для цього є так багато факторів, я б сказав, що це неможливо. Серед речей, які можуть піти не так:

• Мода. Люди втрачають інтерес і звертають увагу на нову гарнішу платформу. У Perl майже монополія на веб-додатки близько 2000 року.
• Частка ринку постачальників. до 2000 року, хоч C ++ / Sun Solaris був хорошим до 3000 року.
• Корпоративні шенагігани. Пару років тому я вибрав би Java як майбутню платформу підтвердження. Якщо авторське право на ORACLE захищає авторські права і т.д.
• Кінець дороги. Я думаю про такі речі, як Visual Basic, які після довгої і почесної історії просто не можна розтягнути, щоб відповідати останнім думкам у розробці програмного забезпечення.
• Невдаха виграє. PHP (який мені подобається) не став і ніколи не вигравав жодних конкурсів краси серед розробників, але це стало беззаперечним королем Інтернету. Коли я вперше написав якийсь php у 2004 році, я ніколи не підтримав би це як linga franca веб-розробки.
• Потворні каченята. Javascript, не змінюючи жодного фрагмента синтаксису або додаючи єдиного API, раптом перейшов з мови скриптів, що анімовує роздратований банер, що додає до центральної частини WEB 2.0.

Зрештою, це не так вже й важливо. CodeIgniter працює для вас і забезпечує те, що ви хочете. Ніщо, що ви зробите, не перестане працювати, оскільки публікації в блозі старі або швидкість випуску сповільнилася. Тому моя порада буде використовувати те, що працює зараз, і займатися майбутнім, коли воно з’явиться.

Рамка PHP, Symfony, чудово пояснила це на їхньому сайті .

10 критеріїв вибору правильних рамок

Ви прогресуєте, і це добре! Ви вже знаєте, що збираєтесь використовувати рамку для розробки свого веб-сайту чи програми. Але який? Ось контрольний список, який ви можете використовувати, щоб не помилитися:

1. Популярність та розмір спільноти

Чим більше відома і визнана рамка, тим більше вона буде "живою", розвивається і завершується: нові ідеї, кількість та якість плагінів тощо.

2.Філософія

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

3. стійкість

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

4.Підтримка

Ще один критерій, який не слід оминати, - це легкість пошуку відповідей на ваші запитання та отримання допомоги. Визначте підтримку, яка доступна: від видавця. Від спільноти (списки розсилки, IRC тощо)? Від сервісних компаній (розробка, підтримка, навчання)?

5.Техніка

Щоб не потрапити в пастку в лабіринті, завжди краще вибирати сумісне рішення; той, який поважає кращі практики щодо розвитку (шаблони дизайну)

6. Безпека

Будь-яка програма потенційно вразлива. Щоб мінімізувати ризик, завжди краще вибрати рамку, здатну забезпечувати функції безпеки (наприклад, управління XSS).

7.Документація

Це абсолютно необхідна оцінка характеру, обсягу та якості існуючої літератури про рамки: добре задокументований інструмент є простішим у використанні та оновленням.

8.Ліцензія

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

9.Наявність ресурсів на ринку

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

10. Спробуйте це!

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

Ключ терпіння. Терпіння, терпіння, терпіння. Не можна точно передбачити майбутнє. (мені це навіть довелося писати?) Але якщо ви дасте новій технології пару років і подивитесь, як її прийняли, ви матимете гарне уявлення про те, чи вона приживеться чи підходить для довгострокових проектів / часових інвестицій .

Тож коли NextNewThing (tm) обійдеться, сміливо стрибайте на смузі ... просто не на щось важливе протягом перших двох років.

Відповідь Мікераса досить приємна. Додам, що захист у майбутньому - це справді вид безпеки чи управління ризиками. Часто це вимагає відмовитися від певних зручностей та вигод від вартості / продуктивності, щоб пізніше уникнути проблем . Я вже досить довгий час заробляю технологію, що може бути впевненою у майбутньому. Є певні закономірності, які можуть допомогти. Ось кілька.

1. Дані слід зберігати у відкритому форматі, який легко витягти або перетворити пізніше. Незвичайні формати файлів - це велика техніка фіксації та пастка загалом. Крім того, віддайте перевагу більш простим підходам, таким як CSV, ASN.1 або JSON, над складними лайнами, такими як XML або, скажімо, формат Word 97;). Ідея полягає в тому, що досить просто зібрати аналізатор разом, і аналізатор формату низького рівня можна використовувати повторно у ваших програмах.

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

3. Стек повинен бути повністю відкритим кодом і вільний для модифікації. Ліцензії GPL, LGPL, BSD, MIT та ін. Ідея полягає в тому, що якщо спільнота починає відмирати, то стек може знадобитися перенести на новий [обладнання / ОС / протокол / тощо]. І для цього вам потрібен код.

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

5. Ваш додаток має бути виконано модульно, щоб визначати деталі платформи, щоб мінімізувати переробку в цій області. Це допомагає структурувати функції в блоки введення / обробки / виведення, де це можливо. Це може допомогти проаналізувати те, на що вплине порт (і правильність аналізу в цілому a la 'Cleanroom методологія). Найменшою платформою підходу до ризику є розумне використання найнижчих загальних знаменників, які підтримуються універсально за допомогою одного інтерфейсу, який дозволяє використовувати їх, зменшуючи перенос. (Я сказав, що ти щось загубиш ...)

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

7. Зберігайте модель одночасності простою. Повідомлення, керовані подіями, що проходять через чіткі інтерфейси, є портативними для ... в основному всього. Є також супроводи. Ви просто хочете уникати маршрутів, схильних як до помилок, так і до проблем з переносом.

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

Ідеальний приклад: Tcl. Я знаю, багато людей ненавиджу це, і я дуже рідко сам його вживаю. Тим не менш, Tcl - це надзвичайно проста мова для розуміння, впровадження (12 основних правил) та кодування. Він невеликий, досить швидкий, інтегрується з веб-серверами, вбудовується в рідні програми, переноситься на безліч матеріалів, має певні функції безпеки , і регулярно оновлюється з 80-х років, коли він був зроблений. Ви або я могли впровадити цілий термін виконання TCL за найкоротший час для основної мови. Якби нам довелося перенести стандартну бібліотеку, це було б простіше, ніж перенесення .NET або Java. І для цього написано досить багато корисного коду. І його використовували у веб-технологіях ще до того часу, як манія «мобільного агента», на яку також спрямовані аплети Java. Наприклад, веб-структура OpenACS починається з 1998 року, сервер старший за це.

Інші приклади: BASIC, COBOL та LISP (схема або CL). Усі ці мови сягають 50-х чи 60-х років. Вони досить прості, щоб полегшити розуміння, реалізацію та механічний переклад. Тим не менш, ви можете створювати корисні речі з ними. COBOL як і раніше працює на більшій частині обробки транзакцій у світі, оновлювався кілька разів і працює навіть у .NET. Старі додатки QBasic / QuickBASIC і досі працюють із відкритими та безкоштовними інструментами на сучасних платформах, а також пропонують можливості переробки кращих інструментів, таких як GAMBAS або RealBASIC. LISP-кодери, природно, роблять свої системи модульними та функціональними, полегшуючи перенесення. Існує стабільний потік реалізацій для нього протягом десятиліть, відкритих та комерційних.

Отже, інтерфейси, відкритість, простота, модульність та архітектура / дизайн / кодування - нейтральна платформа. ЦЕ отримає вам майбутнє виправдання, яке вам потрібно. Більшість часу, все одно.