Doğru miktarda dokümanın belirlenmesi


10

Şu anda çalıştığım yerde genel yaklaşım -

dokümantasyondan mümkün olduğunca kaçının

Yalnızca farklı bir ekibin ihtiyaç duyacağını belgeleyin

sadece açıklama için, kod dokümantasyonu demek istemiyorum - bunu yapıyoruz, tasarım sürecini çevreleyen tüm dokümantasyonları kastediyorum - eğer UML veya DB Şemaları, sınıf şemaları ve spesifikasyonları ve benzerleri olan kelime dokümanları.

Patronumun belgelememe nedenini listeleyeceğim:

  1. zaman alıcı - uygulamaya odaklanın
  2. tasarım değişirse - o zaman belgeler değişmeli, çift sorun
  3. sonunda kimsenin okumak istemediği yüzlerce sayfa elde edersiniz ve kimse gerçekten düzenlemez, bu yüzden zamanla güncelliğini yitirir
  4. Bu bir acı - kimse gerçekten yapmak istemiyor

Şimdi daha hızlı çalıştığımızı anlıyorum, ama buraya gelen ve hiçbir şey anlamadan doğrudan eski kodlara daldığımız zamanı da hatırlıyorum.

Aslında, hala bu eski kodun çoğunu alamıyorum ve bazen içeri girdiğimde farklı geliştiricilerden küçük düzeltmeler yapmaya çalışan birçok yamalar görüyorum.

Belgeleme eksikliğinin bu tür yamaları ve geniş anlamda sistem anlayışı eksikliğini arttırdığını düşünüyorum.

sorum şu:

Ekip arasında sürekli bilgiyi teşvik edebilmemiz ve hala hızlı ve verimli olabilmemiz için belgeleri nasıl dengeleyebiliriz?


Benim yerimde de aynı sorun var - takımım kod yorumları bile yazmıyor!
MattDavey

1
En azından asgari gereklilikleri ve spesifikasyonları belgeliyorlar mı? Değilse, bitmiş ürünü karşılaştırmak için herhangi bir gereklilik yoksa doğru şeyi kodladığınızı nasıl anlarsınız?
SinirliWithFormsDesigner

özellikle modern dillerde teknik dokümantasyon kodu belgelemekten çok daha önemlidir. kod kendi kendini açıklayıcı olmalıdır.
AK_

Çok fazla dokümantasyondan kaçınmak gerçekten iyi bir fikir olsa da, patronunuz bunu tüm yanlış nedenlerle yapar.
Christian Rau

Şirketinizin faaliyet gösterdiği sektör hakkında fikir verebilir misiniz? Bazı endüstriler, asgari düzeyde belge gerekliliği konusunda yasal zorunluluklara sahiptir.
tehnyit

Yanıtlar:


5

HERHANGİ BİR dokümantasyon NO dokümantasyonundan daha iyi buldum. Uygun miktar genellikle bunu yapmamız gereken süreye veya telefon görüşmelerinden ve e-postalardan ne kadar nefret ettiğimize göre belirlenir.

Mevcut ekip üyelerinizin anıları hakkında gerçekçi olmayan beklentileri olduğu ya da yazma becerilerinden utandıkları ve pratik yapmak istemedikleri anlaşılıyor.

Belgeyi angarya olarak bulamadığım için burada bir azınlıktayım (lisansüstü okulda yazılım mühendisliğine giren İngiliz bir anadal). Değerli bir profesyonel araç. Yazmayı bazı iş arkadaşlarım kadar zor bulamayabilirim, ama bunun sebebi daha çok pratik yapmam. Bir projenin belgeleri olmadığı sürece bittiğini düşünmüyorum ve genellikle tamamen bencilce nedenlerle yazıyorum: bu yüzden telefon görüşmeleri ve e-postalar almak yerine insanlara bir şeyler okuyabilirim, ya da en son ne hakkında konuştuğumuzu hatırlayabilirim veya gecenin ortasında desteklemem gerekirse nasıl bir şey yaptığımı anlatabilirim.

