Eski Kodları Vermek için En İyi Uygulamalar

Birkaç ay içinde bir meslektaşım yeni bir projeye geçecek ve ben onun projelerinden birini miras alacağım. Hazırlanmak için, Michael Feathers'ın Eski Kod ile Etkili Çalışmasını emretmiştim .

Ancak, bu kitapların yanı sıra, şu ana kadar bulduğum eski kod ile ilgili birçok soru, olduğu gibi kodun devralınmasıyla ilgilidir. Fakat bu durumda asıl geliştiriciye erişebiliyorum ve düzenli bir devir için zamanımız var.

Kod parçasındaki bazı bilgiler miras alacağım:

• Çalışıyor: Bilinen bir hata yok, ancak performans gereksinimleri artmaya devam ettikçe, çok uzak olmayan bir gelecekte bazı optimizasyonlar gerekli olacaktır.
• Belgelenmemiş: Yöntem ve sınıf düzeyinde hemen hemen sıfır belge var. Kodun daha yüksek bir seviyede yapması gereken şey, anlaşılmalı, çünkü API’sına (kara kutu olarak) yıllardır yazıyordum.
• Sadece daha üst seviye entegrasyon testleri: API (diğer bir deyişle, kara kutu) aracılığıyla diğer bileşenlerle doğru etkileşimi test eden entegrasyon testleri vardır.
• Çok düşük seviye, hız için optimize edilmiş: Bu kod tüm uygulama sistemlerinde merkezi olduğundan, çoğu yıllar boyunca birkaç kez optimize edilmiştir ve son derece düşük seviyededir (bir bölümün belirli yapılar için kendi hafıza yöneticisi vardır). / kayıtları).
• Eşzamanlı ve kilitsiz: Eşzamanlı ve kilitsiz programlamaya çok aşinayım ve aslında bu koda birkaç parça katkıda bulunduğum halde, bu başka bir karmaşıklık katmanı ekliyor.
• Büyük kod temeli: Bu proje on binden fazla kod satırı içeriyor, bu yüzden bana her şeyi açıklayamam mümkün değil.
• Delphi'de yazılmıştır: Ben sadece bunu ortaya koyacağım, ancak dilin soruya almanca olduğuna inanmıyorum, çünkü bu türden bir dilin agnostik olduğuna inanıyorum.

Ayrılışına kadar geçen zamanın en iyi nasıl harcanacağını merak ediyordum. İşte birkaç fikir:

• Makinemde oluşturulacak her şeyi edinin: Her şey, arada bir dosyayı kontrol etmeyi unutmayan, kaynak kod denetimi olarak kontrol edilmek zorunda olsa da, bu muhtemelen ilk iş sırası olmalıdır.
• Daha fazla test: Daha fazla sınıf düzeyinde birim testi yapmak istememde, değişiklik yapacağım zaman, ortaya koyduğum herhangi bir hata erken yakalanabilsin, şimdi olduğu gibi kod test edilebilir değil (devasa sınıflar, uzun yöntemler, çok fazla karşılıklı bağımlılıklar).
• Belgeye Ne aksi nedeniyle düşük seviyede / derece optimize doğa ör anlamak zor olurdu kodunda bu alanlarda belgelerine odaklanmak iyi olurdu ben başlayanlar için düşünüyorum. Korkarım ki, çirkin ve yeniden yapılanma / yeniden yazma ihtiyacı duyan birkaç şey var, ama aslında orada özleyebileceğim iyi bir sebep için yapılmış olan optimizasyonlar var (bkz. Joel Spolsky, Yapmanız Gerekenler Asla Yapma, Bölüm I )
• Nasıl belgelenir: Bence bazı nesirlerin eşlik ettiği mimari fonksiyonların bazı sınıf diyagramları ve kritik fonksiyonların sekans diyagramları en iyisi olur.
• Kim belgeleyecek: Neyin daha iyi olacağını merak ediyordum, onun belgeleri yazmasını sağlamak ya da bana açıklamasını yaptırmak, böylece belgeleri yazabiliyorum. Korkarım, onun için açık olan ama benim için açık olmayan şeyler başka türlü düzgün bir şekilde örtülmeyecek.
• Çift programlama kullanarak yeniden yapılanma: Bu, zaman kısıtlamaları nedeniyle yapmak mümkün olmayabilir, ancak belki de bazı şeylerin neden olduğu konusunda girdi sağlamak için hala etraftayken daha sürdürülebilir hale getirmek için bazı kodlarını yeniden düzenleyebilirim.

