Büyük kod tabanlarına nasıl dalıyorsunuz?

Bilinmeyen bir kod tabanını keşfetmek ve öğrenmek için hangi araçları ve teknikleri kullanıyorsunuz?

Ben gibi araçlarla düşünüyorum grep, ctagsbirim-testleri, fonksiyonel test, sınıf diyagramı jeneratörleri, grafikler çağrı gibi kod ölçümlerini sloccountvb, vb. Deneyimleriniz, kullandığınız veya yazdığınız yardımcılar ve çalıştığınız kod tabanının büyüklüğü ile ilgileniyorum.

Bir kod tabanıyla tanışmanın zaman içinde gerçekleşen bir süreç olduğunu ve tanıdıklığın "kodu özetleyebiliyorum" ila "yeniden boyutlandırabilir ve boyutunun% 30'una küçültebileceğimi" şeklinde bir anlama gelebileceğinin farkındayım. Ama nasıl başlamalı?

Her zaman yaptığım şey şudur:

Editörümün (Visual Studio / Eclipse / Whatever) birden fazla kopyasını açın ve ardından hata ayıklayın ve satır sonlarını kodun içinden geçirin. Kodun akışını bulun, kilit noktaların nerede olduğunu görmek için üst üste yığın ve oradan gidin.

Yöntemden sonra yönteme bakabilirim - ancak bir şeyi tıklatıp sonra kodun neresinde çalıştırıldığını ve devam ettiğini görebilseydim çok hoş olur. Geliştiricinin işlerin nasıl olmasını istediği konusunda bir fikir edeyim.

Bir fili nasıl yersin?

Bir seferde bir ısırık :)

Cidden, önce kodun yazarlarıyla konuşmaya çalışıyorum.

İşi bitirene kadar kesmek zorunda mıyım?

Büyük ölçüde, evet (üzgünüm).

Göz önünde bulundurabileceğiniz yaklaşımlar:

1. İş açısından, kodun ne yapması gerektiğini bulmaya çalışın.
2. Ne kadar kötü olursa olsun, mevcut tüm belgeleri okuyun.
3. Kod hakkında bir şeyler bilen biriyle konuşun .
4. Hata ayıklayıcıdaki kodu adım adım izleyin.
5. Küçük değişiklikler yapın ve neyin kırıldığını görün.
6. Daha açık yapmak için kod üzerinde küçük değişiklikler yapın.

Kodu açıklığa kavuşturmak için yaptığım bazı şeyler:

1. Kodu güzel bir şekilde biçimlendirmek için bir kod hazırlayıcı çalıştırın.
2. Ne yapabileceğini düşündüğümü açıklamak için yorum ekle
3. Değişken adlarını daha net hale getirmek için değiştirin (bir yeniden düzenleme aracı kullanarak)
4. Belirli bir sembolün tüm kullanımlarını vurgulayan bir araç kullanmak
5. Koddaki karışıklığı azaltma - yorumladı kod, anlamsız yorumlar, anlamsız değişken başlatmalar vb.
6. Geçerli kod kurallarını kullanmak için kodu değiştirin (yeniden refactoring araçlarını kullanarak)
7. İşlevselliği anlamlı rutinlere çıkarmaya başlayın
8. Mümkün oldukça testler eklemeye başlayın (çoğu zaman mümkün değildir)
9. Sihirli sayılardan kurtulun
10. Mümkünse çoğaltmayı azaltmak

... ve yapabileceğiniz diğer basit iyileştirmeler.

Yavaş yavaş, her şeyin arkasındaki anlamı netleşmelidir.

Başlamak için yer gelince? Ne biliyorsan başla. Giriş ve çıkışları öneririm. Bunların ne olması gerektiği ve ne için kullanıldığı konusunda sık sık anlaştınız. Uygulamadaki verileri takip edin ve nereye gittiğini ve nasıl değiştiğini görün.

Tüm bunlarla ilgili yaşadığım sorunlardan biri motivasyon - gerçek bir slogan olabilir. Tüm işi bir bilmece gibi düşünmeme ve ne kadar küçük olursa olsun yaptığım ilerlemeyi kutlamama yardımcı oluyor.

Durumun aslında yaygın. Çalışacak kodun olduğu yeni bir işe girmek zorunda olan herkes, onun bazı unsurlarıyla ilgilenecek. Sistem gerçekten kötü bir miras sistemi ise, o zaman tarif ettiğinize çok benzer. Tabii ki, hiçbir zaman geçerli bir dokümantasyon yoktur.

