Menentukan apakah bahasa / kerangka / teknologi 'Masa Depan-bukti'

Saya seorang pengembang PHP dan saya baru-baru ini mulai bekerja dengan CodeIgniter. Tampaknya setiap kali saya mencari sesuatu yang terkait dengan CodeIgniter, posting blog dan apa yang tidak biasanya dari '09 atau '10, jadi itu membuat saya berpikir, apakah CodeIgniter masih relevan dan apakah akan di masa depan? Apakah ada kerangka kerja lain yang sedang berlangsung?

Hal yang sama juga berlaku untuk bahasa dan kerangka kerja lain. Pada titik apa Anda meninggalkan pembelajaran bahasa atau kerangka kerja tertentu? Apakah ada cara mudah untuk menemukan yang muncul dan layak untuk diambil?

Ini bukan ilmu pasti, jadi jangan berharap untuk dapat memprediksi tren masa depan dalam lanskap teknologi lebih dari 5 tahun dengan pasti.

Tetapi saya akan mencari semua hal berikut:

• Basis Terinstal - basis terinstal yang lebih besar berarti banyak perusahaan akan bersaing untuk berinvestasi dalam teknologi dan pemeliharaannya, yang berarti pengembang akan diperlukan untuk bekerja dengan teknologi tersebut. Siklus positif terjadi kemudian. Misalnya Java, seperti COBOL sebelumnya, tidak akan pergi untuk waktu yang sangat lama.
• Dukungan industri berbasis luas - adakah banyak pemain industri besar yang mendukung teknologi ini? Hanya satu pendukung yang berkomitmen adalah tanda peringatan - itu bisa dijatuhkan atau disingkirkan kapan saja dengan satu perubahan strategi.
• Open source - produk-produk open source utama telah terbukti sebagai taruhan jangka panjang yang sangat bagus (lihat Linux, Apache, Red Hat, JBoss, Eclipse misalnya ....). Produk paten di sisi lain agak atas kemauan satu vendor di mana Anda berisiko penghentian / kenaikan harga / upaya untuk memaksa untuk bermigrasi ke "hal besar berikutnya" mereka.
• Kualitas - produk berkualitas tinggi hanya akan hidup lebih lama karena orang ingin menggunakannya daripada beralih ke yang lain. Sebaliknya, produk berkualitas rendah akan ditinggalkan begitu sesuatu yang lebih baik datang.
• Inovasi - adalah teknologi menuju inovasi terdepan? Jika demikian, kemungkinan akan mendapatkan adopsi dan dukungan di antara perusahaan dan pengguna yang lebih inovatif. Ini pada akhirnya akan mulai menjadi arus utama (saya akan mengatakan bahasa baru seperti Scala dan Clojure misalnya berada dalam kategori ini)
• Komunitas - apakah ada komunitas yang positif, berpikiran terbuka, pragmatis, berkomitmen, dan membantu di seputar teknologi? Inilah orang-orang yang pada akhirnya akan menjamin masa depan .....

Tidak ada cara untuk mengetahui apakah sesuatu akan menjadi bukti di masa depan saya lebih suka fokus pada apakah teknologi membantu saya memecahkan masalah yang saya miliki saat ini. Anda akan berhenti mempelajari bahasa atau kerangka kerja tertentu ketika tidak lagi berfungsi untuk menyelesaikan masalah Anda.

Terlibat dalam komunitas yang mewakili apa yang Anda lakukan dan Anda bisa mendapatkan pemahaman yang baik tentang apa yang datang dan pergi tetapi bahkan kemudian saya lebih suka menghabiskan waktu saya dengan alat terbaik untuk pekerjaan, bukan apa yang panas atau apa yang saya pikir akan menjadi panas. satu atau dua tahun dari sekarang.

