Yazılım mühendisleri ve programcılar arasındaki temel farklar nelerdir? [kapalı]


Yanıtlar:


80

İşe alırken, sistemimizi tasarlamamıza, süreçleri tanımlamamıza, teknik özellikler oluşturmamıza, gelişmiş yeniden düzenlemeyi yapmamıza, vb. Kontrol programından programlama görevlerini tamamlamamıza yardımcı olacak bir kişi arasında bir ayrım arıyoruz. . Eskiden Yazılım Mühendisi ve sonuncusunu da Programcı olarak adlandıracağınıza inanıyorum .


10
Lütfen açıklar mısınız, ikisini de (farklı işler için) veya yalnızca yazılım mühendislerini işe alıyor musunuz?
Jaap

2
Sen olabilir eski bir Yazılım Mühendisi diyoruz ama olmaz. Brendan'ın onayladığı gibi, bu genellikle bir yazılım mimarının işidir.
JᴀʏMᴇᴇ

131

Bir mezhep veya başka bir şeyi uygulamak için yasal bir çerçeve bulunmadığını veya en azından benim bilmediğim ve bunun ülkeden ülkeye değişebileceğini düşündüğümden gerçekten şirkete kalmış (örneğin, terimin kullanımı “mühendis” aslında Fransa'da oldukça düzenli bir şekilde düzenlenmiştir, ancak “kötü niyetli” durumlar için izin verilen çeşitler vardır).

Genel eğilim şöyle devam ediyor:

  • Bir programcı pozisyonu genellikle bir bilgisayar programının kodunu üretmek için işe alınan profesyonellerden biridir . Kod yazmayı bildiğiniz , bir algoritmayı anlayabileceğiniz ve teknik özellikleri takip edebileceğiniz anlamına gelir . Ancak, genellikle sorumluluk açısından orada durur.

  • Bir geliştirici pozisyonu genellikle programcı pozisyonunun bir süper tipi olarak kabul edilir . Aynı sorumluluklarını kapsar artı tasarım ve mimarı bir yazılım bileşeni yeteneği , ve teknik belgeleri yazmak (şartnamelere dahil) bunun için. Sen mümkün - en azından teknik olarak - kurşun diğerleri (böylece, programcılar), şart olmamakla birlikte bir ekip (hav gelir ki ...)

  • Bir mühendis pozisyonu, genellikle belirli bir dereceye sahip , biraz mühendislik bilgisi olan ve bir sistem tasarlama yeteneğine sahip bir geliştirici olduğunuz anlamına gelir (şu şekilde: bir bütün olarak bütün bir bütünlüğü oluşturan yazılım bileşenlerinin / modüllerinin bir kombinasyonu) . Temel olarak, daha geniş bir resim görüyorsunuz, onu tasarlama ve açıklama ve daha küçük modüllere ayırma yeteneğine sahipsiniz .

Ancak, tüm bunlar tartışılabilir ve dediğim gibi , ABD / İngiltere ülkelerinde bildiğim hiçbir yasal zorunluluk yok . Bu söylenirse, Fransa'da kendinize yalnızca bir mühendislik okulundan geliyorsanız ("Komisyon des Titres d'Ingenieurs veya benzeri bir şey tarafından tanınan) kendinize bir" mühendis "diyebilirsiniz. Bir "Mühendislik Derecesi" olduğunu söyleyemezsiniz, ancak mühendislik ve teknolojiler portresine giren bir disiplin okuduysanız "Mühendislik Derecesi" ye sahip olduğunuzu söyleyebilirsiniz.

Bazı ülkelerin benzer bir ayrımı olabilir, ben sadece bilmiyorum.

Yazılım mühendisi unvanına geri dönün… Bir zamanlar öğretmenimden biri sınıfımıza - ve haklı olarak - bugünden itibaren “yazılım mühendisliği” diye bir şey olmadığını söyledi . Çünkü bir şeyi mühendislik yapmak (bir bina, araç, donanım parçası ...), tasarımını ve üretiminin tüm aşamalarını öngörebilmeniz ve ihtiyaç duyacağınız kaynakları ve dolayısıyla ihtiyaç duyacağınız doğrulukla tahmin edebilmeniz anlamına gelir. üretim maliyeti.