Lütfen yorum yapın ve buna ekleyin. Tüm bunları yapmak için yeterli zaman olmadığından, özellikle nasıl öncelik vereceğinize ilgi duyuyorum.

Güncelleme: Proje teslim edildiğinde bu listeyi aşağıdaki cevabımdaki kendi deneyimlerimle genişlettim .

Geliştiriciye erişiminiz olduğu için aşağıdakileri sorun: -

• Hangi modüllerin kodlanması / uygulanması en zor olanıydı. Sorunlar neydi ve nasıl aşıldılar.

• Hangi modüller en fazla hata üretmiştir.

• Hangi modüller hataları çözmek için en zor sonuçlandı.

• En çok hangi kod parçasından gurur duyduğunu gösterir.

• Hangi kod parçalarını gerçekten refaktör yapmak istiyor, ancak zamanı olmadı.

Bu sorular size en çok soruna neden olacak şeyler hakkında bir fikir verecektir ve belki de daha önemlisi, orijinal geliştiriciyi düşünce süreçleri ve perspektifleri üzerine ele alacaktır.

Proje teslim süresi sona erdiğinde, zaman alacağım ve benim için en iyi olan şeyleri içeren kendi cevabımı yazacağımı düşünüyorum.

• Her şeyi sürüm kontrolü altında tutma: Oluşturmam gereken her şeyin sürüm kontrolü altında olduğundan emin olduktan sonra, uygulamanın konuşlandırılması ve / veya test edilmesine yardımcı olacak, ancak uygulamanın test edilmesine ve / veya test edilmesine yardımcı olacak ek komut dosyaları veya yardımcı programlar aramak için eski geliştiricinin sabit diskinde de arama yaptım. kontrol edilmedi.
• Yukarıdan aşağıya: Ana sınıfların eski geliştiricisi ile rehberli bir tura ve ana sınıflara yüksek bir bakışla başlardım. Sonra geri kalanı daha derine kazıp, bana anlamlı gelmeyen //TODOkalemlerle işaretlerdim.
• Tüm dökümanları kendim yaz: Eski geliştiricinin doğru yaptığımdan emin olmak için yazımı incelerken, her şeyi kendim yazmakta ısrar ettim. Bu yolla yazının sadece eski geliştiriciye değil, bana da mantıklı geldiğinden emin olurdum.
• Her yerde yorumlar: Her sınıfa ve her yönteme XML belgeleri özetleri ekledim . Bu şekilde en azından her kod parçasına baktığımdan ve bir cümle içinde yaptıklarını özetlemek için yeterli bir anlayışa sahip olduğumdan emin oldum. Ayrıca, IntelliSense bu bilgileri alırken, özetleme yöntemlerini / sınıflarını kullanarak yöntemlerin anlaşılmasını da kolaylaştırdı. Ayrıca hala bakmak zorunda olduğum kodun alanlarını kolayca belirleyebilirdim.
• Kaynağa yakın belge: Kaynak kod ile dokümantasyon arasındaki bağlantıyı kolaylaştırmak için dokümantasyonumun çoğunu kaynak koduna koydum. Çeşitli alt sistemler arasındaki etkileşimi tanımlayan üst düzey belgeler için, bu bilgiyi kodun sadece bir yerine koymak işe yaramadığı için bir wiki kullandım. Tüm belgelendirme elektronik ve tam metin aranabilir olmalıdır.
• Diyagramlar: Temel bir bakış için farklı alt sistemler için çeşitli tanecikli sınıf diyagramları kullandım. Eşzamanlı parçalar için, nesne ve etkileşim şemaları gerçekten yardımcı olmuştur; konuyla ilgili diğer soruma da bakınız .
• Bir çift olarak refactoring : Eski geliştirici ile kod hakkında bir fikir edinmek ve daha fazla bakım yapmak için yeniden yapılanma yaparken bir miktar yeniden yapılanma yaparken, iyi yeniden yapılandırma araçları ve kötü bir demet olmadığı için bu zaman alıcı ve riskli bir süreçti. çeşitli parçalar arasındaki bağımlılıklar. Michael Feathers'ın Eski Kodla Etkili Bir Şekilde Çalışması , uygun alet desteği olmadan yeniden yapılanmanın hala acı verici olmasına rağmen, bunun için gerçekten iyi bir yardımdır. Refactoring yaparken fare ve klavyeyi kontrol etmesine izin verecektim, çünkü bu onun için daha eğlencelidi (ayrıca son madde işaretime bakın) ve öğrendiklerimi yazmakta özgürdüm.
• Yorumlar ve değişiklikler için ayrı check-in'ler: Yanlışlıkla bir yorum yazarak bir hata yaptıktan sonra override, ayrı check-inlerde yorum ve değişiklikler yapmak için dikkatli oldum. Bir şeyi kontrol etmeden önce kaynak koddaki tüm yorumları silmek için küçük bir yardımcı program kullandım, bu nedenle yalnızca yorumlu bir check-in farkını 0 fark gösterecekti. Tüm değişiklikler (örneğin kullanılmayan alanların kaldırılması) eski geliştirici ile, hala ihtiyaç duyulan şeyleri kaldırmadığımdan emin olmak için dikkatlice gözden geçirildi.
• Kritik geçitlerin satır adım ilerleyişi : En iyileştirilmiş / karmaşık geçişler için, eski geliştiriciyle ve bazen de üçüncü bir meslektaşımla kod satır satır satır üzerinden geçeceğim. Bu şekilde, kodun tam olarak anlaşılmasını sağladım ve daha fazla kişi kodu gözden geçirdiğinde, aslında daha da iyileştirilebilecek bazı şeylerin yanı sıra birkaç hata da belirledik.
• Çabuk olun ve eski geliştiriciyi motive edin: Eski geliştiricinin son gününün yaklaşmasıyla (şaşırtıcı şekilde değil) daha az ilgi duyduğunu fark ettim. Bu nedenle, en kritik parçaların ilk önce teslim edildiğinden emin olurdum, gerisini gerekirse kendi başıma çözmem için bırakırdım. Ayrıca ona daha eğlenceli şeyler bırakmaya çalıştım (örn. Çift programlama sırasında klavyenin kontrolü) ve kendimi belgeler gibi sıkıcı şeyler yapmaya çalıştım.
• Özellik isteklerini belirleme: Eski geliştiriciden, insanların istediği, ancak henüz eklenmemiş olan özelliklerin listesini sormasını faydalı buldum. Bana eklenmesi kolay görünen birkaç şey vardı, ancak ilk başta düşündüğüm gibi uygulandıklarında başka şeyleri kırdıkları için eklenmemelerinin iyi bir nedeni vardı.

