Başkasının kodu üzerinde çalışmak [kapalı]

Kodlama konusunda neredeyse bir yıllık tecrübem yok. Çalışmaya başladıktan sonra, çoğu zaman başkasının kodu üzerinde çalışıyordum, ya mevcut olanların üzerine yeni özellikler ekliyorum ya da mevcut özellikleri değiştiriyordum. Asıl kodu yazan adam artık şirketimde çalışmıyor. Kodunu anlamakta ve görevlerimi yapmakta zorlanıyorum. Ne zaman kod değiştirmeye çalışsam, bir şekilde çalışma özellikleri ile uğraşıyordum. Başkasının kodu üzerinde çalışırken akılda tutmalı mıyım?

Kodda birim testleri var mı? Değilse, kesinlikle eklemeye başlamanızı öneririm. Bu şekilde, başarısız testler olarak yeni özellikler / hata düzeltmeleri yazabilir ve ardından testin geçtiği kodu değiştirebilirsiniz. Oluşturduklarınız ne kadar fazlaysa, eklenen kodunuzun başka bir şeyi bozmadığına o kadar güveneceksiniz.

Tam olarak anlamadığınız kod için birim testleri yazmak, söz konusu kodu anlamanıza yardımcı olacaktır. Tabii ki, eğer mevcut değilse, fonksiyonel testler eklenmelidir. Benim izlenimim, zaten mevcut olanların OP sorusunu oluşturduğuydu. Bu noktada yanılıyorsam, bu fonksiyonel testler ilk adımınız olmalıdır.

Eagle76dk bu işi yapmak için müdürünüzün gemiye binmesi konusunda harika bir noktaya değinmektedir - Eagle76dk'in gönderisinde daha fazla detay.

Bu sınamaları yazarken, sınamanın çalışmasını doğrulamış, sınama davranışını doğrulamak için sınama kodları değil, sınamaları da denemenizi öneririm. Ayrıca, kodda gördüğünüz iş davranışlarının doğru davranışlar olduğunu varsaymayın - Uygulamanın ne yapması gerektiğini size söyleyebilecek birisine sahipseniz, bu çoğu durumda kodun size söyleyebileceğinden daha değerlidir.

Birim testlerinden bahseden bir başka cevaba ek olarak, değişikliklerin kolayca geri alınabilmesi için her şeyin sürüm kontrolünde olduğundan emin olmanızı öneririm. Ve kodu daha sürdürülebilir hale getirmek için küçük değişiklikler yapmak.

Kanımca başkasının kodunu öğrenmenin en hızlı yolu, (özellikle değişiklikler tanımladığınız şekilde beklenmeyen davranışları tetiklediğinde) bir hata ayıklayıcı kullanarak kodda ilerlemektir .

Programın ana döngüsü / ana yöntemleri gibi görünen adımlarla başlayın. Kullanım içine adımını ve dışarı adım farklı yöntemler ne yaptığını görmek için işlevler. Bu size kodun genel yapısını öğretecektir.

Ondan sonra, programın farklı bölümlerini daha derinlemesine adımlayarak ve öğrenerek bölün ve fethedin. Çoğu hata ayıklayıcısında değişkenleri ve bunların geçerli değerlerini inceleyebilirsiniz . Ne zaman ve nasıl değiştiklerini inceleyin.

Yola kesme noktaları Sizi ilgilendiren davranışları tetikleyen yöntemleri. Örneğin, programdaki bir metni değiştirmeye çalışıyorsanız ve metin orijinal değerine geri dönmeye devam ediyorsa, metnin değiştirildiği tüm yerlere kesme noktaları ayarlayın veya tüm bu değişiklikleri tek bir yönteme taşımayı deneyin. Bu yöntemin nerden, vb. Denildiğini görmek için çağrı yığınını kullanın .

