Kötü programlama uygulamaları yazılım endüstrisinde tipik midir? [kapalı]


140

İlk işime bir ay önce bir yazılım geliştiricisi olarak başladım. OOP, KATI , KURU , YAGNI, tasarım desenleri, SRP vb. Hakkında öğrendiğim her şey pencereden atılabilir.

C # .NET Webforms'u kullanırlar ve neredeyse arkasındaki her şeyi, nesne olarak adlandırılmayan çok az harici sınıfla yaparlar. Özel kontrolleri kullanıyorlar ve yeniden kullanıyorlar. Kullanılan nesneler hakkında Entity Framework'e aittir . Her müşteri için Behind Code'u tekrar kullanırlar. Her tür şeyi yapan 400 satır uzunluğundaki yöntemleri var. Yeni müşteriler için aspx ve aspx.cs dosyalarını alırlar ve müşteri kodunu çıkarırlar ve yeni müşteriye özel kodu eklemeye başlarlar.

İlk mazereti, ek bakım eklemesi olabilirdi ve daha fazla kod daha fazla bakım gerektiriyor. Kendim dahil üç geliştiriciden oluşan küçük bir dükkan. Bir geliştirici 30 yıldan fazla deneyime sahip, diğeri 20+ yıl deneyime sahip. Biri oyun geliştiricisi, diğeri ise her zaman C ve C ++ 'da çalışıyordu.

Yazılım endüstrisinde bu ne kadar yaygındır? OOP'un ve ilgili ilkelerin üzerinde durmamı nasıl sağlayabilirim? Boş zamanlarımda pratik yapıyorum ve OOP'ta daha iyi olabilmek için daha deneyimli bir geliştirici altında çalışmam gerektiğini hissediyorum.


Sohbet başlıklarında bir tartışma başlattım: chat.stackexchange.com/transcript/message/40126879#40126879 Lütfen bana katılın.
17'de

1
Yorumlar uzun tartışmalar için değildir; bu konuşma sohbete taşındı .
Dünya Mühendisi

Yanıtlar:


263
  1. Sorunuzda bahsettiğiniz prensipler sadece ... prensiplerdir. Zorunluluk, kanun veya emir değildirler.
  2. Bu ilkelere uyan insanlar çok akıllı olsalar da, mutlak otoriteler değildir. Onlar sadece fikirlerini ve rehberliklerini sunan insanlar .
  3. Programlamanın "doğru" bir yolu yoktur. Bu, yaptığımız "kabul edilen" yolun zaman içinde köklü olarak değiştiği ve değişmeye devam ettiği gerçeğiyle kanıtlanmaktadır.
  4. Bir ürünün nakliyesi, genellikle "doğru" yöntemle yapılmasından öncelikli olabilir. Bu, böyle bir yaygın uygulama adıdır: Teknik Borç.
  5. Yaygın olarak kullanılan bazı yazılım mimarileri ideal değildir. En iyi uygulamalar, geniş, monolitik uygulamalardan, gevşek bir şekilde birleştirilen modül koleksiyonlarına doğru evrimleşiyor .

  6. Bağlam önemlidir. Birçok mimari ilke, yalnızca büyük programlarla veya belirli alan adlarıyla çalışırken değerlerini kanıtlar . Örneğin, devralma çoğunlukla UI hiyerarşileri ve derinlemesine yuvalanmış, sıkı eşleşmiş düzenlemelerden yararlanan diğer yapılar için yararlıdır.

