Ustalanie, czy język / środowisko / technologia jest „przyszłościowa”

Jestem programistą PHP i niedawno zacząłem pracować z CodeIgniter. Wygląda na to, że ilekroć szukam czegoś związanego z CodeIgniter, posty na blogu, a nie te, które zwykle pochodzą z „09” lub „10”, więc pomyślałem, czy CodeIgniter jest nadal aktualne i czy będzie w przyszłości? Czy istnieją inne ramy, które mają miejsce?

To samo dotyczy również innych języków i ram. W którym momencie rezygnujesz z nauki niektórych języków lub ram? Czy jest jakiś prosty sposób na znalezienie tych, które się pojawiają i które warto podnieść?

To nie jest ścisła nauka, więc nie spodziewaj się, że będziesz w stanie przewidzieć przyszłe trendy w krajobrazie technologicznym dłużej niż 5 lat z całą pewnością.

Ale szukałbym wszystkich następujących elementów:

• Zainstalowana baza - większa zainstalowana baza oznacza, że ​​wiele firm będzie nadal inwestować w technologię i jej utrzymanie, co oznacza, że ​​programiści będą musieli pracować z tą technologią. Następuje cykl dodatni. Na przykład Java, podobnie jak wcześniej COBOL, nie odchodzi bardzo długo.
• Szerokie wsparcie branżowe - czy istnieje wielu znanych graczy branżowych wspierających tę technologię? Tylko jeden zatwierdzony podmiot popierający jest znakiem ostrzegawczym - może zostać upuszczony lub odsunięty na bok w dowolnym momencie za pomocą jednej zmiany strategii.
• Open source - główne produkty open source okazały się wyjątkowo dobrymi długoterminowymi zakładami (na przykład Linux, Apache, Red Hat, JBoss, Eclipse ...). Z drugiej strony produkty zastrzeżone są w pewnym stopniu kaprysem pojedynczego dostawcy, w przypadku którego istnieje ryzyko wycofania się / podwyższenia cen / prób zmuszenia do migracji do „następnej wielkiej rzeczy”.
• Jakość - produkty wysokiej jakości będą po prostu dłużej żyć, ponieważ ludzie będą chcieli z nich korzystać, zamiast przechodzić na coś innego. I odwrotnie, produkty niskiej jakości zostaną porzucone, gdy tylko pojawi się coś lepszego.
• Innowacje - czy technologia zmierza w kierunku innowacji? Jeśli tak, prawdopodobnie zyska adopcję i wsparcie wśród bardziej innowacyjnych firm i użytkowników. To ostatecznie stanie się głównym nurtem (powiedziałbym, że nowe języki, takie jak na przykład Scala i Clojure, są w tej kategorii)
• Społeczność - czy istnieje pozytywna, otwarta, pragmatyczna, zaangażowana, pomocna społeczność wokół technologii? To są ludzie, którzy ostatecznie zagwarantują jej przyszłość .....

Nie ma sposobu, aby dowiedzieć się, czy coś będzie przyszłym dowodem, na którym wolę się skupić, czy technologia pomoże mi rozwiązać problem, który mam dzisiaj. Porzuciłbyś naukę określonego języka lub frameworka, gdy nie działa on już w celu rozwiązania twoich problemów.

Zaangażuj się w społeczność, która reprezentuje to, co robisz, i możesz dobrze orientować się w tym, co nadchodzi i odchodzi, ale nawet wtedy wolę spędzać czas z najlepszym narzędziem do pracy, a nie gorącym lub moim zdaniem gorącym za rok lub dwa.

Nie ma sposobu, aby ostatecznie ustalić, czy coś jest na przyszłość. Najbliższe, jakie możesz przyjść, to określenie poziomu aktywności wokół określonego języka lub frameworka - jeśli jest dużo aktywności programistów, zwykle jest to dobry znak, że popularność języka / frameworka będzie opłacalna i przez jakiś czas będzie opłacalna . Odwrotność wskazuje, że emocje są mniejsze i że wsparcie (za pośrednictwem forów programistów) może być trudniejsze do uzyskania.

Tak długo, jak twój wybrany język / struktura rozwiązuje problem, który próbujesz rozwiązać, nie powinieneś się martwić o zabezpieczenie na przyszłość, chyba że wyraźnie pracujesz z umierającą technologią. Technologia ciągle się zmienia - jedyne, co możesz zrobić, to śledzić trendy w branży. Nauka nowych języków / struktur programowania, jak zauważono w tym wątku , może pomóc ci nadążać za trendami i daje ci możliwość ciągłej oceny nowych narzędzi.

„Odporność na przyszłość” dotyczy zarówno siły woli i uporu, jak i bardziej pragmatycznych problemów.