Bir kod satırını değiştirmek diğer yerlerde beklenmeyen değişikliklere neden olursa, o satıra bir kesme noktası koyun ve orada ne olduğunu görün; örneğin, kapsamdaki geçerli değişkenlerin değerlerini kontrol ederek, içine adım kullanarak veya arama kümesini kullanarak arama geldi.

Bunu yaparken, kodun yapısını şaşırtıcı derecede hızlı öğrenmeye başlayacaksınız. Tıpkı ilk programlama işlerimde yaptığınız gibi, yıllar önce yazılmış ve yıllar boyunca birçok kişi tarafından değiştirilen birçok kodla başladım. Bu kod sadece benim çalıştığımdan beri orada çalışan diğer insanların aynı anda çalıştığı yerdi. O noktada hepsini yeniden yazamadım. Bütün bu kod için testler yazmak aylar ya da yıllar sürdü. Hata ayıklayıcı beni gerçekten kurtardı, kodu o olmadan nasıl öğrenebilirdim bilmiyorum ...

Akılda tutulması gereken ilk şey kod yazmaktan çok kod okumak için harcanan zamandır. Diğer adamın nasıl çalıştığını anlamak için zaman harcayın - tarzı ve problemlere yaklaşımı.

Mevcut stili mümkün olduğunca benimsemeye çalışın - aksi halde sizden sonra yapacağınız ayarların iki katı kadarını yapacak.

Bir başkasının kodu ile uğraşmak bir kuraldır, istisna değil, diğer adamın bir sorunu nasıl çözeceğini ya da bir özelliği nasıl uygulayacağını anlamakta ustalaşmanız gerekir. Bunu yaptıktan sonra, onun koduyla uğraşmayı daha kolay bulacaksınız.

Diğer adamın kodunun koktuğunu varsaymak için fazla hızlı olmayın.

Ama her zaman şüpheli ol.

Ama evet, başka bir dev'in kodunu anlamak zaman alıyor. Bir işlev veya nesne ne kadar çok olursa, sistemin birçok parçası tarafından o kadar dikkatli olmanız gerekir. Sorunu belirtiye yakın bir şekilde çözebiliyorsanız, bu bazen yardımcı olabilir. Örneğin, veri teslim edildikten sonra ancak başka bir şey olmadan önce sorunlu nesnenin tarafındaki başka bir nesneden gelen verileri normalleştirin.

Bir şeyi değiştirmenin beklenmedik bir şekilde bir başkasını kırması kötü bir işarettir. Daha fazla tecrübeli geliştiriciniz varsa, yardım almak için güvenebilirsiniz, sorun yaşamaya neden olan şeylere bakmalarını tavsiye ederim. En azından onların hata ayıklamasını izleyen bir şeyler toplayabilirsiniz.

İdeal bir dünyada, belirli bir geliştirici tarafından yazılan tüm kodlar, hem birim testleri gibi otomatik araçlarla hem de kullanıcının beklenen sonucu aldığınızı kontrol etmek için kullandığı senaryo komutlarını kullanarak iyi belgelendirilir, iyi yapılandırılır ve anlaşılır bir şekilde test edilir.

Ancak, öğreneceğiniz ilk şey ideal bir dünyada yaşamamamız!

Pek çok geliştirici kodlarını doğru bir şekilde belgelendirmiyor, eğer hiç değilse, iş mantığını alakasız kod ile karıştırıyorlar ve yaptıkları tek test normal kullanım durumu olmasını bekledikleri şeylerin hızlı bir şekilde yapılması.

Bunun gibi bir kodla çalışırken, yapmanız gereken ilk şey, ne yapması gerektiğini belirlemektir. Yorumlar varsa, size ipuçları verebilir, ancak buna güvenmeyin. Tecrübelerime göre, birçok kodlayıcı kendilerini açıklamada iyi değil ve yorum yapsalar bile anlamsız olabilirler. Bununla birlikte, şirketteki tek kodlayıcı siz değilseniz, kesinlikle birisinin en azından kodun ne için olduğu ve ne yapması gerektiği konusunda temel bir fikri olması gerekir. Sormak etrafında!