Öyleyse vahşi doğada ortaya çıkabilmek için ilkeli bir yol olan "doğru" bir yolu nasıl takip edersiniz?

  1. Doğruluk yerine uygunluğu inceleyin . Yazılım geliştirmede bir şey yapmanın "doğru" yolu, özel gereksinimlerinizi en etkili şekilde karşılayan yoldur.
  2. Değişim çalışmaları. Yazılım geliştirmedeki her şey bir değişimdir. Daha fazla hız mı yoksa daha az bellek kullanımı mı istiyorsunuz? Birkaç uygulayıcı ile çok etkileyici bir programlama dili ya da birçok geliştiricinin bildiği daha az etkileyici bir dil mi istiyorsunuz?
  3. Zamansızlığı inceleyin. Bazı prensipler zamana dayanmıştır ve her zaman ilgili olacaktır. Tip sistemleri evrenseldir. Birinci sınıf fonksiyonlar evrenseldir. Veri yapıları evrenseldir.

  4. Pragmatizmayı öğrenir. Pratik olmak önemlidir. Gemi kuramazsanız matematiksel saflık, kristal katedral mimarileri ve fildişi kule ilkeleri işe yaramaz.

  5. Bir zanaatkar olmak, bir coşkun değil. En iyi yazılım geliştiriciler, kuralları bilenler ve daha sonra mantıklı geldiğinde onları nasıl kıracağınızı bilenler. Onlar hala problemleri nasıl çözeceğini ve kendileri için düşünmeyi bilenler. Seçimlerini bilgilendirmek ve yönlendirmek için ilkeleri kullanıyorlar, dikte etmiyorlar.
  6. Kod yaz Onun çoğu. Yazılım tasarım ilkeleri, çok sayıda kod yazana ve doğru şekilde nasıl uygulanacağına ilişkin bir içgüdü geliştirinceye kadar erken optimizasyonlardır.

1
Yorumlar uzun tartışmalar için değildir; bu konuşma sohbete taşındı .
yannis

Bu öngörüleri sistematik olarak herhangi bir rehberliğe sahip olmadığım nereden alabilirim?
Ooker,

4
Sadece en iyi uygulamanın ne olduğunu anlamayın, aynı zamanda en iyi uygulamanın somut faydalarını da anlayın. En iyi uygulamayı uygunluğa bağlamanıza izin verir ve aynı zamanda uygulamanın en iyi etkiye sahip olması için etkililiği sağlar . En iyi uygulamanın “endişelerin ayrılmasını” sağladığını söylerseniz, muhtemelen uygulamanın faydalarını elde etmek için doğru yolu kullandığınızdan emin olamazsınız.
AaronLS

51

Nadir değildir. Gerçekleşmesi gereken bir şey, yazılım endüstrisinin inanılmaz derecede farklı olmasıdır. Bazı şirketler son teknolojidir. Önde gelen üniversiteler ve yenilikçi yazılım şirketleri (hatta büyükleri de bazı laboratuarlar!) Yanı sıra dörtlü çete gibi kutsanmış kişiler veya gruplar, ortak şeyler yaparak ortaya çıkan sorunları analiz eder ve yeni diller, makineler, araçlar ve kalıplar icat eder. Yeni şirketler, çoğu zaman bölünmeler veya bölünmeler, ticari olarak bunları kullanmaya çalışır ve bazen şaşırtıcı bir başarıya sahiptir. Facebook veya Google'ı düşünün.

Ancak yazılım, bugünlerde hemen hemen her yerde, belki de çoğunlukla yazılım şirketi olmayan şirketlerde kullanılır. Daha çok ulaştırma endüstrisinde (otomotiv ve demir yolu) çalıştım ve çok çeşitli deneyimlerim var. Fakat hiçbiri "en üst seviyeye" yakın değildi. Bazen olamazlar; güvenlikle ilgili yazılım iyi işlenmiş araçlara bağlıdır (şu anda 1990'lardan itibaren doğrulanmış bir C ++ derleyicisi kullanıyoruz). Bazen doğru insanlara sahip değiller. Genellikle, yazılım, gittikçe daha önemli hale geldiğinde, şirketlerinde yazılım geliştirmeye yeni giren diğer alanlardaki mühendisler tarafından geliştirilmiştir. Bunlardan biri yazılım mühendisliği ilkelerini bilmelerini veya kullanmalarını bekleyemez.

Dikkate alınması gereken başka bir şey, gerçek dünyada bir mühendisde önemli olan şeydir. Genellikle eldeki görev, kelimenin tam anlamıyla roket bilimi değildir. Yazılım dışı şirketlerdeki ekmek ve tereyağı sorunları mütevazı yazılım araçlarıyla çözülebilir. Yararlı, belki de iyi bir yazılım mühendisi yapan şey kısmen iyi bir genel mühendis yapan şeydir: Güvenilir olun; işinizi sorumlu bir şekilde organize etmek ve belgelemek; kooperatif olmak; iyi maliyet ve zaman tahminleri yapın (tahminin geçerliliği gerçek maliyet ve zamandan daha önemlidir!); ne yapabileceğinizi ve yapamayacağınızı anlayın. Burada dikkat çekici bir şekilde eksik olan "son teknoloji araç ve prosedürleri bilmek ve kullanmak". Tanımladığınız şey, onlar için çalışan bir araç seti ve süreci kuran bir şirkettir. Muhtemelen asla seksi ya da olağanüstü bir şey üretmeyeceklerdir. ancak, sürekli olarak yeterli gelir akışı elde etmek için müşteri taleplerini yeterince iyi karşılarlar. Mühendisliğin tanımı bu olabilir ;-).