Benzer bir durumda olan, aşağıdakilerin de dikkate değer olacağını düşünüyorum:

• Bir dağıtım yapabileceğinizden ve test edebileceğinizden emin olun: Sıfırdan, ürünün kendi dağıtımını yapın - ve bunun ayrılan kişi tarafından yapılanla aynı olduğunu doğrulayın . Bu, tüm komut dosyalarının ve talimatların sizin için açık ve net olmasını sağlar ve sürüm kontrol sisteminize giriş yapılmayan içerikler gibi kazayla gözle görülür bir görüş yakalar. (Bu demiyorum ediyorum o eğer sadece, ne etti olmuş kişi ayrılmadan önce, o şimdi başa çok daha kolay olacaktır)

  (Bu, örneğin Sürekli Entegrasyon veya Sürekli Dağıtım yaptıysanız, sizin için uygun olmayabilir, ancak söz konusu olduğunda, söz etmeye değer…

• Daha fazla test Yazma: Bu bir gerçekten bir sistemin anlayışınız sınamak için iyi bir yol. Kodun alanlarına daha yakından bakmanızı sağlar (veya zorlar) ve kodun, şüphelendiğiniz kadar hatasız olduğunu veya niyeti anladığınızı düşündüğünüz alanları ortaya çıkardığını doğrular; ayrılmadan önce meslektaşınızdan açıklama istemeniz gerekir

• Belgelerin eşleştirilmesi: Bu, genel bakış yazmanın etkili bir yoludur. Sana bir özelliği veya alan tanımlamak için İş arkadaşınızın olsun öneriyorum ve sonra sen kendi deyişle, belgelerde, o kadar yazın. Birlikte iki kişi tarafından yapıldığında bunun çok daha kolay olduğunu gördük .

Testlerin yazılmasını, kişisel olarak, testlerin size muhtemelen daha fazla veya daha sıkı bir şekilde anlamanızı sağlayacağından, belgelerin yazılmasından daha öncelikli koyardım.

Çift programlama kullanarak Refactoring ile ilgili olarak söyleyeceğim tek şey, bunun sadece düşük seviyeli testlere sahip olduğunuzu söylediğiniz göz önüne alındığında, bunun dipsiz bir çukur olma tehlikesi olduğudur. İstediğiniz sürenin daha fazlasını kullanarak bittiğini görebilirsiniz.

Sorunuzda zaten var cevaplar için +1!

Rehberli tur
10k kod satırı çoktur, ancak diğer adamın size 'rehberli tur' vermesinin hala imkansız olmadığını düşünüyorum. Kodun önüne birlikte oturuyorsunuz ve sizi yukarıdan aşağıya doğru bir yolculuğa çıkarıyor, 'katmanları' inceliyor. Bunu kısa aralıklarla yapmanız gerekecek - bir seferde hepsi ikinizi de öldürür.

Zoom-zoom, zoom-out
Bunu yapmanın avantajı, size açıklarken, sadece belgelemeye çalıştığında yapamayacağı bazı "oh, evet, bu da var" anları olacak. kendi başına. Ve sorularınız, açıkça göze çarpacak başkalarına değil, kimseye açık olmayan bitlere odaklanmanıza yardımcı olacaktır. Bu tür yakınlaştırma / uzaklaştırma etkileşimi, yalnızca birebirdir, hantal bir şey yazmaya veya okumaya çalışırken mümkündür.

Dokümantasyon
Bence her ikinizi de bağımsız olarak belgelemelisiniz - en alttan başlamalı (birlikte oraya gitmek için vaktiniz yoksa) ve en baştan, ne anladığınıza dayanarak başlamalısınız. rehberli turu ve sanki başkası gibiydi [önceki bir işte çok sayıda 'eski' kod devralmıştım ve sadece kendimi terk etmeden önce belgelemek için zamanım oldu :)].