Birim testleriniz varsa, o zaman hayatınızı çok daha kolay hale getirir. Bunu yapmazsanız, kod tabanını öğrenmenin bir kısmı, zaten var olan kod için birim testleri yazmayı içerebilir. Normalde bu iyi bir uygulama olarak kabul edilmez, çünkü mevcut koda göre ünite testleri yazarsanız, kodun olduğu gibi çalıştığını düşünen ünite testlerine sahip olursunuz (bu davranışın aslında bir hata olduğunu varsaymak için yazılırlar) doğru), ama en azından size bir temel oluşturur. Daha sonra doğru olduğunu düşündüğünüz bazı davranışların aslında yanlış olduğunu keşfederseniz, kodun şimdi verdiği sonuçtan ziyade beklenen sonucun ne olduğunu test etmek için birim testini değiştirebilirsiniz. Birim testine başladıktan sonra, değişiklikler yapabilir ve yaptığınız değişikliklerin hangi yan etkilere sahip olduğunu değerlendirebilirsiniz.

Son olarak, belgelenmemiş bir kod parçasıyla çalışırken elde ettiğiniz en iyi kaynak, son kullanıcılara sormaktır. Kod hakkında hiçbir şey bilmiyor olabilirler, ancak uygulamanın ne yapmasını istediklerini biliyorlar. İhtiyaç toplama herhangi bir projenin ilk aşamasıdır ve geliştirilecek sistemin olası kullanıcılarıyla konuşmak her zaman bunun önemli bir parçasıdır. Sadece zaten yapılmış olan yeni bir projenin gereksinim yakalama aşamasını yapıyor olarak düşünün.

İyi yazılmış ve iyi belgelenmiş bir kodun bile bir yabancı tarafından anlaşılmasının zor olabileceğini unutmayın. Kod, esasen, onu yazan kişinin o zaman nasıl düşündüğünü ve herkesin kendine özgü düşünce sürecine sahip olduğunu ifade eder. Biraz sabırlı olmayı ve bir dedektif olmayı öğrenmelisin. Başka bir kişinin düşünce sürecine girebilmek zor, ancak mevcut kod üzerinde bakım yapan bir programcı için çok önemli bir yetenek. Çoğu kodlamanın (yaklaşık% 70'i) mevcut kodun korunmasına bağlı olması nedeniyle, öğrenmek önemli bir beceridir.

Oh, ve şimdi kötü belgelenmiş, denenmemiş ve karışık kodun neden olabileceği acıları gördünüz, bunu yapmak için bir sonraki yoksul geliştiriciye yapmayacaksınız, değil mi? :) Selefinizin hatalarından ders alın, kodunuzu iyi yorumlayın, her modülün kendisine bağlı olduğu açıkça tanımlanmış bir sorumluluğu olduğundan emin olun ve ilk önce yazdığınız kapsamlı bir ünite testine sahip olduğunuzdan emin olun (TDD metodolojileri için) veya en azından geliştirilmekte olan kodun yanında.

Yazmadığınız kodu okuma yeteneğinin çok değerli bir beceri olduğunu ve muhtemelen kod yazmaktan daha değerli olduğunu unutmayın. Ne yazık ki, bu okullarda yaygın olarak anlaşılamıyor ve yetersiz öğretiliyor.

Söylemeye çalıştığım şey, ilk kez okuduğunuzda her zaman kodu anlamanızın normal olmaması (tıpkı ilk kez mükemmel bir kod yazmamanızın normal olması gibi). Yabancı bir kod almanın zaman alacağını kabul ederseniz, fazladan çaba harcamanın sakıncası olmaz. Küçük bir özet:

• Birim testleri idealdir, ancak her zaman gerçekçi olmaz; Özellikle de ağır bürokrasili büyük bir kuruluşta çalışıyorsanız.

