Bao nhiêu tài liệu là đủ?


15

Bao nhiêu tài liệu kỹ thuật (cho các nhà phát triển trong tương lai) là đủ ? Có một tỷ lệ giữa giờ mã hóa và giờ tài liệu phù hợp không?

Papadimoulis lập luận rằng bạn nên

sản xuất số lượng tài liệu ít nhất cần thiết để tạo điều kiện cho sự hiểu biết nhất,

Đó có phải là một hướng dẫn tốt, hay có những thứ cụ thể tôi nên tạo ra?


1
Người dùng cuối / UI hoặc tài liệu mã kỹ thuật / mã nguồn?

2
Để được tư vấn về mã nguồn, hãy xem câu hỏi đầu tiên của trang web của chúng tôi: lập trình
viên.stackexchange.com /

Câu trả lời:


24

Làm thế nào về một số thử nghiệm khả năng sử dụng hành lang? Hiển thị mã và tài liệu cho một nhà phát triển không quen thuộc với dự án. Khi bạn có thể làm điều đó mà không cần quá nhiều để giải thích điều gì đó trong khi xem họ xem lại mã, bạn đã có đủ.


1
+1 Tôi cũng thích ý tưởng đó. Phát triển phần mềm của bạn sao cho trực quan đến mức tài liệu không cần thiết.

12

La perfection est atteinte non pas quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retirer.
Antoine de Saint-Exupéry

(bằng tiếng Anh: Không đạt được sự hoàn hảo khi không còn gì để thêm, nhưng khi không còn gì để xóa nữa).

1
Vì vậy, một dự án mà tất cả các tài liệu đã được gỡ bỏ, là hoàn hảo?

@ ThorbjørnRavnAndersen - Không, sự hoàn hảo đạt được khi loại bỏ bất kỳ nội dung nào sẽ làm giảm giá trị của tài liệu nói chung.
cjmUK

1
@cjmUK và cách giải thích đó trả lời câu hỏi được hỏi như thế nào?

@ ThorbjørnRavnAndersen. Nó không; đó là một bình luận để đáp lại bình luận của bạn - mà, đối với hồ sơ, tôi nghi ngờ đó là sự giải thích sai về câu trả lời của Benoit. Chỉ Benoit có thể trả lời cho chắc chắn. Tuy nhiên, câu trả lời của tôi được liệt kê ở nơi khác ...
cjmUK

2
Sai lầm. Nó có nghĩa là nhiều hơn không nhất thiết phải tốt hơn. Brevity sẽ được coi trọng, nhưng rõ ràng là không nếu làm một cái gì đó đơn giản hơn có nghĩa là bỏ lỡ thông tin hữu ích. Nhưng đồng đều, việc viết khối lượng và khối lượng tài liệu có thể khiến nhà phát triển khác khó tiếp cận thông tin hữu ích nhất. Khi viết tài liệu, bạn không chỉ cần nghĩ về những gì còn thiếu, mà cả những gì bạn có mà bạn không thực sự cần.
cjmUK

3

Tôi đã suy nghĩ về chủ đề này trong một thời gian.

Kết luận của tôi là - đó không phải là vấn đề về số lượng, mà là chất lượng và bối cảnh.

Ví dụ, một cấu trúc dự án phù hợp đánh bại các bình luận giải thích vị trí của các tệp (thực hiện so với cường độ)

Tương tự, phân loại để làm rõ bối cảnh nhịp đặt tên (Id trên một bệnh nhân -> Bệnh nhân.Id).

Tôi tin rằng DDD có tiếng nói trong tài liệu tốt - phân loại cung cấp bối cảnh, bối cảnh tạo ra ranh giới và ranh giới dẫn đến việc triển khai có chủ ý (đây là nơi nó thuộc về, thay vì nó cần tồn tại).

Bản thân mã không đủ tốt để được coi là tài liệu. Vấn đề trong hầu hết các trường hợp không nằm trong thực tế là hoạt động của các mã được nhận xét hoặc không được nhận xét, nhưng thay vào đó, động lực (logic miền) thì không.

Đôi khi chúng ta quên ông chủ của ai - nếu mã thay đổi, logic miền hoặc lý luận không nên, nhưng nếu logic miền hoặc lý luận thay đổi thì mã chắc chắn sẽ.

Tính nhất quán cũng rất quan trọng - bản thân quy ước là vô ích nếu nó không nhất quán.

