Dilin / çerçevenin / teknolojinin 'Geleceğe uygun' olup olmadığını belirleme


10

Ben bir PHP geliştiricisiyim ve yakın zamanda CodeIgniter ile çalışmaya başladım. Her ne zaman CodeIgniter ile ilgili bir şey aradığımda, blog gönderileri ve genellikle '09 veya '10'dan olmayan şey, bu yüzden beni düşündürdü, CodeIgniter hala alakalı ve gelecekte olacak mı? Onun yerini alan başka bir çerçeve var mı?

Aynı şey diğer diller ve çerçeveler için de geçerlidir. Hangi noktada belirli dilleri veya çerçeveleri öğrenmeyi bırakıyorsunuz? Ortaya çıkan ve almaya değer olanları bulmanın kolay bir yolu var mı?



1
@MotiveKyle Hızlı bir arama bana bunu getirdi ... tiobe.com/index.php/content/paperinfo/tpci/index.html Bunun yararlı olup olmadığından emin değilim ama ilginç hiçbiri az.
Ominus

3
@MotiveKyle Bence altta yatan sorun (ve bundan muzdarip) "Ben öğrenmek için seçtiğim şey içine koymak üzereyim zaman / çaba değer mi?". Bu kadar çok seçenekle, seçtiğimiz çalışma serimizde en büyük getiriyi elde etmek için zaman / enerjiye en iyi nasıl yatırım yapılacağını bulmak çok zor olabilir.
Ominus

1
Aklımda olan buydu. Listelenen çerçeveleri yoksa çok kötü!
Kyle

3
COBOL, geleceğe yönelik en ileri teknolojilerden biridir. COBOL kurulu tabanının kaybolması pek olası değildir. Bunun ne anlama geldiğini düşünmek isteyebilirsiniz.
user16764

Yanıtlar:


17

Bu tam bir bilim değil, bu yüzden teknoloji alanında gelecekteki eğilimleri 5 yıldan fazla bir süre boyunca kesin olarak tahmin edebilmeyi beklemeyin.

