Khách hàng của tôi muốn 25% ý kiến ​​trong dự án hiện tại của tôi, làm thế nào để phản ứng? [đóng cửa]

nhà phát triển cơ sở ở đây.

Tôi hiện đang làm việc một mình trên một ứng dụng web cho một khách hàng lớn của công ty tôi. Tôi đã bắt đầu vào tháng trước. Khách hàng muốn có ít nhất 25% ý kiến ​​trong mỗi dự án phần mềm của mình.

Tôi đã kiểm tra mã của các ứng dụng trước đây và đây là những quan sát của tôi:

• mỗi tệp bắt đầu bằng một khối nhận xét (gói, ngày cập nhật lần cuối, tên công ty & bản quyền của tôi)

• tất cả các biến được bình luận với tên của họ // nameOfCustomer public String nameOfCustomer

• tất cả các getters và setters được bình luận

• rất ít ý kiến ​​hữu ích

Có vẻ như các nhà phát triển chỉ cần đặt càng nhiều bình luận càng tốt để đạt ngưỡng 25% đó, bất kể chất lượng và tính hữu dụng. Công ty của tôi nói với tôi rằng "chúng tôi làm điều đó như khách hàng muốn".

Tôi đã không nói chuyện trực tiếp với khách hàng về điều này. Đây là những lập luận của tôi cho đến nay:

• dòng vô dụng để đọc và viết (lãng phí thời gian)
• ý kiến ​​đôi khi không được cập nhật (nguồn gây nhầm lẫn)
• nhà phát triển ít sử dụng hoặc tin tưởng những bình luận hữu ích thực sự

Lời khuyên của bạn về chủ đề này là gì? Tôi nên xử lý tình huống như thế nào?

Tất cả các câu trả lời và nhận xét khác ở đây thực sự đã ném tôi vào một vòng lặp, bởi vì chúng rất phản ứng với phản ứng đầu tiên của tôi và phản lại thái độ mà tôi đã chứng kiến ​​ở đồng nghiệp. Vì vậy, tôi muốn mô tả một cách tiếp cận khác, nếu chỉ vì mục đích là tiếng nói bất đồng .

Nguyên tắc hướng dẫn của câu trả lời này là "Làm hài lòng khách hàng". Làm hài lòng khách hàng không chỉ có nghĩa là đáp ứng mong đợi của họ; điều đó có nghĩa là hiểu được yêu cầu của họ sâu sắc đến mức bạn có thể diễn giải những gì họ nói theo cách họ muốn nói, và cung cấp ở trên và vượt ra ngoài những gì họ yêu cầu. Thay vào đó, các câu trả lời khác dường như được hướng dẫn bởi nguyên tắc tuân thủ độc hại, mà tôi thấy gớm ghiếc; và bên cạnh đó là thực tiễn kinh doanh đáng ngờ vì đó là một cách tồi để có được khách hàng lặp lại.

Đối với tôi, khi tôi nghe khách hàng nói: "Tôi muốn 25% ý kiến", đó là khởi đầu của một hộp thoại. Đối với tôi rõ ràng hàm ý ở đây là "Tôi muốn có nhiều văn bản mô tả, để những người mới sử dụng cơ sở mã này có thể đứng dậy và chạy nhanh", chứ không phải "Tôi muốn bạn thêm tính ngẫu nhiên trong một danh mục cú pháp nhất định" như các câu trả lời khác dường như đang dùng nó Và tôi sẽ thực hiện yêu cầu đó một cách nghiêm túc và có ý định viết rất nhiều bình luận mô tả, hữu ích, hướng dẫn một người mới đến cấu trúc của mã, chỉ ra các quyết định kỹ thuật đáng ngạc nhiên và phác thảo lý do đi vào chúng, và đưa ra tiếng Anh cấp cao mô tả về các phần mã phức tạp (ngay cả khi chúng không có bất kỳ sự ngạc nhiên nào). Ý định và sự hiểu biết này là điểm khởi đầucủa cuộc thảo luận - đó là trước khi chúng ta bắt đầu nói chuyện. Đối với tôi, hàm ý của yêu cầu rõ ràng đến mức nó thậm chí không cần làm rõ điều đó; nhưng nếu không rõ ràng thì bạn nên đăng ký với họ!

