Thực tiễn Agile: Đánh giá mã - Không xem xét hoặc nêu vấn đề?

Vào cuối giai đoạn nước rút 2 tuần và một nhiệm vụ có đánh giá mã, trong phần đánh giá chúng tôi phát hiện ra một chức năng hoạt động, có thể đọc được, nhưng nó khá dài và có một vài mùi mã. Công việc tái cấu trúc dễ dàng.

Nếu không, nhiệm vụ phù hợp với định nghĩa của thực hiện.

Chúng tôi có hai sự lựa chọn.

• Thất bại trong việc xem xét mã, để vé không đóng trong lần chạy nước rút này và chúng tôi có một chút ảnh hưởng đến tinh thần, bởi vì chúng tôi không thể bỏ vé.
• Bộ tái cấu trúc là một phần nhỏ của công việc, và sẽ được thực hiện trong lần chạy nước rút tiếp theo (hoặc thậm chí trước khi nó bắt đầu) như một câu chuyện nhỏ, nửa điểm.

Câu hỏi của tôi là: có bất kỳ vấn đề hoặc cân nhắc cố hữu nào với việc tăng một vé khỏi mặt sau của đánh giá, thay vì thất bại không?

Các tài nguyên tôi có thể tìm và đã đọc các đánh giá mã chi tiết là 100% hoặc không có gì, thông thường, nhưng tôi thấy điều đó thường không thực tế.

Có bất kỳ vấn đề hoặc cân nhắc cố hữu nào với việc tăng một vé khỏi mặt sau của đánh giá, thay vì thất bại không?

Không phải vốn có. Ví dụ, việc thực hiện thay đổi hiện tại có thể đã phát hiện ra một vấn đề đã có, nhưng cho đến nay vẫn chưa được biết / rõ ràng. Không bán vé sẽ không công bằng vì bạn thất bại vì điều gì đó không liên quan đến nhiệm vụ được mô tả thực sự.

trong phần đánh giá, chúng tôi phát hiện ra một chức năng

Tuy nhiên, tôi phỏng đoán rằng chức năng ở đây là một cái gì đó đã được thêm vào bởi sự thay đổi hiện tại. Trong trường hợp này, vé sẽ không thành công vì mã không vượt qua bài kiểm tra mùi.

Bạn sẽ vẽ đường đó ở đâu, nếu không phải là nơi bạn đã vẽ nó? Bạn rõ ràng không nghĩ rằng mã này đủ sạch để ở trong cơ sở mã ở dạng hiện tại; vậy tại sao sau đó bạn sẽ xem xét cho vé một vé?

Thất bại trong việc xem xét mã, để vé không đóng trong lần chạy nước rút này và chúng tôi có một chút ảnh hưởng đến tinh thần, bởi vì chúng tôi không thể bỏ vé.

Đối với tôi có vẻ như bạn đang gián tiếp lập luận rằng bạn đang cố gắng cho vé này vượt qua để mang lại lợi ích cho tinh thần của đội, hơn là có lợi cho chất lượng của cơ sở mã.

Nếu đó là trường hợp, thì bạn đã có sự ưu tiên của bạn hỗn hợp. Tiêu chuẩn của mã sạch không nên được thay đổi đơn giản vì nó làm cho nhóm hạnh phúc hơn. Tính chính xác và sạch sẽ của mã không ảnh hưởng đến tâm trạng của đội.

Bộ tái cấu trúc là một phần nhỏ của công việc, và sẽ được thực hiện trong lần chạy nước rút tiếp theo (hoặc thậm chí trước khi nó bắt đầu) như một câu chuyện nhỏ, nửa điểm.

Nếu việc thực hiện vé ban đầu gây ra mùi mã, thì nó nên được giải quyết trong vé ban đầu. Bạn chỉ nên tạo một vé mới nếu mùi mã không thể được quy trực tiếp cho vé ban đầu (ví dụ: kịch bản "ống hút làm vỡ lưng con lạc đà").

Các tài nguyên tôi có thể tìm và đã đọc các đánh giá mã chi tiết là 100% hoặc không có gì, thông thường, nhưng tôi thấy điều đó thường không thực tế.

Pass / fail vốn dĩ là một trạng thái nhị phân , vốn dĩ là tất cả hoặc không có gì.

Những gì bạn đang đề cập ở đây, tôi nghĩ, nhiều hơn là bạn diễn giải các đánh giá mã là yêu cầu mã hoàn hảo hoặc thất bại, và đó không phải là trường hợp.

