Eğer akıcı bir kodlayıcı iyi uygulamaları göz ardı ederse, akıcılığı ona karşı çalışmıyor mu? [kapalı]

Oldukça büyük ve buggy bir uygulama üzerinde çalışıyorum - ve yazılma şekli nedeniyle (size ayrıntıları ayıracağım, ancak aklınıza gelebilecek çoğu alanda kuralları ihlal ediyor), büyük bir yeniden düzenleme yapmadan bunu geliştirmek imkansız.

Uygulamanın önemli bir kısmı stajyerler, n00b'ler vb. ama aynı zamanda Usta Geliştirici rütbesinde bir programcı vardı ve tüm alçakgönüllülükle geride bıraktığı kod da şüpheli ama belki de farklı bir şekilde.

Verdiği gibi, kodu işi çoğu zaman yapıyor - ama genellikle şifreli, tekerleği yeniden icat ediyor (örneğin, oldukça sıradan bir SQL db yedeklemesini gerçekleştiren büyük bir özel yöntem) vb. Temel olarak, gereksiz karışıklık artı çok fazla mühendislik

Ve çok yetenekli bir kodlayıcı olmanın (daha geniş bir beceri kümesini gösterdiğini varsayarak, "geliştirici" kelimesini kasten kullanmıyorum), diğer niteliklerin eşlik etmediği takdirde, aslında bir çeşit zehirli olabileceğini düşündürdü.

Bunun doğru olduğunu varsayarsak, aklıma gelen bazı nedenler şunlardır:

• kolaylıkla kod yazıyorsanız, kitaplıklara, önceden var olan işlevselliklere vb. olmadan kendi çözümlerinizi anında ortaya çıkarmak için daha hızlı (veya aslında kısa vadede) hissedersiniz.
• karmaşık bir programın zihinsel imajını kolayca koruyacak kadar deneyimli ise, onu modüllere, katmanlara vb. bölmeye daha az eğilimlidir.

Demek istediğim, akıcı bir kodlayıcı kötü bir geliştirici olursa, akıcılıkları sadece ikincisini telafi etmekle kalmaz, bunun yerine aslında daha fazla zarar verir.

Bunun hakkında ne düşünüyorsun? Doğru mu (eğer varsa ne ölçüde)?

kolaylıkla kod yazıyorsanız, kitaplıklara, önceden var olan işlevselliklere vb. olmadan kendi çözümlerinizi anında ortaya çıkarmak için daha hızlı (veya aslında kısa vadede) hissedersiniz.

Evet. Ben o adamdım. Ve bunun korkunç bir şey olduğunu öğrendim.

Her şey senin için çok iyi, yeni bir şey öğrenmek zorunda değilsin.

Peki ekibinizin geri kalanı ne olacak? Size çok güveniyorlar. Yazdığınız nesne-ilişkisel eşleyici hakkında yardım almak için "Clive's Quicky ORM" için Google'ı kullanamazlar.

Ve sonra yeni birini işe almaları gereken gün geliyor ve Clive's Quicky ORM'de tecrübesi olan insanları arayamıyorlar.

Sonunda ayrıldığınız gün gelir ve birisi ORM'nizde bir hata fark eder. Ve orada olacak, çünkü ürününüzü test eden ve tamir eden bir insan topluluğunuz yok.

Evet, Hazırda Beklet'i öğrenmek hafif bir şey yazmaktan daha fazla zaman almış olabilir. Ancak bunu yapmanın yararı, görmezden gelinemeyecek kadar büyük IMHO.

• kolaylıkla kod yazıyorsanız, kitaplıklara, önceden var olan işlevselliklere vb. Gerek kalmadan kendi çözümlerinizi anında ortaya çıkarmak için daha hızlı hissettirir (veya aslında kısa vadede).

Dil konusunda yetenekli ama araçlar değil. Bu gerçekten güçlü bir kodlayıcı bile değil. Sadece bir beceriyi (dil bilgisi) parlatıyor ve diğerinin paslanmasına (kütüphane bilgisi) izin veriyor. Diğer yol ise aynı derecede kötü, ama fark edilmesi daha kolay.

• karmaşık bir programın zihinsel imajını kolayca koruyacak kadar deneyimli ise, onu modüllere, katmanlara vb. Bölmeye daha az eğilimlidir.

Bu sadece bir beceri olarak gizlenen tembellik. Aktif olarak üzerinde çalıştığınız şeyi kafanızda tutmak fazla çaba gerektirmez. Uygun dikişleri bulmak ve kodu bunlara bölmek beceri gerektirir. Her şeyi bir noktada bırakmanın daha hızlı veya daha iyi olduğunu söyleyen kodlayıcılar, hangi öğelerin ayrılacağını göremez.

Bunun "Klavyeniz tıklamıyorsa, çalışmıyorsunuz" ortamında çalıştığı için olmadığından emin olun. Hepimiz kodlara bakıyoruz ve ne düşündüğümüzü merak ediyoruz. Ayrıca, bu mağaza kodlarını yeniden düzenleme pratiğinde mi? Bu kendisine verilmemiş bir lüks olabilirdi.