Birincisi, birçok kişi Michael Feathers tarafından Eski Kod ile Etkili Çalışmayı tavsiye etti. Bu gerçekten iyi bir kitap, "Bu sınıfı bir test donanımına sokamıyorum" veya "Uygulamamın yapısı yok" gibi yararlı bölümler var, ancak bazen Tüyler yalnızca çözümden daha fazla sempati sunabilir. Özellikle, kitap ve örnekleri büyük ölçüde kaşlı ayraç dillerine yöneliktir. Budaklı SQL prosedürleri ile çalışıyorsanız, bu kadar yararlı olmayabilir. Sanırım, "Bu kodu değiştirecek kadar iyi anlamıyorum" bölümü sorununuzu konuşuyor. Tüyler burada not almak ve listeleri işaretlemek gibi bariz şeylerden bahseder, ancak kaynak kontrolünüz varsa kullanılmayan kodu silebileceğiniz konusunda iyi bir noktaya gelir. Birçok insan, kod bölümlerini yorumladı.

Daha sonra, önerilen yaklaşımınızın kesinlikle iyi bir adım olduğunu düşünüyorum. İlk önce kodun amacının ne olduğunu yüksek düzeyde anlamanız gerekir.

Sorularınızı yanıtlamanız gerekiyorsa, kesinlikle bir danışman veya takımdaki biriyle çalışın.

Ayrıca, eğer kusurlar ortaya çıkarsa, kodu destekleme fırsatını kullanın (bazen bunun için gönüllü olmanıza gerek kalmasa da ... kusur sizi bulacaktır!). Kullanıcılar yazılımı ne için kullandıklarını ve kusurun onları nasıl etkilediğini açıklayabilir. Yazılımın anlamını anlamaya çalışırken bu genellikle çok yararlı bir bilgi olabilir. Ek olarak, saldırıya niyetli bir hedefe sahip koda girmek bazen "canavar" la karşı karşıya kaldığınızda odaklanmanıza yardımcı olabilir.

Gerçekten büyük bir kaynak dosyam olduğunda aşağıdakileri yapmak isterim:

• Bütün karışıklığı panoya kopyala
• Word'e / textmate'e yapıştırın
• Yazı tipi boyutunu en aza indirin.
• Koddaki kalıplara bakarak aşağı kaydırın

Normal editörünüze döndüğünüzde, kodun ne kadar tanıdık göründüğüne şaşıracaksınız.

O zaman alır

Eski bir kod tabanını anlamaya çalışırken, özellikle de aşina olmadığınız teknolojiler / diller / çerçeveler kullanıyorsanız, fazla aceleci olmayın. Bu sadece biraz zaman alan kaçınılmaz bir öğrenme eğrisi.

Bir yaklaşım, ilgili teknolojilerle ilgili kod ve öğreticiler arasında ileri ve geri gitmektir. Öğreticiyi okudunuz / izliyorsunuz, sonra selefinizin nasıl yaptığını görmek için koda bakın, benzerlikleri ve farklılıkları not alın, not alın ve mevcut geliştiricilere sorular sorun.

"Neden bu kısmı bu şekilde yaptın"

“İnternetteki çoğu insanın bu şekilde yaptığını farkettim ve siz hepiniz başka bir yolla yaptınız. Neden bu?”

“Hepiniz teknoloji Y üzerinden X teknolojisini seçtiniz mi?”

Bu soruların cevapları, projenin tarihini ve tasarım ve uygulama kararlarının arkasındaki mantığı anlamanıza yardımcı olacaktır.

Sonunda, bir şeyler eklemeye / düzeltmeye başlayabileceğiniz konusunda yeterince bilgi sahibi olacaksınız. Her şey kafa karıştırıcı görünüyorsa veya çok fazla "sihir" oluyor gibi görünüyorsa, onu incelemek, sindirmek ve şekillendirmek için yeterince zaman harcamadınız. Diyagramları oluşturmak (sekans diyagramları, proses akış diyagramları, vb.), Karmaşık bir işlemi anlamanız için harika bir yoldur, ayrıca "bir sonraki adama" yardımcı olacaktır.

cscope, ctag'lerin C için yapabileceği her şeyi yapabilir, ayrıca tüm geçerli fonksiyonun çağrıldığı yerleri de listeleyebilir. Ayrıca çok hızlı. Milyonlarca LOC'ye kolayca ölçeklenebilir. Emacs ve vim'e düzgün şekilde entegre olur.