Mã không nên vô nhiễm, nó chỉ cần tuân thủ tiêu chuẩn sạch sẽ hợp lý mà nhóm / công ty của bạn sử dụng. Tuân thủ tiêu chuẩn đó là một lựa chọn nhị phân: nó tuân thủ (vượt qua) hoặc nó không (thất bại).

Dựa trên mô tả của bạn về vấn đề, rõ ràng rằng bạn không nghĩ rằng điều này tuân thủ tiêu chuẩn mã dự kiến, và do đó nó không nên được thông qua vì những lý do thầm kín như tinh thần đồng đội.

Nếu không, nhiệm vụ phù hợp với định nghĩa của thực hiện.

Nếu "nó hoàn thành công việc" là điểm chuẩn tốt nhất cho chất lượng mã, thì chúng ta sẽ không phải phát minh ra nguyên tắc mã sạch và thực hành tốt để bắt đầu - trình biên dịch và kiểm thử đơn vị sẽ là quy trình xem xét tự động của chúng tôi và bạn sẽ không cần đánh giá mã hoặc đối số kiểu.

Vào cuối giai đoạn nước rút 2 tuần và một nhiệm vụ có đánh giá mã [...] Công việc tái cấu trúc dễ dàng.

Tại sao điều đó bật lên ở cuối nước rút? Việc xem xét mã sẽ diễn ra ngay khi bạn nghĩ rằng mã được thực hiện (hoặc thậm chí trước đó). Bạn nên kiểm tra định nghĩa của bạn được thực hiện với mỗi câu chuyện bạn hoàn thành.

Nếu bạn thấy mình hoàn thành các câu chuyện trong thời gian ngắn trước khi xem xét bản demo / chạy nước rút của bạn rằng bạn không thể phù hợp với nó một nhiệm vụ "nhỏ", thì bạn cần phải làm tốt hơn để ước tính công việc của mình. Vâng, câu chuyện đó đã không được kết thúc. Không phải vì đánh giá mã, mà vì bạn không có kế hoạch kết hợp các thay đổi từ đánh giá mã. Điều đó giống như ước tính "thử nghiệm" không mất thời gian, bởi vì "nếu bạn lập trình nó một cách chính xác, nó sẽ chỉ hoạt động, phải không?". Đó không phải là cách nó hoạt động. Kiểm tra sẽ tìm thấy lỗi và xem xét mã sẽ tìm thấy những điều cần thay đổi. Nếu không, nó sẽ là một sự lãng phí lớn thời gian.

Vì vậy, để tóm tắt: có, DoD là nhị phân. Đạt hoặc thất bại. Một đánh giá mã không phải là nhị phân, nó sẽ giống như một nhiệm vụ đang diễn ra. Bạn không thể thất bại . Đó là một quá trình và cuối cùng nó đã được thực hiện. Nhưng nếu bạn không lập kế hoạch đúng đắn, bạn sẽ không kịp đến giai đoạn "hoàn thành" đó và bị mắc kẹt trong lãnh thổ "chưa hoàn thành" ở giai đoạn nước rút. Điều đó không tốt cho tinh thần, nhưng bạn cần tính đến điều đó trong kế hoạch.

Đơn giản: Bạn xem lại sự thay đổi . Bạn không xem lại trạng thái của chương trình. Nếu tôi sửa một lỗi trong hàm 3.000 dòng, thì bạn hãy kiểm tra xem các thay đổi của tôi có sửa lỗi đó không, và đó là lỗi. Và nếu thay đổi của tôi sửa lỗi, bạn chấp nhận thay đổi.

Nếu bạn nghĩ rằng hàm quá dài, thì bạn đưa ra yêu cầu thay đổi để làm cho hàm ngắn hơn hoặc tách nó ra, sau khi thay đổi của tôi được chấp nhận và yêu cầu thay đổi đó có thể được ưu tiên theo mức độ quan trọng của nó. Nếu quyết định được đưa ra là nhóm có nhiều việc quan trọng hơn, thì nó sẽ được xử lý sau.

Sẽ là vô lý nếu bạn có thể quyết định các ưu tiên phát triển trong quá trình đánh giá mã và từ chối thay đổi của tôi vì lý do đó sẽ là một nỗ lực để quyết định các ưu tiên phát triển.