Bu, çoğu "gerçek" mühendislik disiplini için geçerlidir. Elbette dalgalanmalar vardır (örneğin, malzemelerin fiyatları zamanla değişecektir), ancak çok sınırlı teorik modeller (tasarım ve planlama için) ve deneysel modeller (eskilerin herhangi birini erişilebilir kısıtlar içinde tutmak için) vardır. Bu, bir projenin bitiş tarihini ve kaynak kullanımını tahmin etmenizi sağlar.

Yazılımdaki en büyük sorun, henüz orada olmamasıdır. Yazılım mühendisliğini hedef almak istiyoruz, ancak henüz orada değiliz. Çünkü çok akışkan ve dinamik bir çevreye, projeler için çok değişken kısıtlamalara ve süreçlerimizde geçmişe baktığımızda hala vade eksikliğine sahibiz. Tabii ki daha iyi olabileceğimizi söyleyebildik (çok zor verilerle tartışılabilir), ancak sadece 60'lardan beri (daha önceki projeler aslında sadece donanımsal bilgisayarlara daha yakındı, bu nedenle gerçek mühendisliğe, ironik olarak daha yakındı) ). Oysa bir asırdan fazla süredir motorlu taşıtlar, birkaç bin yıldır genel olarak taşıtlar üretiyoruz ve daha da fazla bin yıldan beri taşıtlar üretiyoruz (ve aslında dünyanın bazı bölgelerinde oldukça iyi davranıyorduk. '

Biz sistematik doğru tarihleri tahmin etmek başarısız biz sistematik doğru maliyetlerini tahmin etmek başarısız biz sistematik verimli ve deterministik doğasında ve dış riskleri belirlemek ve azaltmak için başarısız . Yapabileceğimiz en iyi şey, yeterince iyi tahminler üretmek ve döngüleri ve ek yükü azaltmak için süreçleri optimize etmek için elimizden gelenin en iyisini yapmaya çalışırken bazı tamponlara uyum sağlamaktır.

Ama bakın, belki de mühendislik budur. İşte bu, birisi bir "yazılım mühendisi" hakkında konuşurken, düşünmeli ve amaçlamalıdır.

Bu nedenle, basit programlama rutinleriyle veya daha gelişmiş uygulamalarla başa çıkabiliyoruz.

Yine de, her şey bir trend meselesidir. Son zamanlarda, takımdaki herkesin bir Kıdemli Yazılım Geliştiricisi olduğu (evet, başkentler, çünkü bizi özel hissettiriyor, öyle değil mi?), Gerçek yaş ayrımı yapmadan (yeterince adil) fikir) ve becerilerin (uh-oh ...) ve sorumlulukların (şimdi tamamen PR vızıltıları için ayrı olmaktan uzak, iyi olamaz) ayrılığı.

Aynı zamanda bazen bir alışkanlık kuvveti ve bir endüstrinin kültürüne ve jargonuna özgüdür.. Gömülü yazılım üretimi için daha fazla pozisyon yazılım mühendisleri için başlıkları kullanır. Çoğunlukla, muhtemelen bu alanda da donanımla her zaman bir dereceye kadar uğraşmak zorunda kalacağınız anlamına geleceğinden, açıkça üretimin ve ürettiğiniz tüm "sistemin" diğer yönleriyle ilgileniyorsunuzdur. Sadece içindeki bitlerin içine değil. Spektrumun diğer tarafında, finansal yazılım üretim pozisyonlarında kullanılan mühendis terimini gerçekten görmüyorsunuz. Bunun nedeni, bu endüstrinin öncüllerinden birinin (mesela gömülü mühendislik, otomobil mühendisliğinde köklerini bulması gibi) mimetik bir evrimi olması ya da sadece bir pozisyona az ya da çok kredi vermek istedikleri için.

Ve siste bulunan herkesi gevşettiğinizden emin olmak için, her ikisini de karıştıran diğer başlıkları ("Yazılım Geliştirme Mühendisi" veya "Testte Yazılım Mühendisi" gibi!) Ve daha sonra diğer alanlarla daha da çılgın köprülere vurgu yapan diğer başlıkları bulacaksınız ( "Yazılım Mimarı" nı ve "yazılım mimarisinin" kelimelerin utanmaz bir hırsızlık olabileceğini düşünün). Ve onların gelmesini sağlayın: Mühendisi bırakın, Geliştirme Müdürü değiştirin, Yapı Mühendisi (ki o da bir ffaaarrrrr'a gider). Ve bazen sadece basitçe "mühendis".

Bu gerçekten bir cevap olmasa da, yardımcı oldu umarım.

Oh, ve bu, yeni şirketinizin sizi ya yeni bir unvanla cezbetmeye çalıştığını ya da unvanları gerçekten önemsemediklerini ya da gerçekten daha yüksek bir pozisyona sahip olacağınız anlamına geliyor. Bilmenin tek yolu mesleğinizin özelliklerini okumak, onlarla konuşmak ve en sonunda kendinize bir şans tanımak. İkinci seçenek ve bununla mutlu olmanı umuyorum (ve potansiyel olarak daha fazla para kazanın). ;)