C ve C ++ Kod Sayacı - cccc, html biçiminde kod metrikleri oluşturabilir. Wc'yi de LOC almak için kullandım.

doxygen, vurgulanmış ve html'de çapraz referans kodunu oluşturabilir. Büyük kod bazında gezinirken kullanışlıdır.

Drupal ile önerdiğim ve gerçekten Drupal'a özgü olmayan bir yöntem: sorun izleyiciden başla. Elbette eski, kapatılmamış hata raporları olacak. Onları çoğaltabilir misin? Evet ise, onaylayan bileti güncelleyin. Eğer değilse, kapatın. Yazılımı bu şekilde kullanmanın bir yolunu bulacaksınız ve çökeceği kod tabanına bakmaya başlayabilirsiniz. Veya kodda ilerlemeye başlayabilir ve çöktüğü yere nasıl ulaştığını görebilirsiniz. Bu şekilde sadece kod tabanını anlamaya başlamayacak, aynı zamanda bir ton karma biriktireceksiniz ve sorularınız topluluk tarafından sıcak bir şekilde karşılanacaktır.

Yapılacak önemli bir şey, kod mimarisini yukarıdan aşağıya incelemek için bağımlılık grafikleri oluşturmak için araç kullanmaktır . İlk önce .NET derlemeleri veya kavanozları arasındaki grafiği görselleştirin, bu size özelliklerin ve katmanların nasıl organize edildiği hakkında bir fikir verecektir, daha sonra daha iyi tanımlı kod fikrine sahip olmak için ad alanı bağımlılıklarını (bir veya birkaç akrabanın içinde .NET derlemeleri veya kavanozları içinde) kazın. yapı ve son olarak, bir sınıfın bir özelliği uygulamak için nasıl işbirliği yaptığını anlamak için sınıf bağımlılıklarına bakabilirsiniz. Bağımlılık grafiği oluşturmak için, örneğin .NET için NDepend gibi, aşağıdaki grafiği oluşturan birkaç araç vardır .

Bir zamanlar harika bir yazılım mühendisim vardı, kod analiz ve bakımının en pahalı biçiminin kod satır satır satır yürümek olduğunu söyledi; Tabii ki, biz programcıyız ve bu hemen hemen işe geliyor. Sanırım mutlu bir ortam şudur: (bu sırayla): 1. Çalışacak kodu nasıl anladığınıza ilişkin notlar oluşturmak için bir not defteri oluşturun ve zaman geçtikçe buna ekleyin. 2. Kod 3 ile ilgili belgelere bakın. Kod tabanını destekleyen yazarlarla veya başkalarıyla konuşun. Onlardan bir "beyin dökümü" isteyin 4. Ayrıntı düzeyindeki sınıf ilişkilerinin bazılarını anladığınız noktaya gelirseniz, kodun nasıl çalıştığını düşündüğünüz arasında sentez yapmak için kodun bazı adımlarında hata ayıklama yapın. kodun gerçekte nasıl çalıştığını.

Öncelikle ne yapmanın ne demek olduğunu anlayın - bu olmadan saçma sapan olma olasılığı yüksektir. Kullanıcılarla konuşun, kılavuzu okuyun, her neyse.

Ardından run tuşuna basın ve temel fonksiyonlar olarak görünen kod için yürümeye başlayın.

Böl ve fethet. Her bir fonksiyonelliğe ve ilgili koda baktım, üzerlerinden geçip bir sonraki adıma geçip yavaşça bütünün bir resmini çiziyorum.

Projenin birim testleri olsaydı, ben de onların içinden geçmeyi seviyorum, her zaman çok açıklayıcı ve aydınlatıcı oluyorlar.

1. Varsa tüm testleri yapın ve hangi kodun kapsandığını ve hangilerinin olmadığını öğrenin.
2. Değiştirmeniz gereken kod kapsam dahilinde değilse, kapsaması için testler yazmayı deneyin.
3. Kodu değiştir. Testleri bozma.

Michael Feathers'ın Eski Kodla Etkili Bir Şekilde Çalışmasına Bakın

İşte kısa listem:

1. Mümkünse, birisinin kodu üst düzeyde görmesini isteyin. Hangi örüntüler göz önünde bulunduruluyor, ne tür sözleşmeler görmeyi bekleyebilirdim vs. önceden var olan projenin soğanı boyunca çalıştığımı sormak için.