Ama aşağıdakilerin tümünü ararım:

  • Yüklü taban - daha büyük bir yüklenen taban, birçok şirketin teknolojiye ve bakımına yatırım yapmaya devam edeceği anlamına gelir, bu da geliştiricilerin teknolojiyle çalışmak için gerekli olacağı anlamına gelir. Pozitif döngü başlar. Örneğin, Java, önceki COBOL gibi, çok uzun bir süre gitmiyor .
  • Geniş tabanlı Endüstri desteği - teknolojiyi destekleyen çok sayıda büyük isim endüstri oyuncusu var mı? Sadece bir taahhütlü destekçi bir uyarı işaretidir - tek bir strateji değişikliği ile istendiği zaman bırakılabilir veya kenara çekilebilir.
  • Açık kaynak - büyük açık kaynak ürünlerinin son derece iyi uzun vadeli bahisler olduğu kanıtlanmıştır (örneğin Linux, Apache, Red Hat, JBoss, Eclipse'e bakın ...). Öte yandan tescilli ürünler, bir sonraki tedarikçilerine göç etmeye zorlama / sürdürebilen fiyatlar / kesintiler riski altında olduğunuz tek bir tedarikçinin hevesindedir.
  • Kalite - yüksek kaliteli ürünler daha uzun yaşayacaktır çünkü insanlar başka bir şeye geçmek yerine bunları kullanmak isteyecektir . Tersine, daha iyi bir şey gelir gelmez düşük kaliteli ürünler terk edilecektir.
  • İnovasyon - teknoloji inovasyonun en ileri noktasına doğru mu? Öyleyse, daha yenilikçi şirketler ve kullanıcılar arasında evlat edinme ve destek kazanma olasılığı yüksektir. Bu nihayetinde ana akım olmaya başlayacak (örneğin, Scala ve Clojure gibi yeni diller bu kategoride)
  • Topluluk - teknoloji çevresinde olumlu, açık fikirli, pragmatik, kararlı, yararlı bir topluluk var mı? Nihayetinde geleceğini garanti edecek insanlar bunlar .....

3
Peki VB6'yı nasıl açıklıyorsunuz? ;-)
sdg

4
Kara büyü.....?
mikera

1
-1, çünkü çoğu puan kanıtlanmamıştır. Örneğin, açık kaynaklı uzun vadeli bahisler olarak bahsediyorsunuz. Peki MacOS, Windows, Visual Studio ve en popüler binlerce ürün uzun vadeli bahisler değil mi? Yenilik: Burada ne göstermek istersiniz? Kullandığımız tüm ürünler yaygınlaşmadan önce yenilikçi idi. Kalite: tanımlayın. Çoğu PHP popüler çerçevesi ve kütüphanesi korkunç spagetti koduyla yazılmıştır, ancak yine de popülerdir.
Arseni Mourzenko

1
@MainMa: Açık kaynak popülaritesi artıyor ve Windows popülaritesi düşüyor, kanıt var gibi görünüyor. "Binlerce popüler ürün uzun vadeli bahis değildir" Doğru. Beş yıl içinde çok sayıda ürün olmayacak. "korkunç spagetti kodu, ama hala popüler." Cevabı okudun mu? "daha iyi bir şey gelir". PHP için daha iyi bir şey yok mu? Yani. Miras yerinde kalır.
S.Lott

3
@MainMa Açık Kaynak yazılımı, projenin terk edilmeyeceğini garanti etmez. Ancak, orijinal ekip yapmazsa, bunu sürdürme olasılığınız olacağını garanti eder. Ürün büyük ve başarılı bir derleme tarafından geliştirilmiyorsa, kapalı kaynak olduğunda eski / genişletilemez bir çerçeveye sıkışmış olma riskiyle karşı karşıya kalırsınız.
Simon Bergot

14

Bir şeyin geleceğin kanıtı olup olmayacağını bilmenin bir yolu yok, odaklanmak istediğim teknoloji bugünkü sorunu çözmeme yardımcı oluyor mu? Sorunlarınızı çözmek için artık çalışmadığında belirli bir dili veya çerçeveyi öğrenmeyi bırakacaksınız.

Ne yaptığınızı temsil eden topluluğa dahil olun ve ne olup bittiğini iyi anlayabilirsiniz ama o zaman bile sıcak olmamak ya da sıcak olacağını düşündüğüm iş için en iyi araçla vakit geçirmeyi tercih ederim. bundan bir iki yıl sonra.


7
Geleceği öngörmek çok zor olduğu için, “geleceğin kanıtı” nın ne anlama gelebileceğini anlamak zordur. "'Sanırım yaklaşık beş bilgisayar için bir dünya pazarı var' - 1943 Thomas J. Watson'a (Uluslararası İş Makineleri Kurulu Başkanı) atfedilen marka".
S.Lott

7

Bir şeyin gelecekteki kanıt olup olmadığını kesin olarak belirlemenin bir yolu yoktur. Gelebileceğiniz en yakın şey, belirli bir dil veya çerçeve etrafındaki etkinlik düzeyini belirlemektir - çok fazla geliştirici etkinliği varsa, genellikle dilin / çerçevenin popülerlik içinde yükseldiğini ve bir süre için geçerli olacağını gösteren iyi bir işarettir. . Tersi, daha az heyecan olduğunu ve desteğin (geliştirici forumları aracılığıyla) gelmesinin daha zor olabileceğini gösterir.

Diliniz / seçim çerçeveniz çözmeye çalıştığınız sorunu çözdüğü sürece, ölmekte olan bir teknolojiyle net bir şekilde çalışmadığınız sürece gelecekteki kanıtlar konusunda endişelenmenize gerek yoktur. Teknoloji değişmeye devam ediyor - yapabileceğiniz tek şey endüstri trendlerini takip etmektir. Bu başlıkta belirtildiği gibi yeni programlama dillerini / çerçevelerini öğrenmek, trendleri takip etmenize yardımcı olabilir ve size yeni araçları sürekli olarak değerlendirme fırsatı verir.


5

"Geleceğe-karşı-beceriksizlik" irade gücü ve inatçılık ile daha pragmatik kaygılar kadar.

Aşırı bir örnek bu . Sparkle Filters, 40'lı yılların sonlarından itibaren IBM 402 bilgisayarını muhasebe sistemi olarak ÇALIŞIYOR. Bu, "dosyalar" yerine elektrik prizleri kullanılarak programlanan bir makinedir.

Şahsen MS-DOS tabanlı makineleri hala on yıllardır çalışmak üzere tasarlanmış özel cihazların içinde tutan bir şirkette deneyim yaşadım. 1997 yılına kadar operasyonel bir PDP bile hurdaya ayırdım.

Şirketiniz bilgisayar tarih müzesinden, Sparkle Filters'ın yaptığı gibi bir ziyaret alırsa, bunun sizin (veya atalarınızın) sistemi başarılı bir şekilde "geleceğe kanıtladığınızı" gösteren bir işaret olacağını söyleyebilirim!


Kelime 'gelecek için kanıtlanmış' olmalı, muhtemelen :)
9000