Được rồi, vậy hộp thoại sẽ đi đâu nếu đó là điểm bắt đầu? Phần tiếp theo của hộp thoại diễn ra như sau:

1. Tôi hy vọng đây sẽ là một nỗ lực bổ sung nghiêm túc, có thể trong giai đoạn thứ hai của dự án, đó là trên và vượt ra ngoài việc sản xuất công cụ mà họ quan tâm khi làm việc. Có thể mất vài phút thảo luận để thảo luận về quá trình này và tại sao nó là công việc bổ sung, nhưng tôi sẽ bỏ qua nó ở đây bởi vì là một lập trình viên chuyên nghiệp, tôi hy vọng bạn biết rằng thật khó để đưa ra nhận xét tốt.
2. "Một nỗ lực bổ sung nghiêm túc" có nghĩa là chúng ta có thể cần ngân sách thời gian dài hơn và ngân sách tiền tệ lớn hơn; hoặc chúng tôi có thể cần giảm ngân sách tính năng; hoặc làchúng ta có thể cần phải thỏa hiệp về chất lượng và số lượng bình luận. Phần này sẽ là một chút của một cuộc đàm phán. Nhưng theo tôi, bạn nên thẳng thắn về chi phí khi làm công việc phụ này và đảm bảo rằng đó là một tính năng quan trọng đối với khách hàng mà họ sẵn sàng chịu những chi phí này. Và nếu họ - tuyệt vời! Bạn nhận được thêm thời gian và tiền bạc, và họ nhận được những bình luận chất lượng cao. Mọi người đều thắng. Và nếu hóa ra tính năng bình luận không quan trọng với họ đến mức họ sẵn sàng mất khả năng làm xáo trộn các vật dụng hoặc sẵn sàng để thời hạn trôi đến cuối Gran muộn, 20x6, thì mọi người lại chiến thắng: họ nhận được sản phẩm họ muốn và bạn không cần phải tốn thêm công sức để tạo bình luận chất lượng cao.

Đây là nơi tôi nghĩ rằng hộp thoại không nên đi:

3. Đừng đe dọa khách hàng bằng những bình luận chất lượng thấp. Hãy để họ giúp bạn chọn mức độ nỗ lực mà họ muốn sử dụng và họ sẵn sàng trả tiền. Đừng hứa với họ 25% ý kiến ​​và sau đó thông báo cho họ rằng bạn có ý định thực hiện lời hứa này bằng cách tự động tạo ngẫu nhiên sau khi dự án được xây dựng.
4. Đừng che giấu kế hoạch của bạn. Đừng hứa với họ 25% ý kiến, và sau đó tự động tạo ra sự ngẫu nhiên mà không nói với họ đó là những gì bạn sẽ làm. Khi họ nhận thấy (không phải nếu), cả hai bạn đều mất thời gian lớn: họ không hài lòng với sản phẩm họ nhận được và bạn nhận được những lời nói tiêu cực.
5. Đừng cố gắng thuyết phục họ mà họ không muốn bình luận. Họ rõ ràng muốn bình luận. Thảo luận về sự đánh đổi của các phương pháp khác nhau: có! Thảo luận về các cách khác nhau để làm cho người mới sử dụng codebase trở nên thân thiện: có! Nói với họ rằng họ không biết họ muốn gì: eh, không. Bạn muốn làm việc với họ để có được những gì họ muốn; vì vậy hãy hiểu đó là gì và tìm ra cách tốt nhất để cung cấp cho họ trong ngân sách họ phê duyệt, ưu tiên các tính năng họ quan tâm nhất nếu tài nguyên họ có không đủ.
6. Đừng bào chữa về việc viết bình luận khó như thế nào. Viết mã là khó; mã gỡ lỗi là khó khăn; viết bình luận là khó. Nếu nó dễ dàng, họ sẽ không thuê bạn. Chỉ cần bỏ qua các khiếu nại và đi thẳng đến điểm họ quan tâm, cụ thể là làm thế nào nỗ lực thêm cần thiết ảnh hưởng đến họ.

