Yazılım mühendisliği hakkında yanlış fikrim var mı? [kapalı]

Son işimden (stajyerlerden) oluşan bir sorum var.

Sadece işleri bir şeylere dahil etmek için - 21 yaşındayım ve 2. üniversitemi bitirdim, daha önce sys admin / QA işlerinde yaklaşık 2 yıllık deneyimim oldu ve temelde ne kadar farklı olduğunu gördüm Bilişim sektörleri işletildi. Şimdiki zamanları dört gözle bekleyin ve işte İngiltere'deki önde gelen araştırma kurumlarından birine stajyerlik yapmam.

Yapmam gereken, teknolojiyi karıştıran içsel araçlar oluşturmaktır - çoğunlukla AWS / Java / Bash - resmi elde edersiniz. Her şey yolunda, işimi yapıyorum ama mutlu değilim. Neden bu - çünkü geçici bir konuda çalışmam bekleniyor. Bu, tasarım için zaman harcamadan hızlı bir şekilde şeyler yaratır. Yöneticim açıkça, ortaya çıktıkça sorunlar yüzünden "acele etmenin" beklendiğini söyledi ve esasen biz. Sonuç olarak, işlerin yeniden yapılması ve yeniden yapılması gerektiği ve hala mükemmel olmadıkları ortaya çıktı. Testler söz konusu olduğunda, en az düzeyde tutun, çalışıyor gibi göründüğü sürece sorun değil.

Bu tür bir iş yürütme yöntemine katılmıyorum yanlış mıyım? Sistemi bir bütün olarak düşünmek, daha sonra farklı bileşenlere odaklanmak ve nasıl çalışabileceklerini görmek, gelecekte sorunlu olabilecek farklı "kilit noktalara" sıfıra düşmek istememek yanlış mıdır? Hızlı bir iş değil, iyi bir iş yapmak istemek suç mu? Belirli bir sorun kümesine bağlı olarak en iyisini seçebilmeniz için bir soruna uygulanabilir veri yapılarını araştırmak istemek yanlış mı yoksa yanlış bir tutum mu? Anladığım kadarıyla, "Yazılım Mühendisliği" ndeki "Mühendislik" biti tam olarak bununla ilgiliydi - sorunlu alanınızı araştırın ve bilgili bir çözüm bulduktan sonra gereken şekilde düzeltin mi?

Birleşik Krallık'ta bir Arm'ın ofisinde bir röportaj yaptım ve bana SCRUM odalarını gösterdiler ve projelerini nasıl yönetecekleri konusunda oldukça iyi fikirleri vardı - her birinin ne kadar sürdüğünü belirten bir birikim vardı. sorun çözülebilir - SCRUM için olağan şeyler - "burada" işlerin yürütülmesinden tamamen farklı

Genel olarak yazılım endüstrisi hakkında yanlış bir fikir mi inşa ettim? Bu konudaki girişinizi duymak isterim. Demek istediğim sadece yazılım geliştirmeye "girdim" çünkü basit ve basit şeyler yaratmak istiyorum ama kaliteli şeyler oluşturmak istiyorum. Yazılımımın çeşitli senaryolarda kullanıldığını görmek istiyorum, kurşun geçirmez olduğunu görmek istiyorum - tüm yazılım mühendisleri için itici güç değil mi? Bence herkes sadece sözdizimini öğrenerek programcı / kodlayıcı olabilir, fakat benim için asıl eğlencenin başladığı yer, gerçek dünyada yapılabilecek bir tasarımla gelmeniz gerektiğidir.

Üniversite ödevlerini sadece onlara bakarak ve doğrudan kodlamaya başladım ve% 75'in üzerinde kolayca not alabiliyordum ve "yazılım geliştirme yaşam döngüsü" modülünü hiç anlamadım. Ama şimdi, gerçek dünyada herhangi bir resmi süreç olmadan çalışmanın ve zorunlulukların yarın değişip değişmeyeceğini bilemeyeceğiniz bir durumda olan hayal kırıklığını görmenin ne kadar kötü olduğunu gördüğümde açıkça tanımlanmış ihtiyaç analizi yapmamış mıyım?)

Gerçekten, bazı insanların kirli işlerini yapmak için sadece bir kod maymuna ihtiyaç duydukları bir konuma indiğime inanmayı gerçekten seviyorum ve bu, yazılım dünyasında genel olarak nasıl çalıştığı değil.