• Sürüm Kontrol sisteminizi doğru kullanmayı öğrenin; Asla varolanları kıramazsın (gerçekten asla değil , ama bu iyi bir güvenlik ağıdır).

• Bunun kötü olduğunu varsaymayın, çünkü anında anlamazsınız. İşe yaradığı için bunun iyi olduğunu varsaymayın. Önemli olan, önceki bakıcının kod stilini anlamanız ve eklediğiniz satırları stiline uyarlamanızdır. Sizden sonra gelecek olan koruyucu bunun için size teşekkür edecektir.

• Bazı firmalarda maalesef kod okuma zorluğu hafife alınabilir. Bu katı süreçleri olan büyük şirketlerde yaygındır. Sık sık (dolaylı olarak), temiz bir şeyler yazmak için zaman ayırmak yerine, hızlı çalışan bir kodu itmenizi tercih ederler. Takımınızın bu noktada nerede durduğuna karar vermenizi size bırakacağım.

• Son olarak, okuma kodunun bir beceri olduğunu asla unutmayın . Ne kadar çok yaparsanız, o kadar iyi olursunuz. Bunu söylemenin bir başka yolu, bu konuda iyi olmanın tek yolunun bunu birçok kez uygulamak olduğudur. Yukarıda bahsedildiği gibi, okuma kodu, yazdığınızdan işinizin çok daha büyük bir parçasıdır ve olacaktır.

Yanlışlıkla kırılma konusundaki problemlerinize bakılırsa, kodun otomatik testler kapsamında olmadığını varsayacağım. # 0 Adımı , Michael Feathers'ın Eski Koduyla Etkili Çalışmayı hemen sipariş etmek ve okumak olacaktır . Bu sadece paha biçilmezdir.

Önereceğim temel adımlar:

• Geçerli işlevselliği kapsayan testlerle kodu kapatın.
• Anlaşılana kadar refactor.
• Yeni veya değiştirilmiş işlevsellik için bir test yazın.
• Yeni işlevselliği uygulayın.
• Memnuniyete kadar refactor.

Testlerin lezzetini (birim, entegrasyon, ...) belirtmeden kasıtlı olarak dışarıda bırakıyorum - sadece bir çeşit otomatik test kapsamı elde ediyorum.

(ve evet, düzen ve isimlendirme açısından kodlama stilini takip edin)

Daha önce de belirtildiği gibi: gerçek dünyaya hoş geldiniz. Sadece daha önceki cevaplarla aynı fikirdeyim. Ben sadece zaman tahminleri hakkındaki iş tecrübemle cevabını genişletmek istiyorum.

Patronunuzu netleştirmeniz için iyi bir öneri, diğer geliştiricilerin nasıl düşündüğünü öğrenmek zaman alacaktır. Genellikle mevcut çözümün geliştiricinin yaşına ve deneyimine bağlı olduğunu göreceksiniz.

Şanslıysanız, elinizdeki görev analiz edilmeli ve belgeleri anlamanız size çok yardımcı olacaktır (ancak bu genellikle böyle değildir).

Deneyimlerim, başkalarının kodunu değiştirirken, şu anki görevinizi içermeyen kodu değiştirmemeye çalışmanızdır. Daha iyi bir çözüm biliyor olabilirsiniz veya daha sezgisel bir şekilde yazılabilir, ancak bunu değiştirmek genellikle aşağıdaki gibi sorunlara yol açar:

• Görev daha uzun sürecek ve patronunuz bunu anlamayacak.
• Değiştirdiğiniz kodun test edilmesi gerekir ve maliyeti de vardır. Mevcut çözüm test edildi ve onaylandı.
• Hangi değişikliklerin mevcut görevi çözdüğünü ve hangilerinin “adil” düzeltmeleri olduğunu görmek zor olacak.

Ancak patronunuza söylemekte tereddüt etmeyin, farklı olması gerektiğini düşündüğünüz bir şey görürseniz (sadece düşünebileceğinizi gösterir).

