Halefleriniz için neyi geride bırakmalısınız?

İşten ayrılan tek bir geliştirici olduğunuzu varsayın. Kodunuzun dışında ne tür bilgi / materyaller oluşturmalı ve değiştirilmeniz için geride bırakmalısınız?

Açık bir cevap, "yeni bir işte ne istersen" kesinlikle, ama yeni bir işe başladığımdan beri bir süredir ve o zamanlar ihtiyacım olan en önemli şeylerin ne olduğunu unutuyorum.

Düşünüyorum:

• hesap / şifreleri
• ekipmanın yeri, yedeklemeler, yazılım CD'leri

Başka?

• Hesaplar ve Şifreler
• Sunucu bilgileri
• İyi kod
• belgeleme
  • Veritabanı diyagramları ve açıklamaları inanılmaz
  • Koddaki tuhaflıkların listesi
• prosedürler
• Manuel süreçlerin veya zaman zaman açık olmayan işlerin açıklaması
• Kullandıkları veya faydalı buldukları programların listesi
• İletişim bilgileri ;)

Güçlü bir fincan kahve ve bir özür notu.

Keşke kalmam .

• Belgeler. Birkaç yorum yazmak ne kadar zor? Sistem notlarını hareket ettirerek notlar, dağıtım notları oluşturun. Yeniden başlattığınızda ve her şey bittiğinde ne yapmalısınız?
• Kağıtlar. Yukarı yaz niye bunu başka bir yol yapmıyor neden merak zorunda kalmamak için bu şekilde yapılıyor. Yedekleme sistemi nasıl çalışır, sunucu yüklere, testlere, test senaryolarına, kullanım senaryolarına nasıl tepki verir.
• Notlar. "Veritabanını kullanırken asla söyleme SELECT * FROM clients. Neden olduğundan emin değiliz ama veritabanını döküyor" .

E-posta adresim, hatta telefon numaram.

Deneyimlerime göre, her ayrıntıyı yazılı hale getirmek zordur, bu yüzden halefleriniz daha fazla bilgiye ihtiyaç duyuyorsa en iyi şey (belirli bir dereceye kadar) mevcut olmaktır.

Yazdığınız programların dokümantasyonu, örneğin amaçları, gelecekteki geliştirme için kaynak dosyalarının yeri, şifreler vb.

Bu, yorum olarak kodun içinde veya açık görüşte olabilir.

Sadece dokümantasyondan öte, bazı kararların alındıklarında neden verildiğini bilmek istiyorum. Şu anda bir projede SWIG kullanıyoruz ve diğer geliştiricilerden biri neden Boost :: Python'u neden kullanmadığımızı bilmek istiyordu. Basit cevap, müşterinin o sırada Boost kullanımına izin vermemesiydi. Şimdi farklı bir hikaye.

Bu tür şeyler onlara sadece projeyi anlamada değil, aynı zamanda uygulamanızın hangi sınırlamaların / kısıtlamaların / zorlukların üstesinden geldiğinde de yardımcı olacaktır. Onlara gelecekteki bakım ve özellik artırımı için bir başlangıç ​​noktası verecektir.

Başka kimsenin bahsetmediğini göremediğim bir şey (bunu gözden kaçırmış olmama rağmen) bir geliştirme ortamının nasıl kurulacağını belgelemektir. Çoğu zaman sadece birkaç şey yüklediğini, en son aldığını, derlediğini ve bittiğini anlıyorum. Ancak bazen bundan daha fazlası vardır (SharePoint akla gelen bir durumdur) ve hangi akı kapasitörünün hangi şekilde yapılandırılması gerektiğini belgelemek sizi takip eden fakir ruh için çok yardımcı olacaktır.

Bir masaüstü programıysa, tüm sistemi sıfırdan nasıl oluşturabilirsiniz (birkaç ayrı program olabilir), dağıtım için bir paket nasıl oluşturulur (sahip olduğu bağımlılıklar, örneğin .NET sürümleri) ve sunuculara nasıl dağıtılacağı uygulanabilirse indirmek için veya bir CD veya DVD'ye yazın.

Web tabanlı bir programsa, FTP ve (varsa) sunucuya SSH erişimi ve kodu yerel olarak oluşturmak ve test etmek için kullanılan araçlar.

Gömülü bir sistemse, ikili görüntüyü oluşturma, hangi araçların kullanıldığı, kodun ürüne nasıl indirileceği ve flash ile gönderilmesi, varsa dosya sisteminde nasıl ayarlanacağı ile ilgili talimatları tamamlayın.

Kısa süre önce size benzer koşullarda bir iş bıraktım ( tek geliştirici değildim, ama gerçekten sadece ikimiz vardı, bu yüzden diğer adamın sahip olmadığı çok fazla bilgim vardı (ve tersi, elbette)).

Normal dokümantasyonla ilgili olarak, tüm sisteme bir genel bakış belgelemek önemlidir. Münferit bileşenler zaten kodda belgelenmiştir, ancak bileşenler arasındaki etkileşim ve bunun neden böyle yaptığı veya bunun bu bileşenle konuşması gerektiğinden önemlidir ve sadece kodda hata ayıklayarak / bakarak her zaman kolay değildir.

Yaklaşık bir ay önce bıraktım için Sonra, ben sadece o şey yaptım her zaman olabilir yapmak, ben neden yapmak zorunda ve ne tam olarak ne olduğunu yazdım. Bu genellikle "xyz bileşeninde bir hata vardı, düzeltmek için X nedeniyle abc dosyasına bakmayı biliyordum, o zaman bu, bu ve bu" zorundaydı bir durum oldu.

Tabii ki, e-posta adresimi ve telefon numaramı kendi başlarına anlayamadıkları bir şey olması durumunda bıraktım. İlk birkaç hafta içinde birkaç telefon aldım, ama yavaş yavaş düştüler.

Hepimiz fonksiyonel gereksinimlerin bir listesini içeren sistemin eksiksiz bir veri akış şemasını istiyoruz. Muhtemelen, sistemi ilk yazdığınızda bunu asla anlayamazsınız! Çoğu yerde olduğu gibi en iyi belge muhtemelen kod kendisi yani en çok isterim iyi belgelenmiş kod. Kodda hem teknik hem de işlevsel olarak ne yapmaya çalıştığınızı açıklayan satırlar ve yorum satırları.

Dokümantasyon için 1. kural değil neyi öyle ama neden . Çalışan programların arka planı nedir ve ne yaparlar?

Her zamanki gibi belgelerin yanında görmek istediğim şey, özelliklerin dışında bırakılmış olacağını düşünüyorum. Gibi belirli fikirler neden DEĞİL uygulanan veya belirli bir platform ya da yöntem DEĞİL (bariz bir seçim aksi olduğu) kullanılır.

Bu halefin her zaman ne yapmamasını veya daha yetenekli olup olmadığını bilmesini sağlar, belki de etrafında bir çalışma yapabilir ve bazı özelliklerin çalışmasını sağlayabilir.

Bu özellikle açık kaynaklı projeler için geçerlidir. Çok zaman ve beyin gücünden tasarruf edebilirsiniz!