Yazılımın yeniden kullanılabilir ve kurşun geçirmez hale getirilmesi, yazılım mühendisliğinin itici gücü değildir . Mühendislik, gerçek dünyadaki problemler içerisinde gerçek dünyadaki problemleri en iyi şekilde çözmekle ilgilidir . Çoğu mühendis bir Ferrari üzerinde çalışmayı tercih ederdi - ancak bir istasyon vagonu kadar mühendisliğe ihtiyaç duyuyor ve bir istasyon vagonunun da iyi performans göstermemesinin nedeni (bazı şekillerde) daha kötü mühendislik nedeniyle değil, daha zor tasarım kısıtlamalarından kaynaklanıyor. .

Bir "hızlı iş" yerine "iyi bir iş" yapmak istediğinizi söylediğinizde, çoğu mühendis bunu yapar, ancak bazen iyi olanı tanımlamanın bir kısmı tamamlamanın ne kadar hızlı olduğudır. Bu yüzden karşıt seçimler olarak "iyi" ve "hızlı" düşünmek doğru değil. Ya da kötü bir iş yaptığınızı ya da sadece "kod maymunu" olduğunuzu düşünmek, mevcut zamanda mümkün olan en iyi işi yapmak için.

Tabii ki, bu işlemin optimal olmaması ve biraz daha fazla ön tasarımla daha iyisini yapması oldukça mümkün. Asit testi , kullanıcılar için çözdüğünden daha fazla sorun yaratan şeyler yapmanın şu anki yolu mu , yoksa bu şekilde çalışmak zorunda olan geliştiricileri mi rahatsız ediyor? Aslında kullanıcılar için sorunlara neden oluyorsa, işinizin bir kısmı bunun böyle olduğunu göstermeye çalışmak ve insanları biraz daha kontrollü bir sürece kazanmaya çalışmaktır.

Aslında, bu beni rahatsız ediyor. Araştırma bilim adamları için araçlar geliştirdiğiniz bir meslektesiniz, doğru. Ancak, bu programları hızlı hale getirmeniz ve en az düzeyde çalışmalarını sağlamanız istenir. Sürpriz sürpriz. Bu sadece araştırmacının gerçek bir programlayıcıya aktarılan para ile programlamaya yönelik tipik yaklaşımıdır.

Buradaki ana kaygı, özellikle testlerin yapılmamasının, araçların önemli bir amacı varsa etik olarak şüpheli olabileceğidir. Yazılımın arızalı olduğundan emin olunmaması nedeniyle, minimum test süresi sınırlandırılmıştır, yani yazılım çalışma koşulundan NO ONE sorumlu tutulmaz ve Atlas silkiyor.

Durup bir anlığına bunu düşünelim. Ne tür araçlar geliştiriyorsunuz? Verileri modelleyen bir yazılım geliştiriyorsanız, burada büyük bir etik ikilem var. Bazı durumlarda, bilimsel araştırmalar birçok insanı büyük ölçüde etkileyen kararlara yol açmaktadır.

Bir an için, insan yapımı iklim değişikliğinin tartışmalı konusunu varsayalım. Diyelim ki bugün kullandıkları sonuca varmak için kullandıkları modelleme yazılımında aynı standartları koydular. Konu, çevreyi ve uluslararası politikayı doğru bir şekilde yönetme yaklaşımımız üzerinde büyük bir etkiye sahiptir.

Modelleme yazılımının öngörülerinde büyük problemler yaşamamasını sağlamak etik değil mi?

Bütün sorun, sera gazlarının yeryüzünü ısıtması değil. Sorun, geri besleme etkilerinin net sonucunun sıcaklıkta hızlanan bir kazanım olup olmadığıdır;

Eğer söz konusu kazanç gerçekleşmiş olsaydı, net bir sonucun kanıtı muhtemelen err aralığında olacaktı.

Bu nedenle, hafif yanlış hesaplamalar, veri depolama ve arka uçta geri alma dahil metodoloji bile, başarısızlığın bir ucunda ciddi bir çevresel sorunu ya da birçok insanı etkileyen uluslararası bir politikayı göz ardı etmesine neden olabilir (işleri yok eder, emekli maaşlarını vb. ) Diğer yandan.

Yani evet, haklısın. Araştırmanın hızının ne olduğu umurumda değil ... Araştırmacılar verileri yönetmek ve hesaplamaları yapmak için yazılım araçlarına güvenmek istiyorlarsa, yazılımın doğru yapılmasını beklemeyi öğrenmeleri gerekir. Aksi halde, bu yazılım teoriklerinde sorumlu tutulmadıkları ve bu sayede etik suistimalle sonuçlanan bir güvenlik açığı haline gelir.