Các mẫu thiết kế không chỉ là 'thực hành tốt' - đó là điều mà các nhà phát triển nên hiểu. Nói cho nhà phát triển thêm loại mới vào Nhà máy được hiểu rõ hơn là thêm loại mới vào phương thức (trong đó bối cảnh và tính nhất quán yếu hoặc thiếu).

Một nửa cuộc đấu tranh là sự quen thuộc .

Mặt khác, các API dường như thiên về nhiều tài liệu cũng rất nhạy cảm với miền và ngữ cảnh. Đôi khi chức năng sao chép không phải là xấu (cùng một thứ, các bối cảnh khác nhau) và nên được coi là riêng biệt.

Về mặt bình luận, thật tốt khi chỉ ra logic miền đằng sau lý luận.

Ví dụ, bạn đang làm việc trong ngành y tế. Trong phương thức của bạn, bạn viết "IsPatientSecure = true;"

Bây giờ, bất kỳ lập trình viên tử tế nào cũng có thể nhận ra rằng bệnh nhân đang được đánh dấu là an toàn. Nhưng tại sao? Ý nghĩa là gì?

Trong trường hợp này, bệnh nhân là một tù nhân được chuyển đến bệnh viện ngoài cơ sở một cách an toàn. Biết điều này, sẽ dễ dàng hơn để tưởng tượng các sự kiện dẫn đến thời điểm này (và có lẽ những gì vẫn cần phải xảy ra).

Có thể bài đăng này có vẻ triết lý nhất - nhưng hãy nhớ rằng đó là 'lý luận' hoặc 'logic' mà bạn đang viết - không phải là mã.


1

Tôi đồng ý với trích dẫn Papadimouslis. Mã nguồn có thể tự nói lên, nhưng mã không thể cho bạn biết lý do tại sao nó tồn tại, nên sử dụng nó như thế nào và cách thức hoạt động của mã.

Tôi không biết một tỷ lệ tốt.

Tôi được thừa hưởng hàng trăm dòng mã với rất ít tài liệu. Nó trở nên khó khăn cho tôi để hiểu tại sao mã được viết. Sau khi tôi tìm ra lý do tại sao mã được viết, tôi phải tìm ra cách sử dụng mã. Sau khi tôi phát hiện ra điều đó, tôi phải hiểu nó giả sử như thế nào để tôi có thể hỗ trợ và duy trì mã.

Chỉ từ kinh nghiệm, đừng đưa ra nhận xét quá cụ thể hoặc cuối cùng bạn sẽ phải duy trì mã thực tế VÀ tài liệu. Đó là một cơn ác mộng khi tài liệu và mã không đồng bộ.


1

Đủ để khiến bạn ngừng đoán thứ hai.

Nếu bất cứ lúc nào trong quá trình làm việc của bạn, bạn giống như "hmm có lẽ tôi nên ghi lại điều này", hãy tiếp tục và thực hiện nó. Sau đó, nếu bạn đã viết một số tài liệu và bạn giống như "có lẽ tôi nên giải thích điều này nhiều hơn", hãy tiếp tục và làm điều đó.

Rửa sạch lặp lại cho đến khi cảm giác đó biến mất.


1
-1: Về cơ bản, bạn đang nói 'ehhhh ... làm bất cứ điều gì bạn muốn'. Đó là một câu trả lời không.
Steven Evers

Anh ta dường như đang nói 'làm bất cứ điều gì bạn cảm thấy cần thiết' nghe có vẻ như là một câu trả lời hợp pháp cho tôi. Tôi sẽ cảnh giác với quá nhiều câu trả lời cụ thể hơn.
cjmUK

1

Tôi đã thấy rằng một cách tiếp cận theo hướng rủi ro như được trình bày trong cuốn sách Just Enough Software Architecture của George Fairbanks hoạt động rất tốt để hiểu được bao nhiêu tài liệu là đủ. Bạn có thể đọc phần trình bày khái niệm này (chương 3) trên trang web của anh ấy nhưng ý tưởng chính là:

  • Thể hiện những điều khiến bạn lo lắng về "sự hiểu biết hệ thống" là rủi ro
  • Ưu tiên các rủi ro
  • Giảm thiểu rủi ro cho đến khi nhóm của bạn cảm thấy rủi ro dự án đã được giảm đủ. Trong trường hợp này có lẽ bạn sẽ tạo ra một số loại tài liệu.

