Yazılım mühendislerinin artık düşük seviye işleri bilmeleri gerekiyor mu? [kapalı]

C #, Java, vb. Gibi yüksek seviyeli programlama dilleri geliştiğinden, birçok kişi, bilgisayar donanımına erişmenizi ve kontrol etmenizi sağlayan assembly dili ve C / C ++ gibi dillerin alternatifi olacağını iddia ediyor, çünkü programcılar odaklanmalıdır. program oluşturma ve problem çözme, bilgisayarla çalışmasını sağlamak için zaman harcamamak. Donanım gelişmeye devam ettikçe, C / C ++ ve Java arasındaki performans farkı önemli olmayacak ve büyük oyunlar Java gibi bir dilde programlanabilir.

İnternette bu konuya baktıktan sonra kısaca özetlediğim genel fikir bu. Yakın gelecekte gerçek olacağını düşünüyor musunuz? Bu, düşük seviye şeyler hakkında öğrendiğimiz her şeyin artık yazılım endüstrisi için pratik olmadığı anlamına mı geliyor? Bu, montaj dili ve C / C ++, yalnızca elektrikli bileşenleri için programlaması gerekenler olacağından, yalnızca elektrik mühendisleri için geçerli olacak mı?

---

Ne kadar öğrenme yeterli? Çok düşük seviyeli maddeleri öğrenirsek, nihayetinde elektrik mühendisliğinde daha yönlendirici oluruz veya çok fazla matematik öğrenirsek, programcı değil matematikçi olmayı öğrenebiliriz. Sadece öğrendiğim Math öğelerini (bu kitapla aynı materyali kapsayan bir Matematik kursu aldım) (farklı ders kitabı kullandılar): Ayrık Matematik ve uygulaması) gerçekten programlama becerilerimiz kadar faydalı olup olmadığını bilmek istiyorum. Birçok matematik alıştırması yapmak için saatlerce zaman harcayabilir ve eğer ciddiyseniz, programlama okumak için daha az zamanınız olacaktır. Gamedev forumumuzda, Matematik ve Fizik bile programlama bölümleriyle karşılaştırmak için yalnızca bir bölüme sahip.

Şu anda "Bilgisayar Programcılığı Sanatı" bölümünü okumaya başladım. Matematik sadece kitabın yaklaşık çeyreğinde ele alınmaktadır, ancak alıştırma bizim için matematikçi olmayanlar için zordur. Böyle bir "ilköğretim" matematiği bile, kariyerimizde o kadar kullandık mı? Bazıları muhtemelen bana TACOP kitabını okumamı söylerdi, kitap tamamen programlamadan ibaret olsa da (kitap benzer şeyleri açıklamak için biraz daha akademik bir karşılaştırma yapsa bile) zaman harcamalı ve muhtemelen daha pratik başka bir şey için zaman harcamalıdır. Ama bence yazar üretmek için büyük bir zaman ve çaba harcadı. 5 kitap setinin tamamını bile yazabilir, oysa biz - izleyiciler - sadece okuma görevimiz vardır. Neden olmasın?

İlginç soru. Şu anda C # ile çalışan (performans kritik işler için biraz yönetilmeyen C ++ ile) çalışan ve eskiden genellikle performans nedenleriyle, zaman zaman montaj kodunu eklemek zorunda kaldım.

Bir soruya cevap hazırlamada birkaç nokta:

• Karşılaştırmalarınız için, C # ile Java arasındaki diğer dil grubundan (C / C ++) bahsettiğiniz diller arasındaki temel ayrımın, eskiden çöp toplama sağlamak için yönetilen bir çalışma zamanı kullanması olduğunu düşünüyorum. Başka farklılıklar da var (örneğin ikili taşınabilirlik, çerçeve büyüklüğü ve taşınabilirlik), ancak performans farklılıklarını karşılaştırırken baktığımızda, bu bir (?) Ana katkısıdır.

• Montaj, C ve C ++ eşit derecede "düşük seviye" den uzaktır. Ben donanım / yazılım / sürücü geliştiricileri ile Montaj ve C dillerini ilişkilendirirken haklısın düşünüyorum, ama C ++ genellikle daha yüksek kademedeki kullanılır ve ağır hala kullanımda olan TIOBE göre açıkça C rağmen # / Java dışarı duking edilir - indeks.