2. Kodu çalıştırın ve sistemlerin neye benzediğini görün. Birkaç hatadan fazlasına sahip olabileceği kabul edilir, ancak bu ne yaptığı hakkında bir fikir edinmek için faydalı olabilir. Bu kodu değiştirmekle ilgili değil, sadece bunun nasıl çalıştığını görmekle ilgili. Çeşitli parçalar genel olarak bir sistem olmak için nasıl bir araya gelir?

3. Kodun içsel zihinsel bir modelinin oluşturulmasında yardımcı olabilecek testlere ve diğer temel dokümantasyon göstergelerine bakın. Elbette, çok az belgelendirme ve tabii ki testler olmadıkça, en az birkaç gün önereceğim yer burasıdır.

4. Bu projede kullanılan dilleri ve çerçeveleri ne kadar iyi tanırım? Buradaki önem, bazı şeylere bakmak ile devam etmek arasındaki farktır, "Evet, bir düzine kez daha önce gördüklerini ve oldukça iyi bildiklerini" ve "Dünyada burada ne deneniyor? Bunun iyi bir fikir olduğunu kim düşündü?" Onları yüksek sesle söyleyemem, özellikle de oldukça kırılgan olabilecek eski kodlara bakarsam ve bunu yazan insanlar kullanılamıyorsa ya da nedenini hatırlamıyorsam bunları düşünürdüm. işler oldukları gibi yapıldı. Yeni alanlar için, yapının ne olduğunu ve bu kodda hangi kalıpları bulabileceğimi öğrenmek için fazladan zaman harcamak faydalı olabilir.

Son fakat en az değil: Projeyi yürütenlerin, beklentilerin neler olabileceğine dair birkaç fikir verildiğinde, her seferinde ne yapmanız gerektiğine ilişkin beklentilerini bilin:

• Yeni özellikler mi koyuyorsunuz?
• Hataları mı tamir ediyorsun?
• Kodu yeniden değerlendiriyor musunuz? Standartlar sizin için yeni mi yoksa çok tanıdık mı?
• Kendinizi sadece kod tabanına alıştırıyor olmanız mı gerekiyor?

Her zaman bir programa sahip olduğum için her zaman programa giriş noktasıyla başlamaya çalışırım (örneğin, ana yöntem, ana sınıf, init, vb.). Bu daha sonra neyin başladığına ve bazen işlerin nasıl bağlantılı olduğuna işaret edecek.

Ondan sonra inerim. Veri tabanı ve DAO bir yerlerde yapılandırılmış, bu yüzden işlerin nasıl depolandığını anladım. Belki bir tür küresel örnek dersi de başlatılmıştır ve orada ne depolandığını bulabilirim. Ve iyi refrakter araçlarıyla kimin neyi aradığını bulabilirim.

Daha sonra arayüzün nerede yapılandırıldığını ve işlendiğini bulmaya çalışıyorum, çünkü bu bir sonraki bilgi noktası. Refrakter, arama ve hata ayıklama araçları aramamda yardımcı oluyor. Daha sonra, bilginin işlenmesinin nerede başladığını ve bittiğini anlayarak, tüm sınıf dosyalarında yolumu buluyorum.

O zaman aklımda bazı kağıda yazı yazmayı deniyorum, sadece kafamı etrafıma sarmak için. Gönder düğmesi, daha sonra DAO veya veritabanına iletilen ve daha sonra veritabanında depolanan genel doğrulamaya geçer. Bu, çoğu uygulamanın brüt aşırı basitleştirilmesidir, ancak genel fikridir. Kalem ve kağıt burada son derece yararlıdır, çünkü her şeyi hızlı bir şekilde not edebilirsiniz ve size yardım etmesi gereken bir programda biçimlendirme konusunda endişelenmenize gerek yoktur.

Belgelerle vb. Başlamak istiyorum, ancak deneyimlerime göre belgelendirme ve yerel bilgilerin derinliği genellikle sistemin yaşı, büyüklüğü ve karmaşıklığı ile ters orantılıdır.

Olduğu söyleniyor, genellikle birkaç işlevsel iş parçacığı tanımlamaya çalışıyorum. İşlevsel olarak, giriş yapmak, müşterilerin bir listesini çıkarmak, vb. Şeyleri kastediyorum. Desenler hiç tutarlı değilse, bir iş parçacığı size sistemin güzel, mutlaka tamamlanmamış bir kesitini vermelidir. Kalıpların tutarlı olup olmadığını belirlemenin en iyi yolu, bir avuç iş parçacığını analiz etmektir.

