Büyük ve karmaşık bir yazılım ürününü yıllar içinde nasıl bakımını koruyabilirim?


156

Uzun yıllardır yazılım geliştiricisi olarak çalışmaktayım. Ürün geliştirmeye daha fazla geliştirici katıldığı için projelerimin daha karmaşık ve sürdürülemez hale gelmesi benim deneyimim olmuştur.

Belli bir gelişim aşamasındaki yazılımın, özellikle mimariyi tanımlayan ekip üyelerinin artık şirkette çalışmadığı zamanlarda "hackier" ve "hackier" alma eğiliminde olduğu görülüyor.

Bir şeyi değiştirmek zorunda olan bir geliştiricinin mimarinin büyük resmini çekmekte zorlandığını sinir bozucu buluyorum. Bu nedenle, orijinal mimariye karşı çalışacak şekilde sorunları çözme veya değişiklikler yapma eğilimi vardır. Sonuç gittikçe daha karmaşık hale gelen ve anlaşılması zor olan koddur.

Kaynak kodun yıllar içinde gerçekten nasıl korunabileceği konusunda herhangi bir yararlı tavsiye var mı?


9
kitapları tavsiye ederim: Steve McConnell'den 'Yazılım Projesi Hayatta Kalma Rehberi', Steve McConnell'den 'Hızlı Gelişim', Martin Fowler tarafından '
Yeniden Düzenleme

15
... ve Bob Amca tarafından 'Temiz Kod';) (Robert C. Martin)
Gandalf

34
Bu soru, üniversitelerde yıllarca süren yoğun okumaya ve bütün derslere değecek bir şey sormuyor mu?
saat

17
@Eric Yin - Ben yorumlara katılmıyorum. Bana göre onlar bir kod kokusudur ve uzun vadede projeler kaçınılmaz olarak güncelledikleri ve yanıltıcı oldukları için iyiden daha fazla zarar verme eğilimindedirler.
JohnFx

8
@Eric Yin: Kendini belgeleyen kod için çalışıyoruz. Niyet yorumlarını yalnızca anlayışı geliştirdikleri yerlerde kullanın.
Mitch Wheat

Yanıtlar:


138

Kod çürümesinden kaçınmanın tek gerçek yolu iyi kodlamaktır!

İyi kodlama başka bir soru. Tek başına çalışan mükemmel bir programcı olsanız bile yeterince zor. Heterojen bir takımda hala daha zorlaşıyor. Dış kaynaklı (alt) projelerde ... sadece dua edin.