Yazılım mühendisliğinin ne olduğu hakkında yanlış bir fikriniz yok. Ancak, bunun çok önemli bir yönünü kaçırıyorsunuz: bu bir hizmet sektörü. Bazılarımız yıllarca bir ürün üzerinde çalışıp v1'de olmadan önce tasarımdan sonra birçok tekrardan geçiyoruz. Diğerleri 3 saat içinde bir şeyler üretmek zorunda. Kime hizmet verdiğinize ve amacın ne olduğuna bağlı.

Yapması gerekeni yapan 3 saat içinde (veya günlerde) bir uygulama üretebilirseniz, neden ön plana çıkmak için daha fazla zaman harcıyorsunuz? Sadece para harcıyorsun. Para israfı genel bir Good Idea ™ değildir.

Diğerlerinin de söylediği gibi, yazılım mühendisliğinin ne anlama geldiğinin büyük bir kısmı “dışsal kısıtlamalar” dır. Örneğin. Zaman, bütçe, hizmet, destek, irrasyonel salak talepleri yerine getirme vb.

Birçoğumuz (kendim dahil) programlamanın, programlamanın kendisiyle ilgili olduğunu düşünüyoruz - güzel ve zarif yazılım parçalarını bir vakumda (ya da en azından göreceli bir boşlukta) kodlayarak. Nadiren öyle. Yaklaşan bazı nadir akademik veya Ar-Ge yazılım işleri olabilir, ancak çoğunlukla, yazılım geliştirme çalışmasının büyük çoğunluğu böyle bir şey değildir. Özellikle, bir ürünün kullanım ömrünün% 90'ı + olan bakım aşamasında ve çoğu kalıcı ticari yazılım çalışmasının günlük rutini olan ekmek ve tereyağı.

Uzun zamandır, bu konuda işimden sık sık beni mutsuz eden içsel bir çatışmaya kapıldım (ve geçen yıl tükenmeye yol açan şeyin bir parçası). Her zaman bir işin güzel kod oluşturma ve doğru şekilde yapmak için zaman ayırma ile ilgili olmadığını her zaman hissettim . Fakat gerçekte, bu gerçek - ve bazı insanlar aslında hizmet odaklı bir iş akışında başarılı oluyorlar. Onları pragmatik ve yararlı hissettiren şey budur. Bir projenin gerçek "saf yazılım mühendisliği" yönleri göreceli olarak acele ve özensizleşse bile.

Neyse, bunu şimdi sorgulaman güzel. Bu okulda asla doğru düzgün açıklamadıkları şeylerden biri. Ve şirketler, yapmasalar bile çok iyi mühendislik uygulamalarını takip ettiklerini iddia etmeyi çok seviyorlar. İpucu: çoğu yok.

Bütün bunlar, her şey değişebilir. Bazı şirketler (çoğunlukla yazılımları ana işlerini yapanlar ve tıbbi donanım gibi güvenlik açısından kritik yazılımlar üzerinde çalışanlar) çok katı bir mühendislik sürecini takip ederler. Ama genel olarak, evet, size şimdi boş bir noktaya değineceğim, çoğu ticari yazılım çalışmasının görece özensiz olduğunu gösteriyor. Genellikle bazı resmi süreçler vardır, ancak buna bağlı kalmak, müşteri girişlerine ve diğer ticari baskılara tepki vermek için hemen hemen her zaman arka koltukta bulunur. Gerçekten de "dikkatsizlik" değil, sadece basit pragmatik bir fayda. İşin püf noktası nişinizi bulmak ve "saf programlama" yönünün ne kadar soğuk olduğu değil, hangi hizmetin sağladığı açısından bir role bakmak.

EDIT : İlk değerlendirmemde tek taraflı geldiğimi düşünüyorum. Sık sık Oradaki eklemek istiyorum olan şeyler olmak hakiki sorunları da çok teknik borç içine projeyi sürüş ve aslında iş için kötü oluyor noktaya - özensiz ve iyi sürecin yoksundur. Ancak bunu görmek tecrübe ile gelir. Başlangıç ​​noktası hala temelde duruyor: Günümüzde çoğu ticari yazılım çalışması, safcılar kadar katı bir mühendislik odaklı değildir.