Skrajny przykład jest taki . Filtry Sparkle Wciąż działają na komputerze IBM 402 z późnych lat 40-tych jako ich system księgowy. Jest to maszyna programowana za pomocą elektrycznych wtyczek zamiast „plików”.

Ja osobiście miałem doświadczenie w firmie, która nadal utrzymuje maszyny oparte na MS-DOS w specjalistycznych instrumentach, zaprojektowanych do działania przez dziesięciolecia. Zlikwidowałem nawet operacyjny PDP dopiero w 1997 roku.

Powiedziałbym, że jeśli twoja firma zostanie odwiedzona przez muzeum historii komputerów, tak jak zrobiły to Sparkle Filters, byłby to znak, że ty (lub twoi przodkowie) udało się „zabezpieczyć” system na przyszłość!

Mogę odpowiedzieć na pytanie, czy dana technologia jest przyszłościowa - odpowiedź jest prawie na pewno nie, ponieważ nie podałeś w tym zakresie czasu.

Aby odpowiedzieć na to pytanie, musisz dodać więcej szczegółów do wymagań. Na przykład:

• O jakiej skali czasowej mówimy - 1 rok, 3 lata, ponad 5 lat?
• Jaki byłby koszt wybrania czegoś, czego nie będzie w ciągu 5 lat?
• Jakie korzyści uzyskasz wybierając mniej „bezpieczną” opcję i czy korzyści przewyższają ryzyko?

Wybór języka / struktury / technologii jest tak naprawdę częścią zarządzania ryzykiem w projekcie. Podobnie jak w przypadku wszystkich rodzajów ryzyka, musisz wziąć pod uwagę szereg czynników (staram się, aby było to krótko), a następnie podjąć kroki w celu obniżenia go do poziomu odpowiedniego do danej sytuacji.

Podobnie jak w przypadku większości rzeczy w życiu, aktywność, która wiąże się z najniższym ryzykiem, może nie być najlepszym wyborem.

Krótko mówiąc, z jaką niepewnością jesteś przygotowany do życia w porównaniu z korzyściami, które będziesz czerpać z korzystania w oczekiwanym okresie życia projektu.

Im dłużej chcesz spojrzeć w przyszłość, tym mniejsza będzie pewność. Jeśli na przykład jesteś zadowolony, że martwisz się tylko o następne 2 lata, wybór będzie o wiele łatwiejszy (i pozostawi Ci o wiele więcej opcji do wyboru) niż wybranie czegoś, co powinno być dostępne przez następne 10 lat.

Jest tak wiele czynników, które powiedziałbym, że jest to niemożliwe. Wśród rzeczy, które mogą pójść nie tak, są:

• Moda. Ludzie tracą zainteresowanie i zwracają uwagę na nową, ładniejszą platformę. Perl miał prawie monopol na aplikacje internetowe około 2000 roku.
• Udział w rynku dostawców. około 2000, ale C ++ / Sun Solaris był dobry do 3000 roku.
• Korporacyjne Shenanigany. Kilka lat temu wybrałbym Javę jako platformę przyszłości. Z ORACLE chroniącymi prawa autorskie do API itp. Myślę, że zobaczę odejście do innych ram językowych, chciałbym tylko wiedzieć, który.
• Koniec drogi. Mam na myśli rzeczy takie jak Visual Basic, których po długiej i honorowej historii nie można już dłużej rozciągać, aby uwzględnić najnowsze myślenie w zakresie tworzenia oprogramowania.
• Przegrany wygrywa. PHP (które lubię) nie wygrałoby i nigdy nie wygrało żadnych konkursów piękności wśród programistów, ale stało się niekwestionowanym królem sieci. Kiedy po raz pierwszy napisałem php w 2004 roku, nigdy nie poparłbym tego jako linga franca do tworzenia stron internetowych.
• Brzydkie kaczątka. JavaScript bez zmiany ani jednej składni ani dodania pojedynczego API nagle przeszedł z hokeyowego języka skryptowego, który animowany irytujący baner dodaje do środkowej części WEB 2.0.

W końcu to nie ma aż tak wielkiego znaczenia. CodeIgniter działa dla Ciebie i dostarcza to, czego chcesz. Nic, co zrobisz, nie przestanie działać, ponieważ posty na blogu są stare lub zwolniło tempo wydawania. Tak więc radzę skorzystać z tego, co działa teraz, i poradzić sobie z przyszłością, jeśli będzie to możliwe.

Struktura PHP, Symfony, doskonale to wyjaśniła na swojej stronie .

10 kryteriów wyboru poprawnych ram

Robisz postępy i to dobrze! Wiesz już, że zamierzasz użyć frameworka do opracowania swojej witryny lub aplikacji. Ale który? Oto lista kontrolna, której możesz użyć, aby uniknąć pomyłki:

1. Popularność i wielkość społeczności