Tidak ada cara untuk menentukan secara pasti apakah sesuatu itu bukti masa depan. Yang paling dekat yang bisa Anda datangi adalah untuk menentukan tingkat aktivitas di sekitar bahasa atau kerangka kerja tertentu - jika ada banyak aktivitas pengembang, itu biasanya pertanda baik bahwa bahasa / kerangka kerja ini sedang populer dan akan bertahan untuk sementara waktu . Kebalikannya menunjukkan bahwa ada sedikit kegembiraan dan bahwa dukungan (melalui forum pengembang) mungkin lebih sulit didapat.

Selama bahasa / kerangka pilihan Anda memecahkan masalah yang Anda coba selesaikan, Anda tidak perlu khawatir tentang pemeriksaan masa depan, kecuali jika Anda jelas bekerja dengan teknologi yang sedang sekarat. Teknologi terus berubah - satu hal yang dapat Anda lakukan adalah melacak tren industri. Mempelajari bahasa / kerangka kerja pemrograman baru, sebagaimana disebutkan di utas ini , dapat membantu Anda mengikuti tren dan memberi Anda kesempatan untuk terus mengevaluasi alat-alat baru.

"Futureproof-iness" adalah tentang kemauan dan keras kepala seperti halnya tentang masalah yang lebih pragmatis.

Contoh ekstrem adalah ini . Filter Sparkle MASIH MENJALANKAN komputer IBM 402 dari akhir 40-an sebagai sistem akuntansi mereka. Ini adalah mesin yang diprogram menggunakan plug-board listrik daripada "file".

Saya pribadi memiliki pengalaman dengan perusahaan yang masih memelihara mesin berbasis MS-DOS di dalam instrumen khusus yang dirancang untuk beroperasi selama beberapa dekade. Saya bahkan membatalkan PDP operasional hingga 1997.

Saya akan mengatakan bahwa jika perusahaan Anda mendapat kunjungan dari museum sejarah komputer, seperti Filter Sparkle lakukan, itu akan menjadi tanda bahwa Anda (atau leluhur Anda) telah berhasil "membuktikan masa depan" sistem!

Saya dapat menjawab apakah teknologi tertentu adalah bukti masa depan - jawabannya hampir pasti tidak, karena Anda tidak menggunakan skala waktu untuk hal ini.

Untuk membuat pertanyaan ini dapat dijawab, Anda perlu menambahkan beberapa detail lagi ke persyaratan. Sebagai contoh:

• Apa skala waktu yang kita bicarakan - 1 tahun, 3 tahun, 5+ tahun?
• Berapa biaya untuk mengambil sesuatu yang tidak ada dalam waktu 5 tahun?
• Apa manfaat yang akan Anda dapatkan dari memilih opsi yang kurang "aman", dan apakah manfaatnya lebih besar daripada risikonya?

Pilihan bahasa / kerangka / teknologi benar-benar merupakan bagian dari manajemen risiko dalam proyek. Seperti halnya semua risiko, Anda perlu mempertimbangkan sejumlah faktor (Saya mencoba untuk membuat ini singkat) dan kemudian mengambil langkah-langkah untuk menguranginya ke tingkat yang sesuai dengan situasi yang ada.

Seperti kebanyakan hal dalam hidup, aktivitas yang melibatkan risiko paling rendah mungkin sebenarnya bukan pilihan terbaik.

Singkatnya, seberapa banyak ketidakpastian yang Anda siapkan untuk hidup dibandingkan dengan manfaat yang akan Anda peroleh dari penggunaan selama waktu hidup proyek yang diharapkan.

Semakin lama Anda ingin melihat ke masa depan, semakin sedikit kepastian yang akan terjadi. Jika Anda senang dengan hanya mengkhawatirkan 2 tahun ke depan misalnya, pilihan Anda akan jauh lebih mudah dibuat (dan membiarkan lebih banyak pilihan terbuka bagi Anda) daripada memilih sesuatu yang perlu ada selama 10 tahun ke depan.

Ada begitu banyak faktor yang menurut saya tidak mungkin. Di antara hal-hal yang bisa salah adalah: -

