Xác định đúng số lượng tài liệu


10

Nơi tôi đang làm việc, cách tiếp cận chung là -

tránh tài liệu càng nhiều càng tốt

Chỉ tài liệu nếu một nhóm khác sẽ cần nó

chỉ để làm rõ, tôi không có nghĩa là tài liệu mã - điều này chúng tôi làm, ý tôi là tất cả các tài liệu xung quanh quy trình thiết kế - nếu đó là UML hoặc DB Schitions, sơ đồ lớp và tài liệu từ có thông số kỹ thuật và lượt thích.

Tôi sẽ liệt kê lý do của ông chủ của tôi để không tài liệu:

  1. tốn thời gian - tập trung vào việc thực hiện
  2. nếu thay đổi thiết kế - thì tài liệu sẽ thay đổi, nhân đôi rắc rối
  3. cuối cùng bạn chỉ nhận được hàng trăm trang không ai muốn đọc, và không ai thực sự chỉnh sửa nên theo thời gian nó sẽ bị lỗi thời
  4. Đó là một nỗi đau - không ai thực sự muốn làm điều đó

Bây giờ tôi nhận ra chúng tôi làm việc nhanh hơn, nhưng tôi cũng nhớ thời gian đến đây và lặn thẳng vào một số mã cũ, không hiểu gì cả.

Trên thực tế, tôi vẫn không nhận được hầu hết mã cũ này và đôi khi khi tôi vào, tôi thấy nhiều bản vá từ các nhà phát triển khác nhau đang cố gắng thực hiện các chỉnh sửa nhỏ.

Tôi thực sự nghĩ rằng thiếu tài liệu thúc đẩy các loại bản vá và thiếu hiểu biết hệ thống theo nghĩa rộng.

câu hỏi của tôi là:

Làm thế nào chúng ta có thể cân bằng tài liệu để chúng ta sẽ thúc đẩy kiến ​​thức liên tục trong nhóm mà vẫn nhanh và hiệu quả?


Tôi có cùng một vấn đề tại chỗ của tôi - ngoại trừ nhóm của tôi thậm chí không viết bình luận mã!
MattDavey

1
Có phải họ ít nhất là tài liệu các yêu cầu tối thiểu và thông số kỹ thuật? Nếu không, làm sao bạn biết bạn đã mã hóa đúng thứ nếu không có yêu cầu so sánh thành phẩm với?
Thất

đặc biệt với các ngôn ngữ hiện đại, tài liệu kỹ thuật quan trọng hơn nhiều sau đó là tài liệu mã. mã nên tự giải thích.
AK_

Trong khi đó thực sự là một ý tưởng tốt để tránh quá nhiều tài liệu, ông chủ của bạn chỉ làm điều đó vì tất cả các lý do sai.
Chris nói Phục hồi lại

Bạn có thể đưa ra một ý tưởng về ngành công nghiệp mà công ty bạn đang hoạt động? Một số ngành có yêu cầu pháp lý về mức độ tối thiểu của tài liệu cần thiết.
tehnyit

Câu trả lời:


5

Tôi đã tìm thấy BẤT K document tài liệu nào tốt hơn tài liệu KHÔNG. Số tiền thích hợp thường được xác định theo thời gian chúng tôi phải thực hiện hoặc bằng cách chúng tôi ghét các cuộc gọi điện thoại và email hỗ trợ.

Dường như các thành viên trong nhóm hiện tại của bạn có một số kỳ vọng không thực tế về ký ức của họ, hoặc họ xấu hổ về kỹ năng viết của họ và không sẵn sàng thực hành.

Tôi nhận ra mình thuộc một nhóm thiểu số (chuyên ngành tiếng Anh, người đã theo học ngành kỹ thuật phần mềm ở trường đại học) ở đây, vì tôi không tìm thấy tài liệu như một việc vặt. Đó là một công cụ chuyên nghiệp có giá trị. Tôi có thể không thấy viết khó như một số đồng nghiệp của mình, nhưng điều đó chủ yếu là vì tôi đã thực hành nhiều hơn về nó. Tôi không xem xét một dự án đã hoàn thành trừ khi nó có tài liệu và tôi thường viết nó vì những lý do hoàn toàn ích kỷ: vì vậy tôi có thể đưa cho mọi người thứ gì đó để đọc thay vì gọi điện thoại và email, hoặc vì vậy tôi có thể nhớ những gì chúng ta đã nói về lần trước tháng, hoặc vì vậy tôi có thể tham khảo cách tôi đã làm một cái gì đó nếu tôi cần hỗ trợ nó vào giữa đêm.