• C ++ katmanında Objective-C'yi eklerdim, çünkü C ++ 'a C # / Java'dan daha çok benzer. Son olarak, shared_ptr <> ve diğer otomatik kaynak yönetimi özelliklerinin eklenmesiyle, bu dillerin çöp toplamaya yakın bir şeyi desteklediğini unutmayın.

Tamam - asıl sorunuza: Yazılım mühendislerinin artık düşük seviye işleri bilmeleri gerekiyor mu?

Cevabım: Evet

Nedenleri:

• C # / Java kullanırken bile, açık kaynak yönetimi gerektiren çerçeve varlıklarına ve / veya önemsiz olmayan uygulamalarda "sabitlenmiş" bellek grafikleri sorunlarına rastlarsınız. Bu sistemlerin etkili bir şekilde önlemek ve hata ayıklamak için bu sistemlerin nasıl çalıştığını anlamanız gerekir.
• Mobil platformlar daha sınırlı kaynaklara sahiptir ve bazılarında Java ve .NET'in sınırlı sürümleri için destek olmasına rağmen, iOS ve Objective-C'nin şu anki baskınlığı, bunun için uzun süre önce yenilenen bir canlı önermektedir.
• Performans: Bir performans duvarına çarptığınız zaman, etrafta dolaşmak için yerel olarak derlenmiş bir kod yığınına girmeniz gerekecektir.
• Eski Destek: yönetilen kodda (henüz) açıklanmayan bir özelliğe erişmek için birlikte çalışmanız gerektiğinde, aynı şeyi yapmanız gerekir.

Güzel soru - ama yönetilmeyen dillerin yakın vadede gittiğini görmüyorum.

• Meşru olacağını kimse değil hakkında bilgi edinmek ve değil çok verimli ve değerli geliştirici alt düzey işlevselliği anlamak ve hala olmak, zaten böyledir.
• Hiç kimsenin düşük seviyeli işlevselliği öğrenmesi veya anlaması gerekmeyecek, her zaman zaman kaybı olacak, asla böyle olmayacak.

Herhangi bir mühendislik disiplinde olduğu gibi, son ürün için hepsi önemli, uzmanlık gerektiren ve değerli olan birçok adım vardır. Özellikle yazılım mühendisliğinde birçok soyutlama katmanına sahibiz . Hepsine ihtiyaç vardır ve hiç kimse hepsinde uzman olamaz.

Olduğu söyleniyor, Assemby / C geliştiricilerinden daha fazla C # / Java / Ruby geliştiricisine ihtiyacımız var. Bizim için "üst seviye" geliştiriciler için, "başlık altında" ne olduğu hakkında daha fazla bilgi edinmek faydalıdır ve bizi daha iyi geliştiriciler yapacaktır. Ama bir sürü başka şey var . Bir .NET geliştiricisi olarak, exmaple için, Ara Dilimizi (çok daha az C ++ / C / Assmebly) çalışmamın, çoğu zaman arka koltukta oturması gerektiğini , beni daha üretken kılacak, öğrenebileceğim çok şey var .

Bugün düşük seviyeli şeyleri bilmeden programcı olarak geçimini sağlayabilirsiniz. Bence sadece seni tanımak için daha iyi bir programcı yapıyor.

Bununla birlikte, düşük seviyeli malzeme ile yüksek düzeyde bir yetkinlik sağlamak, gittikçe daha az önem kazanıyor. Demek istediğim, 20 yıl içinde mecliste hiçbir şey yapmadım ve muhtemelen tekrar üretken olmadan önce ciddi bir tazeleme yapılması gerekecekti, ancak bu seviyedeki işlerin nasıl yürüdüğü hakkındaki genel kavramlar hala bilincimin bir parçası ve zaman zaman yüksek seviyeli dillerde çalışırken bile yararlı olur.