Tóm lại, hoàn toàn chấp nhận được việc chấp nhận thay đổi mã và ngay lập tức tăng vé dựa trên những điều bạn đã thấy khi xem xét thay đổi. Trong một số trường hợp, bạn thậm chí sẽ làm điều này nếu chính sự thay đổi gây ra các vấn đề: Nếu điều quan trọng là phải có các thay đổi ngay bây giờ hơn là khắc phục các sự cố. Ví dụ: nếu những người khác bị chặn, chờ thay đổi, thì bạn muốn bỏ chặn họ trong khi mã có thể được cải thiện.

Thất bại trong việc xem xét mã, để vé không đóng trong lần chạy nước rút này và chúng tôi có một chút ảnh hưởng đến tinh thần, bởi vì chúng tôi không thể bỏ vé.

Đây dường như là vấn đề.
Về lý thuyết bạn biết bạn nên làm gì, nhưng nó gần đến hạn chót nên bạn không muốn làm những gì bạn biết bạn nên làm.

Câu trả lời rất đơn giản: Làm bất cứ điều gì bạn sẽ làm nếu bạn có cùng một mã để xem lại mã vào ngày đầu tiên của lần chạy nước rút. Nếu nó sẽ được chấp nhận thì bây giờ nó nên. Nếu không, bây giờ sẽ không.

Một phần lớn của quá trình là quyết định những gì được thực hiện có nghĩa là và dính vào súng của bạn. Điều đó cũng có nghĩa là không cam kết quá mức và thực hiện đánh giá ngang hàng của bạn kịp thời để cho phép kiểm tra đảm bảo công việc cũng hoàn thành về mặt chức năng.

Khi nói đến vấn đề xem xét mã, có một vài cách bạn có thể xử lý nó và lựa chọn đúng phụ thuộc vào một vài yếu tố.

• Bạn chỉ có thể tự làm sạch mã và cho người đó biết bạn đã làm gì. Cung cấp một số cơ hội tư vấn, nhưng đây sẽ là công cụ khá đơn giản có thể được thực hiện trong vài phút.
• Bạn có thể đá nó lại với những bình luận về những gì sai. Nếu việc xử lý lỗi được thực hiện kém hoặc nhà phát triển tiếp tục lặp lại các lỗi tương tự, điều này có thể được bảo hành.
• Bạn có thể tạo một vé và phát sinh nợ kỹ thuật. Vé ở đó để đảm bảo bạn trả nó sau. Có thể là bạn đang trong thời gian khủng hoảng và trong quá trình xem xét các thay đổi, bạn sẽ thấy một vấn đề lớn hơn không liên quan trực tiếp đến thay đổi.

Điểm mấu chốt là khi bạn hoàn thành công việc, bạn cần phải hoàn thành nó. Nếu có vấn đề lớn hơn những gì nhà phát triển đã làm, hãy giương cờ và tiếp tục. Nhưng bạn không nên ở một vị trí có nhiều giờ trước khi kết thúc cuộc chạy nước rút và bây giờ bạn mới nhận được đánh giá ngang hàng. Điều đó có vẻ như quá cam kết tài nguyên của bạn hoặc chần chừ trên các đánh giá ngang hàng. (một mùi quá trình).

Không có vấn đề cố hữu nào với các vấn đề đánh giá mã khử, nhưng có vẻ như các vấn đề chính bạn cần phải đồng ý, với tư cách là một nhóm, là:

1. Mục đích của việc xem xét mã của bạn là gì?
2. Làm thế nào để kết quả đánh giá mã liên quan đến Định nghĩa Hoàn thành cho một mục công việc?
3. Nếu đánh giá mã được áp dụng như một thử nghiệm gating, vấn đề nào được coi là 'chặn'?

Tất cả điều này thuộc về những gì nhóm đã đồng ý theo định nghĩa của Xong. Nếu việc xem xét mã với Zero Issues là định nghĩa được thực hiện cho một mục công việc, thì bạn không thể đóng một mục không đáp ứng yêu cầu này.

Nó giống như trong khi kiểm tra đơn vị một bài kiểm tra đơn vị thất bại. Bạn sẽ sửa lỗi, không bỏ qua kiểm tra đơn vị, nếu vượt qua kiểm tra đơn vị là một yêu cầu để được Thực hiện.