Her zamanki iyi uygulamalar yardımcı olabilir:

  1. Basit tut.
  2. Basit tut. Bu, özellikle mimari, "büyük resim" için geçerlidir. Geliştiriciler büyük resim elde etmek zor anlar yaşıyorsanız, bunlar edilir buna karşı kod olacak. Bu yüzden mimariyi basitleştirin, böylece tüm geliştiricilerin elde etmesi için. Mimarinin basitten az olması gerekiyorsa, geliştiricilerin bu mimariyi anlamak için eğitilmesi gerekir. Eğer içselleştirmiyorlarsa, kod yazmamalılar.
  3. Hedefleyin düşük bağlantı ve yüksek uyum . Ekipteki herkesin bu fikri anladığından emin olun. Gevşek bir şekilde bağlanmış, yapışkan parçalardan oluşan bir projede, parçaların bazıları sürdürülemez bir karışıklık olursa, bu parçayı kolayca çıkarabilir ve yeniden yazabilirsiniz. Bağlantı sıkı ise, daha zor veya neredeyse imkansızdır.
  4. Tutarlı ol. Hangi konularda biraz takip etmek, ancak izleyin lütfen standartları bazı standartlar. Bir takımda herkes aynı standartlara uymalıdır. Öte yandan, standartlara fazla bağlı olmak ve gerisini unutmak kolaydır: lütfen standartların faydalı olmasına rağmen, iyi kodlamanın sadece küçük bir parçası olduklarını anlayın. Çok fazla yapmayın.
  5. Kod incelemeleri , bir ekibin tutarlı bir şekilde çalışması için yararlı olabilir.
  6. Tüm araçların (IDE'ler, derleyiciler, sürüm kontrolü, yapı sistemleri, dokümantasyon jeneratörleri, kütüphaneler, bilgisayarlar , sandalyeler , genel ortam vb.) Geliştiricilerin ikincil meselelerle zamanlarını boşa harcamalarına gerek kalmayacağından emin olun. proje dosyası sürümünün çatışması olarak, Windows güncellemeleri, gürültü ve her ne kadar banal ama rahatsız edici şeyler varsa. Bu gibi ilginç olmayan şeylerle uzun süre tekrar harcamak zorunda kalmak moralinizi düşürür ve bu da en azından kod kalitesini artırmaz. Büyük bir ekipte, asıl işi geliştirici araçlarını korumak olan bir veya daha fazla kişi olabilir.
  7. Teknolojik kararlar alırken, teknolojiyi değiştirmenin ne olacağını düşünün; Hangi kararların geri dönüşü yoktur, hangisi değildir. Geri dönüşü olmayan kararları çok dikkatli bir şekilde değerlendirin. Örneğin, projeyi Java'ya yazmaya karar verirseniz , bu oldukça geri dönüşü olmayan bir karardır. Veri dosyaları için kendinden kaynatılmış bir ikili format kullanmaya karar verirseniz, bu aynı zamanda oldukça geri dönüşü olmayan bir karardır (kod vahşi olduğunda ve bu formatı desteklemeye devam etmeniz gerekir). Ancak GUI'nin renkleri kolayca ayarlanabilir, başlangıçta bırakılan özellikler daha sonra eklenebilir, bu nedenle bu tür konular hakkında daha az stres yaratır.

8
Bunlar harika noktalar. “Basit tut” ile mücadele ettiğimi itiraf etmeliyim. Farklı bağlamlarda farklı insanlar için farklı şeyler ifade ediyor, bu da “basit” değil karmaşık hale geliyor (ama daha sonra işleri karmaşıklaştırmak için doğal bir tendaniyetim var).
Kramii

3
Puanlarınızla, özellikle de "KIS" ile tamamen aynı fikirdeyim. Ancak, gittikçe daha fazla (genç?) Geliştiricinin, en basit bağlamları bile tanımlamak için oldukça karmaşık yapılar kullanma eğiliminde olduğunu gördüm.
chrmue


8
Umm ve "8. Basit tutun".
Dawood ibn Kareem

7
# 6, +10 değerinde.
Jim G.

55

Birim testleri senin arkadaşın . Bunları uygulamak düşük bağlantıya zorlar. Ayrıca, programın "hack" bölümlerinin kolayca tanımlanıp düzeltilebileceği anlamına gelir. Ayrıca, mevcut işlevleri bozmamalarını sağlamak için herhangi bir değişikliğin hızlı bir şekilde test edilebileceği anlamına gelir. Bu, geliştiricilerini, bir şeyleri kırmaktan korktuğu için kodu çoğaltmak yerine mevcut yöntemleri değiştirmeye teşvik etmelidir.

Birim testleri ayrıca, her bir parçanın ne yapması gerektiğini açıklayan, kodunuz için ekstra bir belge parçası olarak da çalışır. Kapsamlı ünite testleri ile, programcılarınızın değişiklik yapmak ve mevcut sınıfları / yöntemleri kullanmak için programınızın tüm mimarisini bilmeleri gerekmez.

Güzel bir yan etki olarak, birim testleri de böcek sayınızı azaltacağını umar.


3
Çok önemli nokta. Eski bir sistemi devraldım, birçok sınıf, birçok kod satırı, dokümantasyon yok, birim testi yok. Tüm kod düzeltmeleri ve geliştirmeleri için titizlikle birim testleri oluşturduktan sonra, sistem tasarımı daha temiz ve daha sürdürülebilir bir duruma dönüştü. Ve önemli çekirdek parçalarını (birim testlerin kapsamına girerek) yeniden yazma cesaretine sahibiz.
Sam Goldberg

40

Buradaki herkes kod çürümesinden hızlıca söz ediyor ve bunu tamamen anlıyorum ve katılıyorum, ancak buradaki daha büyük resmi ve daha büyük sorunu hala özlüyor. Kod çürümesi sadece gerçekleşmez. Ayrıca, iyi olan birim testlerinden bahsedilir, ancak sorunu gerçekten ele almazlar. Biri iyi bir birim test kapsamına ve nispeten hatasız kodlara sahip olabilir, ancak yine de çürümüş kod ve tasarıma sahip olabilir.

Bir projede çalışan geliştiricinin bir özelliği uygulamada zorluk çektiğini ve genel mimarinin daha büyük resmini özlediğini ve bu nedenle sistemin içine girmediğini belirtti. Tasarımı uygulamak ve etkilemek için teknik liderlik nerede? Bu süreçte kod incelemeleri nerede?

Aslında kod çürüklüğü çekmiyorsun, ama takım çürüklüğü çekiyorsun . Gerçek şu ki, yazılımın asıl yaratıcılarının artık takımda olmaması önemli değil. Mevcut ekibin teknik liderliği, altta yatan tasarımı tam olarak ve gerçekten anlıyorsa ve teknik lider olma rolünde herhangi bir yararsa, bu sorun olmazdı.


Çok iyi nokta, boğa gözüne çarptın! Söylemek üzücü, ama tam olarak ne oluyor burada. Teknoloji lideri olmadan bir şeyleri değiştirmek imkansız gibi görünüyor ...
chrmue

4
@chrmue Sadece işler böyle yürüyor sanırım, ama bıkmaya başladım. Birçok yönden, etrafımdaki her şeyin ne kadar yanlış göründüğünün farkında değildim. Kariyer ortası krizi erken atıyor gibiyim. Ama başıboş dolaşıyorum ... yardım etmekten mutluluk duyuyorum.
maple_shaft

1
@Murph Bakım aşamasında neden her şeyi bilen bir ekibin liderine sahip olmamalısınız? Her patron ne olursa olsun bir takım liderinden daha az bir şey beklemiyordum ve takım lideriyken kendimden daha az bir şey beklemiyordum.
maple_shaft

1
@maple_shaft çünkü a) Bu projeye adanmış bir takım liderinin olduğunu tahmin etmiyorum ve bu ilk gereksinimin az çok olması ve b) Tasarım ve uygulamayı (bunların hepsini) anlamanız gerektiğini düşünüyorum. zor. Bir yandan hepimiz projelerimizle ilgili tüm bilgimizden tek bir yazı tipi olmamamız gerektiğini ve yine de burada bir tane olması gerektiğini söylüyoruz. Bu ekleme değil mi?
Murph

2
@maple_shaft muhtemelen huysuz eski bir programcı olmam (-: Fakat mevcut bir kod tabanında derin takip edilmesi gereken ve genellikle kodlayıcıya ve öncülüğe yabancı olabilecek bir uygulama şeklidir) ) gerçek dünya nedenlerinden.
Murph

18

Yapabileceğimiz birkaç şey var:

Mimari için bir kişiye genel sorumluluk verin. Bu kişiyi seçerken, bir mimariyi geliştirme ve sürdürme vizyonuna ve becerisine sahip olduklarından ve diğer geliştiricilerin mimariyi izlemelerine yardımcı olacak etki ve yetkiye sahip olduklarından emin olun. Bu kişi, yönetim tarafından güvenilen ve meslektaşları tarafından saygı duyulan deneyimli bir geliştirici olmalıdır.