Son olarak, çözümü yapmak için yeterli zamanınız olduğundan emin olun. Daha hızlı bir çözüm, deneyim ile birlikte gelir. Ancak, nadiren hızlı bir çözüm vardır, çünkü bu hataların ve ulaşılamaz kodların ilk / ana nedenidir.

Bir kişiye ameliyat yapmak gibi düşünün.

Arızanın giderilmesi için gereken sorunu araştırıyorsunuz, atardamarların çoğunun, vb. Sizin yaptığınız gibi ayarlanmadığını görüyorsunuz - bu nedenle, tam size bakana kadar onları kesip doğrayıp sorunu düzeltirsiniz.

Şaşırtıcı bir şekilde hastamız neredeyse hemen ölüyor.

Eski uygulamalar aynı. Zaten bir çalışma şekline sahipler - yazılımdaki çeşitli bileşenleri ve birbirleriyle nasıl ilişki kurduklarını anlamanız ve sonra değişikliklerinizi aynı şekilde yapması için yapmanız gerekir. Yaratıcılığınızın çılgına dönmesine izin vermek heyecan verici değildir, ancak bunu kişisel projelerde yapabilirsiniz.

Üst düzey bir mühendisden her Pazartesi bir saat kadar seninle oturup, sistemin farklı bir yönünü açıklamasını isterim. Söylediklerinin notlarını al ve yöneticinin ekleyeceği bir şey olup olmadığını görmek için notları kendisine ve yöneticine e-posta ile gönder. Bu şekilde oldukça hızlı bir şekilde hızlanmalısınız.

Bir şeyleri nasıl kırmayacağınıza gelince, öncelikle sistemin ne yaptığını anladığınızdan emin olun. Önce test et - değişiklik yap - sonra test et. Büyülü formül yok; deneyim kazandıkça daha iyi olacaksınız - ya da kovulacaksınız sanırım!

Burada dokunmadığım bir şey var - bir adada çalışma.

Eğer kıyafeti sadece programcı değilseniz, orada bağlı olduğu birini Yaslanacak Sizden daha fazla deneyime sahiptir ve büyük ihtimalle birçok kişi.

Sorular sor. Çoğu.

Başkasının "sinir bozucu" olduğu konusunda endişelenmeyin (aklın içinde) - Birisinin daha sonra bir üretim ortamına ateş yakmak yerine normal bir geliştirme döngüsü sırasında bir veya iki soru için beni kesmesini tercih ederim.

Bir şeyi kontrol etmeye hazır olduğunuzda, danışmanınızla görüşün. Size sadece bir şeyin başka bir şeyi kıracağını değil, daha önemlisi nedenini söyleyebileceklerini söyleyebilmelidirler. Ayrıca, kodu gözden geçirmek, mentoru daha iyi bir programcı haline getirerek, sisteme başka türlü bakamadıklarına dair bir fikir verir.

Unutmayın - sadece herhangi bir yeni çalışanın yapması gerektiği gibi sistemi öğrenmiyorsunuz, aynı zamanda nasıl programcı olunacağını da öğreniyorsunuz.

Ve beş yıl sonra, bir sonraki Yeni Adam'ı sizi mentor olarak kullanmaya teşvik edin.

Kod hata ayıklama söz konusu olduğunda, unutmayın: Her zaman bir nedeni vardır . Birkaç gündür aynı aptal hatayı bulmaya ve düzeltmeye çalışıyorsanız ve herhangi bir ilerleme kaydetmiyorsanız, şunlardan birini veya birkaçını düşünmeye başlamak cazip gelir:

• Bu kodun nasıl çalıştığını anlayacak kadar akıllı değilim.

• Bu kodu yazan adamın ne yaptığı hakkında hiçbir fikri yoktu.

• Büyü katılır: çok kara büyü

