Bilinmeyen bir kod tabanını keşfetmek ve öğrenmek için hangi araçları ve teknikleri kullanıyorsunuz?
grep,
ctags, birim testleri, fonksiyonel test, sınıf diyagramı üreteçleri, çağrı grafikleri,
sloccount gibi kod ölçütleri gibi araçları düşünüyorum. Deneyimleriniz, kullandığınız veya yazdığınız yardımcılar ve birlikte çalıştığınız kod tabanının boyutu ile ilgilenirim.
Ben bir kod tabanı ile tanışmak zaman içinde gerçekleşen bir süreç olduğunu ve aşinalık "Ben kodu özetlemek mümkün" den "Ben refactor ve boyutu% 30 küçültmek" için bir şey anlamına gelebilir. Ama nasıl başlamalı?
her zaman yaptığım şey şudur:
Düzenleyicimin birden çok kopyasını (Visual Studio/Eclipse/Whatever) açın ve sonra hata ayıklayın ve satır sonlarını kodda yapın. Kodun akışını öğrenin, kilit noktaların nerede olduğunu görmek için izleri biriktirin ve oradan gidin.
Metoddan sonra yönteme bakabilirim - ama bir şeye tıklayabilir ve daha sonra kodun nerede yürütüldüğünü görebilir ve takip edebilirsem güzel. Geliştiricinin işlerin nasıl çalışmasını istediğine dair bir fikir edeyim.
Bir fili nasıl yersin?
Her seferinde 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).
Düşünebileceğiniz yaklaşımlar:
Kodu açıklığa kavuşturmak için yaptığım bazı şeyler:
... ve yapabileceğiniz diğer basit geliştirmeler.
Yavaş yavaş, arkasındaki anlam daha açık olmalı.
Başlamak için bir yer var mı? Bildiklerinizle başlayın. Girdi ve çıktı öneririm. Bunların ne olması gerektiği ve ne için kullanıldıkları hakkında sık sık başa çıkabilirsiniz. Verileri uygulama üzerinden takip edin ve nereye gittiğini ve nasıl değiştirildiğini görün.
Tüm bunlarla ilgili yaşadığım sorunlardan biri motivasyon - gerçek bir kabahat olabilir. Tüm işi bir bulmaca olarak düşünmeme ve ne kadar küçük olursa olsun yaptığım ilerlemeyi kutlamama yardımcı oluyor.
Durumunuz gerçekten yaygın. Çalışmak için mevcut kodun bulunduğu yeni bir işe girmek zorunda kalan herkes, bunun bazı unsurlarıyla ilgilenecektir. Sistem gerçekten kötü bir eski sistemse, tarif ettiğiniz gibi. Tabii ki, hiçbir zaman mevcut belgeler yoktur.
İlk olarak, birçoğu Michael Feathers tarafından Eski Kod ile Etkili Çalışma önerdi. Bu gerçekten iyi bir kitap, "Bu sınıfı bir test koşumuna sokamıyorum" veya "Uygulamamın bir yapısı yok" gibi yararlı bölümleri var, ancak bazen Tüyler yalnızca çözümden daha fazla sempati sunabiliyor. Özellikle, kitap ve örnekleri büyük ölçüde kıvırcık parantez dillerine yöneliktir. Budaklı SQL prosedürleri ile çalışıyorsanız, o kadar yararlı olmayabilir. "Bu kodu değiştirmek için yeterince iyi anlamıyorum" başlıklı konunun sorununuzu söylediğini düşünüyorum. Tüyler burada not almak ve listeleri işaretlemek gibi bariz şeylerden bahsetmektedir, ancak kaynak kontrolünüz varsa kullanılmayan kodu silebileceğiniz de iyi bir noktaya işaret etmektedir. Birçok kişi yorumlanmış kod bölümlerini yerinde bırakır, ancak bu genellikle yardımcı olmaz.
Sonra, önerilen yaklaşımınızın kesinlikle iyi bir adım olduğunu düşünüyorum. Önce kodun amacının ne olduğunu yüksek seviyede anlamalısınız.
Soruların cevaplanması gerekiyorsa kesinlikle bir akıl hocası veya ekipteki biriyle çalışın.
Ayrıca, kusurlar ortaya çıkarsa kodu destekleme fırsatını kullanın (bazen bunun için gönüllü olmanız gerekmez ... kusur sizi bulacaktır!). Kullanıcılar yazılımı ne için kullandıklarını ve hatanın onları nasıl etkilediğini açıklayabilir. Bu, yazılımın anlamını anlamaya çalışırken genellikle çok yararlı bir bilgi olabilir. Ayrıca, amaçlı bir saldırı hedefi olan koda girmek bazen "canavarla" yüzleştiğinizde size odaklanmanıza yardımcı olabilir.
Gerçekten büyük bir kaynak dosyam olduğunda aşağıdakileri yapmak istiyorum:
Normal düzenleyicinize geri döndüğünüzde kodun ne kadar garip göründüğüne şaşıracaksınız.
Eski bir kod tabanını anlamaya çalışırken çok acele etmeyin, özellikle de aşina olmadığınız teknolojiler/diller/çerçeveler kullanıyorsa. Bu biraz zaman alan kaçınılmaz bir öğrenme eğrisidir.
Bir yaklaşım, ilgili teknolojilerle ilgili kod ve öğreticiler arasında gidip gelmektir. Eğiticiyi okuyup/izledikten sonra, öncüllerinizin nasıl yaptığını görmek için koda bakın, herhangi bir benzerlik ve farklılığa dikkat edin, not alın ve mevcut geliştiricilere sorular sorun.
"Neden bu kısmı bu şekilde yaptın"
"Çevrimiçi ortamda çoğu insanın bunu bu şekilde yaptığını fark ettim ve hepiniz başka bir şekilde yaptınız. Neden bu?"
"Hepinizin teknoloji Y yerine X teknolojisini seçmesini sağlayan nedir?"
Bu soruların cevapları, projenin geçmişini ve tasarım ve uygulama kararlarının ardındaki mantığı anlamanıza yardımcı olacaktır.
Sonunda, bir şeyler eklemeye/düzeltmeye başlayabileceğiniz kadar tanıdık hissedeceksiniz. Her şey kafa karıştırıcı görünüyorsa veya çok fazla “sihir” var gibi görünüyorsa, ona bakmak, sindirmek ve diyagramlamak için yeterince zaman harcamadınız. Diyagramlar oluşturmak (sıra diyagramları, süreç akış diyagramları, vb.) Karmaşık bir süreci anlamanız için harika bir yoldur, ayrıca "bir sonraki adama" yardımcı olurlar.
cscope, ctags'ın C için yapabildiği her şeyi yapabilir, ayrıca mevcut tüm fonksiyonların nerede çağrıldığını da listeleyebilir. Ayrıca çok hızlı. Milyonlarca LOC'a kolayca ölçeklenebilir. Emacs ve vim ile düzgün bir şekilde bütünleşir.
C ve C++ Kod Sayacı - cccc, html biçiminde kod metrikleri oluşturabilir. WOC'yi LOC almak için de kullandım.
doxygen html'de sözdizimi vurgulanmış ve çapraz başvurulan kod oluşturabilir. Büyük kod tabanına göz atmada kullanışlıdır.
Drupal ile öneriyorum ve gerçekten Drupal spesifik: sorun izleyiciyle başlayın. Kesinlikle eski, kapatılmamış hata raporları olacaktır.) Evetse, onaylayan bileti güncelleyin. Hayır ise kapatın, bu şekilde yazılımı kullanmanın bir ton yolunu bulacaksınız ve çöktüğü kod tabanına göz atmaya başlayabilirsiniz. kod aracılığıyla ve nasıl çöktüğü yere nasıl geldiğini görmek.Bu şekilde sadece kod tabanını anlamaya başlamakla kalmayacak, aynı zamanda bir ton karma biriktirecek ve sorularınız topluluk tarafından sıcak bir şekilde karşılanacaktır.
Yapılması gereken önemli bir şey, kod mimarisini yukarıdan aşağıya keşfetmek için bağımlılık grafikleri oluşturmak için araç kullanmaktır. Önce .NET derlemeleri veya kavanozları arasındaki grafiği görselleştirin, bu size özelliklerin ve katmanların nasıl düzenlendiği hakkında bir fikir verecektir, daha sonra daha ayrıntılı bir kod fikrine sahip olmak için ad alanları bağımlılıklarına (bir veya birkaç akraba .NET derlemesi veya kavanozuna) kazın Son olarak, bir dizi 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, aşağıdaki grafiği oluşturan NDepend for .NET gibi birkaç araç vardır.
Bir zamanlar oldukça harika bir yazılım mühendisi bana kod analizi ve bakımının en pahalı formunun kod boyunca satır satır yürümek olduğunu söyledim; Tabii ki, biz programcıyız ve bu hemen hemen işle birlikte geliyor. Bence mutlu ortam (bu sırayla): 1. Çalışmak için kod anlamak için notlar oluşturmak için bir not defteri alın ve zaman geçtikçe buna ekleyin 2. Kod 3 ile ilgili belgelere bakın. Yazarlar veya kod tabanını destekleyen diğer kişilerle konuşun. Onlardan bir "beyin dökümü" isteyin. 4. Ayrıntı düzeyi sınıf ilişkilerinden bazılarını anladığınız noktaya geldiyseniz, kodun nasıl çalıştığını düşündüğünüz ve kod aslında nasıl çalışır.
Öncelikle ne yapması gerektiğini anlayın - bu muhtemelen anlamsız olacaktır. Kullanıcılarla konuşun, kılavuzu okuyun, her neyse.
Sonra koşmak isabet ve anahtar fonksiyonları gibi görünen için kod yürümeye başlayın.
Böl ve fethet. Her işlevselliğe ve ilgili koda bakıyorum, adım adım ilerleyip yavaş yavaş bütünün resmini oluşturuyorum.
Projede birim testleri olsaydı, ben de onlardan geçmeyi severim, her zaman çok açıklayıcı ve aydınlatıcıdırlar.
Michael Feathers'ın Eski Kod ile Etkili Çalışma
İşte kısa listem:
Mümkünse, birine kodun üst düzey bir görünümünü verin. Hangi kalıplar dikkate alındı, ne tür sözleşmeler görmeyi bekleyebilirdim, vb. Bu, başlangıçta olduğu gibi birkaç tur olabilir. önceden var olan projenin soğanıyla çalışırken soruyorum.
Kodu çalıştırın ve sistemlerin nasıl göründüğüne bakın. Verilen birkaç hatadan daha fazla olabilir, ancak bu ne işe yaradığı hakkında bir fikir edinmek için yararlı olabilir. Bu, kodu değiştirmekle ilgili değil, sadece bunun nasıl çalıştığını görmekle ilgilidir. Genel olarak bir sistem olmak için çeşitli parçalar birbirine nasıl uyuyor?
Kodun iç zihinsel bir modelinin oluşturulmasına yardımcı olabilecek testler ve diğer temel belgelere bakın. Tabii ki çok az belge ve test olmadığı sürece muhtemelen en az birkaç gün önereceğim yer burasıdır.
Bu projede kullanılan dilleri ve çerçeveleri ne kadar iyi biliyorum? Buradaki önem, bazı şeylere bakmak ve gitmek arasında, "Evet, bir düzine kez daha önce gördüm ve bunu oldukça iyi biliyordu" ve "Burada ne deneniyor? Bunun iyi bir fikir olduğunu kim düşündü?" onları yüksek sesle söylemezken, özellikle oldukça kırılgan olabilecek eski koda bakıyorsam ve bunu yazanlar ya kullanılamaz ya da nedenini hatırlamıyorsam işler oldukları gibi yapıldı. Yeni alanlar için, bu kodda yapının ne olduğunu ve hangi kalıpları bulabileceğimi öğrenmek için biraz zaman harcamak faydalı olabilir.
Son fakat en az değil: Projeyi yürütenlerin, beklenen her şey hakkında aşağıdaki birkaç fikir göz önüne alındığında, her bir zamanda ne yapmanız gerektiği konusunda beklentilerini bilin:
Belgeleme ile başlamayı söyleyebilirim, ancak deneyimlerime göre, belgelemenin derinliği ve yerel bilgi genellikle bir sistemin yaşı, boyutu ve karmaşıklığı ile ters orantılıdır.
Bununla birlikte, genellikle birkaç işlevsel iş parçacığını tanımlamaya çalışırım. Fonksiyonel olarak, giriş yapmak, bir müşteri listesini aşağı çekmek vb. Gibi şeyler kastediyorum. Desenler hiç tutarlı değilse, bir iplik size sistemin Nice, ille de tam olmayan bir kesitini vermelidir. Kalıpların tutarlı olup olmadığını belirlemenin en iyi yolu bir avuç iş parçacığını analiz etmektir.
Bunun söylemeye gerek olmadığını düşünüyorum, ancak bence, sistemi teknik bir perspektiften ziyade işlevsel bir perspektiften anlamak daha iyidir. Genellikle kullanılan araçlar (ORM'ler, kütüphane kütüphaneleri, vb.) Hakkında çok fazla endişelenmiyorum ve kullanılan desenlere (MVP, vb.) Daha fazla odaklanıyorum. Deneyimlerime göre, araçlar genellikle kalıplardan daha akışkandır.
Kaynak kodu yazdırın ve okumaya başlayın. Özellikle büyükse, daha iyi anlamak ve ihtiyacınız olduğu kadar çok not/yorum yapmak için yalnızca belirli bölümlerini yazdırın.
Programın başlangıcından başlayarak programı izleyin. Kod tabanının belirli bir bölümüne atanmışsanız, o bölümdeki yürütmeyi izleyin ve hangi veri yapılarının kullanıldığını bulun.
Nesneye yönelik bir dil kullanıyorsanız, genel bir sınıf diyagramı oluşturmaya çalışın. Bu size iyi bir üst düzey genel bakış sunacaktır.
Ne yazık ki, sonunda, mümkün olduğunca çok kod okumak zorunda kalacaksınız. Şanslıysanız, önceki programcılar neler olup bittiğini anlamanıza yardımcı olmak için mümkün olduğunca çok belge yazmışlardır.
Her zaman programın giriş noktasıyla çalışmaya çalışıyorum, çünkü tüm programların bir tane var (örneğin ana yöntem, ana sınıf, init, vb.). Bu daha sonra beni nelerin başladığını ve bazen şeylerin nasıl bağlantılı olduğunu gösterecektir.
Ondan sonra ayrıntıya iniyorum. Veritabanı ve DAO bir yerde yapılandırılmış, bu yüzden şeylerin nasıl saklandığını anlıyorum. Belki de bir çeşit küresel bulut sunucusu sınıfı başlatılır ve orada neyin saklandığını bulabilirim. İyi refrakter araçlarıyla kimin neyi çağırdığını bulabilirim.
Daha sonra bir sonraki giriş noktası olduğu için arayüzün nerede yapılandırıldığını ve işlendiğini bulmaya çalışıyorum. Refrakterleme, arama ve hata ayıklama araçları aramamda yardımcı olur. Daha sonra bilginin işlenmesinin nerede başladığını ve bittiğini anlayabilirim, tüm sınıf dosyalarında yolumu buluyorum.
Daha sonra, akımı bir şeyler kağıda yazmaya çalışıyorum, sadece başlangıçta kafamın etrafına 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 fikirdir. Kalem ve kağıt burada son derece faydalıdır, çünkü her şeyi hızlı bir şekilde not edebilirsiniz ve size yardımcı olması gereken bir programda biçimlendirme konusunda endişelenmenize gerek yoktur.
Yaptığım bazı şeyler ...
1) Proje hakkında fikir edinmek ve önemsiz olmayan alanların belirlenmesine yardımcı olmak için çeşitli modül boyutlarını, karmaşıklık metriklerini vb. Belirlemek için Kaynak Monitörü gibi bir kaynak analiz aracı kullanın.
2) Neler olup bittiğini ve kod tabanının neresinde olduğunu öğrenene kadar kodu yukarıdan aşağıya doğru Eclipse (referanslara göz atabilecek bir düzenleyiciye sahip olmak vb.) İçinde delin.
3) Bazen, mimarinin daha iyi bir resmini elde etmek için Visio içinde diyagramlar çiziyorum. Bu, projedeki diğer kişiler için de yararlı olabilir.
Yeni bir kod tabanı öğrenirken yapmanız gereken ilk şey, ne yapması gerektiği, nasıl kullanıldığı ve nasıl kullanılacağı hakkında bilgi edinmek. Ardından, kodun nasıl düzenlendiğini öğrenmek için mimari belgelere bakmaya başlayın, ayrıca bu noktada veritabanının nasıl olduğuna bakın. Aynı zamanda mimariyi öğreniyorsunuz, işlem akışlarını gözden geçirmek veya vaka belgelerini kullanmak için iyi bir zaman. büyük resmi anladıktan sonra dalış yapmaya ve kodu okumaya başlayın, ancak yalnızca bu kod üzerinde yapabileceğiniz herhangi bir çalışma ile ilgili kod, sadece tüm kodu okumaya çalışmayın. Kodun X'i nerede yapmak olduğunu bilmek, X'in tam olarak nasıl yapıldığından daha önemlidir, kod, onu nasıl bulabileceğinizi söylemek için her zaman oradadır.
Sadece kodu öğrenmenin ötesinde bir amaç olmadan kod atlamaya ve okumaya çalışmak genellikle verimsiz, kendiniz küçük değişiklikler yapmaya veya başkalarının değişikliklerinin kodunu gözden geçirmenin zamanınızın çok daha verimli bir kullanımı olduğunu görüyorum.
Bir kod tabanı büyükse, dikkatinizi şu anda üzerinde çalışmakta olan parçalara odaklayın. Aksi takdirde bunalmış hissedersiniz ve muhtemelen kafanız patlayabilir. Bazı yüksek seviyeli genel bakışın yararlı olduğunu düşünüyorum (varsa), ancak program akışını takip etmek için hata ayıklayıcıda çok fazla zaman geçirme şansınız vardır. Kodun nasıl/ne/neden kullanıldığını anlayabilmeniz için uygulamaya genel bir bakış ve bunun kullanıldığını görmek iyi bir fikirdir.
Genellikle sorun alanları nerede olduğunu söylemek için kod üzerinde kod karmaşıklık aracı bir tür çalıştırın. Yüksek puan alan alanların güncellenmesi çok zordur. Örneğin, siklomatik ölçekte 450 puan alan bir fonksiyonla karşılaştım. Tabii ki, yüzlerce IF. Bunu korumak veya değiştirmek çok zor. Yani en kötüsüne hazır olun.
Ayrıca, özellikle sistem üzerinde çalışıyorlarsa mevcut geliştiricilere soru sormaktan korkmayın. İç 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 hiç kimse bebeğe çirkin olduğunu söylemeyi sevmez.
Küçük adımlar atın, en küçük kod değişikliğinin bile büyük etkisi olabilir.
Program kodu akışları ile gelip yardımcı olur buluyorum, bu yüzden değişiklik yapıyorsam, hangi yöntemlerin/fonksiyonların 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ıyorsa, bu oldukça güvenli bir değişikliktir. 100'lerce yöntem/işlev C'yi çağırırsa, bu daha büyük bir etki yaratacaktır.
Umarım kod tabanınız iyi tasarlanmış, yazılmıştır ve korunur. Eğer öyleyse, bunu anlamak biraz zaman alacaktır, ancak sonunda gelgit çevrilecektir.
Eğer büyük bir çamur topu ise, iç işleyişini asla anlamayabilir (veya anlamak istemeyebilirsiniz).
Çok şey yaptım ...
İşte "çalışan bir şeyin" olduğu durumlar için şu anki yaklaşımım ve bunu "başka bir şekilde" yapmak zorundasınız.
Her adım arasında gerekli olabilecek bir başka isteğe bağlı yapılacak şey: f "bu değişikliklerin dün yapılması gerektiğini" söyleyen yönetici (proje sahibi). Birkaç projeden sonra, teknik özelliklerin ve belgelerin önceden alınmasına bile yardımcı olabilir.
Ancak genellikle (özellikle komut dosyaları için) iş kapsamında mümkün değildir (maliyet çok yüksek, değer düşük olacaktır). Bir seçenek, kritik kitleye ulaşana kadar herhangi bir değişiklik yapmamaktır ve sistem üretimden kaybolur (örneğin yeni sistem gelecek) veya yönetim tüm bunların yapılmaya değer olduğuna karar verdi.
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ığını" ve "hangi yapılandırma istemcilerinin" sahip olduklarını düşünerek, hiçbir şeyi frenlememek ve kopya yapıştırma kodunu değil. Ayarlarını proje CV'lerine koymak ve spesifikasyonlar yazmak, bu düşünme süresini neredeyse 0'a düşürür.
Herhangi bir dokümantasyon olmayacak veya yetersiz dokümantasyon olacak veya güncel olmayacaktır. Var olan tüm belgeleri bulun. Ekip deposundaysa, kopya oluşturmayın. Değilse, oraya koyun ve müdürünüzden belki biraz gözetim altında düzenlemek için izin isteyin.
Her şeyi ekip için depoya alın ve bir Sözlük ekleyin. Tüm bazların jargonu vardır; sözlükte belgeleyin. Aletler, ürünler, müşteriye özel, vb. İçin bölümler oluşturun.
Yazılım ortamı oluşturma belgesi oluşturma/güncelleme. Tüm araçlar, tuhaflıklar, kurulum seçenekleri vb. Buraya gidin.
Ardından "ProductName" ile Başlarken belgesini veya benzerini yükleyin. Bırakın sadece akıl akışı olsun ve zamanla kendi kendini organize edin. Ardından eski dokümanları gözden geçirin ve güncel hale getirin. Diğer geliştiriciler bunu takdir edecek, kodu öğrenirken benzersiz bir şekilde katkıda bulunacaksınız. Özellikle sizi zorlayan ya da yanlış adlandırılan ya da sezgisel olan tüm şeyleri belgeleyin.
Eğilme eğriniz sona erdiğinde, belgeleri güncelleme konusunda endişelenmeyin. Bir sonraki yeni adam bunu yapsın. O geldiğinde, onu işinize yönlendirin. Size sürekli cevaplar verdiğinde, ona cevap verme. Bunun yerine, sorunuzu belgelerinize ekleyin ve ardından URL'yi ona verin. Olta kamışı.
Bir yan etkisi, unutacağınız aylardan itibaren kendinize referans verebileceğiniz bir araç yapmış olmanızdır.
Belgeleme olmasa da, ilgili bir sorun, takım arkadaşlarınızın yaptığı biraz tuhaf, manuel olarak yoğun prosedürlerdir. Onları gruplar, sql komut dosyaları ve benzerleriyle otomatikleştirin ve bunları da paylaşın. Sonuçta, prosedürel bilgi tartışmalı bir bilgi kadar yeni bir ortamda üretken olmak açısından büyüktür. Her neyse, yapma; bunun yerine komut dosyasını ve komut dosyasını çalıştırın. Olta kamışı tekrar vuruyor.
Bu çok oluyor. Açık kaynaklı bir platformda çalışmaya başlayana kadar, kodun bazı 'tuhaflıkları' olduğu kabulü ile başlamayan bir işe başladığımı sanmıyorum.
Bir adım hata ayıklayıcı ve çok fazla sağlamlık ile uzun bir yol elde edebilirsiniz. Ne yazık ki, genellikle büyük bir çamur topunu öğrenmek zaman ve deneyim gerektirir ve o zamandan sonra bile, kimsenin bilmediği bazı alt sistemler olabilir.
Bence en önemli şeylerden biri basit bir özellik almak, aklınıza gelebilecek en basit olanı seçmek ve uygulamak. Devamlı bir istek listesi varsa, bunu kullanın veya kod tabanına aşina olan biriyle konuşun ve bir özellik önermelerini sağlayın. Genellikle bunun 5 ~ 20 LOC ile bir değişiklik olmasını beklerim. Önemli olan, çok süslü bir özellik eklemeniz değil, kod tabanı ile çalıştığınız (veya daha ziyade boğuştuğunuz :) ve tüm iş akışından geçtiğinizdir. Yapmaya mecbur kalacaksın
Liste devam ediyor, ancak nokta, böyle bir mini projenin, bir sistemle tanışmak için kontrol listenizdeki tüm öğeleri gözden geçirmesi ve aynı zamanda verimli bir değişiklik yapılmasına neden olması.
Eklemek istediğim küçük bir şey:
Son zamanlarda çok yardımcı olan bu tür bir sorun için kullanmaya başladığım bir araç zihin haritalamasıdır. Kafamda bir şeyin nasıl uygulandığına dair tüm ayrıntıları sıkıştırmaya çalışmak yerine, yaşadığım sistemin nasıl çalıştığını açıklayan bir zihin haritası oluşturacağım. Neler olup bittiğini ve hala neyi çözmem gerektiğini daha derinlemesine anlamama yardımcı oluyor. Aynı zamanda çok hassas bir ölçekte değiştirmem gereken şeyleri takip etmeme de yardımcı oluyor.
Zihin haritalama seçenekleri bolluğu arasında serbest uçak kullanmanızı öneririm.
Bu konuda oldukça uzun bir yazı yazdım. İşte bir alıntı
Bu sorunu uzunca bir süre düşündüm. Genel bir süreç olarak kendi kişisel çözümümü yazmaya karar verdim. Belgelediğim adımlar aşağıdaki gibidir:
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.
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örev seç/atarsanız, belirli bir özelliğe daha fazla odaklanacağım.
Bir sonraki adım, içeri girip keşfetmeye başlayabileceğim kodu bulmak olacaktır. Yolda bağımlı modülleri, kütüphaneleri, çerçeveleri vb.
Bir sonraki adım, sorumluluklarıyla basit sınıf diyagramı oluşturmak olacaktır (CRC kartları gibi)
Küçük değişiklikler yapmaya başlayın veya düzeltmek ve uygulamak için küçük hatalar alın. Böylece projenin iş akışını öğrenebiliriz; sadece kodu değil. Genellikle büyük ürünlerin yetkilendirme ve denetimler için bir tür defter tutmaları olacaktır (örneğin sağlık projeleri)
Zaten proje üzerinde çalışan insanlarla konuşun. Fikirlerinizi, düşüncelerinizi ifade edin ve karşılığında bu projeyle uzun süre çalışma konusundaki deneyimlerini ve görüşlerini alın. Bu oldukça önemlidir, çünkü bu aynı zamanda ekiple iyi geçinmenize yardımcı olur.
Çamur topundaki herhangi bir şeyi değiştirmeden önce birim testleri yazmanızı öneririm. Ve sadece testleri geçmek için o anda yeterli kodu değiştirin. Refactor olarak, önceden işlevsellik testleri ekleyin, böylece iş işlevselliğinin yeniden düzenleme ile etkilenmediğini bilirsiniz.
Çift programlama bir seçenek midir? Fikirleri zıplatmak için başka bir kişiye sahip olmak, bu pislikle başa çıkmak için harika bir fikirdir.
İşte yinelenenleri ortadan kaldırmak için kullandığımız bir prosedür.
[dupe]yorum işaretinden hemen sonra;
[dupe][procedure_arbitrary_name]çoğaltılan işlemden önce;
[dupe][procedure_arbitrary_name][n]);
grepmutlu!
Kendimi büyük bir kod tabanına daldırmam gerektiğinden uzun zaman geçti. Ancak son birkaç yılda, yeni geliştiricileri mevcut, oldukça büyük bir kod tabanına sahip olduğumuz ekiplere dahil etmeye çalıştım.
Başarılı bir şekilde kullandığımız ve söyleyebileceğim yöntem IMHO'yu sorgulamadan en etkili yol, çift programlama.
Son 12 ayda, ekibe 4 yeni üye kazandık ve her seferinde yeni üye, kod tabanını iyi bilen başka bir üyeyle eşleştirecekti. 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ıtlanmıştır.
Büyük kod projesini incelememin yolu şöyledir:
Programın ana akışını ve çekirdek sistemin uygulanmasını anladıktan sonra, programın diğer modüllerini keşfedebilirsiniz.
Şimdi büyük kod projesini anladınız! Lütfen tadını çıkarın!