Yani evet: Üniversitede öğrendiklerin aslında bu alanda pek yaygın değil.


Bir parça teselli ya da daha iyimser bir not eklemek istiyorum. Öğrendiklerin pencereden atılmamalı. Günlük işlerinizde işleri bozmadığı daha iyi prensipler uygulayabilirsiniz. Belki de yeni bir araç veya tasarım deseni tanıtmak için bir fırsat penceresi olacak. Eski şeyler yapmanın meslektaşlar için hoş olmadığı ya da karmaşıklığı ya da bakımını yönetme sorunlarıyla karşılaştığında (inovasyonların ele aldığı en sık karşılaşılan iki sorun) ihtimaller en iyisidir. Bir fırsat olduğunda iyileştirmeler sunmaya hazır olun. Olumlu bir etki olun ve yöntemleri ve araçları adım adım iyileştirin; takdir edildiği bilgiyi yaymak.


2
@nocomprende: entiendo yok ... Ortak olanın daha yaygın olduğunu ve olağanüstü olanın ne yazık ki olağanüstü olduğunu mu kastediyorsunuz? Yoksa ortak olanın olağanüstü iyi olmadığını mı? İyi evet.
Peter A. Schneider

3
"Üniversitede öğrendiklerin aslında bu alanda pek yaygın değil" - Bu anahtar gibi görünüyor ...
Brian Knoblauch

1
Demek istediğim, yazılım alanının tüm insan becerisine, insanlara ve uzmanlığa sahip insanlara sahip olduğunu, şirketlerin tüm hazırlıklara, tüm sorunlara ve benzerlerine, yani dünyanın geri kalanına olduğu gibi. Yazılım bu yollarla diğer alanlardan farklı değildir. Herhangi bir SE sitesinde sorun yaşanmış olabilir.

1
"güvenlikle ilgili yazılım iyi değerlendirilmiş araçlara bağlı (şu anda 1990'lardan beri doğrulanmış bir C ++ derleyicisi kullanıyoruz)", bana çok etkileyici geliyor!
Hovercouch

1
@ PeterA.Schneider, aletlerinizi incelemek için ne kadar ileri teknoloji olduğuna dair aptalca bir şakaydı. ;)
Hovercouch

16

C # .Net Webforms'u kullanıyorlar ve çok az Dış Sınıf ile Code Behind içindeki hemen hemen her şeyi yapıyorlar.

İşte açıklamaların orada. Farkında değilseniz, kullanıma hazır Web Formları kodu OOP, KATI, KURU, YAGNI, Tasarım Desenleri, SRP , vb. bugün seni sıkma yapardı.