Bunların hepsi vazgeçme biçimleridir. Panzehir her zaman bilgisayarların deterministic olduğunu hatırlamaktır: Yaptıkları şeyin her zaman bir nedeni vardır . Kod, bir balık konservesinde düşük gelgit gibi kokuyor ve dev bir linguine çanağına benziyor, ancak durmaksızın rasyonel ve açık bir fikir sahibi olmakla çözeceksiniz .

Mümkünse ünite testleri yazsanız veya değiştirdiğiniz kodu içeren küçük uygulamalar yazsanız, mantığa bakmanız, anlamanız ve sonra belgelendirmeniz gerekecektir.

Kod çoğunlukla çalışırsa - olduğu gibi ses çıkarır - o zaman stiliniz olsun veya olmasın, o modül için kod formatlama stilini korurum. İşleri düzgün tutar. Ancak, iyi yorumlar asla modası geçmez.

Üretimi kesintiye uğratmadan bu kodu değiştirebileceğiniz ve test edebileceğiniz bir test sistemi ve test platformu öneririm.

Kodun öğelerini bir kütüphaneye kaldırabiliyorsanız, bir kütüphanede çalışmadığınız sürece yapardım.

Zamanla, mantığı anladıktan sonra, tekrar yazıp test edebilirsiniz.

Bu öneri, kullandığınız dilden, bir test yatağı alabilmeniz ve sahip olduğunuz diğer kısıtlamalardan kaynaklanmaktadır.

Kullanılmayan kodu silmek için bazı kod çözümleyici araçlarını kullanmayı deneyin - bu nedenle en azından bu kod için endişelenmenize gerek yok.

Yukarıda, sadece kodun ayrıntılarını değil, sistemin amacını anlamanız gerektiği belirtildi. Sipariş giriş sistemi yazmak için yeterli deneyime sahip bir programcı genellikle ürünlerin seçilmesini, bir fatura biçimlendirilmesini ve ödemenin işlenmesini içeren 'ileriye doğru' bölümü ile rahatça çalışır. Takıldıkları yer, kullanıcının 'boşver' demediğine karar vermesi ve işlemleri geri almaya başlaması veya ödeme işleminde hata yaptığında ve 'geri' düğmesine basmasıdır. Bu noktada pek çok programcı gömülüyor, çünkü 'hiçbir yerde görünmüyor' kodunu görüyorlar ve neden orada olduğunu çözemiyorlar.

Kısacası, sadece 'normal akışı' değil, birisinin bir hata yapması veya fikrini değiştirmesi durumunda gerekli olan tüm geri izlemeyi anlamalısınız. Bu, bazı kodların yalnızca belirli hesap ayrıcalıklarıyla çalıştırılabileceği denetleyici geçersiz kılmalarıyla daha da kötüleşiyor.

Birisi yılda 10.000 satır kod yazıyorsa ve bir uygulamanın on yıllık bir “ömrü” varsa, bir başkasının çalışmasını almaktan sorumlu bir programcının 100.000 satırlık kodu anlaması gerekebilir. Bunu sayfa başına 50 satıra bölme 2000 sayfadır. Program bir tasarım desenine yazılırsa, programcı bir “blok” anlayışının en azından geri kalanının çoğu hakkında genel bir anlayışa yol açtığını görecektir. Olmazsa, lanet olası her satırı okumak gerekir.

Bazı programcılar 'söyleneni yaparlar' ve spagetti yazarlar. Asla 'büyük resmi' anlamıyorlar - kullanıcılar şikayet edince düzeltmeler yapıyorlar. Böyle bir durumda elinizden geldiğince uygun bir yapıya geçmeye başlamak iyi bir fikirdir. Sonunda bu, 'kırılmayan' şeyleri yeniden kodlamak anlamına gelebilir. Endişelenmeyin, yalnızca projeniz olduğu sürece aşamalı olarak daha sürdürülebilir olduğundan emin olun.