Tüm geliştiricilerin mimariye sahip olduğu bir kültür oluşturun. Tüm geliştiricilerin mimari bütünlüğü geliştirme ve sürdürme sürecinde yer almaları gerekir.

Mimari kararların kolayca iletilebileceği bir ortam geliştirin. İnsanları tasarım ve mimarlık hakkında konuşmaya teşvik edin - yalnızca mevcut proje bağlamında değil, aynı zamanda genel olarak da.

En iyi kodlama uygulamaları mimarinin koddan daha kolay görülmesini sağlar - yeniden yapılandırıcıya zaman ayırın, kodu yorumlayın, birim testleri geliştirin, vb. kendi standartlarınızı geliştirmek ve takip etmek için zaman ayırmak.

Gerekli tüm belgelerin açık, öz, güncel ve erişilebilir olduğundan emin olun. Hem yüksek hem de düşük seviye mimari şemalarını herkese açık yapın (duvara sabitlemek yardımcı olabilir) ve kamuya açık bir şekilde bakım yapılabilir.

Son olarak (doğal bir mükemmeliyetçi olarak) mimari bütünlüğün değerli bir özlem olduğunu kabul etmeliyim, ama birlikte daha iyi çalışabilen ve gerçekten çalışan bir ürün gönderen bir ekip oluşturmak gibi daha önemli şeyler olabileceğimin farkındayım.


1
+1, özellikle "birlikte iyi çalışabilen ve çalışan bir ürün gönderen bir ekip oluşturmak" için.
deworde

1
Bir kişinin mimarlıktan sorumlu kök olması iyi bir fikirdir. Bununla birlikte, eğer bu sorumluluk sıklıkla kullanılırsa bir "takım kokusu" yaşarsınız: Ekip, cevapları sağlamak için bir kişiye güvenmek yerine, doğal olarak ortak sonuçlara varmalıdır. Neden? Projenin toplam bilgisi her zaman paylaşılır, bir kişiye sabitlenmesi sonuçta daha büyük sorunlara yol açar: Sadece görüşüne memnun, takımın geri kalanının kanatlarını etkin bir şekilde keser. Bunun yerine en iyi insanları işe alın ve birlikte çalışmasına izin verin.
casper

1
@ casper: Kesinlikle. Aklımdakileri benden daha iyi ifade ediyorsun.
Kramii

18

Bu konuda gitmeme yol açan bu kök kökünden koparmak:

Açıklamam Microsoft / .NET'ten gelen terimleri kullanacak, ancak herhangi bir platform / araç kutusuna uygulanabilecek:

  1. Temel olarak her şey için adlandırma, kodlama, checkin, hata akışı, işlem akışı standartlarını kullanın.
  2. Standartlara uymayan takım üyelerine elveda demekten korkmayın. Bazı geliştiriciler tanımlanmış standartlar dahilinde çalışamazlar ve kod tabanını temiz tutmak için savaş alanında 5. sütun düşmanı olacaklar
  3. Düşük vasıflı ekip üyelerini test etmek için uzun süre tahsis etmekten korkmayın.
  4. Çürüyen kodda kontrol etmekten kaçınmak için cephanenizdeki her aracı kullanın: bu, özel dosyaları ve ayrıca derleme dosyalarını, proje dosyalarını, dizin yapısını vb. Test eden önceden yazılmış birim testlerini içerir.
  5. Yaklaşık 5-8 kişilik bir ekipte, en iyi adamınızın neredeyse sürekli olarak refactoring yapmasını sağlayın - diğerlerinin geride bıraktığı pisliği temizleyin. Alanında en iyi uzmanları bulsanız bile, yine de bir karmaşa yaşayacaksınız - bu kaçınılmazdır, ancak sürekli yeniden yapılanma ile sınırlandırılabilir.
  6. Ünite testlerini yaz ve bakımlarını yap - projeyi temiz tutmak için ünite testlerine bağımlı DEĞİLDİR, yapmazlar.
  7. Her şeyi tartışın. Takımdaki şeyleri tartışmak için saat harcamaktan korkmayın. Bu, bilgiyi yayacak ve kötü kodun temel nedenlerinden birini kaldıracak: teknolojiler, hedefler, standartlar, vb.
  8. Be çok kod yazmak danışmanlarla dikkatli: Onların kodu, neredeyse tanım gereği, gerçek boktan şeyler olacaktır.
  9. Tercihen kontrol etmeden önce proses adımı olarak gözden geçirin. Geri alma işlemlerinden korkmayın.
  10. Açma / kapama ilkesini bırakmadan önceki aşamada asla kullanmayın : çürüyen kodun kokmaya bırakılmasına neden olur.
  11. Ne zaman bir sorunla karşılaşılırsa, bir çözümü uygulamadan önce onu en iyi şekilde anlamaya zaman ayırın - çoğu kod çürüklüğü, çözümün uygulanmasından tam olarak anlaşılmayan sorunlara kadar gelir.
  12. Doğru teknolojileri kullanın. Bunlar genellikle setler halinde gelir ve taze olur: Gelecekte desteklendiğiniz bir çerçevenin beta sürümüne bağımlı olmak, desteklenmeyen son derece kararlı, ancak eski çerçevelere bağımlı olmaktan daha iyidir.
  13. En iyi insanları işe alın.
  14. Gerisini bırak - bir kahve dükkanı işletmiyorsun.
  15. Eğer yönetim en iyi mimarlar değilse ve karar alma sürecine müdahale ederse - başka bir iş bulun.