Bence bu demeden geçiyor ama bence sistemi teknik açıdan değil işlevsel bir açıdan anlamak daha iyi. Genel olarak, kullanılan araçlar (ORM'ler, kayıt kütüphaneleri vb.) Hakkında fazla endişelenmiyorum ve kullanılan kalıplara (MVP, vb.) Daha fazla odaklanıyorum. Benim tecrübeme göre, aletler genellikle kalıplardan daha akışkandır.

Çok şey yaptım ...

İşte "çalışan bir şey" olduğu durumlar için şimdiki yaklaşımım ve "başka bir şekilde çalışmasını" sağlamanız gerekiyor.

1. Hedefleri alın, bu sistemin çözmesi gerekir (eğer yazılmamışlarsa) - yazın. Yöneticiye, diğer çalışanlara, varsa eski olduklarını sorun. Müşteriye sorun veya herhangi bir belgeyi arayın.
2. Spesifikasyona gir. Eğer yoksa - yaz. Birisi için sormaya değmez, sanki yokmuş gibi, o zaman diğerinin umrunda değil. Yani kendi yazmanın tek yolu (daha sonra buna atıfta bulunmak daha kolay olacaktır).
3. Tasarım olsun. Var değil - yaz. Herhangi bir belgeye ve kaynak koduna mümkün olduğunca başvurmaya çalışın.
4. Değiştirmeniz gereken kısmı ayrıntılı tasarım yazın.
5. Nasıl test ettiğinizi tanımlayın. Böylece eski ve yeni kodların aynı şekilde çalıştığından emin olabilirsiniz.
6. sistemi tek adımda inşa edebilme. Ve eski kodla test edin. Henüz değilse, SVC'ye koyun.
7. Değişiklikleri uygulayın. Daha önce değil.
8. Bir ay kadar sonra, hiçbir şeyin kırılmadığını doğrulayın.

Her adım arasında ihtiyaç duyabilecek bir başka isteğe bağlı yapılacaklar: “Bu değişikliklerin zaten dün yapılması gerektiğini” söyleyen yönetici (proje sahibi). Birkaç projeden sonra, teknik özelliklere ve belgelere önceden ulaşmak için yardım etmeye bile başlayabilir.

Ancak genellikle (özellikle senaryolar için) iş kapsamında mümkün değil (maliyet çok yüksek, değer düşük ise). Bir seçenek, kritik kütleye ulaşılıncaya kadar herhangi bir değişiklik yapmamak ve sistem üretimden kalkmak (örneğin yeni sistem gelecek) veya yönetim tüm bunların yapmaya değer olduğuna karar vermiştir.

Not: Farklı ayarlara sahip 5 istemci için kullanılan bir kodu hatırlıyorum. Ve her değişiklik (yeni özellik), "hangi parçaların kullanıldığı" ve "hangi konfigürasyon istemcilerinin" olduğu düşünülerek gerekliydi; Ayarlarını cvs'e yansıtmak ve özellikleri yazmak, bu düşünme süresini neredeyse 0'a düşürür.

Kaynak kodu yazdırın ve okumaya başlayın. Özellikle büyükse, daha iyi anlamak ve istediğiniz kadar not / yorum yapmak için yalnızca belirli kısımlarını yazdırın.

Uygulamanın başlangıcından başlayarak programı izleyin. Kod tabanının belirli bir kısmına atanmışsanız, o kısımdaki yürütmeyi izleyin ve hangi veri yapılarının kullanıldığını belirleyin.

Nesne yönelimli bir dil kullanıyorsanız, genel bir sınıf şeması oluşturmaya çalışın. Bu size iyi bir üst düzey genel bakış sağlayacaktır.

Maalesef, sonunda, mümkün olduğu kadar çok kod okumalısınız. Şanslıysanız, önceki programcılar, neler olduğunu anlamanıza yardımcı olmak için mümkün olduğunca fazla belge yazdı.

Yeni bir kod temelini öğrenirken yapmanız gereken ilk şey, ne yapması gerektiği, nasıl kullanıldığı ve nasıl kullanılacağı hakkında bilgi edinmektir. Ardından, kodun nasıl yerleştirildiğini öğrenmek için mimari belgelere bakmaya başlayın, bu noktada veritabanının nasıl olduğuna da bakın. Aynı zamanda mimariyi öğreniyorsunuz, herhangi bir süreç akışını gözden geçirmek veya vaka belgelerini kullanmak için iyi bir zaman. sonra büyük resmi anladıktan sonra dalmaya ve kod okumaya başlayın, ancak yalnızca bu kod üzerinde yaptığınız herhangi bir çalışmayla ilgili kod, sadece tüm kodu okumaya çalışmayın. Kodun nerede X yapılacağını bilmek X'in tam olarak nasıl yapıldığından daha önemlidir, kod her zaman orada nasıl bulacağınızı söyleyebilmenizi sağlar.

Kodun öğrenilmesinin ötesinde, yalnızca kodu atlamaya ve okumaya çalışmak, kodun öğrenilmesinin genellikle verimsiz olduğunu, küçük değişiklikler yapmayı denemenin ya da başkasının değişikliklerinin kodunu incelemenin zamanınızın çok daha verimli olduğunu düşünüyorum.

Bir kod tabanı büyükse, dikkatinizi üzerinde çalışmakta olan parçalara odaklayın. Aksi takdirde bunalmış hissedeceksiniz ve muhtemelen başınız patlayabilir. Bazı yüksek seviyeli genel bakışların (eğer varsa) faydalı olduğunu düşünüyorum, ancak olasılıkla program akışını takip etmek için hata ayıklayıcısına çok fazla zaman harcıyor olacaksınız. Uygulamaya genel bir bakış atmak ve kullanıldığını görmek iyi bir fikirdir, böylece kodun neden / ne / neden kullanıldığını anlayabilirsiniz.

Genellikle sorunlu alanların nerede olduğunu söylemek için kod üzerinde bir tür kod karmaşıklığı aracı çalıştırıyorum. Yüksek puan alan bölgelerin güncellenmesi çok zordur. Örneğin, siklomatik ölçekte 450 puan alan bir işleve girdim. Tabii ki, yüzlerce IF. Bunu sürdürmek veya değiştirmek çok zor. Yani en kötüsüne hazırlıklı ol.

Ayrıca, mevcut sistem geliştiricilerine, özellikle de sistem üzerinde çalışıyorlarsa, soru sormaktan çekinmeyin. İç düşüncelerinizi kendinize saklayın ve sorunları çözmeye odaklanın. Diğer geliştiricilerin üzülmesine neden olabilecek yorumlardan kaçının. Sonuçta, bebek olabilir ve kimsenin bebeğe çirkin olduğunu söylemekten hoşlanmıyor.

Küçük adımlar atın, en küçük kod değişikliğinin bile büyük etkisi olabilir.

Program kod akışlarını bulmanın faydalı olacağını düşünüyorum, böylece değişiklikler yapıyorum, hangi yöntemleri / fonksiyonları neyi çağırdığını görmek için bağımlılık aramaları yapabilirim. Diyelim ki C yöntemini değiştiriyorum.

Yalnızca 1 yöntem / işlev C'yi çağırırsa, oldukça güvenli bir değişiklik olur. 100'lerce yöntem / işlev C çağırırsa, bunun daha büyük etkisi olur.

Umarım kod tabanınız iyi bir şekilde tasarlanır, yazılır ve korunur. Eğer öyleyse, anlaşılması biraz zaman alacaktır ancak sonunda gelgit de dönecektir.

Büyük bir çamur topuysa, iç işleyişini asla anlayamazsınız (ya da anlamak isteyemezsiniz).

Yaptığım bazı şeyler ...

1) Proje hakkında bilgi edinmek ve önemsiz alanları tespit etmeye yardımcı olmak için çeşitli modül boyutlarını, karmaşıklık ölçütlerini vb. Belirlemek için Source Monitor gibi bir kaynak analiz aracı kullanın .