• Mode. Orang-orang kehilangan minat dan mengalihkan perhatian ke platform yang lebih cantik. Perl memiliki hampir monopoli aplikasi web sekitar tahun 2000. Ini hampir tidak disebutkan sekarang.
• Pangsa pasar vendor. sekitar tahun 2000 Anda akan memiliki C ++ / Sun Solaris baik sampai tahun 3000.
• Perusahaan Shenanigans. Beberapa tahun yang lalu saya akan memilih Jawa sebagai platform bukti masa depan. Dengan ORACLE menyalin API, dll. Saya pikir akan melihat pindah ke beberapa kerangka bahasa lain, saya hanya berharap saya tahu yang mana.
• Ujung jalan. Saya sedang memikirkan hal-hal seperti Visual Basic yang setelah sejarah panjang dan terhormat tidak dapat ditarik lagi untuk mengakomodasi pemikiran terbaru dalam pengembangan perangkat lunak.
• Yang kalah menang. PHP (yang saya suka) tidak dan tidak akan pernah memenangkan kontes kecantikan di antara para pengembang, tetapi PHP telah muncul sebagai raja web yang tidak perlu. Ketika saya pertama kali menulis beberapa php pada tahun 2004 saya tidak akan pernah mendukungnya sebagai bahasa pengembangan web.
• Bebek jelek. Javascript tanpa mengubah satu pun sintaks atau menambahkan satu API, tiba-tiba berubah dari bahasa scripting tipu yang dianimasikan spanduk yang menjengkelkan menambah bagian tengah WEB 2.0.

Pada akhirnya itu tidak masalah. CodeIgniter bekerja untuk Anda dan memberikan apa yang Anda inginkan. Tidak ada yang Anda lakukan akan berhenti berfungsi karena posting blog sudah tua atau tingkat rilisnya melambat. Jadi saran saya adalah menggunakan apa yang berhasil sekarang, dan, berurusan dengan masa depan ketika itu datang.

Kerangka kerja PHP, Symfony, menjelaskan ini dengan sempurna di situs mereka .

10 kriteria untuk memilih kerangka kerja yang benar

Anda membuat kemajuan dan itu hal yang baik! Anda sudah tahu bahwa Anda akan menggunakan kerangka kerja untuk mengembangkan situs atau aplikasi Anda. Tapi yang mana? Berikut adalah daftar periksa yang dapat Anda gunakan untuk menghindari kesalahan:

1.Popularitas dan ukuran komunitas

Kerangka kerja yang lebih terkenal dan diakui adalah, semakin akan "hidup," berkembang dan lengkap: ide-ide baru, jumlah dan kualitas plug-in, dll.

2.Filsafat

Ini adalah esensi dari kerangka kerja: ini adalah kriteria mendasar untuk memastikan bahwa kerangka kerja itu akan memenuhi kebutuhan Anda. Alat yang dikembangkan oleh para profesional untuk kebutuhan mereka sendiri jelas akan memenuhi tuntutan profesional lainnya.

3. Keberlanjutan

Sebelum memilih suatu kerangka kerja, pastikan bahwa ia akan bisa mengikuti Anda selama durasi. Ini menyederhanakan pemeliharaan dan peningkatan aplikasi Anda.

4. Dukungan

Kriteria lain yang tidak boleh diabaikan adalah kemudahan menemukan jawaban atas pertanyaan Anda dan mendapatkan bantuan. Identifikasi dukungan yang tersedia: dari penerbit. Dari komunitas (milis, IRC, dll.)? Dari Perusahaan Layanan (pengembangan, dukungan, pelatihan)?

5. Teknik

Untuk menghindari terjebak dalam labirin, itu selalu lebih baik untuk memilih solusi yang bisa dioperasikan; yang menghargai praktik terbaik dalam hal pengembangan (pola desain)

6. Keamanan

Aplikasi apa pun berpotensi rentan. Untuk meminimalkan risiko, selalu lebih baik untuk memilih kerangka kerja yang mampu memastikan fungsi keamanan (manajemen XSS, misalnya).

7.Dokumentasi

Merupakan keharusan mutlak untuk mengevaluasi sifat, volume, dan kualitas literatur yang ada tentang suatu kerangka kerja: alat yang terdokumentasi dengan baik lebih mudah digunakan dan lebih dapat ditingkatkan.