1
Şimdi, C # boş zamanlarında tekrar yazmaya çalışırken, 100'lerce form ve sınıfla kabuslu 12 yaşındaki bir VB6 uygulamasını sürdürmek ve geliştirmek zorunda kalırsanız ne yapardınız?
jfrankcarr

7
# 3 ile aynı fikirde değilim. Test, eğitimsiz olanlar için bir ceza olarak görülmemelidir. Aslında, tüm geliştiriciler tarafından yapılmalı ve kodlama ve tasarım kadar önemli sayılmalıdır! Takımda Bay Eğitimsiz varsa, biraz antrenman için onu takımdan çıkarın !.
NWS

1
"# 3'e katılmıyorum. Test, eğitimsiz olanlar için bir ceza olarak görülmemelidir." - Yazdıklarım olmamalı ve olmamalı, açıklamama izin ver: Test yapmak, henüz yapmadığınız insanlara, kendi kurallarına girmeleri için değişiklik yapma konusunda güven duymalarına izin vermenin iyi bir yoludur. Bulduğum en iyi test cihazları, kodun katkısı olmak isteyenler ve kodlarını inceleyerek, programı çalıştırarak yetkinliklerini kanıtlayanlar ve çalışma süresindeki bulgularını çalışma kodları ile kaynak kodla ilişkilendirebildiklerini gösteriyor. Bu bir ceza değil - eğitimi.
casper,

1
"# 10 ile aynı fikirde olma - bu doğru şekilde yapıldığında kod kalitesine yardımcı olur" Bu, çalışma deneyimimde kesinlikle yanlıştır: Kilitlenmiş kod yeniden etkinleştirilemez, bu da kilidi açılıncaya kadar geçerli durumda kalacağı anlamına gelir. Bu durumun bir aşamada çalıştığı doğrulanabilir, ancak daha sonraki bir aşamada bu doğrulama yanlış bir pozitif: Son sistem testinden önceki aşamaya kadar yeniden düzenleme için tüm kodlar açık bırakılmalıdır.
casper,

3
@ casper: IMHO, Açık / kapalı prensibi “kaynağı değiştiremezsiniz” olarak anlaşılmamalı, “kodunu dondurulacak şekilde tasarla” olarak anlaşılmamalıdır. Değişikliklerin yapılmasını gerektirmeden kodu gerekli kılmak için gerekli olduğundan emin olun. Sonuç, doğası gereği gevşek bir şekilde bağlanmış ve ortalama koddan daha yüksek yapışmış. Bu ilke, üçüncü şahıslar tarafından kullanılmak üzere bir kütüphane geliştirirken de önemlidir, çünkü içeri giremez ve kodunuzu değiştiremezler, bu yüzden uygun şekilde genişletilebilir olmanız gerekir.
Kevin Cathcart

12

Ünite testleri yazarken yeniden aktive ederek çürümüş kodu temizleyin. (Bu) tasarım borcunu istediğiniz zaman dokunduğunuz tüm kodlardan öde:

  • Yeni bir özellik geliştirin
  • Bir sorunu düzelt

İlk deneme geliştirme döngünüzü büyük ölçüde hızlandırın:

  • Kod modüllerini bir komut dosyası diline dönüştürmek için yeniden düzenleme
  • Hızlı, bulut tabanlı test makineleri kullanın

Düşük kuplaj (dahili olarak birleşik birimlerden) kullanmak için refactor kodu:

  • Daha basit, (daha fazla) fonksiyon (rutin)
  • Modüller
  • Nesneler (ve sınıflar veya prototipler)
  • Saf fonksiyonlar (yan etki olmadan)
  • Devralma tercihini devralma
  • Katmanlar (API'lerle)
  • Birlikte çalışabilen küçük, tek amaçlı programların koleksiyonları

Organik büyüme iyidir; büyük ön tasarım kötüdür.

Mevcut tasarım hakkında bilgili bir lider var. Değilse, bilgili olana kadar projenin kodunu okuyun.

Refactoring kitaplarını okuyun.


1
+1 İyi ilk cevap, bize kendinizi tanıtmak için mükemmel bir yol!
yannis

11

Basit cevap: yapamazsın .

Bu yüzden küçük ve basit bir yazılım yazmayı hedeflemelisiniz . Kolay değil.

Bu, mümkün olduğu kadar basit ve özlü bir şekilde tanımlamak için görünüşte karmaşık probleminiz hakkında yeterince uzun süre düşünürseniz mümkündür.

Gerçekten büyük ve karmaşık sorunların çözümü genellikle küçük ve basit modüller üzerine inşa edilerek çözülebilir.

Başka bir deyişle, başkalarının da belirttiği gibi, basitlik ve gevşek eşleşme anahtar bileşenlerdir.

Eğer bu mümkün değilse veya mümkün değilse, muhtemelen araştırma yapıyorsunuzdur (bilinen basit bir çözümü olmayan veya hiç bilinen bir çözümü olmayan karmaşık problemler). Araştırmanın doğrudan sürdürülebilir ürünler üretmesini beklemeyin, bu bunun için değildir.


9

1999'dan beri sürekli gelişimde olan bir ürün için kod bazında çalışıyorum, böylece şu ana kadar karmaşık olduğunu hayal edebiliyorum. Bizim kod temeli hackiness en büyük kaynağı biz limana bunu yaşadım defalarca dan ASP klasik için ASP.NET için geri göndermeler gelen ADO'DAN ADO.NET'e, Ajax UI kütüphaneleri, kodlama standartları, vb anahtarlama,

Sonuç olarak, kod tabanını sürdürülebilir kılmak için makul bir iş yaptık. Buna katkıda bulunan başlıca şeyler şunlardır:

1) Sürekli yeniden düzenleme - Anlaşılması zor veya anlaşılması zor bir kod parçasına dokunmanız gerekiyorsa, temizlemek için fazladan zaman ayırmanız ve zamanlamada yer alması beklenir. Birim testleri bunu daha az korkutucu kılar, çünkü gerilemelere karşı daha kolay test edebilirsiniz.