Neyin var?
Bunun çoğunun amacı, olayların gerçekleştiği yer hakkında bir fikir edinebilmenizdir. Böylece, belirli bir hata veya değişiklik yapıldığında, konsantre olmanız gereken koddaki yeri çok hızlı bir şekilde bulabilirsiniz. Eski hataların listesini alarak ve sorunun nerede olduğunu doğru bir şekilde tahmin edip edemediğinizi görerek kendinizi test edebilirsiniz.

Onu kurulayın
. Senden nefret etmesi bilemezse (gülümseyebilir), işin o adamın beyninden mümkün olduğu kadar fazla bilgi almaktır. Tarafınızdan yönetim aldığınızdan ve bilgi aktarımını "ayrılmadan önceki son birkaç hatayı düzeltmek" (öncelikli olarak onarımacaksanız…) üzerinden önceliklendirdiklerinden emin olun.

Aşağıdakileri öneriyorum (önceden tanımlanmış olanlara ek olarak) - Öncelikle, yöneticinizden size bu adamla mümkün olduğunca çalışmanız için zaman vermesini ve değişiklik yapmakla görevli olduğu zaman onunla oturmaya çalışmasını isteyin. Yaptığı her şeyi bilmek zorunda değilsin ama olabildiğince çok yakalamaya çalış. En önemlisi onunla arkadaş olmak.