8. Lisensi

Lisensi itu penting hanya karena mereka dapat berdampak signifikan pada aplikasi Anda. Misalnya, aplikasi yang dikembangkan menggunakan kerangka kerja berlisensi GPL harus tunduk pada GPL. Di sisi lain, ini bukan kasus untuk kerangka kerja berlisensi MIT.

9. Ketersediaan sumber daya di pasar

Mungkin Anda ingin memiliki tim teknis yang mengelilingi Anda selama fase pengembangan atau dalam jangka panjang, untuk pemeliharaan dan peningkatan. Dengan kata lain, pastikan keterampilan yang diperlukan untuk alat yang Anda gunakan tersedia di pasar terbuka.

10. Coba!

Itu kuncinya! Jangan puas dengan membaca ulasan, komentar dan rumor, baik atau buruk, di Internet. Dengan mengujinya, Anda akan dapat mengambil keputusan sendiri dan memastikan bahwa Anda benar-benar nyaman dengan alat tersebut.

Kuncinya adalah kesabaran. Kesabaran, kesabaran, kesabaran. Tidak ada cara pasti untuk memprediksi masa depan. (apakah saya bahkan harus menulis itu?) Tetapi jika Anda memberikan teknologi baru beberapa tahun dan menonton bagaimana adopsi Anda akan memiliki ide yang baik apakah itu akan berakar atau tidak dan cocok untuk proyek jangka panjang / investasi waktu .

Jadi ketika NextNewThing (tm) muncul, jangan ragu untuk ikut-ikutan ... hanya saja tidak untuk hal-hal penting dalam beberapa tahun pertama.

Jawabannya cukup bagus. Saya akan menambahkan bahwa pemeriksaan di masa depan adalah semacam keamanan atau manajemen risiko. Seringkali Anda diharuskan untuk melepaskan kenyamanan tertentu dan manfaat biaya / produktivitas sekarang untuk menghindari masalah di kemudian hari. Saya telah membuat teknologi yang hampir pasti kedepannya cukup lama sekarang. Ada pola tertentu yang bisa membantu. Ini beberapa.

1. Data harus disimpan dalam format terbuka yang mudah diekstrak atau diubah kemudian. Format file ganjil adalah area teknik & perangkap besar pada umumnya. Juga, lebih suka pendekatan yang lebih sederhana seperti CSV, ASN.1, atau JSON daripada omong kosong yang rumit seperti XML atau, katakanlah, format Word 97;). Idenya adalah bahwa itu cukup sederhana untuk membuat parser bersama-sama sendiri dan parser format tingkat rendah dapat digunakan kembali di seluruh aplikasi Anda.

2. Aplikasi idealnya harus memiliki antarmuka vendor dan teknologi netral yang dibangun di dalamnya, ditambah deskripsi yang tepat tentang apa yang mereka lakukan. Anda harus merancang hal-hal di mana Anda dapat mengubah atau membuang implementasi tanpa merusak apa pun. Juga, pindah ke platform baru itu mudah jika metode prosedur panggilan Anda atau pemrosesan data berfungsi lintas platform. Jadi, antarmuka adalah hal yang paling penting untuk diperbaiki. Semakin sederhana, semakin cepat, dan semakin terbuka metode implementasi antarmuka, semakin baik.

3. Tumpukan harus sepenuhnya open source dan bebas untuk dimodifikasi. Lisensi GPL, LGPL, BSD, MIT, dll. Berlaku di sudut ini. Idenya adalah bahwa, jika komunitas mulai sekarat, maka tumpukan mungkin perlu dipindahkan ke [perangkat keras / OS / protokol / etc] baru. Dan Anda perlu kode untuk melakukan itu.

4. Desain tumpukan harus sangat modular dengan masing-masing bagian dapat dimengerti oleh satu orang. Ini memudahkan grup baru untuk mengambil dan memeliharanya. Bahkan dengan tingkat runtime terendah, pustaka dan kompiler yang difaktorkan dengan baik dapat memiliki hasil yang sangat besar jika perlu diangkut. Seringkali, hanya satu bagian saja yang dapat porting dan semua kode lama Anda akan berfungsi.