5

Belirli bir teknolojinin geleceğe kanıt olup olmadığını cevaplayabilirim - cevap neredeyse kesinlikle hayır, çünkü buna bir zaman ölçeği koymadınız.

Bu soruyu yanıtlanabilir yapmak için gereksinimlere biraz daha ayrıntı eklemeniz gerekecek. Örneğin:

  • Hangi zaman ölçeğinden bahsediyoruz - 1 yıl, 3 yıl, 5+ yıl?
  • 5 yıl içinde olmayan bir şeyi seçmenin maliyeti ne olur?
  • Daha az "güvenli" bir seçenek seçmekten ne gibi faydalar elde edersiniz ve faydalar risklerden daha ağır basar mı?

Dil / çerçeve / teknoloji seçimi, projedeki risk yönetiminin bir parçasıdır. Tüm risklerde olduğu gibi, bir dizi faktörü göz önünde bulundurmanız gerekir (bunu kısa tutmaya çalışıyorum) ve ardından eldeki duruma uygun bir seviyeye indirmek için adımlar atmanız gerekir.

Hayattaki çoğu şeyde olduğu gibi, en düşük riski içeren etkinlik aslında en iyi seçim olmayabilir.

Kısacası, projenin beklenen yaşam süresi boyunca kullanmanın getireceği faydalara kıyasla yaşamak için ne kadar belirsizlik hazırlıyorsunuz.

Geleceğe ne kadar uzun süre bakmak isterseniz, o kadar az kesinlik olacaktır. Sadece önümüzdeki 2 yıl için endişelenmekten memnunsanız, seçiminizi yapmak önümüzdeki 10 yıl boyunca etrafta olması gereken bir şey seçmekten çok daha kolay olacaktır (ve size daha fazla seçenek bırakın).


3

Bunun imkansız olduğunu söyleyeceğim çok faktör var. Yanlış gidebilecek şeyler arasında: -

  • Moda. İnsanlar ilgilerini kaybediyor ve dikkatleri yeni bir güzel platforma çeviriyor. Perl 2000 dolaylarında neredeyse tek bir web uygulaması tekeline sahipti.
  • Satıcıların pazar payı. 2000 dolaylarında C ++ / Sun Solaris 3000 yılına kadar iyi olurdu.
  • Kurumsal Shenanigans. Birkaç yıl önce gelecekteki kanıt platformu olarak Java'yı seçerdim. ORACLE'ın API vb. Telif hakkı olmasıyla, başka bir dil çerçevesine doğru bir hareket göreceğini düşünüyorum, sadece hangisini bilseydim.
  • Yolun sonu. Visual Basic gibi, uzun ve onurlu bir tarihten sonra yazılım geliştirmedeki en son düşünceye uyum sağlamak için daha fazla genişletilemeyen şeyleri düşünüyorum.
  • Kaybeden kazanır. PHP (sevdiğim), geliştiriciler arasında herhangi bir güzellik yarışması kazanmaz ve asla kazanmaz, ancak web'in tartışmasız kralı olarak ortaya çıktı. 2004 yılında ilk php yazdığımda bunu web geliştirme linga franca olarak asla desteklemezdim.
  • Çirkin ördek yavrusu. Tek bir sözdizimini değiştirmeden veya tek bir API eklemeden Javascript, aniden can sıkıcı banner'ın WEB 2.0'ın orta parçasına eklediği hokey komut dosyası dilinden gitti.

