Yazılım mühendisliğinin diğer mühendislik alanlarından daha uzman olduğunu nasıl açıklarsınız? [kapalı]

Herhangi bir yazılım mühendisinin herhangi bir yazılım teknolojisinde gelişebileceği konusunda ısrarcı olan biriyle çalışıyorum ve belirli bir teknolojideki deneyim, iyi yazılım oluşturmak için önemli değil. Onun benzetmesi, söz konusu ürünü üreten bir montaj hattının nasıl oluşturulacağını bilmek için inşa edilen ürün hakkında bilgi sahibi olmanız gerekmediğiydi.

Bir bakıma, "iyiyseniz, her şeyde iyisinizdir" gibi bir gözle görülmek iltifattır, ancak bir şekilde "Codemonkey, go sling code" da olduğu gibi mesleği de önemsizleştirir. Belirli yazılım çerçevelerinde deneyim olmadan, hızlı bir şekilde sorun yaşayabilirsiniz ve bu önemlidir.

Bunu açıklamaya çalıştım, ama satın almadı. Bir şeydeki deneyimimin, her şeye dönüşmediğini açıklamaya yardımcı olacak farklı görüşler veya düşünceler?

ancak bir şekilde "Codemonkey, sling code" da olduğu gibi mesleği de önemsizleştiriyor.

Ben bunun tam tersini savunuyorum. İyi bir yazılım mühendisi, teknolojiden bağımsız kaliteli yazılımları kavramsallaştırma, tasarlama ve tasarlama yeteneğine sahip olacaktır. Bu spektrumun diğer ucu, yön veya teknik özellikler verme ve yazılımı uygulamak için aracı kullanmada iyi olan .NET veya Java veya yalnızca PHP "kodek anahtarı" dır .

Bir yazılım mühendisinin tüm araçların ustası olması gerekmez, ancak çoğunluğunun ne olduğu, masaya ne getirdikleri ve verilen proje için neyin en uygun olacağı konusunda oldukça iyi bir üst düzey anlayışa sahip olması gerekir. . Bir kod maymun sadece belirli bir araç olarak ilan uzmanlık ustası olmasını beklenir.

Mekanik işini nasıl yapacağını bilmeyen bir Ford mühendisine güvenmem.

Yine de, yazılım mühendisliği, çoğu durumda aynı anda Mühendis, İnşaatçı ve Mekanik olmamız beklenen bu alanlardan biridir.

Birlikte çalıştığınız kişiyle bir ölçüde hemfikirim. İyi bir yazılım mühendisi tasarım ve yazılım üretiminin genel prensipleri ile ilgilenir. Gerçek diller ve çerçeveler ayrıntılardır.

Bu, yeni dilleri ve çerçeveleri seçebilme kolaylığını önemsizleştirmek değil. Her zaman onlarla ilişkili bir öğrenme eğrisi vardır, ancak mesele, iyi bir yazılım mühendisine dikey bir duvar değil, bir eğridir.

İyi bir yazılım mühendisi, birçok farklı araç ve teknolojide geniş bir deneyime sahiptir. Yapmazsa, iş için en iyi aracı nasıl seçebilir? Eski klişeyi dışarı atmak için, çekiç kullanmayı bilen bir adama, her sorun çiviye benziyor. Bir tornavida ile uzman olmasanız bile, bunları anlamak için para ödüyor, böylece bir vidayı sadece komik görünümlü bir çivi olarak tanımlayabilirsiniz.

TLDR versiyonu: Diğer mühendislik disiplinleri kullandıkları malzemeler hakkında bilgiye ihtiyaç duyarlar (örneğin mimarların tasarımlarında kullandıkları malzemelerin ne kadar yük taşıyabileceklerini bilmesi gerekir ). Yazılım mühendisliği için kullandığımız diller ve çerçevelerin belirli sınırları vardır ve bunlara karşı etkili bir şekilde tasarım ve geliştirme yapmak için onlara aşina olmamız gerekir.