2) Temiz bir geliştirme ortamı sağlayın - Artık kullanılmayan kodu silmek konusunda dikkatli olun ve proje dizininde yedek kopyaları / çalışma kopyalarını / deneme kodunu bırakmayın.

3) Projenin ömrü için tutarlı kodlama standartları - Kabul edelim, kodlama standartları konusundaki görüşlerimiz zaman içinde değişiyor. Geri dönüp yeni standarda uymak için tüm kodları yeniden düzenlemek için zamanınız yoksa, bir projenin ömrü boyunca başladığınız kodlama standardına bağlı kalmanızı öneririm. Şu anda Macar gösterimini aşmış olmanız harika , ancak bu dersi yeni projelere uygulayın ve yalnızca bu yeni projenin akışını değiştirmeyin.


8

Soruyu proje yönetimi ile etiketlediğinizden beri bazı kod dışı noktalar eklemeye çalıştım :)

  • Ciro planı - tüm geliştirme ekibinin bakım aşamasına geldiğinde kaybolacağını varsayalım - tuzlarının hiçbir geliştiricisi, sistemini sonsuza dek sürdürmekle sıkışıp kalmak istemez. Geçiş materyallerini hazırladığınızda vaktiniz olduğu andan itibaren.

  • Tutarlılık / tekdüzelik yeterince vurgulanamaz. Bu, 'yalnız başına gitme' kültürünü teşvik etmeyecek ve yeni geliştiricileri şüpheli olup olmadıklarını sormaya teşvik edecektir.

  • Yaygın tutun - kullanılan teknolojiler, tasarım kalıpları ve standartlar - çünkü ekibe yeni bir geliştirici (herhangi bir seviyede) hızla kalkma ve koşma şansını artırır.

  • Belgeler - özellikle mimarlık - neden kararlar alındı ​​ve kodlama standartları. Ayrıca, referansları / notları / yol haritalarını işletme alanını belgelemek üzere tutun - kurumsal işletme için etki alanı deneyimi olmayan bir geliştiriciye ne yaptıklarını açıklamalarının ne kadar zor olduğunu görünce şaşıracaksınız.

  • Kuralları açıkça belirtin - yalnızca mevcut geliştirme ekibiniz için değil, gelecekteki bakım geliştiricileri hakkında düşünün. Bu, ilgili tasarıma köprü koymak ve her sayfada standart belgeleri kodlamak anlamına gelirse, öyle olsun.

  • Mimarisi ve özellikle kod katmanları net bir şekilde çizilmediği ve ayrılmış olduğundan emin olunuz - yeni teknolojiler, örneğin, bir ile bir Web Forms arayüzünün yerini, gelip olarak bu potansiyel kod katmanlarının değiştirilmesi için izin verecektir HTML5 jQuery UI hangi may vb uzun ömürlü bir yıl ya da öylesine satın almak.


7

Yüksek derecede maide edilebilir kodun bir özelliği fonksiyon saflığıdır .

Saflık, fonksiyonların aynı argümanlar için aynı sonucu vermesi gerektiği anlamına gelir. Yani, diğer fonksiyonların yan etkilerine bağlı olmamalıdırlar. Ek olarak, yan etkileri olmamaları da yararlıdır.

Bu özellik, bağlama / uyum özelliklerinden daha kolay tanınır. Bunu başarmak için yolundan çıkmak zorunda değilsin ve ben şahsen daha değerli olduğunu düşünüyorum.

İşleviniz saf olduğunda, türü kendi başına çok iyi bir belgedir. Ek olarak, argüman / geri dönüş değeri açısından dokümantasyon yazmak ve okumak, bazı genel durumlardan (muhtemelen O_O diğer konu başlıkları tarafından erişilebilir) bahsetmekten çok daha kolaydır.

Sürdürülebilirliği sağlamak için yoğun bir şekilde kullanımın bir örneği olarak, sera gazı görebilirsiniz . Büyük yeniden düzenlemelerin yapıldığı ve yeni ana özelliklerin halen tanıtıldığı, yaklaşık 20 yıllık büyük bir proje.

Son olarak, "Basit tut" noktasını çok fazla sevmiyorum. Karmaşık şeyleri modellerken programınızı basit tutamazsınız. Basit bir derleyici yapmayı deneyin; oluşturulan kodunuz yavaş yavaş ölecektir. Elbette, bireysel işlevleri basitleştirebilirsiniz (ve gerekir), ancak bunun sonucunda tüm program basit olmayacaktır.



6

Diğer cevaplara ek olarak, katmanları tavsiye ederim. Çok fazla değil ama farklı kod türlerini ayırmak için yeterli.

Çoğu uygulama için dahili bir API modeli kullanıyoruz. Veritabanına bağlanan dahili bir API var. Sonra bir UI katmanı. Farklı kişiler, uygulamaların diğer bölümlerini bozmadan veya parçalamadan her seviyede çalışabilir.

Başka bir yaklaşım da herkesin comp.risks ve The Daily WTF'i okumasını sağlamaktır , böylece kötü tasarım ve kötü programlamanın sonuçlarını öğrenirler ve The Daily WTF'de yayınlanan kendi kodlarını görmekten korkarlar .


6

Bu cevapların çoğu, en başından beri bile biggish takımlara odaklanmış gibi gözüktüğünden, bir girişim için iki kişilik bir geliştirme ekibinin (tasarımcıyı eklerseniz üç) bir parçası olarak görüşümü göstereceğim.