Web Forms, kontrol tıklamaları ve benzeri işlemlerle tetiklenen bazı sahte "olaylarla" kendini prosedür akışına doğru iter. Web Formları yaparak çok fazla zaman harcayan Devs de genellikle ondan ayrılmak konusunda isteksiz görünüyor, çünkü muhtemelen sayfa yaşam döngüsünü öğrenmeye ve bu bilgiyi şimdi atlatmak için nefret ettikleri dinamik olarak oluşturulmuş kontrolleri nasıl yapacaklarına çok fazla zaman harcadılar. daha yeni / daha iyi yöntemler karşısında. Düşük maliyetli yanlışlığın bilinçsiz bir versiyonu. Bu devler yıllarını Web Formlarını nasıl boğacaklarını öğrenerek geçirdiler ve şimdi bu uzmanlıktan kolayca ayrılmayacaklar, bu yüzden "bakım" zamanı hakkında konuşmaları.

Ve bu, .NET Web Formları alanında, btw'de oldukça yaygındır.


6
Teknoloji söz soruyu yığını adrese Güzel
jasonoriordan

5
Kim bir onay kutusunu işaretlerken veya işaretini kaldırdığınızda ne olacağını bulmak için iç içe geçmiş ve birbirini arayarak 20 sınıfa bakmak ister? Sadece çılgın insanlar veya üniversite profesörlerini düşünen insanlar tanrılardır.
developerwjk

1
Aslında, WebForm oluşturulduğunda, endüstri standardı uygulamaları farklıydı (ya da yoktu) ve zaten mevcut olan uygulamalar "işleri yapmanın yeni yeni yolu" kabul edilmeye başladığında hiçbir zaman yeniden değerlendirme yapmazlar. Bu yüzden karmaşaya karışmış bir sürü WebForm kodu görüyorsunuz. Programlama ilkeleri, kullandığınız teknoloji yığından uzaktır, böylece WebForms, Cobol, Assembly'de bile uygulanabilir.
BgrWorker

1
Evet bu doğru. ViewState'iniz kaç MB? İşin garibi, sunucu tarafı denetimlerinin işletme mantığını kullanıcı arabirimine teşvik etme eğiliminde olduğunu düşünüyorum. Yine de, programcı asp.net kargo-kültü programlama saçmalığını kolayca kullanabiliyordu. Böylece: iş nesnelerinin doğru duruma ulaşamadığı pek çok olay var. Otobüs. UI kuplajı nedeniyle nesneler birbirini arayamadı. O zaman: oh, Mo'ya bak! "Bağlantısız!" Çalışabiliriz. nyuck, nyuck, nyuck. Gerçek veri hacmi, uygulamanızı bir taşlama işlemi durdurucuya bıraktı ve asp.net sınıfları bir veritabanı motoru gibi davrandı. Ama bağlantıları yıpratmaktan kurtardık!
radarbob

1
Tüm bu rant doğrudur ... kalp anahtar olarak doğrudur. WebForms uygulamaları ile ilgili olarak bu yazıda anlatılanların çoğunu gördüm, bu uygulamalar bana enerji içecekleri üzerine dizilmiş bir lise öğrencisi tarafından atılan bazı PHP betiklerinden biraz daha iyi hissettiriyor - ve kurumsal bir yazılım olarak kabul edildi!
Greg Burghardt,

12

Yazılım endüstrisinde bu ne kadar yaygındır?

Çok yaygın. Su tesisatçısına sahip olmakla aynı sıklıkta su tesisatınızı, önemsiz bir marangoz marangozu veya uygun bir terzi yapan ucuz bir terzi var. Yani, hepsi insan.

Bunun olmasının iyi bir nedeni var: gerçekten iyi eğitilmemiş (veya hevesli olmayan) insanlar baskı altında bir şey uygulamak zorunda.

Bu, öncelikle bu insanların değil, genellikle o şirketteki yazılım geliştirmeyi çevreleyen yapıların sorunudur. Örneğin, bir şirketin stajyerleri kendi iç yazılımlarını geliştirmiş olabilir; Bu stajyerler aydınlık ve bilgili olsalar bile, sadece birkaç hafta veya ay boyunca orada olacaklar ve mülkiyet sık sık değişecek.

Veya etki alanında harika olan, ancak bir programcı olmayan bir kişi, bazı VBA vb. Uygulamaları bir araya getirebilir, çünkü başlangıçta oldukça kolay görünüyor.