Nếu nhóm không đồng ý đánh giá mã là định nghĩa của Xong, thì đánh giá mã của bạn không phải là thử nghiệm chấp nhận gating của mục công việc. Chúng là một hoạt động nhóm là một phần của quy trình tồn đọng của bạn để tìm kiếm công việc bổ sung có thể cần thiết. Trong trường hợp đó, bất kỳ vấn đề nào bạn phát hiện ra đều không liên quan đến các yêu cầu của mục công việc ban đầu và là các mục công việc mới để nhóm ưu tiên.

Ví dụ, một nhóm hoàn toàn có thể chấp nhận việc sửa lỗi chính tả trong một số tên biến vì nó không ảnh hưởng đến chức năng kinh doanh đã được phân phối, mặc dù nhóm thực sự ghét nhìn thấy tên biến "myObkect".

Các câu trả lời được bình chọn cao hơn ở đây là rất tốt; Điều này giải quyết các góc tái cấu trúc.

Trong hầu hết các trường hợp, phần lớn công việc khi tái cấu trúc là hiểu mã hiện có; thay đổi nó sau đó thường là phần nhỏ hơn của công việc vì một trong hai lý do:

1. Nếu chỉ làm cho mã rõ ràng hơn và / hoặc súc tích, những thay đổi cần thiết là rõ ràng. Thường thì bạn có được sự hiểu biết về mã bằng cách thử các thay đổi có vẻ sạch hơn và xem liệu chúng có thực sự hoạt động hay không, nếu chúng bỏ lỡ một số tinh tế trong mã phức tạp hơn.

2. Bạn đã có sẵn một thiết kế hoặc cấu trúc cụ thể mà bạn cần để xây dựng một tính năng mới dễ dàng hơn. Trong trường hợp đó, công việc phát triển thiết kế đó là một phần của câu chuyện tạo ra nhu cầu về nó; nó độc lập với bạn cần phải thực hiện tái cấu trúc để có được thiết kế đó.

Học và hiểu mã hiện tại là khối lượng công việc hợp lý vì lợi ích không cố định (một tháng kể từ bây giờ có khả năng ai đó đã quên nhiều về mã nếu họ không tiếp tục đọc hoặc làm việc với nó trong thời gian đó), và vì vậy nó không có ý nghĩa để làm điều này ngoại trừ các lĩnh vực mã gây ra sự cố cho bạn hoặc bạn dự định thay đổi trong tương lai gần. Đổi lại, vì đây là công việc tái cấu trúc chính, bạn không nên thực hiện tái cấu trúc mã trừ khi nó hiện đang gây ra sự cố cho bạn hoặc bạn đang dự định thay đổi nó trong tương lai gần.

Nhưng có một ngoại lệ: nếu ai đó hiện đang hiểu rõ về mã sẽ bị rò rỉ theo thời gian, sử dụng sự hiểu biết đó để làm cho mã rõ ràng hơn và hiểu nhanh hơn sau này có thể là một khoản đầu tư tốt. Đó là tình huống một người vừa hoàn thành phát triển một câu chuyện.

Bộ tái cấu trúc là một phần nhỏ của công việc, và sẽ được thực hiện trong lần chạy nước rút tiếp theo (hoặc thậm chí trước khi nó bắt đầu) như một câu chuyện nhỏ, nửa điểm.

Trong trường hợp này, bạn đang nghĩ đến việc tạo một câu chuyện riêng để tái cấu trúc là một dấu hiệu cảnh báo trên một số mặt trận:

1. Bạn không nghĩ đến việc tái cấu trúc như là một phần của mã hóa mà là một hoạt động riêng biệt, điều này sẽ khiến nó có khả năng bị giảm áp lực.

2. Bạn đang phát triển mã sẽ có nhiều công việc hơn để hiểu vào lần tới khi ai đó cần làm việc với nó, làm cho câu chuyện mất nhiều thời gian hơn.

3. Bạn có thể lãng phí thời gian và năng lượng tái cấu trúc những thứ mà bạn không nhận được nhiều lợi ích. (Nếu thay đổi xảy ra muộn hơn, dù sao thì ai đó vẫn sẽ phải hiểu lại mã, dù sao, đó là kết hợp hiệu quả hơn với công việc tái cấu trúc. Nếu thay đổi không xảy ra sau đó, việc tái cấu trúc sẽ không phục vụ bất kỳ mục đích ở tất cả, ngoại trừ có lẽ là một thẩm mỹ.)