Burada gerçekten çok güzel cevaplar var. Ancak, iyi tasarım modellerine ne kadar aşina olmanın, varolan kodu okumak (iyi yazılmış) ve okunabilir kod yazmak için ne kadar yardımcı olabileceğinden bahsetmenin de faydalı olacağını düşünüyorum .

Elbette SomethingFactory, mevcut bir kodla karşılaştığınızda kafa karıştırıcı olabilir , bu aslında fabrika modelini izlemiyor . Ancak ekibinizin ve çerçevenizin izin verdiği ölçüde, bu tür davaları minimumda tutmak yararlı olabilir.

Tasarım desenlerini takip etmek (işletmenin ihtiyaç duyduğu yerlerde) ayrıca kod çoğaltmasını önemli ölçüde azaltabilir ve bu da gelecekteki değişiklikler üzerindeki hataları azaltır.

Tasarım kalıplarında bazı iyi kaynaklar

http://sourcemaking.com/design_patterns

http://www.oodesign.com/

ve tabii ki kitap

http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Yöntemler arasındaki kontrol akışının izlenmesi, iş mantığının zihinsel bir haritasını geliştirmede çok önemlidir.

Bizim çözümümüz, eski bir sisteme yaklaşırken mevcut birkaç güvenilir bilgi parçasından birinin çalışan sistemin kendisi olduğunun kabulüne dayanmaktadır. Yaklaşımımız yürütme izlerini yeniden düzenler ve üzerlerindeki testleri ifade etmek için mantıksal programlama kullanır.

Bir iş akışı veri modeli oluşturmak, tüm kod yollarını analiz etmenin en iyi yoludur:

Uygulamada, kod incelemesi eski bilimsel iş akışlarında huzursuz olur. Bu tür iş akışlarının kökeni, yazılım mühendisliği uygulamalarının geliştirme sırasında uygulanamayabileceği ve etkin bir şekilde gizlenen bir kod tabanına yol açacağı anlamına gelir. Statik analiz, veri akışı analizi için gelişmiş tekniklere sahip olsa da, gerçek dünya iş akışlarındaki davranışı desteklememektedir. Örneğin, verilerin nasıl işlenmesi gerektiğini belirlemek için bir yapılandırma dosyasının yüklenmesi gerektiğinde veya dinamik kod değerlendirmesinin ne zaman kullanıldığını.

Ve iş akışını görselleştirmek idealdir:

Kendisini görsel gelişime ödünç veren ortak bir motif, iş akışının grafik halinde sunulmasıdır. Bu, kullanıcıyı, kaynakların ve yürütmenin altında yatan karmaşıklıktan korur

Referanslar

• Çalışma Zamanı Analizi ile Eski İş Akışlarını Anlama (pdf)
• Nesneye Dayalı Eski Sistem İzine Dayalı Mantık Testi (pdf)
• console.trace () - Web API'ları | MDN
• Proxy'ler üzerinden yöntem çağrısı izleme
• Ruby Yöntemlerinizi Nasıl İzleyebilirim?
• Python'da iç içe geçmiş işlev çağrılarının kolayca izlenmesi - Eli Bendersky'nin web sitesi
• Metod giriş / çıkış günlüğü - Mebyon Kernow
• İz: İşlev Çağrısını Gösterecek Araçlar
• -Xtrace -
• GitHub - johnno1962 / SwiftTrace: İz Swift ve Objektif-C yöntemi çağrıları
• Debug :: Trace - Alt rutin çağrıları izlemek için Perl uzantısı - metacpan.org

Geçerli dosyada bir şeyler bulmanıza yardımcı olan bir program kullandığınızdan emin olun. Aradığın şeyin mevcut dosyada olduğunu bilmekten daha kötü bir şey yoktur, ancak kaydırır, kaydırır ve bulamazsınız. Kodu düzenlemek için kullandığınız araçtaki anahat görünümü gerçekten bu soruna yardımcı olur.