Belgelere yaklaşmanın en iyi yolu, tıpkı test kodu yazmak gibi, SİZİN GİBİ gibi yazmaktır. Önceden yazılmış birkaç şablonun (başlıklar, kod dizileri vb.) Dokümantasyonu nasıl daha kolay ve hızlı hale getirebileceği şaşırtıcı. Bu şekilde, değişikliği gerçekleştiği anda yakalayabilirsiniz ve zamanla örtmek için daha az zemine sahip olursunuz. Bu şekilde daha verimli olursunuz, çünkü belgelere ihtiyacınız olduğu gibi başvurabilir ve bu şekilde değiştirebilirsiniz. Örneğin, bir wiki'de bunu yapmak güncelleştirmeleri kolaylaştırır ve en son ve en büyüğü her zaman aynı yerde çevrimiçi olduğunda belge sürümü sorunlarından kaçınabilirsiniz ve yalnızca okuması gereken kişilere bağlantılar gönderebilirsiniz.

Belgelemek için biraz zaman harcarsanız, özellikle de yeni bir kişi takıma katıldığında TÜM daha hızlı çalışacaksınız, çünkü her şeyi anlamak için zaman harcamak zorunda kalmayacaklar. Bir şeyler bulmak işimizin eğlenceli bir parçası, ancak üretimi düzeltmek için acele etmeniz gerektiğinde eğlenceli değil. Hepimiz birkaç not daha yazsaydık hepimiz çok zaman kazanırdık.

Ekibinizin test veya test kodu yazmayla aynı sorunları var mı? Değilse, bu daha kolay bir satış olacaktır.

Belgeleriniz birçok açıdan faydalıdır:
1) Proje üzerinde çalışırken şu anda size ve iş arkadaşlarınıza.

2) müşterilerinize. Kullanıcılara gösterebileceğiniz belgelere (diyagramlar dahil) sahip olmak, özellikle karmaşık sistemleri tartışıyorsanız, toplantılardaki tartışmaları kolaylaştırır. Belgeler eksik olsa bile, başlangıç ​​noktasıdır.

3) Çalışmanızı devralacak insanlara (üç yıl içinde bile siz olabilirsiniz). Genç meslektaşlarımın çoğu, sonsuza dek bir şeyler hatırlayacaklarını düşünüyor. Bunu yazmazsam bu haftadan sonra hatırlamayacağımı biliyorum. Belgelere sahip olmak, bir şeyi nasıl yapılandırdığınızı hatırlamak ve her şeyi tekrar anlamak zorunda kalmak için yarım gün harcamaktan kurtarır.

4) Durum siyasi veya tartışmalı olursa, size ve başkalarına. Toplantılarda not alan biri olarak, kendimi uyanık tutmak ve can sıkıntısıyla mücadele etmek için, genellikle kararın yazılı versiyonuna sahip olan tek kişi oldum. Yazan kişi anlaşmazlığı kazanır. Bir dahaki sefere birisi "Geçen kış konferans salonu 4'te buluştuğumuzu, X'in üzerine gittiğimizde? Fred oradaydı ve Muhasebe'den gelen adam kim?"


1
3. nokta için +1. Kendi kişisel belgelerim beni çok defa kurtardı.
Brandon

Benimkini genellikle Markdown'da (bazen biraz matematik olduğunda LaTeX'te) kodla aynı git repo'suna atıyorum.
TRiG

4

Son birkaç işverenimde "geliştirme" wiki'miz oldu. Önemli işlevsellik parçaları (yeni içe aktarma / dışa aktarma feed'i, güvenlik alt sisteminin nasıl çalıştığı, sistem yüklenen belgeleri nerede saklar vb.) Hepsi burada belgelenir. Genellikle kod inceleme adımından önce tamamlanması zorunlu bir öğedir. Başlangıçta genellikle biraz direnç var, ancak birisinin biraz bilgi araması gerektiğinde ve orada, başka bir dönüştürmeniz var.