5. Aplikasi Anda harus dibuat dengan cara modular yang memperhitungkan detail platform untuk meminimalkan pengerjaan ulang di area itu. Ini membantu untuk menyusun fungsi menjadi blok input / pemrosesan / output jika memungkinkan juga. Ini dapat membantu analisis tentang apa yang akan dipengaruhi oleh pelabuhan (dan analisis kebenaran pada umumnya a la 'Cleanroom metodologi). Platform pendekatan risiko terendah adalah dengan menggunakan fitur common denominator terendah yang didukung secara universal dengan satu antarmuka yang memungkinkan Anda menggunakannya, semakin mengurangi porting. (Aku bilang kamu akan kehilangan sesuatu ...)

6. Pengetikan dinamis, inferensi tipe atau bantuan pengetikan fleksibel lainnya membantu. Port ke platform baru dapat mengubah definisi tipe dasar. Bahasa yang melakukan pengetikan kuat secara internal berarti Anda tidak terlalu khawatir dengan hal ini.

7. Buat model konkurensi tetap sederhana. Didorong oleh peristiwa, pesan yang melewati antarmuka yang jelas adalah portabel untuk ... pada dasarnya segalanya. Ada juga coroutine. Anda hanya ingin menghindari rute yang rentan terhadap kesalahan dan masalah portabilitas.

8. Lihatlah runtime portabel Mozilla dan Apache. Mereka memfaktorkan banyak masalah platform spesifik dengan antarmuka tertentu dan pilihan implementasi. Mereka dapat memberi tahu Anda apa yang perlu dikhawatirkan, bersama dengan memberikan solusi yang baik untuk banyak masalah.

Contoh sempurna: Tcl. Saya tahu, banyak orang membencinya dan saya jarang menggunakannya sendiri. Namun, Tcl adalah bahasa yang sangat mudah dimengerti, diimplementasikan (12 aturan utama), dan kode masuk. Ini kecil, cukup cepat, terintegrasi dengan server Web, menanamkan dalam aplikasi asli, telah diangkut ke banyak hal, memiliki fitur keamanan tertentu , dan telah diperbarui secara teratur sejak 80-an saat dibuat. Anda atau saya dapat mengimplementasikan runtime seluruh TCL dalam waktu singkat untuk bahasa inti. Jika kami harus mem-port perpustakaan standar, itu akan lebih mudah daripada porting. NET atau Java. Dan ada sedikit kode berguna yang ditulis untuk itu. Dan ini telah digunakan dalam teknologi web sejauh "agen mobile" menggila yang juga ditujukan oleh applet Java. Sebagai contoh, kerangka kerja OpenACS kembali ke 1998 dengan server yang lebih tua dari itu.

Contoh lain: BASIC, COBOL dan LISP (Skema atau CL). Bahasa-bahasa ini semua kembali ke 50-an atau 60-an. Mereka cukup sederhana untuk memudahkan pemahaman, implementasi dan terjemahan mekanis. Namun, Anda dapat membangun hal-hal yang berguna dengannya. COBOL masih mendukung sebagian besar pemrosesan transaksi dunia, telah diperbarui beberapa kali, & bahkan berjalan di .NET. Aplikasi QBasic / QuickBASIC lama masih berjalan hari ini dengan alat terbuka / gratis pada platform modern, bersama dengan porting kemungkinan ke alat yang lebih baik seperti GAMBAS atau RealBASIC. LISP coders secara alami membuat sistem mereka modular dan fungsional, memudahkan porting. Sudah ada aliran implementasi yang stabil selama beberapa dekade, terbuka dan komersial.

Jadi, antarmuka, keterbukaan, kesederhanaan, modularitas, dan arsitektur / desain / pengkodean platform-netral. INI akan memberi Anda pemeriksaan masa depan yang Anda butuhkan. Bagaimanapun, sebagian besar waktu.