Khách hàng là thượng đế. Vì vậy, là nhà thầu, bạn sẽ đáp ứng bất cứ điều gì khách hàng đã xác định là tiêu chuẩn chất lượng. Hoặc bạn có nguy cơ bị ra ngoài.

Điều này đang được nói, nó rất quan trọng về cách các tiêu chuẩn chất lượng (ở đây kém) được định nghĩa:

• Tiêu chuẩn chất lượng hợp đồng: mã được giao phải tuân thủ hoặc nếu không, đó là vi phạm hợp đồng. Không có lựa chọn.

• Tiêu chuẩn chất lượng chính thức của công ty: ngay cả khi nó hoạt động hoàn hảo, mã không tuân thủ sẽ bị nhiều người coi là chất lượng kém, rằng bạn sẽ già trước khi bạn chuyển đổi tất cả chúng thành một cách thực hành tốt hơn. Tồi tệ hơn: các công cụ nổi tiếng có thể được sử dụng để tự động hóa và hợp pháp các số liệu chất lượng như vậy (ví dụ: khối sonar ). Hầu như không có sự lựa chọn.

• Tiêu chí đặc biệt được xác định bởi một vài người tại khách hàng. Ở đây bạn có thể tham gia thảo luận. Vẫn còn hy vọng :-)

Trong trường hợp cuối cùng này, có thể có một số linh hoạt, và bạn có thể cố gắng đưa ra quan điểm ngoại giao. Dưới đây là một số lập luận chống lại tiêu chí của khách hàng:

• Vấn đề năng suất: mã hóa được thực hiện hai lần (một lần bằng tiếng Anh và một lần bằng mã).
• Vấn đề chính xác: nếu thay đổi được thực hiện trong mã, chúng phải được thực hiện trong các bình luận, hoặc các bình luận có thể trở nên vô dụng.
• Vấn đề tái cấu trúc: vì công cụ tái cấu trúc không xử lý các tên biến trong các bình luận.
• Vấn đề rủi ro: sự mơ hồ (hoặc lỗi thời) của các bình luận có thể tạo ra sự nhầm lẫn và rủi ro để tăng lỗi.
• Số lượng không chất lượng
• Bộ sưu tập hài hước về những bình luận vô dụng trên StackOverflow .
• Bài viết này lập luận rằng tỷ lệ bình luận cao thậm chí có thể là dấu hiệu của mùi mã.

Nhưng thay vì nói chống lại cái xấu và đối đầu với khách hàng, có thể bạn chỉ đơn giản là thúc đẩy các cách tiếp cận tốt hơn:

• Mã sạch (đề xuất sách cho khách hàng của bạn: có một phần thuyết phục dành riêng cho nhận xét và mã tự viết tài liệu).
• Thực hành tài liệu: Những điều khó nắm bắt nhất và do đó thông tin có giá trị nhất, chẳng hạn như mối quan hệ và tương tác giữa các lớp được ghi lại tốt hơn trong một tài liệu riêng biệt (ví dụ trong một bức tranh UML thay vì 1000 từ nhận xét?)

Nếu khách hàng vẫn không bị thuyết phục, bạn có thể đề xuất một giải pháp thay thế thử nghiệm, sử dụng các công cụ tạo tài liệu tự động với các nhận xét, chẳng hạn như javadochoặc doxygen. Đề xuất sau đó để chuyển trọng tâm từ số lượng (25% mã) sang chất lượng (tạo ra một javadoc dễ hiểu).

Khách hàng muốn có ít nhất 25% ý kiến ​​trong mỗi dự án phần mềm của mình.