Ya da iyi yapılmış bir uygulama bakım aşamasında sona erer, tüm iyi geliştiriciler devam eder ve daha sonra bu konuda çok az şey bilen, hiçbir belgeye sahip olmayan az sayıda kişi (en kötü durum: bir) tarafından geliştirilmeye devam edilir.

OOP'un ve ilgili ilkelerin üzerinde durmamı nasıl sağlayabilirim? Boş zamanlarımda pratik yapıyorum ve OOP'ta daha iyi olabilmek için daha deneyimli bir geliştirici altında çalışmam gerektiğini hissediyorum.

İki olası cevap var:

  • Her ikisi de: Bunu patronunuzla tartışın ve temiz projeler yaptığınızdan emin olun. Mümkünse, yeni bir patron bulun.
  • Veya: Bunun sorumluluğunu kendiniz üstlenin. Bu, kendi başınıza yapmak anlamına gelir - boş zamanlarınızda, ya da şirkette, ancak kendiniz tarafından tahrik ediliyorsanız (olası değildir).

İkinci cevap sizin için çok alaycı geliyorsa, o olmadığını size söyleyeyim. Evde bir ağaç dükkanı olan bir marangoz olacak en Kesinlikle yapmaz olandan daha iyi bir marangoz olmak.

Örneğin, bazı insanlar için, örneğin Ruby gibi yeni bir dile kazmak, sadece sözdizimini öğrenmekle kalmamakta, aynı zamanda o dilin özel OO yönlerinden de bağımsız ve gerçekten derinlemesine dalmak kesinlikle mümkün ve çok eğlenceli. Tüm boş zamanlarınızda, işinizle hiçbir bağlantısı olmadan. Bu sadece bir hobi olacak, fakat sizin gibi eğitimli bir profesyonel olmak, bazı lider geliştiricilerin yanında oturmak ve yaptıklarını takip etmeye çalışmak kadar etkili (veya daha fazla) olabilir. Bu kesinlikle kişisel gelişiminiz ve kendi eğlenceniz için olacaktır. Bunu yapmaktan zevk almıyorsanız ya da herhangi bir anlama ulaşamadığınızı görürseniz, bunu çizin ve ilk cevaba geri dönün.

Seni eğitiyor O kurşun geliştirici gelmiştir oldukça büyük olasılıkla tam olarak bu şekilde bu şeyler öğrendim ...


2
Yani, sadece iyi nitelikli, tamamen eğitimli ve hevesli insanları işe almak için işe alın. Bunu neden yapmıyoruz? Şu soruyu sorar: iyi kalifiye olmayan, iyi eğitimli ve hevesli olmayan insanlar nasıl yaşamalı? Charles Dickens bunun cevabını bildirdi: hiç değilse pek iyi değil.

@nocomprende, fikrinizi yansıtıyorsunuz, hiçbir şekilde yazdıklarınızı ima etmedim. OP'nin farkına varılması için nedenleri açıklıyorum.
AnoE

Sadece gelen Kurt Vonnegut'ın soru hakkında düşünmeye devam Tanrı You Mister Rosewater Bless : "Bu da ne insanlar için ?"

2
@nocomprende, "eğitilmemiş bir insandan" bahsedersem, insanların aptalca olduğunu söylemiyorum, ne olursa olsun bir insanın o iş için iyi eğitilmemiş bir iş yaptığını söylüyorum . Hata, yanlış iş vermesi için menajeriyle olabilir; veya (iş arkadaşı hastalanacak şekilde) veya ne olursa olsun hayal edebileceğiniz çeşitli nedenlerle. Sadece harika insanları işe almamız gerektiğini düşündüren hiçbir şey yapmıyor. Evimdeki su tesisatını tamir etmem gerekirse, başka ne yapabilirsem harika olduğum halde, bir karışıklık yaratacağımdan emin olabilirsiniz.
AnoE