Sonunda o kadar önemli değil. CodeIgniter sizin için çalışır ve istediğinizi sunar. Blog gönderileri eski olduğu veya yayınlanma hızı yavaşladığı için hiçbir şey çalışmayı durduramaz. Bu yüzden tavsiyem şu anda işe yarayanı kullanmak ve gelecekteki geleceği ele almak olacaktır.


2

Bir PHP çerçevesi olan Symfony, bunu sitelerinde mükemmel bir şekilde açıkladı .

Doğru çerçeveyi seçmek için 10 kriter

İlerleme kaydediyorsunuz ve bu iyi bir şey! Sitenizi veya uygulamanızı geliştirmek için bir çerçeve kullanacağınızı zaten biliyorsunuz. Fakat hangisi? Hata yapmamak için kullanabileceğiniz bir kontrol listesi:

1. popülerlik ve topluluk boyutu

Çerçeve ne kadar iyi bilinir ve tanınırsa, o kadar "canlı" olur, gelişir ve tamamlanır: yeni fikirler, eklentilerin sayısı ve kalitesi, vb.

2.Philosophy

Çerçevenin özü budur: ihtiyaçlarınızı karşılayacağından emin olmak için temel bir kriterdir. Profesyoneller tarafından kendi ihtiyaçları için geliştirilen bir araç, açıkça diğer profesyonellerin taleplerini karşılayacaktır.

3.Sustainability

Bir çerçeve seçmeden önce, süre boyunca size ayak uydurabildiğinden emin olun. Bu, uygulamalarınızın bakımını ve yükseltilmesini kolaylaştırır.

4.Support

Göz ardı edilmemesi gereken bir diğer kriter, sorularınıza cevap bulma ve yardım alma kolaylığıdır. Kullanılabilir desteği belirleyin: yayıncıdan. Bir topluluktan mı (posta listeleri, IRC vb.)? Hizmet Şirketlerinden (geliştirme, destek, eğitim)?

5.Technique

Bir labirentte sıkışıp kalmamak için birlikte çalışabilir bir çözüm seçmek her zaman tercih edilir; geliştirme açısından en iyi uygulamalara saygı duyan (tasarım modelleri)

6.Security

Herhangi bir uygulama potansiyel olarak savunmasızdır. Riski en aza indirmek için, güvenlik işlevlerini (örneğin XSS yönetimi) sağlayabilecek bir çerçeve seçmek her zaman daha iyidir.

7.Documentation

Bir çerçeve hakkında mevcut literatürün niteliğini, hacmini ve kalitesini değerlendirmek mutlak bir zorunluluktur: iyi belgelenmiş bir araç hem daha kolay hem de daha yükseltilebilir.

8.License

Lisanslar, uygulamalarınız üzerinde önemli bir etkisi olabileceğinden önemlidir. Örneğin, GPL lisanslı bir çerçeve kullanılarak geliştirilen bir uygulama mutlaka GPL'ye tabi olacaktır. Öte yandan, bu MIT lisanslı bir çerçeve için geçerli değildir.

9.Pazardaki kaynakların kullanılabilirliği