Wiki formatında sahip olmanın en güzel yanı, tüm güzel Word formatlarını ve daha fazlasını yapmaya daha az meyilli olmanız ve kaydetmeniz gereken gerçek bilgileri yazmanızdır. Çoğu (hepsi olmasa da) wiki paketi, belgeleri veya görüntüleri (Visio UML diyagramları veya UI tel çerçeveleri gibi) yüklemenize izin verir, böylece görsel parçalara da sahip olabilirsiniz.

Çoğu şey gibi, bence işe yarayabilecek en düşük miktarı da yapmayı hedeflemelisiniz. Bu hiçbiri ile aynı şey değil.


Bu harika bir öneri. Bazı wiki, içeriğin bir .rtf belgesine dışa aktarılmasına izin verir. PHB için neredeyse mükemmel.
tehnyit

XWiki'yi, özellikle PDF, RTF ve HTML'de belge oluşturma yeteneği için kullanıyoruz. Kötü iyi.
Jennifer S

2

Doğru belgeleri yazmak için zaman ayırmaktan kaçamazsınız. Ne kadar iş verdiğinize bağlı olarak bunu dengeleyin, ancak yaptığınız işi belgelemek için zamanınızın% 15-20'sini bırakın. Takımdaki herkes menajeriniz de dahil olmak üzere bununla birlikte olmalıdır, aksi takdirde sadece başkalarının yararına belgeleyeceksiniz ve karşılığında hiçbir şey alamayacaksınız. Dokümantasyon, geliştirme sürecinizin ayrılmaz bir parçası olmalıdır.


1

Belgeler, HOW parçasını gerçek koda ve NE parçasını birim testlerine bırakırken neden bir şey yaptığınızı söylemelidir. Daha fazlası bir acıdır. Bu genellikle bir başlangıç ​​noktası isteyen akıllı insanlar için yeterince iyidir.

Ayrıca, kod tabanınızın her büyük bileşeninin genel olarak yüksek düzeyde bir mimarisini korumayı unutmayın. Yeni ekip üyelerini teşvik etmeyi çok kolaylaştırır.

Son olarak, ne zaman bir tuhaf düzeltme eklerseniz, bir yorumdan hata veritabanınıza bağlantı - çok yararlı.


1

Patronunuz haklı, kimsenin okumayacağı UML belgelerini yazdırmayın. Ekibimizde yaptığımız şey, sınıf diyagramı görünümlerini kullanarak modelde canlı olarak gezinmektir. Prensip MOF'u her zaman güncellemek, UML modeli koddan canlı olarak ve sınıf diyagramının modelin sadece bir görüntüleyicisi olmasına izin vermek, modelin kendisini değil.

Gerçekten iyi çalışıyor çünkü tüm karmaşıklık backoffice model düzeyinde yapılıyor. Projemi yeniden düzenleyebilir, java doc yazabilir veya modelde uml belgeleri yazabilirim. Bu bir tür tık ve git. Tıkladığınızda canlı belgeleri alırsınız. Bir şey net değilse, o zaman sınıf diyagramını açar ve onunla oynamaya başlarım. Diyagram sınıflandırıcılarından silme, yeni sınıflandırıcılar ekleme, yakınlaştırma ve uzaklaştırma, ilişkilendirme, ilişkilendirmeyi silme vb.

Bir paketin şemasını açmak ve doğrudan sınıf şemasında bu sınıfın ne olması gerektiği hakkında bir yorum okumak gerçekten önemlidir. Bu yöntemin ne yapması gerekiyor ve akış vb.

UML harika, gerçekten yararlı, ancak modelleme / geliştirme aşamalarında daha fazla esneklik ve daha fazla yineleme sağlamak için Model Odaklı Geliştirme'yi kullanmayı bırakmalıyız. Sınıf diyagramı koddan canlı olarak güncellenir ve belgeler her zaman doğrudur ve sadece bir tıklama ile kullanılabilir. Bir araçtan bahsetmeyeceğim, ancak Java ve Eclipse kullanıyorsanız hangi aracı kullandığımı bulmak kolay :-)

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.