Khách hàng có thực sự muốn 25% ý kiến ​​hay khách hàng của bạn muốn mã của bạn càng mô tả càng tốt?

IMHO, khách hàng biết những gì anh ta muốn, nhưng không phải những gì anh ta cần. Vì khách hàng không phải là nhà phát triển và nhận phản hồi từ chính nhân viên / khách hàng của mình, khách hàng của bạn chỉ nhìn thấy phần trên cùng của tảng băng trôi.

Tôi đoán khách hàng của bạn có một số kiến ​​thức giả và muốn mã được ghi chép tốt và dễ bảo trì và rẻ tiền, và công cụ cho việc này là nhận xét (trong tâm trí của anh ấy).

Hãy thử nói chuyện với anh ta và chuẩn bị một số đoạn mã với mã được viết tốt để giải thích chính nó, và một đoạn văn bản xấu khác có bình luận. Chỉ vài dòng thôi. Hiển thị điều này nếu cần thiết và sử dụng nó như hình ảnh cho lời nói của bạn.

Nói chuyện với khách hàng / người giám sát của bạn / bất cứ điều gì và cố gắng nói với họ các nguyên tắc kiểm soát phiên bản hiện đại (không cần bình luận ở phần đầu của tệp) và mã sạch (tôi cũng khuyên bạn nên đọc sách ) và do đó dẫn đến việc tự giải thích mã.

Có thể, nếu bạn có thể hiển thị nó đủ tốt và khiến khách hàng của bạn hiểu rằng anh ta muốn mã sạch, không chỉ nhận xét, bạn và nhóm của bạn có thể viết mã tốt hơn (với ít bình luận hơn) và ngay lập tức cho thấy bạn là nhà phát triển tốt đáng để giữ .

Điều này làm tôi nhớ đến những câu trả lời Stack Overflow ngớ ngẩn mà bạn thấy bao gồm một dòng theo sau, theo nghĩa đen là "một số văn bản ở đây để đạt đến giới hạn ký tự tối thiểu".

Khi điều này xảy ra, các đối số có thể được đưa ra rằng hai nhóm người có lỗi:

1. Những người đặt trong giới hạn - rõ ràng là quá mức và ngăn mọi người gửi thông tin được định dạng đúng của họ mà không thêm tiếng ồn nhân tạo

2. Những người đã gửi thông tin không được hình thành đúng cách, sau đó thêm tiếng ồn nhân tạo khi hệ thống nhắc họ thay vào đó thêm chất thực tế

Đôi khi, một câu hỏi sẽ vừa đơn giản vừa có chủ đề, và không có gì nhiều để nói hơn một vài từ. Tuy nhiên, điều này là cực kỳ hiếm. Trong hầu hết các trường hợp, có rất nhiều chất để nói. Nếu không có gì khác, rõ ràng là cách để vượt qua giới hạn ký tự không phải là bỏ tiếng ồn ngẫu nhiên vào bài đăng của bạn.

Tình huống bình luận này bạn đang đối mặt là gần như nhau. Các nhà phát triển của bạn đã đưa ra yêu cầu cho ý kiến ​​và thực hiện nó bằng cách bỏ nhiễu ngẫu nhiên vào mã của họ. Tài liệu về tên của các biến, ngay bên cạnh khai báo của các biến, là phá hoại . Điều đó không bao giờ nên xảy ra.

"Nhưng làm thế nào khác chúng ta có thể nhận được đến 25%?" Bằng cách viết bình luận thực tế của chất. Sử dụng nhiều từ hơn, từ tốt hơn, từ tốt nhất để ghi lại tác dụng của các chức năng. Mở rộng về giải thích của bạn. Mô tả các trường hợp cạnh chi tiết hơn.

Tuy nhiên, quay trở lại điểm ban đầu, máy khách cũng có một phần lỗi tại đây, vì "25% mã nguồn" là cực kỳ tùy ý. Cuối cùng, mặc dù, họ là khách hàng, vì vậy hãy tận dụng tốt nhất. Nhưng tôi có nghĩa là "tốt nhất". Không phải "tệ nhất", như đã xảy ra cho đến nay.