Vì vậy, câu trả lời ở đây là thất bại mục này để làm rõ rằng có điều gì đó trong quy trình của bạn không thành công (trong trường hợp này, đó là nhà phát triển hoặc nhóm không phân bổ thời gian để xem xét và thực hiện các thay đổi được xem xét) và nhà phát triển ngay lập tức tiếp tục làm việc trên các mục.

Khi bạn ước tính cho lần lặp tiếp theo, hãy ước tính lại câu chuyện hiện tại vì số lượng công việc dường như còn lại để làm cho nó vượt qua đánh giá và thêm nó vào lần lặp tiếp theo của bạn, nhưng giữ nguyên ước tính từ lần lặp trước. Khi câu chuyện được hoàn thành vào cuối lần lặp tiếp theo, hãy đặt tổng số lượng công việc lịch sử thành tổng của ước tính thứ nhất và thứ hai để bạn biết có bao nhiêu công việc ước tính thực sự được đưa vào nó. Điều này sẽ giúp tạo ra các ước tính chính xác hơn về các câu chuyện tương tự trong tương lai ở trạng thái hiện tại của quy trình của bạn. (Tức là, đừng cho rằng ước tính dưới mức rõ ràng của bạn sẽ không xảy ra lần nữa; giả sử điều đó sẽ xảy ra một lần nữa cho đến khi bạn hoàn thành thành công những câu chuyện tương tự trong khi làm việc ít hơn.)

Tôi ngạc nhiên vì thiếu phản hồi trong các câu trả lời và nhận xét về khái niệm "thất bại" một đánh giá mã, bởi vì đó không phải là một khái niệm mà cá nhân tôi quen thuộc. Tôi cũng sẽ không thoải mái với khái niệm đó hoặc bất kỳ ai trong nhóm của tôi sử dụng thuật ngữ đó.

Câu hỏi của bạn rõ ràng kêu gọi "thực hành nhanh", vì vậy hãy xem lại bản tuyên ngôn nhanh (nhấn mạnh của tôi):

Chúng tôi đang khám phá những cách tốt hơn để phát triển phần mềm bằng cách làm điều đó và giúp người khác làm điều đó. Thông qua công việc này, chúng tôi đã đạt được giá trị:

• Các cá nhân và tương tác qua các quy trình và công cụ
• Phần mềm làm việc trên tài liệu toàn diện
• Hợp tác khách hàng qua đàm phán hợp đồng
• Đáp ứng để thay đổi theo kế hoạch

Đó là, trong khi có giá trị trong các mục ở bên phải, chúng tôi đánh giá các mục ở bên trái nhiều hơn.

Nói chuyện với nhóm của bạn. Thảo luận về mã trong câu hỏi. Đánh giá chi phí và lợi ích và quyết định - với tư cách là một nhóm chuyên gia gắn kết - có nên cấu trúc lại mã này ngay bây giờ, sau này hay không bao giờ.

Bắt đầu hợp tác. Dừng đánh giá mã thất bại.

trong bài đánh giá, chúng tôi phát hiện ra một chức năng hoạt động, có thể đọc được, nhưng nó khá dài và có một vài mã có mùi ...

Có bất kỳ vấn đề hoặc cân nhắc cố hữu nào với việc tăng một vé từ mặt sau của đánh giá, thay vì thất bại không?

Không có vấn đề gì (theo ý kiến ​​của đội tôi). Tôi giả sử rằng mã đáp ứng các tiêu chí chấp nhận được nêu trong vé (nghĩa là nó hoạt động). Tạo một mục tồn đọng để giải quyết độ dài và bất kỳ mã nào có mùi, và ưu tiên nó giống như bất kỳ vé nào khác. Nếu nó thực sự nhỏ, thì chỉ cần ưu tiên nó cao cho lần chạy nước rút tiếp theo.

Một trong những câu nói chúng tôi có là "Chọn cải tiến tiến bộ so với sự hoàn hảo bị trì hoãn".

Chúng tôi có một quy trình rất linh hoạt và xây dựng một số lượng khá lớn các tính năng 'bằng chứng về khái niệm' (1 hoặc 2 mỗi lần chạy nước rút) để vượt qua thử nghiệm và thử nghiệm nhưng không bao giờ vượt qua đánh giá của các bên liên quan nội bộ (hmm, chúng tôi có thể làm điều này thay thế ?), alpha hoặc beta ... một số tồn tại, một số thì không.