Açıkçası, basit tasarımlar ve çözümler en iyisidir, ancak tam anlamıyla maaşınızı boynunuza çeken bir adama sahip olduğunuzda, en zarif, sade ve korunabilir çözümü düşünmek için mutlaka zamanınız olmaz. Aklımda, ilk büyük noktam:

Belgelendirme Yorum yapmamak, kod çoğunlukla kendi kendini belgelemek zorundadır, ancak tasarım belgeleri, sınıf hiyerarşileri ve bağımlılıkları, mimari paradigmalar vb. Gibi şeyler. Kod tabanını anlamada yeni veya hatta var olan bir programcıya yardımcı olan herhangi bir şey. Ayrıca, en sonunda "bu sınıfı bu işlevsellik için bir öğeye ekle" gibi açılan garip sözde kütüphaneleri belgelemek yardımcı olabilir, çünkü bu, insanların işlevselliğini yeniden yazmasını da önler.

Ancak, ciddi bir zaman sınırınız olsa bile, akılda tutulması gereken başka bir iyi şeyin olduğunu düşünüyorum:

Hack'lerden ve hızlı düzeltmelerden kaçının . Hızlı düzeltme gerçek düzeltme olmadıkça, temel sorunu bir şeye çözümlemek ve daha sonra düzeltmek her zaman daha iyidir. Kelimenin tam anlamıyla "gelecek 2 dakika içinde çalışmasını sağlayın ya da kovuldunuz" senaryosuna sahip değilseniz, düzeltmeyi şimdi yapmak daha iyi bir fikirdir, çünkü kodu daha sonra düzeltmeyeceksiniz, sahip olduğun bir sonraki göreve geç.

Ve en sevdiğim ipucum daha çok alıntı, kaynağını hatırlayamasam da:

"Ardından gelen kişiyi nerede yaşadığını bilen cinayet hastası bir psikopat sanki kodla"


İşlev ve sınıf yorumlarında, sözdizimi vurgulamayı kullanarak yalnızca kod bölümlerinin işlev ve sınıf konumlarında ayrılmasını sağlasam bile yararlı olacağını her zaman buldum. İşlev koduna çok nadiren yorumlar eklerim, ancak her sınıf ve işlev için /** Gets the available times of a clinic practitioner on a specific date. **/veya gibi bir satır yazarım /** Represents a clinic practitioner. **/.
Nick Bedford,

5

Bahsetmediğim ancak önemli bulduğum bir ilke açık / kapalı prensibidir .

Geliştirilmiş ve test edilmiş kodu değiştirmemelisiniz: böyle bir kod parçası mühürlü. Bunun yerine, mevcut sınıfları alt sınıflar aracılığıyla genişletin veya bunları sarmalayıcılar, dekoratör sınıfları veya uygun bulduğunuz herhangi bir deseni kullanarak kullanın . Ancak çalışma kodunu değiştirmeyin .

Sadece 2 sentim.


Ya çalışma kodunda ifade edilen işletme gereksinimleri değişirse? Zayıf faktörlü fakat teknik olarak 'çalışan' kodlara dokunma, uzun vadede, özellikle de gerekli değişiklikleri yapma zamanı geldiğinde size zarar verebilir.
jinglesthula

jinglesthula: Uzantıya aç, yeni işlevselliği mevcut bir arabirimin yeni bir uygulaması (örn. sınıf) olarak ekleyebileceğiniz anlamına gelir. Tabii ki, zayıf bir şekilde yapılandırılmış kod buna izin vermez: mevcut kodu değiştirmek yerine kodun "değiştirilmesine" izin veren bir arabirim gibi bir soyutlama olmalıdır.
Giorgio

5
  • İzci ol . Kodu daima bulduğunuzdan daha temiz bırakın.

  • Kırık camları tamir edin . Tüm bu yorumlar, sürüm 3.0'da olduğunuzda "sürüm 2.0'da değişiklik yapın".

  • Büyük kesmeler olduğunda, takım olarak daha iyi bir çözüm tasarlayın ve yapın. Hack'i bir takım olarak düzeltemezseniz, sistemi yeterince iyi anlamazsınız. "Bir yetişkinden yardım isteyin." Etrafındaki en yaşlı insanlar bunu daha önce görmüş olabilir. Sistemin bir şemasını çizmeyi veya çıkarmayı deneyin. Etkileşim şemaları gibi özellikle tehlikeli olan kullanım durumlarını çizmeyi veya çıkarmayı deneyin. Bu sorunu çözmez, ama en azından görebiliyorsunuz.

  • Tasarımı belirli bir yöne iten hangi varsayımlar artık doğru değil? Bu karışıklığın arkasına saklanmış küçük bir yeniden ateşleme olabilir.

  • Sistemin nasıl çalıştığını açıklarsanız (sadece bir kullanım durumunda bile) ve bir alt sistemden tekrar tekrar özür dilemeniz gerektiğini fark ederseniz, sorun budur. Davranış, sistemin geri kalanını daha kolay hale getirecektir (ne var ne kadar zor uygulanmış olursa olsun). Yeniden yazılacak klasik alt sistem, çalışma semantiği ve uygulamasıyla diğer tüm alt sistemleri kirleten bir sistemdir. “Oh, değerleri froo alt sistemine beslemeden önce değerleri vermelisiniz, ardından froo'dan çıktı alırken bunları yeniden grozetlemelisiniz. Belki de kullanıcı ve depodan okunduğunda tüm değerlerin kaldırılması gerekir. ve sistemin geri kalanı yanlış mı? İki ya da daha fazla farklı grozifikasyon olduğunda bu daha heyecan verici oluyor.

  • Bir haftayı ekip halinde yaparak uyarıları kaldırarak gerçek sorunların görünmesini sağlayın.

  • Tüm kodu kodlama standardına göre yeniden biçimlendirin.

  • Sürüm kontrol sisteminizin hata izleyicinize bağlı olduğundan emin olun . Bu, gelecekteki değişikliklerin iyi ve hesap verebilir olduğu ve NEDEN çalışabileceği anlamına gelir.

  • Biraz arkeoloji yap. Özgün tasarım belgelerini bulun ve inceleyin. Ofisin köşesindeki o eski PC'de, terkedilmiş ofis alanında ya da hiç kimsenin açmadığı dosya dolabında olabilirler.

  • Tasarım belgelerini bir wiki'de yeniden yayınlayın. Bu bilgiyi kurumsallaştırmaya yardımcı olur.

  • Sürümler ve derlemeler için kontrol listesi benzeri prosedürler yazın. Bu, insanların düşünmesini engeller, böylece problem çözmeye konsantre olabilirler. Mümkün olan her yerde yapıları otomatikleştirin.

  • Sürekli entegrasyon deneyin . Başarısız bir yapı ne kadar erken olursa, proje raylardan ne kadar az zaman harcayabilir?

  • Takım lideriniz bunları yapmazsa, bu şirket için kötüdür.

  • Tüm yeni kodların ölçülen kapsama alanıyla uygun birim testleri aldığından emin olun. Yani sorun daha da kötüye gidemez.

  • Birim testine tabi olmayan eski bitlerin bir kısmını test etmeye çalışın. Bu, değişim korkusunu azaltmaya yardımcı olur.

  • Yapabiliyorsanız entegrasyon ve regresyon testinizi otomatikleştirin. En azından bir kontrol listesi var. Pilotlar akıllı ve çok para alıyorlar ve kontrol listeleri kullanıyorlar. Aynı zamanda nadiren berbat ediyorlar.