Tôi không biết những gì ồn ào về yêu cầu này.

Chỉ bằng cách chuyển đổi cơ bản mã của bạn, bạn có thể đã ở mức 10% hoặc hơn. Và hãy lấy thêm 5% ý kiến ​​bạn đã viết cho chính mình (một số viết nhiều hơn, nhưng 5% có vẻ như là một ước tính bảo thủ nếu bạn không thề im lặng). Tại thời điểm này, đó là khoảng 15% (vâng, vâng, tôi biết, 5% của 90% là dưới 5%, không phải là nitpick). Nếu doxygen của bạn dưới 10%, có lẽ phương pháp của bạn rất dài; thường là một ý tưởng tốt để chia chúng thành các phần nhỏ hơn (chủ yếu là riêng tư / được bảo vệ) hoặc sử dụng các lớp trợ giúp chung chung hơn, v.v.

Bây giờ, đối với phần còn lại của văn bản nhận xét - đặt các cân nhắc thiết kế và các tình huống sử dụng trong các nhận xét cấp lớp / tệp. Có một số bảng hoặc nghệ thuật ASCII (hoặc mã doxygen tạo ra các công cụ trông đẹp hơn khi được hiển thị). Tất nhiên, tôi không biết dự án của bạn là gì, nhưng tôi tin rằng bạn có thể làm điều này mà không cần bình luận giả (ngoại trừ bản tóm tắt doxygenation) và đạt gần 25%.

Nếu chỉ, giả sử, 20% chứ không phải 25% - Tôi chắc chắn rằng khách hàng chỉ đưa ra con số đó là một cái gì đó tùy ý, và sẽ ổn với nó. Dù sao, hãy nói chuyện với họ để thảo luận về những gì các ý kiến ​​nên bao gồm; và cho họ xem một tập tin ví dụ để xem họ có hài lòng không. Nếu họ là như vậy, nếu họ nghĩ thiếu thứ gì đó, họ sẽ cho bạn biết những gì còn thiếu. Họ sẽ không nói với bạn "Chúng tôi không thể đề xuất bất kỳ bình luận thêm nào có thể nhưng chúng tôi vẫn muốn bạn thêm một số".

Tái bút - Nhìn vào mã của các bộ chứa Java tiêu chuẩn để xem cách bạn có thể tiếp cận, ồ, 70% hoặc hơn ...

Có 25% ý kiến ​​trong mã của bạn là một mục tiêu tuyệt vời để có, và nó làm cho khách hàng hài lòng. Bây giờ viết 25% bình luận điền vào crappy như "i + = 1; // tăng i lên 1" nên ở bên dưới bạn, vì vậy hãy dành thời gian, viết bình luận hữu ích và tận hưởng cảm giác rằng bạn thực sự được trả tiền để làm điều gì đó bạn nên làm dù sao.

Chúng ta đều biết đây là một yêu cầu tào lao. Câu hỏi thú vị ở đây là

Phản ứng thế nào?

Tôi là một người tin tưởng lớn trong việc làm cho vấn đề hiển thị. Ở đây tôi sẽ sử dụng thực tế là các cuộc đàm phán về tiền bạc.

Yêu cầu tôi làm điều này và tôi sẽ nói chắc chắn rằng, sẽ thêm 1% vào giá thầu của tôi. Ồ, nhưng nó sẽ thêm 20% cho bất kỳ giá thầu bảo trì nào trong tương lai.

Chỉ một lần họ hỏi tại sao tôi sẽ dạy họ rằng quan điểm của những cái tên hay là để tránh phải bình luận.

Thay vào đó, tôi sẽ đề xuất việc tạo tài liệu nhằm mục đích giúp một lập trình viên bảo trì với một bộ các bằng cấp giả định được xác định để tăng tốc độ cho các ý tưởng đằng sau dự án. Hoặc chắc chắn, tôi có thể cho bạn 25% ý kiến. Tùy bạn