Cách tốt nhất để tiếp cận tài liệu là viết nó NHƯ BẠN ĐI, chính xác như viết mã kiểm tra. Thật đáng ngạc nhiên khi một vài mẫu được viết sẵn (với các tiêu đề, sơ khai mã, v.v.) có thể làm cho tài liệu dễ dàng hơn và nhanh hơn để làm. Bằng cách này, bạn có thể nắm bắt được sự thay đổi khi nó xảy ra và bạn có ít mặt bằng hơn để che đậy theo thời gian. Bạn hiệu quả hơn theo cách này, vì bạn có thể tham khảo tài liệu khi bạn cần và bạn thay đổi nó trên đường đi. Ví dụ, làm như vậy trong wiki giúp cập nhật dễ dàng hơn và bạn có thể tránh các sự cố phiên bản tài liệu nếu bản mới nhất và lớn nhất luôn trực tuyến ở cùng một nơi và bạn chỉ có thể gửi liên kết tới những người cần đọc nó.

Nếu bạn dành một ít thời gian để làm tài liệu, bạn sẽ TẤT CẢ làm việc nhanh hơn, đặc biệt là khi ai đó mới gia nhập nhóm, vì họ sẽ không phải dành tất cả thời gian đó để tìm ra mọi thứ. Tìm hiểu công cụ là một phần thú vị trong công việc của chúng tôi, nhưng thật không vui khi bạn phải vội vàng sửa chữa sản xuất. Tất cả chúng ta sẽ tiết kiệm rất nhiều thời gian nếu tất cả chúng ta đã viết thêm một vài ghi chú.

Nhóm của bạn có cùng các vấn đề với kiểm tra hoặc viết mã kiểm tra không? Nếu không, đây sẽ là một bán dễ dàng hơn.

Tài liệu của bạn hữu ích theo nhiều cách:
1) Đối với bạn, ngay bây giờ và với đồng nghiệp, khi bạn làm việc trong dự án.

2) Để khách hàng của bạn. Có tài liệu (bao gồm các sơ đồ) mà bạn có thể hiển thị cho người dùng giúp cho các cuộc thảo luận trong các cuộc họp dễ dàng hơn, đặc biệt nếu bạn đang thảo luận về các hệ thống phức tạp. Ngay cả khi tài liệu không đầy đủ, đó là nơi để bắt đầu.

3) Gửi đến những người sẽ kế thừa công việc của bạn (thậm chí có thể là bạn, trong ba năm). Nhiều đồng nghiệp trẻ của tôi nghĩ rằng họ sẽ nhớ mọi thứ mãi mãi. Tôi biết tôi sẽ không nhớ nó trong tuần này nếu tôi không viết nó ra. Có tài liệu giúp bạn không phải mất nửa ngày để nhớ cách bạn cấu trúc một cái gì đó, và phải tìm lại tất cả.

4) Đối với bạn và những người khác, nếu tình hình trở nên chính trị hoặc gây tranh cãi. Là một người ghi chép trong các cuộc họp, để giữ cho mình tỉnh táo và chống lại sự nhàm chán, tôi thường là người duy nhất có phiên bản bằng văn bản của một quyết định. Người viết nó xuống thắng cuộc tranh chấp. Hãy nhớ điều này vào lần tới khi ai đó nói rằng "Hãy nhớ rằng cuộc họp mà chúng ta đã có trong mùa đông vừa qua tại phòng hội nghị 4, khi chúng ta đi qua X? Fred đã ở đó, và anh chàng đó từ Kế toán là ai?"


1
+1 cho điểm # 3. Tài liệu cá nhân của riêng tôi đã cứu tôi rất nhiều lần.
Brandon

Tôi ném mã của tôi trong cùng một git repo như mã, thường là trong Markdown (thỉnh thoảng trong LaTeX, khi có một chút toán học liên quan).
TRiG

4

Ở vài nhà tuyển dụng cuối cùng của tôi, chúng tôi đã có một wiki "phát triển". Các khối chức năng đáng kể (nhập / xuất nguồn cấp dữ liệu mới, cách hệ thống con bảo mật hoạt động, nơi hệ thống lưu trữ các tài liệu được tải lên, v.v.) đều được ghi lại trên đó. Đây thường là một mục bắt buộc phải được hoàn thành trước bước xem xét mã. Ban đầu thường có một chút chống lại nó, nhưng một khi ai đó cần tìm kiếm một chút thông tin và nó ở đó, bạn đã có một chuyển đổi khác.