Yaptığımız işin iki ayrı aşaması var. Birincisi kavramsal tasarım. Bu, yüksek seviyeli ve düşük seviyeli sistem tasarımıdır (örn. UML kullanarak). Yüksek seviyeli tasarımlar teorik olarak uygulama agnostik olabilir (bazen Yüksek seviyeli bir tasarımın veritabanı platformu, raf ara katman yazılımı vb. Gibi özellikleri dikkate alması gerekir). Düşük seviyeli tasarımlar biraz daha zor. Altyapı ayrıntılarını bunlara koymadan iş mantığının özelliklerini tasarlayabilirsiniz ve yine bunlar teorik olarak platform agnostik olabilir.

İkinci aşama gerçek programlamadır. Bazıları programlamayı inşaat olarak görürken, diğerleri (ben dahil) kodlamanın hala bir tasarım disiplini olduğunu iddia ederken ( PPP'de Bob Martin, yazarın bu etki için çok iyi bir argüman öne sürdüğü bir makaleye atıfta bulunur, buna sahip değilim) şimdi, ama bu cevabı o makalenin bağlantısıyla güncelleyeceğim). Gerçek yapı, derlemeye bastığınızda gerçekleşir ve aslında serbesttir.

Bir mimarın kullandığı yapı malzemelerinin gerilme ve basınç dayanımı gibi şeyleri hesaba katması gerektiği gibi, bir yazılım mühendisi de kod yazarken geliştirdikleri platformun yeteneklerini bilmek zorundadır. Platform seçimlerini de dikkate almazsa, düşük seviyeli bir sistem tasarımının çok etkili olmadığını iddia ediyorum.

Yazılım Mühendisliği lisans programından mezun olan biri olarak iş arkadaşınızın kısmen doğru olduğunu söyleyebilirim. İyi bir yazılım mühendisi, bir sistem oluşturmak için matematik, istatistik, bilgisayar bilimi ve etki alanı deneyimini uygulamaya odaklanır. Bir yazılım mühendisinin kullandığı yöntemler tipik olarak teknoloji ve dil bilincidir - araçlar temel prensipler kadar önemli değildir.

Bununla birlikte, iş arkadaşınızın benzetmesi hatalı. Alan problemlerini anlamak, herhangi bir mühendislik disiplini için önemlidir. Çözmeye çalıştığınız sorunu ve tatmin etmeye çalıştığınız insanları tam olarak anlamadıysanız, sorunlarına mümkün olan en iyi çözümü oluşturmak son derece zorlaşır.

Sonuçta, yazılım mühendisliği (ve herhangi bir mühendislik disiplini) bir sorunu çözmek için bir dizi kavram uygulamakla ilgilidir. Aynı araçları sık sık kullanıyorsanız, bu araçlarla daha yetkin hale gelirsiniz. Bu araçların çözebileceği sorunları, bu araçları kullanarak riskleri veya tuzakları tanımlamanız ve daha sonra bir çözüm oluşturmak için bu araçları kullanmanız daha kolay olacaktır.

Onun benzetmesi, söz konusu ürünü üreten bir montaj hattının nasıl oluşturulacağını bilmek için inşa edilen ürün hakkında bilgi sahibi olmanız gerekmediğiydi.

Bu neredeyse kesinlikle yanlış. Uzman üretim mühendisleri, bakımları altındaki ürünler hakkında çok şey anlamalıdır.

Her durumda, makine mühendisliği dersleri mezunları ile daha iyi bir benzetme vardır: herkes aynı skeçlerle (hem mekanik hem de yazılımda) başlasa bile, hiç kimse "makine mühendisi" olarak kalmaz, bunun yerine inşa ettikleri şeyler. Benzer şekilde, yazılım geliştirmenin de çok farklı alt alanları vardır.

Montaj hattı benzetmesine geri dönmek için her montaj hattı her ürün için farklıdır ve farklı yazılım geliştirme türleri farklı metodolojiler gerektirir - güvenlik yazılımınızı bir oyunla aynı şekilde oluşturmazsınız.

Farklı uzmanlıklarla ilgili bir öğrenme eğrisi vardır. Gömülü / Gerçek zamanlı programlama, Web-Uygulama programlama, Sistem / OS programlama, Kalın istemci programlama, Mobil geliştirme vb. Arasındaki farklardan bahsediyorum.

Bir tür programlama konusunda uzman olan biri, farklı gereksinimler nedeniyle hemen diğerine geçemeyebilir. Elbette, bir yazılım mühendisi bunun için temel özelliklere sahiptir, ancak bir konuda uzmanlaşmak zaman alır.

Bir uyarı eklesem de meslektaşınızın önerdiği önermeye katılıyorum.

İyi bir yazılım mühendisi, yeni teknolojide biraz öğrenme yaptıktan sonra herhangi bir teknolojide iyi bir yazılım oluşturabilir.

İlk başta açık olmayan bazı tuhaflıklar olabilir, ancak iyi bir yazılım mühendisi yakında bunları öğrenecek.

Bence gerçekten demek istediğim, bir geliştiricinin 2 yıllık sağlam C # deneyimine sahip olması, daha önce hiç C # yapmayan, Java arka planına sahip daha iyi bir yazılım mühendisi anlamına gelmiyor, C # öğrenemiyordu ve hızlı bir şekilde ilk adamdan daha iyi bir C # geliştiricisi olun.

Başka bir deyişle, C # 'da "zaman yaptı" çünkü bir iş için Java adam, SADECE mutlaka indirim olmamalıdır.

Tipik bir örnek: büyük olasılıkla ile özel bir deneyim olması çok önemlidir hissediyorum yazılım çerçevesi olmasaydı 10 yıl önce, ya da yapsam geçirmiş önemli bir dönüşüm vardır. Mesleğimizin doğası, kişinin kariyerinin tamamı için uzmanlaşmayı imkansız hale getirir. İlgili beceri seviyelerinize bağlı olarak, uzmanlığınız size özel çerçevenizi hiç kullanmayan birine göre 1 ila 6 ay arasında bir avantaj sağlar. Bundan sonra, par.

Bir helikopter şirketi için çalışıyorum ve buradaki havacılık mühendisleri birlikte çalışabilecekleri uçak türleri konusunda uzmanlaştı. Bunların "tipte derecelendirilmiş" olmaları gerekir. Teknik olarak, Robinson R22'den Jumbo Jet'e kadar herhangi bir şey üzerinde çalışabilirler, ancak dönüşüm eğitimi olmadan çalışamazlar.

"Dönüşüm eğitimi" yazılım mühendisleri için daha gayri resmi olması dışında bu yazılım mühendisliği oldukça benzer olduğunu düşünüyorum.

Bir ressamla konuşurken ona heykelcilikle ilgili bir sorunu olmadığını söyler misiniz?

Yeni bir dil veya yeni bir alana özgü ayrıntılar öğrenmek, öncelikle kalem ve mürekkeple uğraşan, nasıl resim yapılacağını öğrenen (veya tam tersi) bir sanatçıya benzer. Diğer cevapların çoğunun konuştuğu şey budur, arkadaşınız nasıl kısmen doğrudur - aynı kavramların çoğu geçerlidir.

Ancak bir ressamın bir 3D nesneyi nasıl şekillendireceğini veya bir roman yazacağını öğretmek (Her iki sanatsal ifade biçimi) tamamen farklı bir yaratıktır. Geldiğiniz bakış açısı budur.

Web tabanlı yazılımlar, masaüstü yazılımlarından tamamen farklı bir düşünme türü gerektirir. Her ikisi de çalışma ortamına karşı oyunlara uygulandığında tamamen farklıdır. Bir işletim sistemi veya entegre sistemler üzerinde çalıştığından da farklı bir şekilde düşünmeyi gerektiririm (ancak onlarla deneyimim yok). Ve şüphesiz farklı bir düşünce tarzı gerektiren başka alanlar da var.

Özet ve örnekler:

"Sanat" heykelleri, romanları, çizgi romanları ve resimleri içerir. Beceri çakışmaları şunları içerir:

• Vücut şekli ve renk teorisi: Heykeller, çizgi romanlar ve resimler
• Metinsel iletişim: Romanlar ve çizgi romanlar

... Ve bunun gibi. Ancak yukarıda belirtildiği gibi, bir çizgi roman sanatçısının ilk romanlarında başarılı olma olasılığı düşüktür. Farklı düşünmeliler.

Benzer şekilde, programlama / yazılım mühendisliğinin farklı alanlarında çakışma vardır, ancak çoğu sadece atlayamayacak kadar farklıdır. Örneğin:

• Algoritmalar: İşletim sistemi / tümleşik sistemler, oyunlar ve hız veya bellek için en iyi duruma getirmeniz gereken diğer yerler. Web geliştirmede nadiren büyük bir anlaşma
• Tasarım: Web geliştirmenin her yerinde, ancak kullanıcı arayüzü olmayan entegre sistemlerde çok önemli değil.
• İstemci / sunucu yazılımı: Bazı bölgelerde (tek oyunculu oyunlar ve diğer bağımsız masaüstü yazılımları, bu günlerde daha nadir olduğunu kabul etmiyorum) zorunlu olmayan "istemciye güvenme" anlayışı.

Tüm yol inşaat işçileri şantiyede her türlü ekipmanı ve makineyi kullanabiliyor mu? Cevap hayır. Bildikleri ve muhtemelen diğerlerine aşina oldukları makine parçaları var. Aynı şey yazılım mühendisleri için de geçerli olmalı, her gün onlarla çalıştığınız için x sayıda dil ve çerçeve var, ancak eğitim almadan başkalarının kesin işlemlerini bilmeleri beklenmemelidir. Jackhammer işçisini alıp ona çimento mikserini kullanma görevini atamak gibi.

Programlama dilleri ve çerçeveleri sadece bir yazılım mühendisleri alet kemerindeki araçlardır. Deneyim nedeniyle diğerlerinden daha iyi bileceğiniz bazı araçlar var. Sonuçta, en iyi araç, temel bilgi işlem kavramlarını ve ilkelerini anlamaktır. Dilleri ve çerçeveleri seçmek sadece hangi vidada hangi tornavidanın kullanılacağını seçmektir.

Bu tür şeyler çalıştığım yerde çok oluyor.

Eşimin amcasının mesleğiyle karşılaştırmayı seviyorum - bir araba tamircisi.

O uzmanlaşmış o arabaların diğer modellerine bilgisini uygulayabilir, Mercedes, ve yaptığı - bazıları oldukça nadir, ancak anlamına gelmez elinden o hemen bunu bir gürültü yapıyor demek onarım yapmak X çünkü.

Birkaç dilde program yapıyorum, ancak bu, sekmeyi her değiştirdiğinizde (bugünün garip çağrısı) MacBook'unuzdaki Safari'nin neden sayfaları yeniden yüklediğini bildiğim anlamına gelmiyor. Nedenini anlamaya çalışacağım ama kafamın üstünü bilemeyeceğim çünkü bilgi işlem alanı BÜYÜK .

Her iki durumda da ilgili alanlarımıza bakarak biraz zaman geçirdikten sonra muhtemelen "ancak arabalarla çalışıyorsunuz" veya "ama bilgisayarlarla çalışıyorsunuz" diye düşündüğümüz cevabı belki on saniyede çözemedik.

İnsanlar yerel doktorlarına böyle şeyler söylüyorlar mı ("Ne tür bir hastalığım var?" Gibi bir baş ağrım var mı?) dedi.