/Büyük kod tabanlarına nasıl girersiniz?
Büyük kod tabanlarına nasıl girersiniz?
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ı?
22 Eyl 2010 miku
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.
22 Eyl 2010 ist_lion
Bir fili nasıl yersin?
Her seferinde bir ısırık :)
Cidden, önce kodun yazarlarıyla konuşmaya çalışıyorum.
22 Eyl 2010 user2567
İşi bitirene kadar kesmek zorunda mıyım
Büyük ölçüde, evet (üzgünüm).
İş terimleriyle kodun ne yapması gerektiğini bulmaya çalışın.
Ne kadar kötü olursa olsun, var olan tüm belgeleri okuyun.
Kod hakkında bir şey bilen herkesle konuşun.
Hata ayıklayıcıdaki kodda ilerleyin.
Küçük değişiklikler yapın ve neyin kırıldığını görün.
Daha anlaşılır olması için kodda küçük değişiklikler yapın.
Kodu açıklığa kavuşturmak için yaptığım bazı şeyler:
Kodu güzel bir şekilde biçimlendirmek için bir kod ön kodu çalıştırın.
Ne yapabileceğini düşündüğümü açıklamak için yorum ekle
Değişken adlarını daha net hale getirmek için değiştirin (yeniden düzenleme aracı kullanarak)
Belirli bir sembolün tüm kullanımlarını vurgulayan bir araç kullanma
Koddaki dağınıklığı azaltmak - yorumlanmış kod, anlamsız yorumlar, anlamsız değişken başlatmalar vb.
Geçerli kod kurallarını kullanmak için kodu değiştirin (yeniden düzenleme araçlarını kullanarak)
Anlamlı rutinlere işlevsellik kazandırmaya başlayın
Mümkün olan yerlerde testler eklemeye başlayın (genellikle mümkün değildir)
Sihirli sayılardan kurtulun
Mümkün olduğunda çoğaltmayı azaltma
... 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.
24 Ara 2010 Kramii
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.
24 Ara 2010 Bernard Dy
Gerçekten büyük bir kaynak dosyam olduğunda aşağıdakileri yapmak istiyorum:
Tüm karışıklığı panoya kopyala
Yazı tipi boyutunu en aza indirin.
Koddaki desenlere bakarak aşağı kaydırın
Normal düzenleyicinize geri döndüğünüzde kodun ne kadar garip göründüğüne şaşıracaksınız.
O zaman alır
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.
28 Mar 2012 CFL_Jeff
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.
13 Eki 2010 aufather
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.
14 May 2011 chx
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.
28 Haz 2011 Patrick Smacchia - NDepend dev
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.
16 Kas 2010 Tim Claason
Ö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.
22 Eyl 2010 aredkid
Varsa, tüm testleri yapın ve hangi kodun kapsandığını ve hangisinin kapsamadığını görün.
Değiştirmeniz gereken kod kapsam dahilinde değilse, kapsamı kapsayan testler yazmaya çalışın.
Kodu değiştirin. Testleri kırmayın.
Michael Feathers'ın Eski Kod ile Etkili Çalışma
28 Haz 2011 kevin cline
İş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:
Yeni özellikler mi ekliyorsunuz?
Hataları düzeltiyor musunuz?
Kodu yeniden düzenliyor musunuz? Standartlar sizin için yeni mi yoksa çok tanıdık mı?
Sadece kod tabanına aşina olmanız mı gerekiyor?
28 Mar 2012 JB King
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.
13 Eki 2010 Casey
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.
27 Şub 2012 Rudolf Olah
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.
22 Eyl 2010 TheLQ
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.
23 Eyl 2010 JeffV
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.
28 Mar 2012 Ryathal
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).
28 Mar 2012 Jon Raynor
Ç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.
Hedefleri alın, bu sistem çözmelidir (yazmamışlarsa) - yazın. Yöneticisi, diğer çalışanlar, hatta eski varsa sor. Müşteriye sorun veya herhangi bir belge arayın.
Ayrıntılı bilgi alın. Eğer yoksa - yazın. Birinden ona sormaya değmez, sanki yokmuş gibi, o zaman başkalarının çok umursamadığı durumdasınız. Bu yüzden kendi yazmanın tek yolu (daha sonra buna bakmak çok daha kolay olacaktır).
Tasarım alın. Mevcut değil - yazın. Tüm belgelere ve kaynak kodlara mümkün olduğunca başvurmaya çalışın.
Değiştirmeniz gereken bölüme ayrıntılı tasarım yazın.
Nasıl test edeceğinizi tanımlayın. Böylece eski ve yeni kodların aynı şekilde çalıştığından emin olabilirsiniz.
sistemi tek adımda kurabilme. Ve eski kodla test edin. Henüz değilse SVC'ye koyun.
Değişiklikleri uygulayın. Daha önce değil.
bir ay sonra hiçbir şeyin kırılmadığını doğrulayın.
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.
24 Ara 2010 Konstantin Petrukhnov
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.
16 May 2013 toddmo
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.
24 Ara 2010 Jeremy French
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
Değiştirdiğiniz bileşeni anlamak için kodu okuyun
Kodu değiştirin ve bunun çevredeki sistemi nasıl etkilediğini anlayın.
Değişikliği test edin ve böylece bileşenlerin birbirleriyle nasıl etkileşime girdiğini belirleyin
Test senaryosunu yazın ve umarım bir veya iki test senaryosunu kırın, böylece bunları düzeltin ve sistemin değişmezlerini anlayın.
Bir şeyi inşa edin veya CI'nin inşa ettiğini görün ve gönderin
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ı.
28 Mar 2012 Osada Lakmal
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.
17 Eki 2012 c.hughes
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:
Kelime Sayfası Oluştur
Kullanılabilir Belgelere Göz Atın
Üçüncü Taraf Kütüphanelerini Bulma
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 Kod Tabanı Öğrenme Süreci
8 Haz 2013 Lars
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.
22 Ağu 2013 sarat
Ç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.
25 Ara 2010 David Weiser
İşte yinelenenleri ortadan kaldırmak için kullandığımız bir prosedür.
kopyalar için standart bir yorum öneki seçin ([dupe] yorum işaretinden hemen sonra;
yinelenen yordamda kullanılacak adlar hakkında ekiplerinizle birlikte teknik özellikler yazın;
ilk tur: herkes bazı dosyalar alır ve [dupe][procedure_arbitrary_name] çoğaltılan işlemden önce;
ikinci tur: herkes bir prosedürü veya bir prosedür alt kümesini alır ve aynı amaçlara yönelik farklı uygulamaların benzerlik sırasını gösteren bir değer atar (dize daha sonra şöyle olur: [dupe][procedure_arbitrary_name][n]);
üçüncü tur: her prosedürden sorumlu kişi onu ilgili sınıfta yeniden yazar;
dördüncü tur: grep mutlu!
25 Ara 2010 cbrandolino
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.
22 Ağu 2013 Pete
Büyük kod projesini incelememin yolu şöyledir:
projeyi yapın ve kullanın.
IDE projeyi açmak için kullanın. Örneğin: Eclipse veya Codelite.Ardından IDE) projenin tüm kaynak kodunu dizine ekleyin.
Projenin dili bu işlevi destekliyorsa, sınıf diyagramı oluşturmak için IDE kullanın.
Ana yöntemi bulun.Ana yöntem programın bir girişi ve ana yöntem de projeyi keşfetmek için iyi bir giriş.
Programın temel veri yapılarını ve işlevlerini bulun.Uygulamaya bir göz atın.
Projenin bazı kodlarını değiştirin. Yapın ve kullanın. Doğru çalışıp çalışmadığını izleyin! Programı değiştirerek teşvik edileceksiniz.
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!
22 Ağu 2013 Edward Shen
% 90 bakım ve% 10 geliştirme yapıyorum, bu normal mi?