Để giúp hiệu chỉnh các mối quan tâm để bạn có thể ưu tiên các rủi ro mà tôi thấy hữu ích khi xác định một vài mục tiêu được gọi là Ngưỡng thành công , đó là mục tiêu tối thiểu mà nhóm của bạn nghĩ rằng một dự án "thành công" phải đạt được. Từ góc độ tài liệu, một ví dụ ToS có thể giống như "Nhà phát triển sẽ có thể xây dựng một trình cắm đơn giản trong vòng 4 giờ sau khi chọn khung công tác lần đầu tiên."

Bây giờ xác định một số rủi ro. Với hệ thống bạn đã xây dựng (hoặc đang xây dựng), điều gì khiến nhóm của bạn lo lắng nhất? Cụm từ này là báo cáo rủi ro. Tôi thích phong cách hậu quả điều kiện của SEI nhưng có những thứ khác. Ví dụ:

  • Mô hình dữ liệu lớn và phức tạp; các nhà phát triển có thể không biết nên sử dụng các yếu tố dữ liệu nào trong một tình huống nhất định.
  • Hệ thống có giới hạn kết nối API để tăng độ tin cậy; nhà phát triển có thể vô tình vượt qua giới hạn kết nối.
  • Plugin được sử dụng trong một số bước tiếp theo; nhà phát triển có thể không xây dựng trình cắm với các bước được yêu cầu này.

Bây giờ là một nhóm, ưu tiên các rủi ro. Đa phiếu hoạt động cực kỳ tốt.

Giảm thiểu rủi ro ưu tiên hàng đầu và lặp lại bắt đầu bằng nhận dạng cho đến khi rủi ro dự án của bạn thất bại (được xác định bởi Ngưỡng thành công) nằm trong giới hạn cho phép. Nói chung, điều này có nghĩa là bạn sẽ có một số rủi ro mà nhóm đồng ý không phải là vấn đề đáng lo ngại. Hãy nhớ rằng bạn có thể sẽ không muốn giảm thiểu tất cả các rủi ro. Một chiến lược giảm thiểu ví dụ cho rủi ro cuối cùng ở trên có thể là tạo ra một hướng dẫn.


1

Càng ít càng tốt, nhưng càng nhiều càng cần thiết

Tôi không thể nhớ nơi và khi tôi nghe lần đầu tiên, nhưng đó là một câu châm ngôn với nhiều ứng dụng.

Công nghệ hoặc ứng dụng càng phức tạp thì càng cần nhiều tài liệu (rõ ràng), nhưng rõ ràng bạn không muốn lãng phí thời gian quá mức.

'Thử nghiệm hành lang' của JohnFx là âm thanh. Nhưng hãy tin tưởng vào bản thân; bạn đã phát triển mã và vì vậy tất cả mọi người nên có cảm giác về các yếu tố cần chú ý thêm và các yếu tố sẽ rõ ràng cho tất cả mọi người. Hãy nghĩ về những cuộc đấu tranh mà bạn đã phát triển mã và bạn có thể sẽ có ý tưởng về những gì nhà phát triển khác sẽ thấy khi họ xem mã của bạn.

Quên bất kỳ mối quan hệ giữa nỗ lực dành mã hóa và nỗ lực dành tài liệu.


0

Tôi tin rằng bạn không thể đặt điều này vào các quy tắc chính xác. Lý do cho tài liệu là để cung cấp kiến ​​thức không dễ dàng thu thập từ mã thô dưới dạng để người khác có thể hiểu và thậm chí có thể duy trì mã thô nói trên.

Do đó cách duy nhất bạn có thể biết nếu bạn đã ghi chép đủ tài liệu, là hỏi đối tượng mục tiêu nếu nó đủ tốt. Tôi tin rằng quá trình "đánh giá ngang hàng" là rất tốt để làm điều này lên phía trước. Lưu ý có bao nhiêu giải thích là cần thiết để làm cho đồng nghiệp của bạn hiểu những gì bạn đang nói và làm việc để giảm thiểu điều đó.

Nếu bạn chưa bao giờ làm điều này trước đây, bạn không thể ước tính được sẽ mất bao nhiêu công việc, nhưng sau một vài lần lặp lại, bạn sẽ có được một ý tưởng tốt hơn nhiều về việc cần bao nhiêu.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.