Vâng, tôi hiểu sự thất vọng của bạn với quy tắc ngớ ngẩn. Tôi đã đọc rất nhiều chương trình với những bình luận vô ích như

x = x + 1; // add 1 to x

Và tôi tự nói với bản thân mình, vậy đó là một dấu cộng có nghĩa là gì !! Ồ, cảm ơn vì đã nói với tôi, tôi không biết điều đó.

Nhưng điều đó nói rằng, khách hàng đang thanh toán hóa đơn. Do đó, bạn cung cấp cho họ những gì họ muốn. Nếu tôi làm việc tại một đại lý xe hơi và một khách hàng nói rằng anh ta muốn một chiếc xe bán tải, tôi sẽ không tranh luận với anh ta về việc anh ta có thực sự cần một chiếc xe bán tải hay không và hỏi anh ta về những gì anh ta mong muốn trong đó. Tôi sẽ bán cho anh ấy một chiếc xe bán tải.

Được rồi, có những lúc khách hàng nói rằng anh ta muốn và những gì anh ta thực sự cần cách xa nhau đến mức tôi cố gắng thảo luận vấn đề với anh ta, có thể thuyết phục anh ta đồng ý với một điều gì đó hợp lý hơn. Đôi khi điều này hoạt động, đôi khi nó không. Cuối cùng, nếu tôi không thể thay đổi suy nghĩ của anh ấy, tôi sẽ cho anh ấy những gì anh ấy muốn. Nếu anh ấy quay lại sau và nói, Ồ, điều đó thực sự không thỏa mãn yêu cầu kinh doanh của tôi, thì chúng tôi có thể tính phí anh ấy nhiều hơn để làm những gì chúng tôi bảo anh ấy làm lần đầu tiên. Bạn có thể thương lượng với khách hàng bao nhiêu tùy thuộc vào mức độ họ tin tưởng vào chuyên môn của bạn, hợp đồng của họ với bạn phù hợp với tổ chức như thế nào, và thẳng thắn, họ là người đầu bò.

Đó sẽ là một trường hợp rất hiếm khi, giả sử điều đó tùy thuộc vào tôi, tôi sẽ mất một hợp đồng vì tôi nghĩ rằng các yêu cầu này không được thực hiện.

Hãy nhớ rằng những người mà công ty bạn đang đàm phán có thể hoặc không phải là người đã phát minh ra quy tắc 25% này. Nó có thể là một quy tắc áp đặt cho họ từ cao hơn.

Tôi thấy năm phản hồi có thể:

Một. Thuyết phục sếp của bạn hoặc bất cứ ai đang đàm phán với khách hàng để tranh luận về vấn đề này. Điều lạ lùng là điều này sẽ chẳng đạt được gì, nhưng bạn có thể thử.

Hai. Từ chối làm điều đó. Điều này có thể sẽ khiến bạn bị sa thải, hoặc nếu công ty đồng ý với bạn, khiến bạn mất hợp đồng. Điều này dường như không hiệu quả.

Số ba. Viết bình luận vô ích để lấp đầy không gian, loại bình luận chỉ lặp lại những gì trong mã và bất kỳ lập trình viên nào có khả năng sửa đổi mã có thể thấy trong 2 giây. Tôi đã thấy rất nhiều ý kiến ​​như thế này. Cách đây nhiều năm, tôi đã làm việc cho một công ty nơi chúng tôi được yêu cầu đặt các khối nhận xét trước mọi chức năng liệt kê các tham số, như:

/*
GetFoo function
Parameters:
  name: String, contains name
  num: int, the number
  add_date: date, the date added
Returns:
  foo code: int
*/
int GetFoo(String name, int num, Date add_date)