Trong dự án hiện tại, tôi đã mất theo dõi số lần chúng tôi đã xây dựng một tính năng nhất định, đưa nó vào tay các bên liên quan và một hoặc hai lần chạy nước rút sau đó, đã loại bỏ hoàn toàn vì hướng sản phẩm đã thay đổi hoặc do yêu cầu gây ra một bản tóm tắt đầy đủ về cách các tính năng nên được thực hiện. Bất kỳ tác vụ 'sàng lọc' nào còn lại cho một tính năng đã bị xóa hoặc không phù hợp với các yêu cầu mới sẽ bị xóa cũng như một phần của việc chải chuốt tồn đọng.

Theo tôi, có hai cách để xem xét vấn đề này:

1. Cách học
2. Cách thế giới thực

Nói về mặt học thuật, hầu hết các quy trình xem xét mã tồn tại để không triển khai PBI (mục tồn đọng sản phẩm) khi tiêu chuẩn chất lượng mã không được đáp ứng.

Tuy nhiên, không ai trong thế giới thực theo nhanh nhẹn với T như vì một (vì nhiều lý do), các ngành công nghiệp khác nhau có các yêu cầu khác nhau. Do đó, sửa mã ngay bây giờ hoặc nhận nợ kỹ thuật (rất có thể bạn sẽ tạo PBI mới) nên được quyết định theo từng trường hợp. Nếu nó sẽ thỏa hiệp chạy nước rút hoặc phát hành hoặc đưa ra một số lượng rủi ro không hợp lý, các bên liên quan kinh doanh nên tham gia vào quyết định.

Cũng không . Nếu nó không xem lại mã thì tác vụ sẽ không được thực hiện. Nhưng bạn không thể đánh giá mã về ý kiến ​​cá nhân. Mã thông qua; chuyển sang nhiệm vụ tiếp theo

Đây phải là một cuộc gọi dễ dàng và thực tế là nó không gợi ý rằng bạn không có quy tắc viết ra đủ rõ ràng để đánh giá mã.

1. "Chức năng khá dài". Viết xuống: Các hàm phải dài hơn X dòng (Tôi không gợi ý rằng các quy tắc về độ dài của hàm là một điều tốt).

2. "Có một số mùi mã". Viết xuống: các chức năng công cộng phải có các bài kiểm tra đơn vị về chức năng và hiệu suất, cả việc sử dụng CPU và bộ nhớ phải nằm dưới giới hạn x và y.

Nếu bạn không thể định lượng các quy tắc để vượt qua đánh giá mã thì bạn sẽ nhận được những trường hợp này về cơ bản là "mã bạn không thích".

Bạn có nên thất bại 'mã bạn không thích'? Tôi sẽ nói không. Bạn sẽ tự nhiên bắt đầu vượt qua / thất bại dựa trên các khía cạnh không phải là mã: Bạn có thích người đó không? Họ có tranh luận mạnh mẽ cho trường hợp của họ hay chỉ làm như họ được nói? Họ có vượt qua mã của bạn khi họ xem xét bạn không?

Ngoài ra, bạn thêm một bước không thể chấp nhận được vào quy trình ước tính. Tôi ước tính một nhiệm vụ dựa trên cách tôi nghĩ nó nên được lập trình, nhưng ngay sau đó, tôi phải thay đổi phong cách mã hóa.

Điều đó sẽ thêm bao lâu? Người đánh giá tương tự sẽ thực hiện đánh giá mã tiếp theo và đồng ý với người đánh giá đầu tiên hay họ sẽ tìm thấy những thay đổi bổ sung? Điều gì sẽ xảy ra nếu tôi không đồng ý với thay đổi và từ chối thực hiện trong khi tôi tìm kiếm ý kiến ​​thứ hai hoặc tranh luận về trường hợp này?

Nếu bạn muốn các nhiệm vụ được thực hiện nhanh chóng, bạn cần phải thực hiện chúng càng cụ thể càng tốt. Thêm một cổng chất lượng mơ hồ sẽ không giúp năng suất của bạn.

Re: Không thể viết ra các quy tắc !!

Nó không khó lắm đâu. Bạn thực sự có nghĩa là "Tôi không thể diễn tả ý của tôi bằng mã" tốt " . Khi bạn nhận ra điều đó, bạn có thể thấy rõ ràng đó là một vấn đề nhân sự nếu bạn bắt đầu nói rằng công việc của ai đó không bị trầy xước, nhưng bạn không thể nói tại sao.

Viết ra các quy tắc bạn có thể và thảo luận về bia về những gì làm cho mã 'tốt'.