2) Ne olup bittiğini ve kod tabanında nerede olduğunu öğrenene kadar Eclipse’de yukarıdan aşağıya doğru bir kod açın (referanslara göz atabilecek bir düzenleyiciye sahip olmak vb.).

3) Bazen, mimarinin daha iyi bir resmini elde etmek için Visio'da diyagramlar çiziyorum . Bu, projede başkaları için de faydalı olabilir.

Bu çok olur. Açık kaynak kodlu bir platform üzerinde çalışmaya başlayana kadar, kodun bazı 'tuhaflıklar' olduğunu kabul eden bir işe girmediğimi sanmıyorum.

Bir adım hata ayıklayıcı ve çok fazla azim ile uzun bir yol alabilirsiniz. Maalesef, belirli bir büyük çamur topunu öğrenmek zaman ve tecrübe gerektirir ve yıllar sonra bile kimsenin haberi olmayan bir ekim sistemi olabilir.

Çamur topundaki herhangi bir şeyi değiştirmeden önce, birim testleri yazmanızı tavsiye ederim. Ve sadece testleri geçmesi için kodun kodunu değiştiriniz. Refactor olarak, elden önce birim testleri ekleyin, böylece işletme işlevselliğinin refactoring tarafından yakalanmadığını bilirsiniz.

