Katı mı yoksa pragmatik mi?

Yazılım geliştirmenin (diğerleri arasında) kendinize sürekli soru sorma süreci olduğunu fark etmeye başlıyorum. Kodun kalitesi, endişelerin ayrılması, bağımlılıkların en aza indirilmesi, ...

Ama asıl soru şu: bir akıl hastanesine gitmeden ne kadar ileri gidebilirsiniz?

Yeni bir işe başvuruyorum. Dün, programlama yeteneklerimi test etmek isteyen gelecekteki olası bir işverenin yanındaydım. Alıştırmalardan biri şuydu: bu kodun ne yaptığını açıklamak. Geliştirdikleri uygulamanın (vb.net winforms) bazı kodlarından geçti (bir hastane için bir idari uygulama). Bu bana bir şeylere nasıl yaklaştıklarını görme fırsatı verdi ve oldukça hayal kırıklığı yarattı.

Bazı örnekler:

• Bir yerde gördüm: [buraya altprogramın adını girin] -> Vuruldum: VB6'dan bir şey değil mi?
• Onlar ado.net kullanarak ayrı bir veri katmanı var, ama incelemek zorunda bir yöntem çağıran katman için bir veri kümesi döndürür. Bu nedenle ayrı veri katmanı olsun veya olmasın, uygulama ado.net'e bağlıdır (başka bir veri erişim yaklaşımına asla geçmezlerse hiçbir zaman sorun olmayabilir).
• Bu veri seti olduğu gibi okunur, bu yüzden hala veri merkezli bir yaklaşımdır (elbette, "Hasta" veya "LabAnalysisRequest" gibi sınıflara ne kadar mantık / davranış koyabileceğiniz tartışılabilir.
• Ben de dize birleştirme ile bir sql sorgusu inşaat gördük inanıyorum.
• Saklı yordamlar kullanıyorlar (benim için mantığın dağılması anlamına geliyor)
• görünümlerden / kontrolörlerden bahsedilmiyor: hepsi form odaklı
• Gördüğüm en çirkin şey:

      TestEnvironment.IsTesting ise
         someVar = [bazı sabit kodlanmış değerler]
      Başka
         someVar = [dinamik olarak alınan bazı değerler]
      eğer biterse
      [burada işlevin geri kalanı]
  

Okulda öğrendiklerimden çok farklı: (kalıcılık agnostik) etki alanı katmanı, kalıcılık katmanı, sunum katmanı, birim testi, ...

Bu yüzden sorumu yeniden ifade ediyorum: kişi ne kadar temel veya dogmatik olmalı? Bir programcı ilkelerine ne ölçüde uymalı veya işi yapan bir kod yazmalı mı?

Bunun sorunuza doğrudan cevap vermediğini biliyorum, ancak bunun bir yorumdan daha değerli olduğunu düşünüyorum:

Bir iş görüşmesi yaptığınızda, sizinle görüştükleri kadar röportaj yaparsınız . Bir röportajı göbeğinizde sürünerek size bir şey teklif etmelerini isteyen bir şey olarak görme alışkanlığını kırın. Onlar size ödeme , ama sen de onları ödeme . Eğer senden hoşlanmazlarsa seni işe almazlar. Onlardan hoşlanmıyorsanız, orada çalışmaya gitmeyin.

Evet, endüstride, son tarih, kaynak eksikliği ve finansal kısıtlamalarla farklı arka plan, beceri ve tutkuya sahip üç düzine geliştirici tarafından zamanla saldırıya uğrayan on yıllık bir eski kod tabanı ile kod asla nasıl görünmesi gerektiğini öğrenmelisin. Bazı tavizler vermeniz gerekecek. Ama kaç tane ve çizgiyi nereye çekerseniz, bu tamamen size bağlıdır.
Elbette, yaptığınız işten daha az taviz vermek daha zor. Ama daha eğlenceli olabilirler.

FWIW, şimdiye kadar (sektörde> 10 yıl) hiçbir zaman birçok geliştirici ile büyük bir şirkette çalışmadım (~ 30 geliştirici en çok, bir düzine norm), çünkü küçük bir şeyde bir şeyi değiştirmeniz çok daha olası şirket. Çocukları aç bırakmamak için yeterli para kazandığım sürece, tek yapmam gereken tek şey dişlilerin geri kalanıyla senkronize olmak.
Geçmemi istedikleri testleri gördükten sonra iş tekliflerini geri çevirdim. Ben bir C ++ geliştiricisiyim ve orada tırnaklarınızı tiksinti kıvırmak çok kötü olan birçok C ++ testi var ve onlar temiz kod yazamayan moronlar işe çünkü yel değirmenleri mücadele zaman harcamak istemiyorum.
Ayrıca birkaç ay sonra işten ayrıldım çünkü röportajda farklı olmalarına rağmen programlama felsefeleri (kısa vadeli hedefler, gelecek yıl boş ver) yeteneklerime (uzun vadeli kod istikrarı) uymadı.

Asla sadece işi yapan kod yazmayın. Ancak doktrininizi incelemeye de aynı derecede istekli olun. Okulda öğrenmiş olmanız, onun mevcut düşünce, hatta geçerli düşünce olduğu anlamına gelmez. İş dünyası için daha reaktif olmak zorunda olan programlama sayesinde yazılım tasarımı yaşam döngüsü artık kullanılmıyor. Bazen garip bir şekilde bağlantılı yazılım çözümleri garip bir şekilde bağlanır, çünkü parçalar izin verilen sürede değiştirilir.

İşte bir şirketin kodlama yaşam tarzına ne kadar iyi uyduğunuzu belirleyecek olan derlediğim sorunların bir listesi.

1. Refactor için kenara koyma süresine ne kadar değer verdikleri ve kod tabanlarını güncelledikleri. Kod tabanının güncellenmesini nasıl gördükleri, ne kadar iyi uyduğunuzda önemli bir belirleyici faktör olacaktır.
2. Şirket içinde kodlamak yerine ne sıklıkla üçüncü taraf satın alıyorlar.
3. Açık kaynaklı yazılımlar hakkında ne düşünüyorlar. Kodu değiştirme esnekliğine sahip olduklarının farkındalar mı? Bunu 3. taraf satın almakla aynı şekilde mi görüyorlar?
4. Belirli bir soyutlama katmanı üzerinde çalışacaksınız. Arayüz kurduğunuz ekip sizin arayüzünüzü belirliyor mu? Hangi katman / ekip / arayüz arayüzü karar vermede daha fazla güce sahiptir.
5. Denetim, karar verirken programcıları ne kadar dinler. Bir programcı kırmızı bayrak attığında, denetim durur ve kararlarını gözden geçirir.
6. Yönetim deneyimli programcılar düşünüyor musunuz? Deneyimlerini nasıl görüyorlar? Deneyimleri geçerli mi? Eski deneyimlerin karar almayı etkilemesine izin veriyorlar mı?
7. Kod tabanı ne kadar yapışkan?
8. Programlama araçlarını (IDE vb.) Ne sıklıkta güncellerler?

Bu soruların cevapları, dogmalarınızla eşleşip eşleşmediklerini görmekten ziyade programlama yaşam tarzlarına nasıl değer vereceğinize daha uygundur.

Dogma kaçınılmaz olarak kırılacak (sadece X'i güncellemek için zamanımız yok). Bununla birlikte, öncelikler stilleri ve karar verme süreçleriyle ne kadar çatıştığınızı tanımlayacaktır.

Bence bunu bütünün bir parçası olarak tartmanız gerekiyor. İlk işlerimden birinin bana nesne odaklı C ++ yaptıklarını söyleyen bir gruptaki bir pozisyon olduğunu hatırlıyorum - ki bu okulda birkaç yıl yaptığım şeydi.

Öz değerlendirmeleri yanlıştı - biraz tıknaz C yapıyorlardı. Doğada hala işlevsel olarak tasarlanmıştı ve kendime printf ve getf ve daha önce öğrenmediğim diğer C mekanizmalarını öğretmek için kendime bir C kitabı almak zorunda kaldım. Takımdaki hiç kimsenin C'nin kodlarını nasıl sevdiğini bile fark etmemesi, bu "C ++ tasarımının" nasıl düştüğüne işaret ediyor. O zamanki amacım OO geliştirmesi yapmaktı, bu yüzden bu nazikti.

Ama sonunda, takıma yapıştığım için mutluyum. Çok akıllı insanlardan oluşan dinamik bir gruptu ve ayaklarımı çok zor problemlerle ıslattım, tüm yaşam döngüsünü çalıştırdım ve sorun alanı (PKI) hakkında öğrendiğim şeyler o zamandan beri kariyerimi körükledi. Ekibin fonksiyonel alanda yaptığı iş harikaydı ve hala bu ürün ve iş deneyimini çok severek düşünüyorum. Daha da iyisi - Bugün hala bu kişilerden bazılarıyla (birkaç şirket sonra) çalışıyorum, hala ilham veriyorlar ve hala iyi işler yapıyoruz.

Bir kodlama dilinin en iyi uygulamalarının mükemmel bir şekilde uygulanmasının iyi bir iş deneyiminin veya iyi bir ekibin yaratılması veya kırılması olduğunu düşünmüyorum - kariyeri besleyen iş bundan çok daha fazla ve ürünün iyi olup olmadığı kalite, takımın iyi çalışma koşulları vardır (Joel Testi gibi) ve takım akıllı ve işleri halleden insanlarla doludur, o zaman uygulamanın mükemmelliği ikincildir. İyi iş, iyi insanlar, iyi çalışma koşulları gibi faktörleri ortadan kaldırın - ve kod tuhaf bir şekilde bir araya getirilsin ya da eklenmesin.

ne kadar temel ya da dogmatik olmalı? Bir programcı ilkelerine ne ölçüde uymalı veya işi yapan bir kod yazmalı mı?

Burada hatırlanması gereken en önemli şey amacın ne ?

Çoğu şirkette, hayattaki amacınız mükemmel kod yazmak değildir. Amacınız kullanıcı için değer sunmaktır. İyi kod yazmak genellikle bakımı kolay, sorun giderme ve geliştirme gibi iyi bir ürün sunmanın en iyi yoludur .

İyi kod, size iyi bir yatırım getirisi sağlayan yere uygulamanız gereken bir araçtır.

Bazı örnekler:

1. API'ları, özellikle iş katmanımın API'sını tasarlamak ve kodlamak için çok zaman harcayacağım. Diğer birçok programcı bunları kullanacak ve uygun şekilde tasarlandıklarında çok zaman ve sorundan tasarruf edecek
2. Sunum katmanımdaki kuralları biraz rahatlatacağım. Orada daha fazla özellik eklemek lehine kod "kusursuzluk" feda etmeye daha meyilli olacak

Sonuç olarak, ilkelere sahip olmanız gerekir, ancak değerden daha fazla zarar getirdiklerinde bu ilkeleri kıracak kadar esnek olmalısınız.

Birkaç yıl e-ticaret perakendecisi için çalıştım. Orada başladığımda, kendi iç uygulamaları için kod MS Access için VB yazılmıştır ve az söylemek korkunçtu. 3 geliştiriciden oluşan bir ekibim vardı ve önümüzdeki birkaç yıl içinde bunu uygun VB.Net uygulamalarıyla değiştirdik.

Ancak işe alım bütçem çok sınırlı olduğu için sadece genç programcıları karşılayabiliyordum. Ve elbette, ürettikleri kod o kadar da büyük değildi. Ancak işe yaradı ve şirket bu uygulamaları her gün para kazanmak için kullandı.

Sonra adamlarla çalışmaya başladım. OOD, veritabanı tasarımı, MVC ve C # eğitim biraz. Ve yıllar geçtikçe işler düzeldi. 4 yıl sonra ayrıldığımda, kod tabanı hala büyük değildi, ama başladığımdan 100 kat daha iyi oldu.

Açıkladığınız gibi bir durum, genellikle mevcut kaynaklarla ilgili olmanızın sonucudur. İdeal bir dünyada yaşamıyoruz. Aynı zamanda, bu aslında bir fark yaratmak için harika bir fırsat.

BTW: Bu uygulamaların bazıları hala kullanımda, yaklaşık 3 yıl öncesine göre değişmeden ve hala para kazanıyorlar.

Bence ilkelerine bağlı kalmak çok önemli. Her zaman verilen kısıtlamalar dahilinde mümkün olan en iyi kodu üretmek için çaba göstermelisiniz. Ancak, ilkeler listenize " asla kötü kod okumak veya değiştirmek zorunda kalmamalısınız" ifadesini eklerseniz , iş bulmakta zorluk çekersiniz. Programcıların% 50'sinin sınıflarının alt yarısında mezun olduğunu unutmayın. Tek kişilik bir ekipte bile, "bugün siz" bir sorunu çözmek için "geçen ay sizden" daha nitelikli. İdeal olmayan kodla çalışabilmek işin sadece bir parçasıdır.

Birçok işveren bunu fark eder, bu yüzden size okumanız için verdikleri kod, en iyilerinden ziyade kod tabanlarındaki en kötü kodu temsil edebilir. Bu bağlamdan net değilse, sormalısınız. Bazen röportaj yaptığım bir meslektaşın, sadece röportaj sorusu olarak kullanmak için kötü yazdığı bir kod sayfası var.

Vakaların% 99'unda, “dogma” dediğiniz gibi davranmalısınız. Dogma, yıllar boyunca tecrübeli kişiler tarafından yapılır ve bir noktada pragmatik görünecek olan şey genellikle değildir. Bu genellikle bu sorunu doğru bir şekilde ele alacak kadar iyi olmamanızdan daha önemlidir.

Ancak dogmayı körü körüne takip etmeyin. Hangi sonuçların insanları bu dogmayı takip etmeye yönlendirdiğini unutmayın. Çünkü takip edilmemesi gereken vakaların küçük bir kısmını bulacaksınız. Her neyse, bu durumlar çok nadir olacak ve böyle bir karar almadan önce her zaman diğer deneyimli programcılar ile tartışmalısınız.

Önemli olduğunda katı olun. Brace stili (veya diğer kodlama kuralları)? Önemli değil. Dükkanın kullandığı ürünü kullanın. Enkapsülasyonu (veya diğer temel programlama ilkelerini) iyi bir sebep olmadan kırmak mı? O kadar önemsiz değil.

Stack Exchange ( para kazanmak için diğer büyük web sitelerinin çoğu gibi) düzeni için tablolar kullanır . Bu, safların kulaklarından duman çıkarıyor mu? Elbette öyle. Ancak pragmatizm her seferinde saflık kazanır. Nakliye ürünü her seferinde mükemmel hale geldiğinde kazanır.

Tüm etki alanı katmanı, kalıcılık katmanı, sunum katmanı, birim test şeyleri, tarihsel açıdan hala nispeten yenidir. Hala bir Client / Server modeli kullanan ve sadece "daha iyi" olduğu için en son mimari stille değiştirilmeyecek tekne yükleri var.