Teslimi bir proje olarak ele alın ve bir plan yapın ve yönetimi dahil edin.

0 - Sistemi nasıl kullanacağınızı bildiğinizden emin olun.

1 - Çözüm bileşenlerinin, her birinin kaynağının ve bulunduğu yerin net bir envanterini çıkarın (farklı havuzlarda)

2 - Şimdi başlayan farklı sunucular için şifreleri alın ve mümkünse yönetin. Tüm yönetici hesap bilgilerine sahip olduğunuzdan emin olun.

3 - Kapsamınız dışında olmadığı sürece (örneğin özel ödemeler, veritabanı vb.) Her bir harici bileşenin lisansını alın.

4 - Geliştiriciden ve müşterilerinizden sistemin mevcut durumu hakkında yazılı bir rapor alın (şirketiniz yerelindeyse)

5 - İşletme kuralları, hesaplama formülleri vb. Belgeleri alın. Bunu onunla yapabilirsiniz. E-postalarını, toplantı bilgilerini, kullanıcı gereksinimi belgelerini, tasarım belgelerini ve sana verilmesini istediğini söyle.

6 - Yazılımın yanıt vermesi gereken zamanlanmış etkinliklerin bir listesini (aylık işler, haftalık işler)

7 - Yedekleme / geri yükleme prosedürlerini öğrenin

8 - Uygulamayı oluştururken kullanılan çerçeveyi / çerçeveleri anlayın

9 - İstenen / beklenen / planlanan değişiklikleri ve bekleyen kullanıcı isteklerinin durumunu öğrenin. Bunları kendi başınıza nasıl yapacağınızı belirlemeye başlayın.

10 - Test ve geliştirme ortamlarınızın çok benzer olduğundan emin olun.

11 - Kolayca tespit edilemeyen büyük bağımlılıkları (diğer sistemlerde veya bileşenler arasında) belirlemeye çalışın.

12 - Her bir yazılım kullanımının gerekli sürümlerini ve satıcı iletişim bilgilerini belirleyin ve belgelendirin (gerekirse)

13 - Size yardımcı olması durumunda kullanmadığı özel araçları tanımlayın.

14 - Yüksek düzeyde bir sistem akışı elde edin. ve dokümantasyon kütüphanenizi oluşturmaya başlayın

15 - Uygulama için kullanıcı güvenliğini nasıl yöneteceğinizi anlama

16 - Hata günlüğünü alın ve eylemleri ve eylemin eski verileri nasıl etkilediğini anlamaya çalışın (varsa)