Belki geliştirme ve uzun vadede hem bakım hem de yükseltme için sizi çevreleyen bir teknik ekibin olmasını istersiniz. Başka bir deyişle, kullandığınız araç için gerekli becerilerin açık pazarda mevcut olduğundan emin olun.

10.Deneyin!

Anahtar bu! İnternette iyi ya da kötü yorumlar, yorumlar ve söylentiler okumaktan memnun kalmayın. Test ederek, kendi fikrinizi oluşturabilir ve araçla tamamen rahat olmanızı sağlayabilirsiniz.


1

Anahtar sabırdır. Sabır, sabır, sabır. Geleceği tahmin etmenin kesin bir yolu yok. (bunu bile yazmak zorunda mıydım?) Ama yeni teknolojiyi birkaç yıl verir ve nasıl benimsendiğini izlerseniz, köklü olup olmayacağı ve uzun vadeli projeler / zaman yatırımı için uygun olup olmadığı hakkında iyi bir fikriniz olacaktır. .

Yani NextNewThing (tm) geldiğinde, bandwagon'a atlamaktan çekinmeyin ... sadece ilk birkaç yıl içinde önemli bir şey için değil.


0

Mikeras'ın cevabı oldukça güzel. Geleceğin kanıtlanmasının bir çeşit güvenlik veya risk yönetimi olduğunu da ekleyeceğim. Genellikle belirli kolaylıklar ve maliyet / verimlilik avantajları vazgeçmek gerektirir şimdi önlemek sorunlarına sonrası. Uzun süredir neredeyse geleceğe dönük bir teknoloji yapıyorum. Yardımcı olabilecek bazı desenler var. İşte birkaçı.

  1. Veriler daha sonra çıkarılması veya dönüştürülmesi kolay açık bir biçimde saklanmalıdır. Tek dosya formatları genel olarak büyük bir kilitleme tekniği ve tuzak alanıdır. Ayrıca, XML gibi karmaşık bok yerine CSV, ASN.1 veya JSON gibi daha basit yaklaşımları tercih edin, örneğin Word 97 formatı;). Fikir, bir ayrıştırıcıyı kendiniz bir araya getirmenin yeterince basit olmasıdır ve düşük düzeyli format ayrıştırıcısı uygulamalarınızda tekrar kullanılabilir.

  2. İdeal uygulamalarda, yerleşik satıcı ve teknoloji nötr arayüzleri ve yaptıklarının kesin bir açıklaması olmalıdır . Hiçbir şeyi bozmadan uygulamayı değiştirebileceğiniz veya atabileceğiniz şeyler tasarlamalısınız. Ayrıca, prosedürleri arama veya veri işleme yönteminiz platformlar arasında çalışıyorsa yeni bir platforma geçmek kolaydır. Yani, arayüzler doğru olması gereken en önemli şeydir. Arayüzü uygulama yöntemi ne kadar basit, hızlı ve açıksa o kadar iyidir.

  3. Yığın tamamen açık kaynak olmalı ve üzerinde değişiklik yapmamalıdır . GPL, LGPL, BSD, MIT vb. Lisanslar bu açıdan gayet iyi. Fikir şu ki, topluluk ölmeye başlarsa, yığının yeni [donanım / OS / protokol / vb.] 'Ye taşınması gerekebilir. Bunu yapmak için de koda ihtiyacınız var.

  4. Yığının tasarımı son derece modüler olmalı ve her bir parça bir kişi tarafından anlaşılabilir olmalıdır. Bu, yeni bir grubun onu almasını ve bakımını yapmasını kolaylaştırır. Çalışma zamanının en düşük seviyelerine bile sahip olmak, kütüphaneler ve derleyicinin güzel bir şekilde dışlanması, taşınması gerekiyorsa büyük bir getiriye sahip olabilir. Genellikle, sadece bir bölüm taşınabilir ve tüm eski kodunuz çalışır.

  5. Uygulamanız, bu alandaki yeniden çalışmayı en aza indirmek için platform ayrıntılarını etkileyen modüler bir şekilde yapılmalıdır. Mümkün olduğunda işlevleri giriş / işleme / çıkış bloklarına yapılandırmaya yardımcı olur. Bu, bir limandan nelerin etkileneceğinin analizine yardımcı olabilir (ve genel olarak a la 'Temiz Oda metodolojisi). En düşük riskli yaklaşım platformu akıllıca, evrensel olarak desteklenen en düşük ortak payda özelliklerini, bunları kullanmanıza izin veren ve bağlantı noktasını daha da azaltan bir arayüzle kullanmaktır. (Bir şey kaybedeceğini söyledim ...)

  6. Dinamik yazım, tür çıkarımı veya diğer esnek yazım yaklaşımları yardımcı olur. Yeni bir platforma giden bağlantı noktası, temel türlerin tanımlarını değiştirebilir. Dahili olarak güçlü yazma yapan diller, bu şeylerle daha az endişe duyduğunuz anlamına gelir.

  7. Eşzamanlılık modelini basit tutun. Olay odaklı, net arayüzlerden geçen mesaj, temelde her şeye taşınabilir. Ayrıca coroutines var. Sadece hem hatalara hem de taşınabilirlik sorunlarına eğilimli rotalardan kaçınmak istersiniz.

  8. Mozilla ve Apache'nin taşınabilir çalışma zamanlarına bakın. Belirli arayüz ve uygulama seçenekleriyle platforma özgü birçok sorunu etkiliyorlar. Pek çok soruna iyi çözümler sunmanın yanı sıra, endişelenmeniz gerekenler konusunda sizi ipucu edebilirler.

Mükemmel örnek: Tcl. Biliyorum, birçok insan ondan nefret ediyor ve nadiren kendim kullanıyorum. Yine de, Tcl, anlamak, uygulamak (12 ana kural) ve kod girmek için son derece kolay bir dildir. Küçük, yeterince hızlı, Web sunucularıyla entegre olur, yerel uygulamalara gömülür, tonlarca şeye taşınmıştır, belirli güvenlik özellikleri vardır , ve 80'lerden beri düzenli olarak güncellendi. Siz veya ben, temel dil için hiçbir zaman tüm TCL çalışma zamanını uygulayabiliriz. Eğer biz noktasına standart kütüphanesi vardı, bu .NET veya Java taşıma daha kolay olurdu. Ve bunun için yazılmış oldukça kullanışlı bir kod var. Ve web teknolojisinde Java uygulamalarının da amaçladığı gibi "mobil ajan" çılgınlığı kadar kullanılmıştır. Örneğin, OpenACS web çerçevesi 1998'den daha eski olan sunucuya geri döner.

Diğer örnekler: TEMEL, COBOL ve LISP (Şema veya CL). Bu diller 50'li veya 60'lı yıllara kadar uzanır. Anlama, uygulama ve mekanik çeviriyi kolaylaştıracak kadar basittirler. Ancak, onlarla yararlı şeyler oluşturabilirsiniz. COBOL halen dünyadaki işlemlerin çoğuna güç veriyor, birkaç kez güncellendi ve .NET üzerinde bile çalışıyor. Eski QBasic / QuickBASIC uygulamaları günümüzde hala modern platformlarda açık / ücretsiz araçlarla ve GAMBAS veya RealBASIC gibi daha iyi araçların taşıma olanaklarıyla birlikte çalışıyor. LISP kodlayıcıları doğal olarak sistemlerini modüler ve işlevsel hale getirerek taşımayı kolaylaştırır. Onlarca yıldır açık ve ticari olarak sürekli bir uygulama akışı olmuştur.

Yani, arayüzler, açıklık, basitlik, modülerlik ve platformdan bağımsız mimari / tasarım / kodlama. BU size ihtiyacınız olan gelecekteki provayı sağlayacaktır. Zaten çoğu zaman.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.