Điều tuyệt vời khi có nó ở định dạng wiki là bạn ít có khuynh hướng thực hiện tất cả các định dạng Word đẹp và như vậy và chỉ cần viết ra thông tin thực bạn cần lưu. Hầu hết (nếu không phải tất cả) các gói wiki sẽ cho phép bạn tải lên các tài liệu hoặc hình ảnh (như sơ đồ Visio UML hoặc khung lưới UI), do đó bạn cũng có thể có các phần trực quan.

Giống như hầu hết mọi thứ, tôi nghĩ bạn nên đặt mục tiêu làm số tiền tối thiểu có thể làm việc. Đó không phải là điều tương tự như không có.


Đây là một gợi ý tuyệt vời. Một số wiki cho phép các nội dung được xuất sang tài liệu .rtf. Gần như hoàn hảo cho PHB.
tehnyit

Chúng tôi sử dụng XWiki, đặc biệt cho khả năng tạo tài liệu bằng PDF, RTF và HTML. Xấu tốt.
Jennifer S

2

Bạn không thể thoát phân bổ thời gian để viết tài liệu thích hợp. Cân bằng nó tuy nhiên bạn muốn tùy thuộc vào số lượng công việc bạn được giao, nhưng để lại 15-20% thời gian của bạn để ghi lại những gì bạn đã làm. Mọi người trong nhóm phải ở trên tàu với điều này, kể cả người quản lý của bạn, nếu không, bạn sẽ chỉ được ghi nhận vì lợi ích của người khác và sẽ không nhận được gì. Tài liệu phải là một phần không thể thiếu trong quá trình phát triển của bạn.


1

Tài liệu sẽ cho bạn biết TẠI SAO bạn đã làm gì đó trong khi bạn để phần CÁCH cho mã thực tế và phần GÌ cho các bài kiểm tra đơn vị. Bất cứ điều gì nhiều hơn là một nỗi đau. Điều này thường đủ tốt cho những người thông minh, những người chỉ muốn một điểm khởi đầu.

Ngoài ra, đừng quên duy trì kiến ​​trúc cấp cao tổng thể của từng thành phần lớn trong cơ sở mã của bạn. Làm cho nó rất dễ dàng để giới thiệu thành viên nhóm mới.

Cuối cùng, bất cứ khi nào bạn thêm một sửa chữa lập dị, liên kết đến cơ sở dữ liệu lỗi của bạn từ một bình luận - rất hữu ích.


1

Sếp của bạn đúng không in bất kỳ tài liệu UML nào mà không ai đọc. Những gì chúng tôi làm trong nhóm của chúng tôi là điều hướng trực tiếp trong mô hình bằng cách sử dụng các khung nhìn sơ đồ lớp. Nguyên tắc là luôn cập nhật MOF, mô hình UML trực tiếp từ mã và để sơ đồ lớp chỉ là người xem mô hình chứ không phải chính mô hình.

Nó hoạt động thực sự tốt bởi vì tất cả sự phức tạp được thực hiện trong backoffice ở cấp độ mô hình. Tôi có thể cấu trúc lại dự án của mình, viết tài liệu java hoặc viết tài liệu uml trong mô hình. Nó là một loại bấm và đi. Khi bạn nhấp vào, bạn nhận được các tài liệu trực tiếp. Nếu có gì đó không rõ ràng thì tôi mở sơ đồ lớp và bắt đầu chơi với nó. Xóa khỏi phân loại sơ đồ, thêm phân loại mới, phóng to và thu nhỏ, hiển thị liên kết, xóa liên kết, v.v ... Mô hình không thay đổi vì tôi không tạo bất kỳ thông tin mô hình mới nào, tôi chỉ sử dụng chúng.

Điều thực sự quan trọng là mở sơ đồ của một gói và có thể đọc trực tiếp trong sơ đồ lớp một nhận xét về lớp này được cho là gì. Phương pháp này được cho là để làm gì và dòng chảy là gì ....

UML là rất tốt, thực sự hữu ích nhưng chúng ta nên ngừng sử dụng Mô hình điều hướng theo mô hình để mang lại sự linh hoạt và lặp lại nhiều hơn ở các giai đoạn mô hình hóa / phát triển. Sơ đồ lớp được cập nhật trực tiếp từ mã và tài liệu luôn chính xác và có sẵn chỉ bằng một cú nhấp chuột. Tôi sẽ không đề cập đến một công cụ nhưng nếu bạn sử dụng Java và Eclipse thì có thể dễ dàng tìm thấy công cụ nào tôi sử dụng :-)

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.