Ne harika bir soru! Bazen hızlı bir şekilde değerli bir şey yapabilirsiniz . Bu genellikle, bilmediğimiz şeyi ne kadar hızlı öğrendiğimizi, ne kadar iyi olacağımızı araştırma laboratuarında geçerlidir. Ürettiğiniz yazılım yalnızca soruları yanıtlamak için bulunur. Bu "kodu atmak" dır. Bu aynı zamanda müşterilerin gerçekte ne istediklerini bilmeyen yeni başlayanlar için de geçerlidir. Ayrıca, ilk defa bir şey yaptığınızda, berbat olacak. Efsanevi Adam Ayını Okuyun .

Bazen iyi olarak değerli bir şey yapabilirsin . Bu genellikle, Adobe Photoshop gibi büzgülü paketlenmiş bir yazılım için geçerlidir. Araştırma zaten yıllar önce yapıldı ve şimdi soru, müşterilerin hata getirmeyecek şekilde istedikleri özelliklerin listesini nasıl ekleyeceğimiz. Mimari, tasarım ve test, test, test meselesidir. Kodun kendisi değerlidir, ondan öğrendikleriniz değil.

Araştırmadan memnun değilseniz (bir şeyi ilk yapmak, daha önce kimsenin bilmediği yeni şeyleri öğrenmek), daha sonra küçültülmüş yazılımı deneyin. Aslında, senin yaşındayken mümkün olduğunca çok şey denemelisin. Git risk al! Çok şey öğreneceksiniz ve uzun vadede daha iyi olacaksınız.

Kariyerinizde çok erken, farkına varmadan, işleri hızlı bir şekilde yapmanın, doğru bir tasarım veya uygun bir test yapmadan sizi ısırmaya meyilli olduğunu fark ettiniz. Belli ki bundan hoşlanmıyorsun ve yapmamak için iyi bir nedenin var. Özellikle ilk çözümler yanlış veya eksik olduğunda bunları tekrar ziyaret etmek zorunda kalırsanız, "sorunların acele etmesi" beklendiği gibi saçma. Sorunlara yalnızca onları tamamen anlarsanız çözümler sunabilirsiniz, bu zaman alır ve dikkatli bir planlama yapar.

Size önerim, üstlerinizin bunun sizi rahatsız ettiğini bilmelerini sağlamak ve onlara işinizi yapmaları için daha iyi bir yaklaşım önermek. Kabul etmezler ve çalışmanızla "acele etmenizi" isterseniz, başka bir yerde iş aramaya başlardım. Endüstrinin beklediği bir yazılım geliştirme kalitesi standardı olmasa bile, kendi standartlarınıza uymayan bir şekilde şeyler yapmanın bir anlamı yoktur.

İşte benim deneyimlerime dayanarak tavsiyem, 20 yaşındayım ve şu anda Birleşik Krallık'taki büyük finans kurumu için çalışmakta olduğum ve birkaç ay önce sahip olduğunuz aynı hislere sahip olduğumu, farkettim ki bunun belki de doğası gereği Yaptığın iş.

Bununla demek istediğin:

“Yapmam gereken, teknolojilerin bir karışımını kullanarak içsel araçlar oluşturmak - özellikle de AWS / Java / Bash”

Ayrıca, belirli süreçleri yönetmek ve otomatikleştirmek için dahili araçlar oluşturmak zorunda kaldım ve gerçek şu ki, hızlı tempolu bir ortamda “küçük” şeylerin hızlı bir şekilde uygulanması gerekiyor. Aracımın çalışma versiyonunun birkaç hafta içinde gerekli olması gerektiğinden 2. yılımda öğretildiğim yazılım mühendisliği veya algoritmaların ve veri yapısı ilkelerinin çoğunu uygulama lüksüne sahip değildim. daha iyi okunabilir kod yazmayı öğrendiğim için hepsi kötü değil.

Sabırlı olmalıydım ve kısa süre önce 10K + kullanıcıları tarafından kullanılan yeni bir yerleşik sistem iterasyonu üzerinde çalışan yeni bir ekibe döndüm ve bunun yazılım mühendisliği yönünün çok ciddiye alındığından emin olabilirim. Gereksinim yakalama / analizden uygulama ve teste kadar tüm yazılım yaşam döngüsüne maruz kalacağım söylendi. İnanıyorum ki bu deneyimi kazanacağım çünkü dahili araçlar üzerinde çalışmıyorum ama büyük bir kullanıcı tabanı olan tam ölçekli bir sistemde çalışıyorum.