4

Oku ve sonra Steve McConnell tarafından Code Complete'i tekrar oku . İlk proje tasarımından tek bir kod satırına ve aralarındaki her şeye kadar iyi bir yazılım yazma inciline benziyor. En çok sevdiğim şey, onlarca yıllık sağlam verilerle desteklenmesi; bu sadece bir sonraki en iyi kodlama tarzı değil.


3

Buna "Winchester Gizem Evi Etkisi" demeye geldim. Ev gibi, yeterince basit bir şekilde başladı, ancak yıllar içinde birçok çalışan, artık kimsenin anlayamadığı bir plan yapmadan çok tuhaf özellikler ekledi. Bu merdiven neden hiçbir yere çıkmıyor ve bu kapı neden sadece bir yönden açılıyor? Kim bilir?

Bu etkiyi sınırlamanın yolu, genişleme ile baş edebilecek kadar esnek olan iyi bir tasarımla başlamaktır. Bu konuda zaten birkaç öneride bulunuldu.

Ancak, genellikle hasarın yapıldığı bir işi alırsınız ve pahalı ve potansiyel olarak riskli bir yeniden tasarlama ve yeniden yazma yapmadan iyi bir tasarım için çok geç. Bu durumlarda, bir dereceye kadar kucaklarken, kaosu sınırlandırmanın yollarını bulmaya çalışmak en iyisidir. Tasarım hassasiyetinizi, her şeyin çok büyük, çirkin, tek bir 'yönetici' sınıfından geçmesi ya da veri erişim katmanının kullanıcı arayüzüne sıkı sıkıya bağlı olması, ancak bununla baş etmeyi öğrenmesi rahatsız edici olabilir. Bu çerçevede savunmacı bir şekilde kodlayın ve geçmişteki programcıların hayaletleri göründüğünde beklenmeyenleri beklemeye çalışın.


2

Kod yeniden düzenleme ve ünite testi tamamen iyi. Ancak bu uzun süredir devam eden proje hack'lerle uğraştığı için, yönetim çürüklüğü temizlemek için ayağını indirmiyor demektir. Ekip, saldırganları tanıtmakla yükümlüdür, çünkü birileri insanları eğitmek ve sorunu / talebi analiz etmek için yeterli kaynak tahsis etmemektedir.

Uzun süren bir projenin sürdürülmesi, bireysel bir geliştirici olarak proje yöneticisinin sorumluluğundadır.

İnsanlar korsanlık yapmazlar çünkü hoşlarına gider; şartlara göre zorlanırlar.


Şartlara göre zorla mı? İnsanlar hack'leri tanıtıyorlar çünkü (a) daha iyi bilmiyorlar => koçluk gerekiyor, (b) daha büyük resmi göremiyorlar => gerekli iletişim, dokümantasyon ve disiplin, (c) daha akıllı olduklarını düşünüyorlar >> en büyüğü bu aşılması gereken engel (d) şartlara göre zorla => hızlı düzeltmeler zaman baskısı altındayken sorun yok, ancak birilerinin sorumluluğu üstlenmesi ve sonradan kodu temizlemesi gerekiyor. Başka herhangi bir "durum" basitçe BS'dir . Bu kuralın istisnaları var, ancak en çok istisnalar "tembel" i heceledi.
JensG

2

Sadece teknik olmayan bir mesele ve (belki) pragmatik bir yaklaşım yerleştirmek istiyorum.

Yöneticiniz teknik kaliteyi önemsemiyorsa (yönetilebilir kod, basit mimari, güvenilir altyapı vb.), Projeyi geliştirmek zorlaşır. Bu durumda, söz konusu müdürü eğitmek ve sürdürülebilirlik ve teknik borcu ele alma çabalarına "yatırım" yapmaya ikna etmek gerekir .

Bu kitaplarda bulunan kod kalitesi ile düşlüyorsanız, bunun için endişelenen bir patrona da ihtiyacınız var.