12
"Pragmatik programcı" kitabı aynı zamanda bu yazılımın mühendislik gibi olmadığını da söylemektedir. Bir ev veya gökdelen planlayabiliyorsanız, yazılım mühendisliği analojisi gibi pek kullanılamaz. Şöyle diyorlar: Yazılım daha çok bahçe işlerine benziyor. Bahçeyi planla, bitkileri dik. Sonra ne büyüyünce bakın, yabani otları temizleyin ve yeni bitkiler dikin.
Şahin,

6
“Bir kez öğretmenim sınıfımıza, bugünden itibaren“ yazılım mühendisliği ”denilen bir şey olmadığını söyledi. Çünkü bir şeyi mühendislik yapmak, tasarımını ve üretiminin tüm aşamalarını öngörebildiğiniz ve doğruluğunu tahmin edebileceğiniz anlamına gelir. ihtiyacınız olacak kaynaklar ". Yazıldığı sırada bu muhtemelen doğru değildi. Mimari gibi, gereksinimleri bilmeden maliyetleri önceden tahmin edemiyoruz (bir gökdelenin maliyeti nedir? Yapmaya başlamadan önce ne kadar yüksek olması gerektiğini size söyleyemem ...). Ancak daha sonra olgun bir yazılım geliştirme grubu verilen maliyetleri tahmin edebiliriz .
MSalters

1
@ MSalters: Elbette, bunu tersine çevirebilirsiniz: arkitet gibi, gereksinimler olmadan maliyetleri tahmin edemiyoruz. Ancak mimariden farklı olarak , iyi tanımlanmış gereksinimler olsa bile (bizimkiler genellikle daha akıcı olsalar da, tahmin etmesi zor, ya da değişmelerine izin verme eğilimimiz var), maliyeti tahmin edemiyoruz. Bunu normal mühendislikte çok doğru bir hassasiyet düzeyinde yapabilirsiniz ve şu anda sıra dışı durumlar için maliyetleri SE’den daha fazla tespit edebiliyoruz. Biz sadece (oldukça kaba) tahminler yapıyoruz. Onları yapmada daha iyiye gidiyoruz, ama hala çok fazla tahmin ediyorlar.
haylem

3
@haylem: Yazılım geliştirmedeki norm budur. Ancak, bir CMM düzey 4/5 şirkette çalıştıysanız, maliyetleri tahmin edebileceklerini fark edecek ve genellikle onlara% 95 güven düzeyleri ekleyebileceksiniz. Yazılım tabanlarını yeterince iyi anlıyorlar ve barikatların nadir olduğu için yeterince iyi gereksinimleri var. Ve bunlarla başa çıkma deneyiminiz olduğunda barikatların maliyeti daha düşük.
MSalters

1
@ pcurry: not Bunun "benim taksonomim" olduğunu iddia etmiyorum. İşe alım yapanlar ve şirket bordroları tarafından oldukça yaygın olarak kabul edilir ve aynı zamanda CS ot BT derslerinde de sıklıkla kabul edilir. Birbirlerine ateş etme eğilimindedirler. Sanırım (sözde) Yazılım Mühendisleri tarafından benimsenen görüşü açıkça (kendi kendini tanımlayan) programcılardan daha fazla listeledik. Kendine ne dediğin önemli değil, daha çok insanların seni ilgilendiren şeyleri düşünür. Ve sadece bu tür şeyleri önemsiyorsanız önemlidir. Dürüst olmak gerekirse, şahsen biri ya da diğeri olmayı umursamıyorum, beni değiştirmiyor.
haylem

81

Yazılım mühendisleri , kendilerine yazılım yazan kişileri "yazılım mühendisleri" olarak adlandıran şirketlerde çalışan kişilerdir.

Programcılar , kendileri için yazılım yazan kişileri "programcılar" olarak tanımlayan şirketlerde çalışan kişilerdir.