Öyle sanmıyorum, çekirdek geliştiricilerin her zaman düşük seviyeli şeylere ihtiyacı olacak. Ayrıca, her şeyin nasıl çalıştığını anlamaktan zarar gelmez, yazdığınız kodun aslında ne yaptığını temel olarak anlarsanız, daha iyi kod yazmayı öğreneceksiniz. Bence düşük seviyeli şeyleri kaldırmak korkunç bir fikir, çünkü bu soyut düşünme zaman zaman faydalıdır, ancak sorunun en iyi şekilde çözülmesini istiyorsanız bir engel olabilir. Örneğin, dizeleri birleştirdiğinizde gerçekte yeni dizeler yarattığınızı anlamak önemlidir, ancak dizelerin nasıl uygulandığını anlamadıysanız, sadece bir araya getirebilir ve 5 dakika bekledikten sonra programınızın çalışması beklenir. Bu gibi şeyler hakkında mükemmel bir makale: http://www.joelonsoftware.com/articles/fog0000000319.html

Bu, yazılım mühendisinin gerçekte ne üzerinde çalıştığına bağlıdır. Şimdiye kadar düşük seviyeli hiçbir şeye dokunmadan verimli, mutlu ve karlı bir kariyer yapmak mümkün, ama hepsi programlama işi değil. İşletim sistemleri ve derleyiciler olması için işletim sistemleri ve derleyiciler üzerinde çalışan mühendisler olmalı ve C, C ++ ve makinelerinin montaj dilini bilmeleri gerekir.

Performans da önemli olabilir. Şu andaki dizüstü bilgisayarım ilk ev bilgisayarımdan milyonlarca kat daha güçlü ve çalışan yazılımlar hala zaman alabilir. Video oyunlarında hala gecikebilirim. Tabii ki, video oyunları daha iyi görünüyor, çünkü ekrandaki bir milyondan fazla pikselin her birine milyonlarca renk verilebilir (bin siyah beyaz karakter konumunun aksine, karakterlerin bir kısmı grafikler için kullanılır) ). Yakın gelecekte bilgisayar gücünde bin kat daha bir artış elde edeceğimizden şüpheliyim ve eğer yaparsak daha da karmaşık bir yazılım tarafından kullanılmasını bekliyorum.

İş yazılımlarının çoğu, genellikle C olmayan, üretilebilecek en hızlı şekilde ve kapıdan çıkarılmaya devam edilmekle birlikte, C ve C ++ uzmanları için çok fazla yer olmaya devam edecektir.

"Donanım gelişmeye devam ettiğinde, C / C ++ ve Java arasındaki performans önemli olmayacak ve büyük oyun Java gibi bir dilde programlanabilecektir."

Bu ifadenin yakın zamanda doğru olacağına inanmıyorum. Yönetilen kodda her zaman sahne arkasında yapılan kontroller nedeniyle bir isabet vardır. Ayrıca donanım daha iyi, donanım daha iyi hale geldiğinden, üzerinde çalışması beklenen uygulamaları da yapın. Yerel kodla yazılmış bir sistemin yönetilen kodla ilgili bir arayüzü olması gerekir. İkisi arasında geçiş yaparken gerçekleşen bir performans vuruşu var.

Ancak, yalnızca genel olarak küçük bir uygulama yüzdesi gerçekten bu optimize edilmiş koda ihtiyaç duyar. İş uygulamalarının çoğu, yönetilen herhangi bir kod, .net, java, vb. İle gayet iyi. İhtiyacı olan uygulamaların en kısa zamanda geçiş yapması gerektiği anlamına gelmez. Ancak elle yazılmış montaj, C / C ++ derleyicilerinin optimizasyonu çok iyi olduğu için şimdi daha az kullanılmaktadır. Son zamanlarda tamamen mecliste yazılmış bir işletim sistemi vardı, bu yüzden hala bazıları buna sahip. Güvenlik alanında da oldukça önemlidir.

Gerçekten iyi bir geliştirici olmak için düşük seviyelerde neler olup bittiğini anlamak gerekir derdim. Özellikle yerel kod girerken bazı zorlu sorunların giderilmesine yardımcı olur.