17 - Çok uzun süren süreçleri ve neye dikkat etmeniz gerektiğini (örneğin olağandışı dosya boyutları, çift kopya ftp'ler vb.) Bilin.

18 - Üretim sunucusu saatini kontrol edin

19 - Konfigürasyonların nerede olduğunu belirleyin ve hangi parametrelerin farklı olduğunu ve nedenlerini bilmek için her bir ortam konfigürasyonunu üretim ile karşılaştırın.

20 - Bu adamın iletişim bilgilerini al

21 - Sistem iç ise, sistem kullanıcıları ile bir toplantı planlayın (kim olduklarını ve her birinin ne rol oynadığını bilmeniz gerekir) ve bunlarla tanışın. Varsa, sistem ve mevcut problemleri hakkında söyleyeceklerini dinleyin. E-postalara mümkün olduğunca erken dahil edildiğinden emin olun (yöneticinizin onayından sonra)

22 - Ayrılmadan 1 hafta önce anlayışınızı değerlendirin ve risk olarak gördüğünüz sorunları bildirin.

Veritabanınızın olmadığını söylediğinden beri, bu liste kısaldı.

İyi şanslar.

Önce en karmaşık, performans için optimize edilmiş parçaları düşünürdüm. İlk önce bu parçaları belgelemesini ve bunları size tek tek anlatmasını sağlarım, sonra bu parçalara karşı testler yazmaya çalışırdım (performans testlerinden önce ve sonra da dahil olmak üzere, böylece yeni bir optimizasyonun işleri daha iyi veya daha kötü hale getirip getirmediğini görebilirsiniz. ) ve diğer kişinin testleri incelemesini isteyin. Bu şekilde, testleri yazmak için açıklamayı kullanır (farklı bir alanı belgelendirirken) ve incelemesi, neyi test etmeniz gerektiğini anladığınızdan emin olmanıza yardımcı olur. Bu şekilde, uygulamanın en kritik bölümlerinden bazıları ve özel performans optimizasyonlarının dokümantasyonu için ek test kapsamı elde edersiniz.

Bunları kapattıktan sonra zaman varsa, daha sonra başvurunun yıllar içinde en sık ihtiyaç duyulan, ancak belgelenen ilk grupta olmayan bölümleriyle benzer bir süreçten geçeceğim.

Sonra kalan her şeyi belgeleyin.

Bence bazı büyük kodları almanın en iyi yolu yukarıdan aşağıya yaklaşımdır. Önce büyük resmi anlamaya çalışın ve ardından bileşenlere birer birer daha derinden inin.

Şimdi her kazma düzeyinde, en çok dikkat gerektiren kısımları önceliklendirmesini isteyin. Seni mümkün olduğu kadar açıklamasın, ama daima kendin de belgele.

Kendinizi belgelemenin en iyi yanı, daha sonra geri döndüğünüzde, içinde bulunduğunuz bilişsel durumu hatırlatmakta hiçbir sıkıntınız olmayacağıdır. Sen çok daha kolay anlayabilir sen başkasının yaptığından daha yazdı. Tecrübelerime göre, aynı kod parçasını belgeleyen iki kişi benzer görünümlü metin parçaları üretmiyor.

Bu, sanırım "neyi ve nasıl belgeleyeceğini" sorunlarını da çözüyor. Size her şeyi açıkladığında, koda döndüğünüzde nelerin belgeleneceğine kendiniz karar verebilirsiniz - ve yalnızca bu bölümleri belgeleyin.

Buradaki fikir, ilk önce kodu (varlığında) tamamen anlamak ve daha sonra (yokluğunda) kullanmanıza izin verecek her şeyi yazmak / yapmaktır.

Kodun tamamen anlaşılması ile demek istediğim, büyük resim hakkında bir fikir edinmeniz - ve her bir bileşenin bu büyük resim ile nasıl bir bağlantısı olduğunu. Her bir parçanın bütünü nasıl topladığını takip etmeyi özellikle yararlı buldum. Yalıtılmış bir şeyi kavramaya çalışmayın - bağlamı gözden kaçırmayın.

Son olarak, yukarıdakileri yaptıktan sonra, proaktif olarak kontrolü elinize alın. Hangi test ünitesinin kapsanması gerektiğine kendiniz karar verin. Hangi parçaların optimize edilmesi gerektiğine (ya da iyileştirilebileceğine), bir bileşeni nasıl yeniden değerlendirebileceğine vb.

Senin için hissediyorum.

Birkaç öneri:

1. Ayrılan programcı ile yaptığınız her konuşmayı bantlayın!
2. "Büyük" sorunların ardındaki motivasyonu isteyin. API'yi anlamanız iyidir, ancak iç kararları araştırın - kod neden olduğu gibi bölümlendi? sorumluluklar neler?
3. Kodu gerçekten incelemek için çaba gösterin. Bakım ve destek görevlerini üstlendiğiniz zaman, bazen "ilerlerken kodu çalışmak" için baskı olabilir. Yapabiliyorsanız direnin ve gerçekten kodu inceleyin.
4. Senaryoları ara. API'yi biliyorsunuz - kodun nasıl davrandığını görün. Akla gelen bir örnek, bir Faks modülünün örneğidir. API'nin bir kullanıcısı olarak, bir sayfa görüntüsü hazırlamanız ve kodu, sayfayı iletmek için bir komut göndermeniz gerektiğine inanıyorsunuz. Ayrılan programcıdan, bu senaryonun nasıl gerçekleştiğini görmek için kodda sizinle birlikte çalışmasını isteyin. Ardından, elbette, "alma sayfası" senaryosuna gidin.
5. 80/20 - önce daha genel senaryoları ele almaya çalışın.
6. Yeniden yazmayı düşünün. Kod eskiyse ve arayüzler iyi tanımlanmışsa, belki de teknolojiyi doğrulamak için yeterince değişti.
7. Bunu söylemekten nefret ediyorum ama yeni bir iş aramayı düşünün.

Makul bir şekilde acısız bir şekilde iyi bir belgelendirme istiyorsanız, Pascal Analyzer'ın (PAL) bir kopyasını satın alın. Bunu Delphi projelerinde kullandım ve harikaydı; bu yüzden her ikisini de (<300 USD) satın almanız gerekebilir, ancak PAL, işlevlerin vb.

Kodumun nasıl yapılandırıldığına dair bir fikir edinmek için PAL kullanın, ayrıca deneyimim devam edecek bir şeyse muhtemelen yaklaşık 1000 önerilen iyileştirme listesi. Listede çalışmak kodun kalitesini iyileştirecek, büyük ölçüde basitleştirecek ve gelecek için hayatınızı kolaylaştıracak. Delphi'nin kendisi, son sürümlerde (son 5 yıl ya da öylesine) yeniden düzenlemeyi desteklemektedir. Dpr dosyasına her şeyi dahil etmen gerekiyordu, bu yüzden bunu yaparken aklımdayken gerçekten düzgün çalışabildi.

Birim testleri istiyorsanız, DUnit'i indirin ve orijinal kodlayıcı ile bazı testler oluşturmaya başlayın - bu muhtemelen zamanlarının en azından bir kısmını kullanmanın yapıcı bir yoludur.

Bir arka uç veritabanı hakkında bahsetmedin ama bir tane varsayalım ki

1. Veri modelini özellikle sütunlar ve PK-FK belgelendirin
2. Bir sql izlemesi kurun ve uygulamayı kullanırken ateşlenen tüm sorguları kaydedin. Sorguların yürütme sırası, uygulamanın akışı hakkında iyi bir fikir verecektir ve ayrıca hata ayıklamada size yardımcı olacaktır.

Mimarımızın Avustralya'ya taşındığı ve son 8 yıldan beri olduğu gibi çok eski miras bıraktığı aynı durumdayım. Kendisi, müteahhit olan önceki Mimar'dan kalan eski şeyleri miras aldı.

Siz ve diğerleri zaten iyi noktalardan bahsettiniz ama işten ayrıldıktan sonra karşılaştığımız problemler daha iyi hazırlanabilirsiniz ...

1) (Teknik Kişi) Satış yaptığı müşterilerin iletişim bilgileri.

2) Yazılım lisansları aldığı hesabı, her yıl yenilenmesi gereken anahtarlar ve bunları yenilemek için işler / maliyetler.

3) Üçüncü taraf yazılım kütüphanelerinin / bileşenlerinin ve ürünlerinizle bütünleşen ürünlerin kurulum belgesi. 4 gün boyunca IT'nin alanı boşalttığı ve kendilerine yanlış talimatlar verildiği için kaybedilen bir makineyi geri getirmek için mücadele ettik.

4) Kaynak kodu depozito şirketlerine (örneğin Emanet) yazılıma vermek için kullanılan belgeler / adımlar.

5) Hala uzun bir liste var, ancak sizin için geçerli olmayabilir. Ayrıca hiçbir belge gerçek bir insanın yerini alamaz.

Ayrıca, bu sizin için ilk defa mı bilmiyorum. Benim için 5/6 işverenlerle çalıştım ve her zaman hatalı belgeler içeren veya hiç belge olmayan kodlar aldım. Böylece tüm belgelerle birlikte sadece olumlu kalın :)