Önerim şu ki, sabırlı olmanız, araçları oluşturmayı tamamlamanız ve bu konuda çok iyi bir iş yapmanız, böylece yöneticileriniz size daha fazla güvenir ve size yazılım mühendisliği ilkelerinin kullanımını gerektiren daha zorlu görevler verir. Bazı ekstra okumalar yapmaktan ekstra bilgi edinin ve bu bilgiyi şu anda yaptığınız şeye uygulayın, şirketteki tüm e-kitap kütüphanesini sadece bilgi muhahahımı ilerletmek için aradığımı hatırlıyorum. Bana çok yardımcı olan gerçekten iyi bir kitap.

Sabırlı olun, kendi bilgilerinize büyük miktarda yatırım yapın ve mümkün olduğunda bu bilgiyi uygulayın. Çok iyi bir iş yapıyorsanız yakında birileri fark edecek.

Şu anki çalışmanızın çalışma şeklinin yetersiz olduğuna katılıyorum, evet. Ancak, bunun hiç işe yaramadığını söylemek istiyorsanız, orada çeşitli sonuçlar olduğu ve kurumun hala olduğu için sizinle aynı fikirde değilim.

Size asıl sorum şu ki, ne kadar hızlı bir şekilde tıbbi bir hastaya ilk yardım vermeye benzer şekilde acil çözümler gerektiren yangınlarla uğraşıyorsunuz, bunun yerine proje olarak ayarlanabilecek ve tıbbi hastaya çok daha farklı bir ölçekte ele alınabilecek talepler var. Derhal ve yakın vadede yapılması gerekmeyen testleri ve çeşitli prosedürleri planlamak zorunda.

Bir işi iyi yapmak için zaman ayırmak, kuruluşun olgunluğuna ve yapılacak bir iddiaya karşı yapılması gereken şeyin ne kadar önemli olduğu ile ilgilidir.

Veri yapılarının araştırılmasıyla ilgili soru, bunu ne kadar süredir yapmak istedikleridir. Birkaç saat sürmekten çok farklı bir veri yapısını araştırmak için on yıl almak istiyorsanız. En iyi cevabı alma arzusunu anlayabilsem de, bir sorun için biraz zaman geçirdikten sonra azalan getiriler için söylenecek bir şey var, örneğin FizzBuzz'a bir çözüm bulmak için saatler harcayabilir misiniz? , çeşitli dillerde çözmeyi deneyeceğiniz gibi misiniz? Ne kadar hızlı çalışabileceğini optimize etmek için çeşitli donanımlar.

Araştırma yapmak önemli olsa da, bir şeyler sunmak da önemlidir. Bir şey teslim etmezsen, gerçekten ne kadar iyisin? Koli Bandı Programcısı burada işlerin yapılmasının bir örneği olabilir.

Scrum, şu andaki iş yerinizde muhtemelen benimsemeye çalışabileceğiniz özel bir metodolojidir. Scrum'ın gümüş bir mermi olduğunu sanmayın. Scrum ve Çevik Altındaki Projeler Hangi Koşullarda Başarısız Olabilir? Bu konuda ilgi çekici olabilecek bir blog yazısı olacaktır.

Tahminime göre, şu anki mekanınızın süreçlerinin ne kadar gayrı resmi olduğunu görmüyorsunuz ve çimin resmi bir metodolojinin olduğu diğer tarafta son derece yeşil olduğunu düşünüyorsunuz. Orada daha iyi olsa da, bazı insanlar büyük bir kovboy olma özgürlüğüne sahip olduğunuzu tercih edebilir .

Bence durumun hala Gerçek Dünya ölçeğinde, kalite tarafında daha az vurgu yapmak için. Tercihiniz gerçek dünyanın diğer ucunda. Özellikler değişir, üstesinden gelir. İşlerin yapılması gerekiyor.

Bir sonraki işinize başvururken bu tür şirketleri tanımlamanın yollarını düşünün. Birkaç yerde, geliştiricilerin tasarımlarını sonsuza dek analiz etmeleri için karşılayabilecekleri bir iş modeli vardır (Profesörlerin bile öğretmesi gerekir). Çalışmanız kuru silme tahtasından ayrılmazsa müşteriler nadiren ödeme yaparlar. Kariyerinde bu kadar erken kendini delirttiğini görmekten nefret ediyorum.