Việc phản đối rằng những bình luận như vậy là một gánh nặng bảo trì vì bạn phải cập nhật chúng là không hợp lệ. Không cần phải cập nhật chúng vì sẽ không có lập trình viên nghiêm túc nào nhìn vào chúng. Nếu có bất kỳ câu hỏi nào về điều đó, hãy chắc chắn nói rõ với tất cả các thành viên của nhóm rằng những bình luận vô ích, dư thừa nên được bỏ qua. Nếu bạn muốn biết các tham số của hàm là gì hoặc dòng mã làm gì, hãy đọc mã, đừng nhìn vào các bình luận vô dụng.

Bốn. Nếu bạn sẽ thêm các bình luận vô giá trị dư thừa, có lẽ bạn nên dành thời gian để viết một chương trình để tạo ra chúng. Một cái gì đó của một khoản đầu tư lên phía trước, nhưng có thể tiết kiệm một loạt các gõ xuống đường.

Quay lại khi tôi mới bắt đầu kinh doanh, một công ty tôi đã làm việc đã sử dụng một chương trình được quảng cáo là "Viết tài liệu của bạn cho bạn! Hoàn thành tài liệu cho mọi chương trình!" Hệ thống yêu cầu chúng tôi cung cấp cho tất cả các biến về cơ bản các tên vô nghĩa và sau đó có một bảng đặt tên có ý nghĩa cho từng biến, vì vậy về cơ bản, "tài liệu tự động" đã làm thay thế tên vô nghĩa mà nó buộc chúng tôi sử dụng bằng một tên có ý nghĩa. Vì vậy, ví dụ - điều này đã làm việc với COBOL - bạn sẽ có một dòng trong chương trình của bạn cho biết

MOVE IA010 TO WS124

và họ sẽ tạo ra một dòng "tài liệu" cho biết

COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE

Dù sao, người ta chắc chắn có thể viết một chương trình để tạo tài liệu vô giá trị tương đối dễ dàng. Đọc một dòng như

a=b+c

và tạo bình luận

// add b to c and save result in a

Vân vân.

Số năm. Làm cho tốt nhất của quy tắc ngớ ngẩn. Cố gắng viết bình luận hữu ích và có ý nghĩa. Này, nó có thể là một bài tập tốt.

Ồ, nhân tiện, tôi có thể thêm rằng bạn luôn có thể chơi trò chơi số liệu.

Tôi nhớ lại một lần một nhà tuyển dụng nói rằng họ sẽ bắt đầu đo năng suất của các lập trình viên bằng cách chúng tôi tạo ra bao nhiêu dòng mã mỗi tuần. Khi chúng tôi được nói điều này tại một cuộc họp, tôi nói, Tuyệt! Tôi có thể dễ dàng tăng điểm của mình. Không viết nữa

x=x+4;

Thay vào đó tôi sẽ viết:

x=x+1;
x=x+1;
x=x+1;
x=x+1;

Vòng lặp? Quên đi, tôi sẽ sao chép và dán mã mười lần. Vân vân.

Vì vậy, ở đây, nếu họ sẽ đếm các dòng bình luận, hãy rút ngắn từng dòng và tiếp tục ý tưởng trên dòng tiếp theo. Nếu có sự thay đổi đối với những gì diễn ra trong các bình luận, đừng cập nhật bình luận hiện có. Đặt một ngày trên đó, sau đó sao chép toàn bộ văn bản và viết "Đã cập nhật" và một ngày mới. Nếu khách hàng đặt câu hỏi, hãy nói với họ rằng bạn nghĩ cần phải duy trì lịch sử. Vân vân.

Số liệu tùy ý dường như là một thực tế của cuộc sống trong quá nhiều dự án ...

Điều này thường được thấy trong các yêu cầu ngu ngốc như độ phức tạp Cyclomatic tối đa dẫn đến mã phức tạp hơn, bởi vì các hàm được phân tách một cách không cần thiết để đảm bảo tuân thủ hoặc các tệp bị tách ra vì chúng vượt quá độ dài SLoC tùy ý

Nhận xét nên thêm vào mã và giải thích những gì đang diễn ra (và không chỉ lặp lại mã!).