Im bardziej znana i rozpoznawalna jest struktura, tym bardziej będzie „żywa”, ewoluująca i kompletna: nowe pomysły, liczba i jakość wtyczek itp.

2. Filozofia

To jest istota ram: jest to podstawowe kryterium zapewniające spełnienie twoich potrzeb. Narzędzie opracowane przez profesjonalistów na własne potrzeby będzie oczywiście spełniać wymagania innych specjalistów.

3. Zrównoważony rozwój

Przed wybraniem frameworka upewnij się, że będzie on w stanie dotrzymać Ci kroku przez cały czas. Upraszcza to zarówno konserwację, jak i aktualizację aplikacji.

4. wsparcie

Kolejnym kryterium, którego nie należy przeoczyć, jest łatwość znalezienia odpowiedzi na pytania i uzyskania pomocy. Znajdź dostępne wsparcie: od wydawcy. Ze społeczności (listy mailingowe, IRC itp.)? Od firm usługowych (rozwój, wsparcie, szkolenia)?

5. Technika

Aby uniknąć uwięzienia w labiryncie, zawsze lepiej jest wybrać rozwiązanie interoperacyjne; taki, który szanuje najlepsze praktyki w zakresie rozwoju (wzorce projektowe)

6. Bezpieczeństwo

Każda aplikacja jest potencjalnie podatna na ataki. Aby zminimalizować ryzyko, zawsze lepiej jest wybrać strukturę zapewniającą funkcje bezpieczeństwa (na przykład zarządzanie XSS).

7. Dokumentacja

Jest to absolutna konieczność oceny charakteru, objętości i jakości istniejącej literatury na temat ram: dobrze udokumentowane narzędzie jest zarówno łatwiejsze w użyciu, jak i bardziej rozbudowalne.

8. Licencja

Licencje są ważne po prostu dlatego, że mogą mieć znaczący wpływ na twoje aplikacje. Na przykład aplikacja opracowana przy użyciu środowiska licencjonowanego przez GPL będzie koniecznie podlegać GPL. Z drugiej strony nie dotyczy to frameworku na licencji MIT.

9. Dostępność zasobów na rynku

Być może chciałbyś, aby zespół techniczny otaczał Cię podczas fazy rozwoju lub w dłuższej perspektywie, zarówno w zakresie konserwacji, jak i aktualizacji. Innymi słowy, upewnij się, że umiejętności wymagane dla używanego narzędzia są dostępne na otwartym rynku.

10. Wypróbuj!

To jest klucz! Nie zadowalaj się czytaniem recenzji, komentarzy i plotek, dobrych lub złych, w Internecie. Testując to, będziesz mógł podjąć decyzję i upewnić się, że czujesz się całkowicie komfortowo z tym narzędziem.

Kluczem jest cierpliwość. Cierpliwość, cierpliwość, cierpliwość. Nie ma możliwości przewidzenia przyszłości. (czy w ogóle musiałem to napisać?) Ale jeśli poświęcisz nową technologię na kilka lat i zobaczysz, jak została ona przyjęta, będziesz miał dobry pomysł, czy zapuści korzenie i czy nadaje się do długoterminowych projektów / inwestycji czasowych .

Więc kiedy pojawi się NextNewThing (tm), nie wahaj się wskoczyć na modę ... po prostu nie na nic ważnego przez pierwsze kilka lat.

Odpowiedź Mikeras jest całkiem niezła. Dodam, że zabezpieczenie na przyszłość jest naprawdę rodzajem bezpieczeństwa lub zarządzania ryzykiem. Często wymaga to rezygnacji z niektórych udogodnień i korzyści w zakresie kosztów / wydajności teraz, aby uniknąć problemów w przyszłości. Od dłuższego czasu tworzę technologię prawie przyszłościową. Istnieją pewne wzorce, które mogą pomóc. Oto kilka.

1. Dane powinny być przechowywane w otwartym formacie, który można łatwo wyodrębnić lub przekształcić później. Nieparzyste formaty plików to duża technika blokowania i ogólnie obszar pułapki. Wolą też prostsze podejścia, takie jak CSV, ASN.1 lub JSON, niż skomplikowane bzdury, takie jak XML lub, powiedzmy, format Word 97;). Chodzi o to, że samodzielne zebranie parsera jest wystarczająco proste, a parser formatu niskiego poziomu może być używany w różnych aplikacjach.

2. Idealnie aplikacje powinny mieć wbudowane interfejsy niezależne od dostawcy i technologii oraz dokładny opis tego , co robią. Powinieneś zaprojektować rzeczy, w których możesz zmienić lub wyrzucić implementację bez niszczenia czegokolwiek. Przejście na nową platformę jest również łatwe, jeśli metoda wywoływania procedur lub przetwarzania danych działa na różnych platformach. Tak, interfejsy są najbardziej ważną rzeczą, aby uzyskać prawidłowe. Im prostsza, szybsza i bardziej otwarta metoda implementacji interfejsu, tym lepiej.