1
Eski Mısırlılar gibi köle toplumlarının, insanların “gelişmesine” yardım eden toplumlardan çok daha az insandan daha az kazandığı Antropolojiden eski bir fikir var. Bu yüzden kapitalizm ortaçağ kültüründen daha iyiydi. İdeal olarak, herkes bunu geliştirmeyi başarabilirdi ve sonra her birinden tam olarak faydalanabilir ve her kişi toplumdan tam olarak faydalanabilir. Kapitalizm bunu sağlayacak kadar iyi değil, bu yüzden daha fazla bir şeye ihtiyacımız var. Optimal işlerden daha azını yapan insanlar var bunun kanıtıdır, çünkü Kapitalizm mükemmel olsaydı bu olmazdı.

11

İspanya'da sürekli olduğunu düşünüyorum çünkü bir geliştirici bir şirkette uzun yıllar geçtiğinde, o (genellikle) analiz ve proje yönetimi gibi daha fazla yönetim alanına terfi eder. Sonuç olarak, meslektaş değerlendirmesi yapılmaz ve kod genellikle az deneyimli kişiler tarafından yazılır.

Bu deneyimli insanların başarısızlıkları hiçbir zaman düzeltilmez: bunun yerine, işleri yapmak için tek odak noktaları. Sonuç olarak, kodda giderek daha fazla yanlış uygulama birikmektedir.

Sonunda bazı akıllı eşek en iyi "çözüm" yeni bir uygulama oluşturmak, daha temiz ve daha bakımlı kod üretecek bir teknolojiye geçmek olduğunu söylüyor. Sanki teknoloji kendi başına yapabilirdi.

Yine, tecrübesiz programcılar bu yeni teknolojide çalışmaya başladı, kimse kodu gözden geçirmedi ve daire tekrar kapatıldı .... sonsuza dek ve sonsuza dek ....


16
İspanya ile ilgisi yok. Bu Peter prensibidir - insanlar, istemedikleri bir konuma gelinceye kadar iyi yapan pozisyonlardan terfi ederler ve orada sıkışıp kalırlar, çünkü onları teşvik edecek hiçbir şey yoktur.
Jan Hudec

3
Ayrıca, yazılım endüstrisinin hala büyümekte olduğu gerçeği var, bu nedenle göreceli olarak az deneyime sahip kişiler çok daha fazla. Ve pek çok şirketin hiç tecrübeli bir insanı yok, çünkü emektar kiralamak için yeni ve ucuzlar. Üniversiteden yeni çıkmış bir sürü yeşil ot olacağını düşünüyorlar.
Jan Hudec

1
@JanHudec Bilmiyorum adamım, kendimi orijinal posterin konuştuğu 20 yaş üstü deneyimlerden birinden daha kolejden genç bir yaşta geçirmiş gibi hissediyorum
Mikey Mouse

9
@MikeyMouse, doğru, 20 yıllık deneyime sahip değil, 20 yıllık 1 yıllık deneyime sahip birçok insan var. Ve gerçekten büyük sıkıntı büyüler.
Jan Hudec

".. peter prensibi .."; özellikle de bilinçli bir fenomen olduğu bir devlet kurumunda. Ben onlara Yönetim Yetiştiriciliği Programı diyorum. Sık sık, iyi / kötü kodlayıcıların bir dengesi olsa da, korku, MIP'in yetersizliği tekrar zorlamasıdır. Yıllar sonra ne zaman belli jr. programcılar artık kimseyi onlardan daha iyi tanımayacak olan bölüm şefleridir, iyi insanlar ve fikirler ayrılır veya zorlanır. Dükkan bir sepet yetersizliği haline geldi; devam etmek için birlikte bir kültür içinde ana bilgisayarlarda programlama "kalan arka plan radyasyon zihniyet" sıkışmış.
radarbob

7

Okulda öğrendiğiniz "en iyi uygulamaların" bazıları gerçek dünyadaki projeler için pratik ya da uygun maliyetli değildir. Fark ettiğim en büyük değişikliklerden biri biçimlendirme ve yorumlardı. Profesörlerimin çoğu, kodunuzu kapsamlı bir şekilde belgelemenin önemini vurguladı, ancak gerçek dünyada, iyi kod genellikle (her zaman değil!) Kendi kendini açıklar ve daha da önemlisi birçok patron, fazladan zaman yazmak için para harcamak istemez yorumlar.