Điều đó nói rằng, nếu đây là những gì khách hàng của bạn muốn và công ty của bạn đã đồng ý cung cấp, trừ khi Trình quản lý QA của bạn phát triển một liều thuốc thông thường, bạn sẽ bị mắc kẹt.

Trong ngắn hạn, không có gì bạn thực sự có thể làm. Đi cùng với nó.

Bạn cũng nên bỏ qua tất cả những ý tưởng ngu ngốc mà tôi thấy trong chủ đề này về các cuộc biểu tình gây hấn thụ động và những trò đùa ngớ ngẩn trong mã.

Khi bạn đã phát triển mối quan hệ tin cậy với khách hàng, họ sẽ tốt hơn để lắng nghe lý lẽ của bạn - bạn có thể thấy rằng đây là một yêu cầu ngớ ngẩn từ một người đã từng có ảnh hưởng và có rất ít sự hỗ trợ trong nhà.

Trong mọi trường hợp, bạn không nên đi ngược lại mà không có sự cho phép của khách hàng.

Tôi thất vọng vì sự thiếu trí tưởng tượng được hiển thị bởi các lập trình viên của tôi ở đây.

Dường như với tôi khách hàng đã làm một số nghiên cứu. Anh ta có thể đã đọc ở đâu đó rằng mã chất lượng thường chứa khoảng 25% ý kiến. Rõ ràng anh ấy quan tâm / lo lắng về việc bảo trì xa hơn trên đường. Bây giờ, làm thế nào để anh ta làm cho cụ thể trong một tài liệu yêu cầu được gắn với một hợp đồng? Điều đó không dễ dàng. Nó thậm chí có thể là không thể. Tuy nhiên, anh ta muốn chắc chắn rằng anh ta sẽ nhận được giá trị đồng tiền của mình để anh ta liệt kê một số chỉ số chất lượng.

Điều đó không có vẻ ngu ngốc hay lố bịch đối với tôi cả. Những người đã viết các yêu cầu rất có thể không phải là lập trình viên. Họ có thể đã có một trải nghiệm tồi tệ với một dự án trước đó. Những người bảo trì của họ đang phàn nàn: "Không ai trong số này là tài liệu!". Nó vang lên trong tai khi họ viết những yêu cầu mới cho dự án tiếp theo.

Nếu bạn nghiêm túc về việc ghi lại mã của mình và về việc cung cấp ngữ cảnh cho băng nhóm bảo trì, yêu cầu này sẽ được thực hiện tự động. Vì vậy, đừng là một âm hộ về nó!

Cuối cùng, có thể là 21% hoặc 29%, sẽ không có ai quan tâm. Khách hàng sẽ xem xét nội dung của bạn bởi một số nhà phát triển độc lập và anh ta sẽ hiểu rõ hơn những gì bạn đã làm.

Tôi đã gặp nhiều lập trình viên, những người không hiểu cách mọi người tồn tại mà hiện không làm việc trong dự án này.

Đối với họ mọi thứ mà họ biết, đều được mọi người biết đến.

Nếu ai đó không biết MỌI THỨ họ hiện đang biết, thì những người đó là "kẻ ngốc" đối với họ.

Với tiêu chuẩn này, bạn có thể buộc mọi người tham gia viết bình luận.

Họ có thể viết bình luận vô ích 99% thời gian, nhưng đôi khi họ thực sự có thể viết ra một trong những điều "MỌI NGƯỜI BIẾT", và ai đó mới trong nhóm thực sự có thể không mất 16 giờ để tìm lỗi (điều đó đã được giải quyết, nhưng sau đó đã được hoàn tác vì một lý do khác) điều đó có thể rõ ràng với một nhận xét tại thời điểm đó trong mã.

Có ý kiến ​​tại các dòng có lỗi không rõ ràng cũng có thể giúp tránh các lập trình viên trong tương lai phá vỡ hoàn toàn một chương trình một cách tình cờ (đặc biệt là khi "bị hỏng" -part không rõ ràng khi làm bài kiểm tra nhanh).