3. Stos powinien być całkowicie open source i swobodnie modyfikować. Licencje GPL, LGPL, BSD, MIT itp. Są odpowiednie pod tym kątem. Chodzi o to, że jeśli społeczność zacznie wymierać, stos może wymagać przeniesienia do nowego [sprzęt / OS / protokół / etc]. Potrzebujesz do tego kodu.

4. Konstrukcja stosu powinna być wyjątkowo modułowa, a każdy element powinien być zrozumiały dla jednej osoby. Ułatwia to nowej grupie jej podniesienie i utrzymanie. Mając nawet najniższe poziomy środowiska uruchomieniowego, biblioteki i kompilator ładnie przemyślane, mogą przynieść ogromne korzyści, jeśli trzeba je przenieść. Często tylko jedna część może być przeniesiona i cały twój stary kod będzie działał.

5. Twoja aplikacja powinna być wykonana w sposób modułowy, który uwzględnia szczegóły platformy, aby zminimalizować przeróbki w tym obszarze. Pomaga także w miarę możliwości strukturywać funkcje w bloki wejściowe / przetwarzające / wyjściowe. Może to pomóc w analizie tego, na co wpłynie port (oraz w analizie poprawności w ogólności metodologii a la Cleanroom). Podejście oparte na podejściu o najniższym ryzyku polega na użyciu funkcji najniższego wspólnego mianownika, które są ogólnie obsługiwane z jednym interfejsem, który pozwala z nich korzystać, co dodatkowo zmniejsza przenoszenie. (Powiedziałem, że coś stracisz ...)

6. Pomagają w tym dynamiczne pisanie, wnioskowanie i inne elastyczne metody pisania. Port na nową platformę może zmienić definicje typów podstawowych. Języki, w których wewnętrzne pisanie na klawiaturze jest mocne, oznacza, że ​​mniej się o to martwisz.

7. Utrzymaj prosty model współbieżności. Sterowany zdarzeniami komunikat przesyłany przez jasne interfejsy jest przenośny do ... w zasadzie wszystkiego. Są też kortyny. Chcesz po prostu unikać tras, które są podatne zarówno na błędy, jak i problemy z przenośnością.

8. Spójrz na przenośne środowiska uruchomieniowe Mozilli i Apache. Rozróżniają wiele problemów specyficznych dla platformy przy określonych opcjach interfejsu i implementacji. Mogą wskazać ci, o co się martwić, a także zapewnić dobre rozwiązania wielu problemów.

Idealny przykład: Tcl. Wiem, że wiele osób go nienawidzi i rzadko sam go używam. Jednak Tcl jest niezwykle łatwym do zrozumienia językiem, implementacją (12 głównych zasad) i kodowaniem. Jest mały, wystarczająco szybki, integruje się z serwerami WWW, osadza się w natywnych aplikacjach, został przeniesiony do wielu rzeczy, ma pewne funkcje bezpieczeństwa , i był regularnie aktualizowany od lat 80., kiedy został wyprodukowany. Ty lub ja moglibyśmy wdrożyć cały środowisko uruchomieniowe TCL w krótkim czasie dla podstawowego języka. Jeśli mieliśmy do portu standardowej biblioteki, byłoby łatwiejsze niż przenoszenie .NET lub Java. I jest do tego napisany całkiem użyteczny kod. I był używany w technologiach internetowych już od szaleństwa „agenta mobilnego”, do którego również dążyły aplety Java. Na przykład platforma internetowa OpenACS sięga 1998 roku, a serwer jest starszy.

Inne przykłady: BASIC, COBOL i LISP (Schemat lub CL). Wszystkie te języki sięgają lat 50. lub 60. Są wystarczająco proste, aby ułatwić zrozumienie, wdrożenie i tłumaczenie mechaniczne. Możesz jednak budować z nimi przydatne rzeczy. COBOL nadal obsługuje większość procesów przetwarzania transakcji na świecie, został kilkakrotnie zaktualizowany i działa nawet w .NET. Stare aplikacje QBasic / QuickBASIC nadal działają dzisiaj z otwartymi / bezpłatnymi narzędziami na nowoczesnych platformach, a także z możliwościami przenoszenia lepszych narzędzi, takich jak GAMBAS lub RealBASIC. Kodery LISP w naturalny sposób sprawiają, że ich systemy są modułowe i funkcjonalne, co ułatwia przenoszenie. Przez dziesięciolecia wprowadzano do niego stały strumień wdrożeń, otwarty i komercyjny.

Interfejsy, otwartość, prostota, modułowość i neutralna dla platformy architektura / projekt / kodowanie. TE zapewni Ci zabezpieczenie, którego potrzebujesz w przyszłości. W każdym razie przez większość czasu.