Bazen, zaman zaman basılan programcıları, kalite çözümlerinden daha az kazan plakası gerektiren kısayollar ve anti-paternler kullanarak göreceksiniz.

Ancak, birçok takım ve projede dikkatimi çeken en büyük sorunlardan biri yeni şeyler öğrenmek istememesi. Konuştuğum eski programcıların birçoğu kariyerlerini kalifikasyonlar başladığında kod yazmaya istekli bir 'Vahşi Batı' yazılım mühendisliği döneminde başlattı. Genellikle tamamen farklı alanlara daldılar ve bir fırsat ortaya çıktığında çok az ya da hiç resmi eğitim olmadan programlamaya atladılar (örneğin, işverenleri bir programcıya sahip değildi ve şirket içi yazılım oluşturmak için öğrenmek için birilerine ihtiyaç duyuyorlardı). Bu eski kendi kendine öğretilen programcıların bazıları, modern kodlama uygulamalarını öğrenmek için hiçbir zaman çaba göstermezler ve on yıl önce öğrendikleri herhangi bir tarzda kabaca kodlamaya devam ederler. Kıdem nedeniyle yeni projelerden sorumlu olduklarında, projeleri geri tutma ve genel kod kalitesine zarar verme eğilimindedirler.

Tabi yukarıdakiler tüm eski programcılar için geçerli değildir ve yeni nesil kodlayıcılar da aynı derecede suçlu olabilir. Üniversiteden yeni çıkan birkaç araç ve kütüphaneyi alan birçok genç programcı ile çalıştım ve sonra tamamen öğrenmeyi bıraktım. Bir kez IDE veya kütüphane indirecekler ve şirketleri gerektirmedikçe asla güncellemeyecekler (bazen bir programcının kütüphanelerinin ne kadar eski olduğuna bağlı olarak hangi yıl mezun olduğunu tahmin edebilirsiniz). Seçtikleri dil (ler) in yeni özelliklerine uymuyorlar ve asla yeni dil öğrenmiyorlar. Yeni programlama stratejileri öğrenemezler ve kalıpları veya paradigmaları kötüye kullanabilirler çünkü daha uygun alternatifleri bilmiyorlar (oh MVC, ne kadar ağır suistimal ettiniz). Zaman geçtikçe iş akışları gittikçe eski hale geliyor ve bir varlıktan daha fazla sorumluluk alıyorlar.

Özetle, dağınık kod tabanlarının en büyük nedenlerinden ikisi, tarihi geçmiş veya eksik bilgilerle son tarihler ve programcılar koştu. Ne yazık ki, her iki konuda da sorumluluk son tarihlerin gerçekçi olmasını ve personelin bilgi ve becerilerini güncel tutmasını sağlamak zorunda olan patron veya CTO'ya düşebilir. Eğer patron iyi programlama uygulamaları hakkında hiçbir şey bilmiyorsa, yapabileceğiniz en iyi şey değişiklikleri önermek ve önerilere açık olmasını ummaktır. Ne yazık ki, OOP'yi anlamayan ve 10.000 satır sınıfı yazmayı seven daha kıdemli bir programcının sözüne güvenmeye meyilli olabilirler.


19
Bu efsaneden gerçekten hoşlanmıyorum, iyi kodun açıklayıcı olması ve yorumların eski olması. En iyi kod size tam olarak ne olduğunu söyleyecektir. Ancak, neden bir şeyler yaptığını veya doğru olsa bile olduğuna dair hiçbir gösterge vermez. Gelecekteki sürdürücü sen nedeninizi tahmin etmek zorunda kalmaması kodunuzu Comment fobricating foo ama bar .
user369450

13
İlk paragrafına katılmıyorum. Kodunuzu belgelemek (örneğin yorumlarla), en azından üniversitedeyken olduğu kadar önemlidir. Aradaki fark, hiçbir profesyonelin bir hattın ne yaptığını yorumlamayacağıdır - NEDEN belgeleyeceklerdir. Olanlar kaynak kodundan okunabilir. Neden genellikle birkaç dakikadan birkaç saate kadar düşünmenin sonucudur.
Araho