Bazı düşük seviyeli şeyleri bilmek, örneğin gömülü programlama gibi, çoğu C ile yapılan hata ayıklama için çok yararlı olduğunu düşünüyorum, ancak bu belirli Mikro kontrolör için hata ayıklama bilmek mecburen son derece yararlı olduğu zaman.

Bilgisayarlar ilk icat edildiğinde sadece birkaç kişi onları nasıl kullanacağını biliyordu. Şimdi, zengin bir ülkedeki herhangi bir evde, ortalama bir kişi tarafından kullanılabilen 1 veya daha fazla bilgisayar vardır. Pek çok sıradan insan günlük olarak bilgisayarlarda çalışan işlere sahiptir. Ortalama bir insan bilgisayar kullanma yeteneğine sahiptir, ancak yine de programcılara ihtiyacımız var.

Benzer şekilde, ortalama bir programcının assembly dilinde bilmesi veya düzenli olarak programlanması gerekmez. Bu, pazarlanabilir yeteneklerin bir koşulu olduğu kadar, teknoloji dünyasına ne kadar ulaştığımıza da selam veriyor. İşletmelerin işleri otomatikleştirmek için bilgisayarlara ihtiyacı var. Bu nedenle, .NET / Java'da programlayabilen programcılar büyük talep görmektedir.

Otomatikleştirilebilecek görevler otomatikleştirilecektir. Tüm görevler otomatikleştirilemez. Tüm otomasyon mükemmel değildir. Peki, montaj önemli mi? Tabii ki. Bir "programcı" olması gerekli midir? Tabii ki değil.

Hmmm Aslında düşük seviyeli şeyler öğrenmekten zevk alıyorum.

Belki de en doğru benzetme değil, ama bana göre bir arabanın içindeki işlemleri öğrenmek gibi. Tüm parçaların birbirine karşı nasıl çalıştığını bilemeyebilirim, ancak bir motor, bir krank mili, silindirler, diferansiyeller, vinçler, frenler, yağ, yanma, soğutma ve sonra sürtünme, gerilme, ısı, kuvvetler olduğunu bilmek eğlenceli. bilim - termodinamik, fizik, akışkanlar mekaniği ...

Belki de pek kullanışlı değil (hepsini bilerek bir arabayı tamir edemem), kesinlikle profesyonelce pratik değil, ama eğlenceli. L'art dökün l'art: la connaissance la dökün connaissance.

Bence yararlı bir kural - daha hızlı olması, almanız gereken daha düşük seviye olması.

Bu yüzden grafik yoğun birinci şahıs nişancı veya algoritmik FX işlem sisteminiz, hız oldukça önemli olduğu için hala oldukça düşük seviyelerde (C ++ vb.). Ama zamanında bir satış raporu yayan web uygulaması? Kahretsin, Sinclair BASIC’e yazabilirsin ve yine de kabul edilebilir olurdu.

Tüm yazılım mühendisliği işleri aynı değildir . İşletim sistemleri, derleyiciler, çerçeveler, aygıt sürücüleri, gömülü sistemler ve yüksek performanslı bilimsel bilgi işlem alanlarında çalışan kişilerin 'düşük seviyeli şeyleri' bilmeleri gerekiyor. Access CRUD formları yazanlar veya Anne ve Pop mağazaları için PHP alışveriş sepetlerini yazanlar, belki de çok fazla değil. Ne tür bir yazılım mühendisliği yapmak istiyorsunuz ve bunu ömrünüz boyunca yapmak mı istiyorsunuz?

Kanımca, genellikle çalıştığınızın altındaki en az bir soyutlama seviyesini öğrenmeniz gerektiğidir. C / C ++ 'da çalışıyorsanız, o zaman bazı makine mimarisi ve montajı almalısınız. PHP'de çalışıyorsanız HTTP'yi ve biraz C / C ++ veya Perl'i anlamalısınız. Access sizin ekmeğiniz ve tereyağınızsa, RDB teorisini biraz daha iyi bilirsiniz ve belki biraz COM veya .Net hakkında. Kariyerinizde bir süre sonra daha düşük bir soyutlama seviyesindeki bir problemle izlerinizde ölü durursunuz ve o alanda uzman biriyle en azından biraz iletişime geçmeniz gerekir. Bu şeyler olmadan 'geçebilir misin?' Elbette, ancak rekabetçi bir iş piyasasında sadece “geçmeyi” planlamak tehlikelidir.