De vardır geliştiriciler veya yazılım geliştiricileri . Sırasıyla, "geliştiriciler" veya "yazılım geliştiriciler" için kendilerine yazılım yazan kişileri arayan şirketlerde çalışan kişilerdir.


26
Bu cevabın gerçekten komik olması gerekmediğine dikkat etmeliyim.
Jer

15

Yani "Yazılım Mühendisi", "Programcı" ve ayrıca "Geliştirici", "Kodlayıcı" ve "SOA uzmanını" asla unutamazsınız.

Bunların hepsi özgeçmişlerinde, önceki pozisyonlardaki asıl rolleri (sadece iş unvanı değil) gibi anlamlı bir şey söyleyemeyen insanlar için pazarlama terimleridir.

İş ilanlarında fark, İK kişisine bağlıdır.

Alt satır: Her insanın "kodla çalışan iyi bir çalışanı neyin yarattığını" yapan bir şey vardır ve bazıları bu tür becerileri bu tür başlıklarla ilişkilendirmeyi sever.

Ne yapmak gerekiyor? İş ilanları, gerekli beceriler hakkında açıklayıcı olmalı ve CV'ler, adayın deneyim detaylarını açıklamalıdır.


10

Fark yok. Onlar aynı şey. Ancak şirketler, terimleri kullanarak resmi iş tanımlarına sahip olabilir ve daha sonra bu terim için şirkete özgü bir anlam olabilir.


8

Programlama kodla ilgilidir. Yazılım mühendisliği son ürün ile ilgilidir.


3

Bu gerçekten şirketin pozisyonları nasıl tanımladığına bağlı. Bir yazılım mühendisi olarak daha fazla tasarım kararı fırsatına sahip olabilirsiniz, oysa geliştirici olarak size UML diyagramları verecek ve programı yazacaksınız.

Ancak gerçek bir tanım yoktur, böylece başlığa dayanarak insanlar ne yaptığınızı ya da ne kadar tecrübeli olduğunuzu bilir.

Bir mimar / geliştirici olduğumda, unvanım bilgisayar bilimciydi, ama insanlara bir programcı olduğumu söylerdim, ilk ikisi kolay tanımlanmadığı için, ama çoğu insan bir programcının ne yaptığını bilir.

Bir başlık sizin için önemliyse, mühendis geliştiriciden daha yüksek olduğu için yenisini kabul edin.


3

Tecrübelerim için herhangi bir "resmi farklılık" olduğunu sanmıyorum:

  • Bazı şirketler aynı şeye atıfta bulunmak için yazılım mühendisleri ve yazılım geliştiriciler kullanır. Sadece en sevdikleri terimleri kullanıyorlar.
  • Diğer her iki terim de farklı iç pozisyonlar için kullanılır, ancak roller şirketten şirkete değişir! Bazılarında işlev üzerinde sadece bir fark olabilir (bir yazılım mühendisi şirketin ürünü üzerinde çalışacakken sistemlerin bakımı ve iyileştirilmesi üzerinde çalışacak) veya hiyerarşik (mühendis geliştiricinin üzerinde) veya hatta mühendis gerçekten Q & A'ya bağımlı!

Ayrıca, aynı zamanda değişen moda terimleri vardır ... İlk önce terim "programcı", sonra "yazılım mühendisi" ve şimdi "geliştirici" gibi görünüyor ...

İş tanımını veya şirketteki birine okumak daha iyi olur.


3

Bazı yargı alanlarında "Mühendis", profesyonel bir mühendis olmanın gerekliliğini, yani P Müh. kimlik bilgileri arasında tasdik Ancak, diğer alanlarda birkaç yıl önce Washington eyaletinde çalışan bir "Softwere Tasarım Mühendisi" olduğum gibi bir fark olmayabilir.


2

Yazılım Mühendisleri, örneğin 5 ila 16 yıl gibi bir çok insanın yıllar sürmesi çok büyük sistemler üzerinde çalışma eğilimindedir. Programcılar, sadece kodlamanın bu stereotipini ve başka bir şeyi yapma eğilimindedir. Ancak bu gerçekten çalıştığınız kuruma ve İK'nın yukarıda açıklandığı gibi rolü nasıl pazarladığına bağlıdır. Onlar aslında aynı şeydir. Sadece bir başlığa fazla da bağlanma çünkü eşanlamlı.

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.