Ya da sadece bir "Frankenstein projesi" evcilleştirmek istiyorsanız bunlar benim ipuçlarım:

  • Organize edin ve basitleştirin
  • Kısaltılmış fonksiyonlar
  • Verimlilik üzerine okunabilirliği önceliklendir (elbette kabul edilebilir olduğunda ve bazı verimlilik kazanımlarının korunamayacak kadar berbat olduğu)

Tecrübelerime göre, programlama ortaya çıkmaktansa entropiktir (en azından popüler zorunlu yapılandırılmış paradigmada). İnsanlar “sadece işe” kod yazdıklarında, eğilimleri örgütlerini kaybetmektir. Şimdi kodun düzenlenmesi zaman gerektirir, bazen sadece çalışmasını sağlamaktan çok daha fazlası.

Özellik uygulaması ve hata düzeltmeleri dışında kod temizliği için zaman ayırın.


"... proje mahkumdur" - benim tecrübeme göre, bu mutlaka böyle değil. Alternatif sözü yöneticisini eğitmek ve çabalar içine "yatırım" için ikna etmektir maintainability ve adresleme teknik-borç
sivrisinek

Üzgünüm, yöneticinin teknik borçla ilgili tüm önerileri görmezden geldiğinde zaten bir deneyim yaşadığım için kendimi yazamadım. Ama bence haklısın: o projeden vazgeçtiğimden yaklaşık bir yıl sonra yönetici, onları yönetememesi nedeniyle teknoloji ekibi üzerindeki tüm yetkisini kaybetti.
Eric.Void

1

Sayısız cevabın hiçbirinin bariz olmadığını vurguladığına şaşırdım: yazılımı sayısız küçük, bağımsız kütüphaneden oluşur. Birçok küçük kütüphaneyle büyük ve karmaşık bir yazılım oluşturabilirsiniz. Gereksinimler değişirse, kod kodunun tamamını atmanız veya büyük bir korna kod kodunun şu anda yaptıklarından başka bir şey yapması için nasıl değiştirileceğini araştırmanız gerekmez. Gereksinimler değiştikten sonra bu kitaplıklardan hangisinin hala geçerli olduğuna ve yeni işlevlere sahip olmak için bunları nasıl birleştireceğinize siz karar verin.

Kütüphanelerde kullanımını kolaylaştıran kütüphanelerde hangi programlama tekniklerini kullanın. Örneğin, nesne yönelimli olmayan herhangi bir dili destekleyen işlev işaretçilerinin aslında nesne yönelimli programlamayı (OOP) desteklediğini unutmayın. Yani, örneğin C, OOP yapabilirsiniz.

Bu küçük, bağımsız kütüphaneleri birçok proje arasında paylaşmayı bile düşünebilirsiniz (git alt modülleri arkadaşınızdır).

Söylemeye gerek yok, her küçük, bağımsız kütüphane ünite testinden geçirilmelidir. Belirli bir kütüphane ünite test edilebilir değilse, yanlış bir şey yapıyorsunuzdur.

C veya C ++ kullanıyorsanız ve birçok küçük .so dosyasına sahip olma fikrinden hoşlanmıyorsanız, tüm kitaplıkları birlikte daha büyük bir .so dosyasına bağlayabilir veya alternatif olarak statik bağlama yapabilirsiniz. Aynı şey Java için de geçerlidir.


Bu benim açımdan biraz teorik görünüyor. Elbette sorumu belirttiğim projeler birden çok kütüphaneden ve modülden inşa edildi. Son 26 yıllık yazılım geliştirmedeki deneyimim, projenin eski organizasyonu ne kadar
eskiyse

0

Basit: Korunabilir sayıda hareketli parça alana kadar kodunuzun çoğunun bakım maliyetlerini sıfıra indirin . Hiç bir zaman değiştirilmemesi gereken kod bakım maliyeti gerektirmez Birçok küçük ve telaşlı yeniden düzenleme iadesinde maliyeti azaltmaya çalışmadan, kodun gerçekten sıfır bakım maliyetine sahip olmasını hedefliyorum . Hemen sıfıra mal olmasını sağlayın .

Tamam, kuşkusuz, göründüğünden çok daha zor. Ama başlamak zor değil. Eğer arayüz tasarımı bir karışıklıksa, kod tabanının bir kısmını alabilir, test edebilir, üzerinde güzel bir arayüz oluşturabilir ve kodbazın güvenilir, istikrarlı (değişme nedenlerinden yoksun) kısımlarını aynı anda geliştirmeye başlayabilirsiniz. güvenilmez ve dengesiz parçaları küçültmek. Her zaman güvenilmez ve değişime yatkın olduğu düşünüldüğü için, genellikle kabus gibi hissetmek isteyen bir kabus gibi görünen, değiştirilmesi gereken hareketli parçaları değiştirmeyen parçalardan uzak tutunuz.

Aslında kod üssünüzün organizasyonunu "istikrarlı" ve "kararsız" parçalara ayırmanın yollarını öneririm; kararlı kısımlar yeniden inşa etmek ve değiştirmek için büyük bir PITA'ydı (ki bu iyi bir şey, çünkü gerekmemeliydiler) gerçekten "kararlı" bölüme aitlerse değiştirilip yeniden oluşturulacaktır).

Sürdürülebilirliği zorlaştıran bir kod tabanının boyutu değil. Korunması gereken kod tabanının boyutu. İşletim sisteminin API'sini kullandığımda, milyonlarca kod satırına bağlıyım. Ancak bu, işletim sisteminin kaynak kodunu korumak zorunda olmadığım için ürünümün bakım maliyetlerine katkıda bulunmuyor. Sadece kodu kullanıyorum ve çalışıyor. Yalnızca kullandığım ve sürdürmek zorunda kalmayacağım kod, benim tarafımda hiçbir bakım maliyeti gerektirmez.

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.