Kendimi C #. NET'te yoğun olarak çalışıyorum ve her zaman C, C ++ 'dan uzaklaştım. Son zamanlarda iş aramaya başladı ve ne kadar işin mevcut olduğunu ve C, C ++ için deneyim gerektirdiğini görünce şaşırdı. Ben başlangıçta C, C ++ modası geçmiş olmasına rağmen mevcut işlere bakarken durum böyle gözükmüyor.

Listelenen yönetilen dillerin hepsinde C / C ++ ile yazılmış tercümanlar veya sanal makineler bulunur. Bu ikisi dışında, çoğu yönetilen veya yorumlanan dil bile mevcut olmazdı. Onların değerini hafife aldığını söyleyebilirim.

Gerçekten "pratik" bir bilgi kavramından nefret ediyorum . Öğrendiğin her şey eşit derecede pratiktir. Donanıma yakın bir soyutlama seviyesinde çalışmayacağınız önemli değildir, sadece o alandaki kavramları bilmek, başka bir soyutlama düzeyinde yeni bilgi oluşturmak için her zaman yararlıdır. Ne kadar çok ilgili kavram bilirseniz o kadar iyidir.

Normalde yaptıklarım için C # çok düşük seviyeli bir dil ve bunu donanıma çok yakın bir şey olarak görüyorum. Ancak yine de dijital elektronik, CPU tasarımı vb. İlkel, paslı bilgimin bile, yaptığım her şey için çok faydalı olduğuna inanıyorum.

Hayır, çoğunluğa gerek yok. Düşük seviye teknikleri uygulamak, bir geliştiriciye çevrimi bir bütün olarak neyin etkileyebileceği hakkında daha iyi bilgi vermesine rağmen, günümüzde geliştirici, daha sonra geliştirilecek, ancak güvenilmeyecek düşük seviye malzeme bilgisine ihtiyaç duyan yeni teknolojileri araştırmak için o zamandan faydalanabilir. üzerinde.

Bana göre, "Mühendis" kelimesini kullandığınızda, her şeyi en baştan tasarlayan ve inşa eden kadın / erkek olduğunu kastediyorsunuz. Bir Yazılım Mühendisinin asıl problemi bir problemi çözmektir, peki hangi problem? Bu büyük bir soru.

Geliştirici bir Mühendis'den birçok yönden farklıdır. "Geliştirici", genellikle varolan platformlarda bir şeyler inşa eden bir kişidir. Mevcut platformları geliştirir veya kesinlikle üst sistem bileşenini kullanarak eskilerinden miras kalan yeni bir platform inşa eder.

Bir Geliştirici genellikle iş perspektifinden düşünüyor, bir Bilim adamı değil. :) Geliştirici, sistemin kullanıcısına daha yakın, bir şeyi kullanıcı bakış açısıyla düşünüyor ve böylece teknolojiyi kullanarak kullanıcı sorunlarını çözüyor.

Bir mühendis akıllı olanı. O bir bilim adamı, çok gerçek bir sorunu çözüyor. Bilgisayarın kendisinde bir özellik olarak bulunan sorunların çoğu ... Biz bu soruna asla yaklaşamıyoruz, kapsüllenmiş. Mevcut sistem üzerinde çok araştırma yaptıktan sonra çalışmalarını geride bırakan ve sorunu çözmek için yeni bir şey ortaya çıkaran mühendisler, eğer çözüm talep ederse, sistemlerinde yeni bir dil gerekiyorsa, mevcut sistemi sağlayamayacağı için yeni bir dil icat ederler. bu sorunu çözmek .. Mühendisler, Geliştiricilerin sistemlerini kurdukları bir sistem kurmaya başladılar.

Gerçekten de, bir Yazılım Mühendisi öğrenmek ve düşük seviyeli şeylerle iyi usta olmak gerekir ... :)

Geliştirici ise, tamamen ilgisine bağlı. :)