Çift programlama bir seçenek midir? Fikirleri zıplatacak başka bir insana sahip olmak, bu kadar iğrenç bir şeyle baş etmek için harika bir fikir.

İşte yinelemeleri kaldırmak için kullandığımız bir prosedür.

• kopyalar için standart bir yorum öneki seçin ( [dupe]yorum işaretleyiciden hemen sonra kullanıyoruz ;
• yinelenen prosedür için kullanılacak isimlerle ilgili takımlarınızla teknik özellikler yazınız;
• ilk tur: herkes bazı dosyaları alır [dupe][procedure_arbitrary_name]ve kopyalanan prosedürden önce ekler ;
• ikinci tur: herkes bir prosedür veya bir işlem alt kümesi alır ve farklı aynı amaçtaki uygulamaların benzerlik sırasını belirten bir değer atar (daha sonra şöyle olacaktır:) [dupe][procedure_arbitrary_name][n];
• üçüncü tur: her prosedürden sorumlu, ilgili sınıfa yeniden yazar;
• dördüncü tur: grepmutlu!

Bence en önemli şeylerden biri basit bir özellik almak, aklınıza gelebilecek en basit olanı seçmek ve uygulamaktır. Devam eden bir dilek listesi varsa, onu kullanın ya da kod tabanına aşina biriyle konuşun ve bir özellik önermelarını isteyin. Genellikle bunun 5 ~ 20 LOC ile bir değişiklik olmasını beklerdim. Önemli olan nokta, çok süslü bir özellik eklemek değil, kod tabanı ile çalışmak ve tüm iş akışından geçmek. Yapmaya mecbur kalacaksın

1. Değiştirmekte olduğunuz bileşeni anlamak için kodu okuyun
2. Kodu değiştirin ve bunun çevreleyen sistemi nasıl etkilediğini anlayın.
3. Değişimi test edin ve böylece bileşenlerin birbirleriyle nasıl etkileşime girdiğini belirleyin
4. Test senaryosunu yazın ve umarım bir veya iki test senaryosunu kırın, böylece onları düzeltip sistemin değişmezlerini anlayın.
5. Bir şey inşa et veya CI'yi gör ve sonra gönder

Liste devam ediyor, ancak bunun gibi bir projenin sizi bir sistem hakkında bilgi sahibi olmak için kontrol listenizdeki tüm öğelere götürdüğü ve aynı zamanda verimli bir değişiklik yapılmasına neden olduğu.

Eklemek istediğim küçük bir şey:

Son derece yardımcı olan bu tür bir sorun için son zamanlarda kullanmaya başladığım bir araç zihin haritalamasıdır. Kafamda bir şeylerin nasıl uygulandığının tüm ayrıntılarını toplamaya çalışmak yerine, içinden geçtiğim sistemin nasıl çalıştığını açıklayan bir zihin haritası oluşturacağım. Bu gerçekten neler olup bittiğini ve hala çözmem gerekenleri daha derinlemesine anlamama yardımcı oluyor. Ayrıca, değiştirmem gereken şeyleri çok hassas bir şekilde takip etmeme yardımcı oluyor.

Zihin haritalama seçeneklerinin bolluğu arasında serbest uçağı kullanmanızı öneririm .

Herhangi bir dokümantasyon olmayacak veya yetersiz dokümantasyon olacak, ya da güncel olmayacaktır. Var olan tüm belgeleri bulun. Ekip deposundaysa, kopya çıkarmayın. Değilse, oraya koyun ve müdürünüzden belki de bir nezaret ile düzenleme izni isteyin.

Her şeyi ekip için depoya yerleştirin ve bir Terimler Sözlüğü ekleyin. Tüm üslerin jargonu vardır; sözlükte belgeleyin. Aletler, ürünler, müşteriye özel vb. İçin bölümler oluşturun.

Bir yazılım ortamı oluşturma belgesi oluşturun / güncelleyin. Tüm araçlar, tuhaflıklar, yükleme seçenekleri vb. Buraya gidin.

Ardından "ProductName" Belgesi veya benzeri bir Başlarken belgesini yükleyin. Sadece akıl akışı olsun ve zamanla kendi kendine organize ol. Daha sonra güncel olmayan dokümanları gözden geçirin ve tekrar güncelleyin. Diğer geliştiriciler bunu takdir edecek, kodu öğrenirken benzersiz bir şekilde katkıda bulunacaksınız. Özellikle sizi güdüleyen ya da yanlış adlandırılan ya da sezgisel olan tüm bunları belgeleyin.

Eğik eğriniz sona erdiğinde, dokümantasyonu güncelleme konusunda endişelenmeyin. Bir sonraki yeni adamın bunu yapmasına izin ver. Geldiğinde onu işine yönlendir. Sürekli olarak cevaplar için seni sinirlendirdiğinde, ona cevap verme. Aksine, soruyu belgelerinize ekleyin ve ardından URL'sini ona verin. Olta kamışı.

Yan etkilerden biri, unuttığınız zamandan itibaren aylarca başvurabileceğiniz bir araç yapmış olmanızdır.

Her ne kadar dokümantasyon olmasa da, ilgili bir sorun takım arkadaşlarınızın yaptığı biraz tuhaf, manuel olarak yoğun prosedürlerdir. Bunları partiler, sql komut dosyaları ve benzerleriyle otomatikleştirin ve paylaşın. Ne de olsa, işlemsel bilgi tartışmalı bir şekilde yeni bir ortamda üretken olmak için beyan edici bilgiler kadar büyük. Her ne ise, yapma; bunun yerine, komut dosyasını çalıştırın ve komut dosyasını çalıştırın. Olta kamışı yine saldırıyor.

Bu konuda oldukça uzun bir yazı yazdım. İşte bir alıntı

Bir süredir bu problem hakkında düşündüm. Kendi kişisel çözümümü genel bir süreç olarak yazmaya karar verdim. Belgeledim adımlar aşağıdaki gibidir:

1. Kelime Sayfası Oluştur
2. Uygulamayı Öğrenin
3. Kullanılabilir Belgelere Göz Atın
4. Varsayım Yap
5. Üçüncü Parti Kütüphanelerini Bulun
6. Kodu analiz et

Bu işlem büyük bir masaüstü uygulaması bağlamında yazılmıştır, ancak genel teknikler hala web uygulamaları ve daha küçük modüller için geçerlidir.

Alınan: Yeni Bir Codebase Öğrenme Süreci

Paylaşabileceğim birkaç küçük ipucu var.

Mevcut bir ürün için onları yoğun bir şekilde test etmeye başladım. Bir görevi seçip alırsanız, bu özelliğe daha çok odaklanacağım.

• Bir sonraki adım, girebileceğim ve keşfetmeye başlayacağım kodu bulmak olacak. Bağımlı modülleri, kütüphaneleri, çerçeveleri vb.

• Bir sonraki adım sorumlulukları ile basit bir sınıf şeması oluşturmak olacaktır (CRC kartları gibi)

• Küçük değişiklikler yapmaya başlayın veya düzeltmek ve taahhüt etmek için küçük hatalar yapın. Böylece projenin iş akışını öğrenebiliriz; sadece kod değil. Genellikle büyük ürünlerde izin ve denetimler için bir tür defter tutma olacaktır (örneğin sağlık projeleri)

• Zaten proje üzerinde çalışan insanlarla konuşun. Düşüncelerinizi, düşüncelerinizi ifade edin ve karşılığında bu projeyle uzun süre çalışarak deneyim ve görüşlerini alın. Bu oldukça önemlidir, çünkü bu aynı zamanda takımla iyi geçinmene de yardımcı olur.

Uzun zamandır kendime ait büyük bir kod tabanına dalmak zorunda kaldım. Ancak son birkaç yılda, yeni geliştiricilerin var olan oldukça büyük bir kod tabanına sahip olduğumuz ekiplere girmesini sağladım.

Ve başarıyla kullandığımız ve şunu söyleyeceğim yöntem IMHO sorusu olmadan en etkili yol, çift programlamadır.

Son 12 ayda, takıma 4 yeni üyemiz oldu ve her seferinde yeni üye, kod üssünü iyi tanıyan başka bir üyeyle eşleşecekti. Başlangıçta, eski ekip üyesi klavyeye sahip olacaktı. Yaklaşık 30 dakika sonra klavyeyi eski ekip üyesinin rehberliğinde çalışacak olan yeni üyeye geçirirdik.

Bu sürecin oldukça başarılı olduğu kanıtlandı.