Bununla birlikte, ilk fikrimizden (oturup çekip çıkarabileceğiniz) kopup biraz daha planlama, araştırma, düşünme yapmamız gerekiyor. Her küçük problemi ortadan kaldırmanın cazibesi caziptir ve tüm proje bu uygulama ile doludur. Kimse insanlara "kırılmayan" şeyleri düzeltmeleri için para ödemek istemiyor, o zaman neden yeniden düzenleyici.

Düzenleme: Cevapları bilenleri cezalandırmadığımızdan emin olalım. Akıcı ve hızlı iyi kod yazanlar var. Anahtar her soruna bu şekilde yaklaşmak değildir.

100%.

Buna bakmanın alaycı yolu, bu tür kodlayıcıların aslında geliştiricilerin çoğunu işte tutması, binlerce geliştirici saatini kararlı, esnek, güvenli bir yolun yarısına batırmayacak kadar temel olan hataları düzeltmesidir. , modüler veya [favori yazılım mülkünüz] sistemi. Bu sistemler o kadar çok kendine güveniyor ki, zaten mevcut olan özelliklerin% 95'i ve arkasındaki canlı bir toplulukla bile başka bir şeye göç etme düşüncesi, saçma ve kovulma gerekçeleri arasında bir yer olarak kabul ediliyor.

Kısacası, akıcı kodlayıcılar bir rakip grubundan daha fazla hasar verebilir, ancak fiyat genellikle uzun yıllar boyunca ödenir. Ve genellikle basitçe işlerini yapıyorlardı (başka biri tarafından tanımlandığı gibi).

Bir geliştirici veya kodlayıcı olup olmadığınızı nasıl anlarsınız? Sanırım bu imkansız, ama kalitenizi düşürmeden kodunuzu basitleştirmenin bir yolunu her bulduğunuzda, aydınlanmaya doğru başka bir adım attınız.

Açıkladığınız problem temelde NIH ("burada icat edilmedi") - başka belirtiler var mı?

Bazen NIH, özellikle bir veya iki kişiye tecrit edilmişse, bir grup tartışmasında ele alınabilir ("Joe, standart kütüphaneleri kullanarak SQL yedekleme yapma konusunda biraz deneyime sahiptir - ne düşünüyorsunuz, Joe?"). Bu, doğrudan kişiye gidip "Hey! Standart kütüphaneyi kullanın, kukla!" :)

Hem durumunuzda hem de benzer durumlara neden olmuş olmanız, hayal kırıklığınızı anlıyorum, ancak bence sorunuzun cevabı düz bir "hayır". Akıcılık, bir programcının sürdürülebilir kod üreteceğini garanti etmez. Genellikle kuruluşlar, programcıları saçma bütçe ve zaman kısıtlamaları nedeniyle kötü tasarlanmış ve uygulanmış yazılımlar sunmaya zorlar. Akıcı programcının köşeleri kesmesi, yalnızca programcıların müşterilerin önem verdiği bir şey sağlamaya önem vermesi mümkündür. Açıkçası bu pratikte iyi değil, ama ne yazık ki her programcının kariyerinin bir noktasında uğraşması gereken bir gerçek. Akıcı programcının tembel ya da kayıtsız olma ihtimali de vardır. Mükemmel İngilizce konuşabiliyorum, ancak argo kullanmak daha kolay ve daha eğlenceli.

Başkalarının kodunu kullanmak veya kendi argümanınızı yuvarlamak için, işin en iyi şekilde yapılmasına gerçekten neden olduğunu düşünüyorum. Bazen "en iyi", iki hafta içinde altı haftalık bir proje sunmak anlamına gelirse stil ve sürdürülebilirlik gibi şeyleri hesaba katmaz. Bu yüzden yeniden düzenliyor ve rafine ediyoruz. Ayrıca, geliştirici üçüncü taraf kodu açısından neyin mevcut olduğunu bilmeli ve nasıl kullanılacağını bilmeli ve çalışacağına ve düzgün bir şekilde destekleneceğine / sürdürüleceğine güvenmelidir. Bu tür şeyleri kullanan herhangi bir popüler geliştirme paradigması için binlerce isteğe bağlı çerçeve, kitaplık ve API olduğu göz önüne alındığında, sadece kendi başınıza dönmekten daha fazla zaman, enerji ve strese mal olabilir. Ayrıca, üçüncü taraf kodunun tam olarak yapmam gereken şeyi yapmadığı durumlarda da bulabilirim - bu ne zaman '

O teknedeyim (miras akıcı bir şekilde yazılmış kod) ve bir süre akıcı tipteydim.

"Hızlı ve kirli" çözümlerin önündeki en büyük engel, daha sonra bunlara daha fazlasını eklemeniz gerektiğidir. Daha fazla özelliğe ihtiyacınız olduğunda. Yapısı olmadan yapabileceğiniz çok şey var. Bundan sonra kırılır ve yeniden düzenlemek pahalıya mal olur (ancak tatmin edici, ancak gerçekten takdir edilmez).

Temel olarak, istekli bir satış elemanı tarafından satılmaya hazır, potansiyel olarak "uygulanabilir bir çözüm" haline gelebilecek HERHANGİ BİR HACK'a karşı kendinizi korumanız gerekir. Eski "Hazır değil! - Ama işe yarıyor, değil mi?" muamma.