1
Kodun neden bir şey yaptığını yazmak için çok az neden vardır ve çoğu zaman daha iyi bir yöntem adıyla açıklanabilir. Kabul edelim, normalde hepimizin yazdığı kodların çoğu yorumları haketmeyecek kadar basit.
BgrWorker

1
Bu nasıl tekrar gider? Kod bir kere yazılır ve defalarca okunur. Yorumlarınızı yazın ve olacak tasarruf uzun vadede zaman. @ BgrWorker Sanırım kişiye bağlı. Düzenli olarak algoritmalar yazarım ve yorumları hak ettiklerini düşünüyorum (en son sembolik bir matematik ayrıştırıcısı olmak ... kesinlikle yorumlara ihtiyaç duyuyor)
kişi27

1
Ünite testlerinin yorumlardan çok daha değerli olduğunu düşünüyorum. Çok sık olarak, kodun güncellendiği ve yorumların artık geçerli olmadığı durumları gördüm. Bu durumda, güncel olmayan yorumlar neler olup bittiğini anlamayı zorlaştırır. Ünite testleri, orijinal programcının amacını belgelemektedir ve CI sisteminiz check-in sırasında ünite testleri gerçekleştiriyorsa, bunları sürdürmek zorundasınız.
bikeman868

2

Kötü programlama uygulamalarından bazıları, yıllar önce gelişime başlayan eski yazılımlarla çalışmak zorunda kalmasından kaynaklanıyor. Çok karmaşık bir yazılım parçası varsa, her şeyi yeniden yazmak bir seçenek olmayabilir. Kodun gerçekte yaptığı her şeyi anlamak bile çok zor olabilir. En iyi seçenek, herhangi bir şeyi bozmadan yapabiliyorsanız, daha iyi programlama uygulamalarını entegre etmeye çalışırken aynı zamanda çalışanı kopyalamak olabilir.


Başarısızlık da genellikle bir seçenek değildir.

1

Ben sadece doğruları yanlış yapmak değil, her doğru ve yanlışın arkasındaki nedenleri bilmek önemlidir . Sebepleri bildiğinizde sonuçları tahmin edebilirsiniz. Neden bu veya bu prensibi bir kitapta anlatıldığı için değil, nasıl kullandığını ve tam olarak ne olduğunu bildiğimiz için kullanmıyoruz . Ne zaman ne olacağını biliyorsanız, o zaman artıları ve eksileri tartıp bir karar verebilirsiniz. Bu aynı zamanda her zaman pozisyonunuzu savunmanıza yardımcı olacaktır. SOLID ve OOP, iyi kullanılırsa bakımı da azaltabilir.

Çok dogmatik olarak kullanılırsa, KATID, çok da iyi olmayan pek çok sınıfa ve yönteme yol açar. Fazla abartma. Bu, kısmen doğru bir şekilde gerekçe göstermeden fikirleri teşvik etmeye çalıştıkları için ders kitaplarımız ve derslerimizle ilgili büyük bir sorundur. OOP ayrıca eksilerini de içeriyor. Birçok ilke ve paradigma birbiriyle çelişir. Zirvede olmanıza gerek yok, her şeyi makul, haklı, zarif ve basit hale getirmeniz gerekiyor.

Ayrıca, bu sizin ilk işiniz olduğundan, bu programcılar çok yetenekli değiller. Fakat yine de, muhtemelen, daha az yetenekli daha ucuz kodlayıcılar tarafından daha az beceri ve daha düşük maaş için yapılabilecek çok zor görevlerle güveniyorlar. Ekonomi böyle işler. Her iş yeri farklı.

Nasıl hissettiğini anlıyorum. Panik yapma . Bildiğiniz şeye ihtiyacınız olacak, belki hemen değil, ama bu size yardımcı olacaktır. Belki farklı bir işyerinde, belki de bazı durumlarda. Daha ileri gitmek için önünüzde vaktiniz var.

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.