Làm cách nào để thuyết phục các nhà phát triển đồng nghiệp của tôi MUỐN MUỐN thêm nhận xét vào cam kết mã nguồn?

Tôi biết rằng Subversion (những gì chúng tôi đang sử dụng tại nơi làm việc) có thể được định cấu hình để yêu cầu nhận xét về các cam kết, tuy nhiên tôi không ở vị trí quyền lực để đơn giản bật tính năng này. Tôi biết rằng tôi lý do cho ý kiến cam kết của tôi là vì nó rất hữu ích, nếu chỉ như là một bộ nhớ Jogger, để nhanh chóng hiểu được lý do đằng sau những cam kết. Tuy nhiên, điều này dường như không đủ để chống lại hai phản hồi tôi luôn nhận được:

1. Mất quá nhiều thời gian và tôi chỉ muốn nhận được những thay đổi của mình trong repo.
2. Nó đủ dễ dàng để chỉ nhìn vào khác biệt.

Tôi thậm chí còn cho họ thấy giá trị của việc chỉ cần đặt ID vấn đề JIRA và cách nó tự động được gắn với vấn đề, nhưng vẫn không có xúc xắc với họ.

Điều tồi tệ nhất, người có thể thực hiện cuộc gọi nằm trong cùng một trại: không muốn làm phiền và vẫn ổn khi nhìn vào khác biệt.

Tôi biết đó là điều đúng đắn, nhưng làm thế nào tôi có thể khiến họ nhìn thấy ánh sáng? Ngay cả khi tôi không thể thuyết phục các nhà phát triển đồng nghiệp của mình, làm thế nào tôi có thể thuyết phục ban quản lý rằng đó là điều đúng đắn để làm cho doanh nghiệp?

Tập trung vào "Tại sao". Tất cả đều nhìn rất rõ các khác biệt và thấy rằng ai đó đã thay đổi luồng logic của một phần mã hoặc một cái gì đó tương tự, nhưng tại sao họ lại thay đổi nó? Tại sao thường có trong vé liên quan (JIRA cho bạn).

Họ có thể tự hỏi tại sao "Tại sao" lại quan trọng nhưng trong 2 năm khi bạn gặp phải một lỗi nào đó là tác động của sự thay đổi đó, biết tại sao nó được thực hiện là vô cùng quan trọng để không chỉ sửa lỗi mới của bạn, mà còn đảm bảo bạn không làm cho lỗi cũ xuất hiện trở lại.

Ngoài ra còn có lý do kiểm toán. Cam kết ràng buộc và id vé giúp dễ dàng nói ok, chúng tôi đang đẩy ra Phiên bản 2, bản sửa lỗi này bị lỗi 23, 25, 26 và 27 nhưng không có cam kết nào đối với khuyết điểm 24 nên vẫn còn tồn tại.

Làm cho họ thực hiện việc sáp nhập và đối phó với hỗ trợ. Một lần nữa có thể bạn không ở vị trí để làm điều này, nhưng nếu bạn thấy mình là người khắc phục sự cố từ một cam kết trước đó, hãy lịch sự gửi nó qua hàng rào và nói. Tôi không thể nói bạn đã làm gì vì không có bình luận cam kết, bạn đã thực hiện những thay đổi này mà bạn cần để tìm ra nó.

Ngoài ra để sáp nhập các chi nhánh. Không chắc điều đó có thuộc về bạn hay không, nhưng đó là một lĩnh vực tôi thấy bình luận hữu ích.

Một lần nữa, không phải trong thuyền của bạn, nhưng khi tôi quản lý một nhóm phần mềm, tôi đã nói với họ nếu họ đưa ra những nhận xét cam kết tốt, tôi sẽ sử dụng những người trong báo cáo tình trạng hàng tuần. Nhận được những cam kết xuất sắc sau đó và tôi cũng dễ dàng theo dõi những gì đang diễn ra với tư cách là người quản lý.

Chúng tôi cần nhận xét đăng ký với cùng lý do chúng tôi cần ngắt dòng và giãn dòng trong mã của chúng tôi. Để làm cho mọi thứ dễ dàng hơn để theo dõi, hiểu đọc và hiểu.

Đôi khi bạn cần phải so sánh khác nhau, nhưng thường thì không. Buộc các nhà phát triển phải so sánh khi tất cả những gì họ cần là đọc 2-3 câu là một sự lãng phí hoàn toàn thời gian. Tôi tự hỏi tại sao họ không thấy giá trị của thời gian của nhà phát triển.

• Đặt một ví dụ tốt. Làm cho thông điệp cam kết của riêng bạn trở thành một ví dụ sáng chói về sự hữu ích. Bao gồm các tham chiếu đến bất kỳ hệ thống nào khác mà nhóm của bạn sử dụng để quản lý các câu chuyện và khiếm khuyết. Đặt một tuyên bố ngắn gọn tóm tắt sự thay đổi, và một lời giải thích tốt về lý do tại sao sự thay đổi là cần thiết và không phải là một cái gì đó khác trong mỗi đệ trình.
• Bất cứ khi nào thiếu một thông điệp cam kết đàng hoàng khiến bạn phải làm thêm, hãy đặt câu hỏi cho người nộp. Hãy kiên trì với điều này (nhưng không phải là một jerk).
• Nếu nó không vượt qua vai trò của bạn, hãy viết một tập lệnh gửi thay đổi hàng ngày bằng cách sử dụng các thông điệp cam kết. Điều này sẽ cho vay sự tin cậy đối với lập luận của bạn rằng các thông điệp hữu ích có lợi ích ngoài việc duyệt qua các bản sửa đổi. Điều này cũng có thể giúp quản lý về phía bạn, vì họ sẽ thấy những gì đang xảy ra hàng ngày.
• Xác định các đồng minh của bạn. Hy vọng rằng có ít nhất một cá nhân khác đồng ý với bạn (có lẽ bằng cách im lặng không đồng ý). Tìm người đó hoặc những người đó và thuyết phục họ thêm để bạn không đứng một mình.
• Khi cơ hội đề cập đến việc các thông điệp cam kết tốt đã giúp bạn tiết kiệm thời gian như thế nào (hoặc các tin nhắn kém khiến bạn mất thời gian), hãy nắm bắt nó.

Đừng sợ trở thành bánh xe chói tai. Chống lại những thói quen xấu của người khác thường là một cuộc chiến tiêu hao.

Đây phải là một trong những câu hỏi kỳ lạ nhất mà tôi đã nghe. Mọi người dành hàng giờ hoặc thậm chí hàng ngày để sửa một cái gì đó và thêm 2 giây để nhập tin nhắn cam kết quá dài?! Tôi phải nói rằng tôi sẽ lo lắng về việc làm việc với những người thiển cận như vậy. Họ rõ ràng là không sử dụng các công cụ của họ để thậm chí gần với tiềm năng đầy đủ của họ.

Đây là một ví dụ từ một đánh giá mã tôi đã tham gia vào tuần trước. Phần mềm kiểm soát phiên bản của chúng tôi không lưu giữ lịch sử trên các hợp nhất, vì vậy, đối với các thay đổi cũ hơn, bạn phải tìm chính xác chi nhánh được tạo, nếu không, thông báo cam kết chỉ hiển thị nội dung như "được hợp nhất từ ​​chi nhánh Y." Nhánh Y có thể hiển thị "được hợp nhất từ ​​nhánh Z" và một nhánh ở một vài cấp độ lồng sâu hơn thực sự có thông điệp cam kết thực sự.

Một nhân viên mới không biết cách theo dõi lịch sử một cách chính xác, điều đó có nghĩa là về cơ bản anh ta chỉ làm việc với các khác biệt. Anh ta thấy một số mã nhận xét liên quan đến lỗi mà anh ta đang theo dõi. Khi anh ta bỏ mã, lỗi của anh ta biến mất. Ông cho rằng ai đó đã nhận xét mã trong quá trình gỡ lỗi và kiểm tra nhầm.

Điều đó không đúng với một vài người trong chúng tôi trong quá trình đánh giá mã, vì vậy tôi đã theo dõi thông điệp cam kết thực sự và thấy rằng có một lý do hợp lệ để xóa mã đó một năm trước. Nhân viên mới đã có thể sửa mã của mình để sửa lỗi mới được phát hiện mà không cần giới thiệu lại lỗi cũ.

Có nhiều cách tốt hơn để tránh đưa ra các loại hồi quy đó, như kiểm tra đơn vị kỹ lưỡng, nhưng bằng cách nào đó tôi không thấy những người không thể bận tâm với thông điệp cam kết 2 giây "lãng phí" thời gian kiểm tra đơn vị.

Tôi đã có chính xác cùng một vấn đề ở đây, vì vậy tôi đã thêm một cam kết trước móc để Subversion vì vậy nó sẽ không chấp nhận bất kỳ cam kết mà không bắt đầu với số tài Story (một số mô hình cơ bản phù hợp cho một định dạng dự kiến).

Không có gì ngăn họ nhập 000-0000, nhưng một khi chỉ có một tên ngốc quậy phá sẽ tạo thành một số khi họ có một số hoàn toàn chấp nhận được ở đó.

Tôi đã làm điều này sau khi dành nhiều ngày cố gắng tìm ra tập hợp các câu chuyện người dùng đã đi vào. Vâng, đó là để đối phó với một thất bại quá trình khác, nhưng đó vẫn là thông tin vô cùng quý giá để theo dõi.

Nhận xét cam kết tốt giống như bất kỳ tài liệu tốt nào, bộ đệm cho bộ não chậm và không còn tồn tại của bạn hoặc bộ đệm của kết quả của bất kỳ quá trình gỡ lỗi / phân tích vấn đề / điều tra dài nào.

Ví dụ, bất cứ khi nào bạn dành thời gian để tìm ra một cái gì đó, như gỡ lỗi, phân tích nhật ký hoặc bất cứ điều gì, kết quả và kết quả của bạn là quý giá. Tất nhiên hầu hết các nhiệm vụ có thể được lặp đi lặp lại, nhưng nó có thể mất thời gian. Vì vậy, bạn nên luôn luôn ghi lại kết quả của bạn.

Tuy nhiên, tài liệu cần có thời gian và đôi khi cảm thấy không cần thiết, như "chúng ta chỉ phải làm điều này một lần, vậy tại sao lại viết nó ra". Điều đó ổn, nhưng ngay sau khi bạn làm điều tương tự lần thứ hai vì bạn không ghi lại kết quả lần đầu tiên, thì tất nhiên là thông minh để ghi lại kết quả.

Vì vậy, nếu đồng nghiệp của bạn cảm thấy quá nhiều công việc để thêm nhận xét cam kết, ví dụ như ít nhất chỉ vào trường hợp Jira / Vé mà họ đang giải quyết, thì họ có thể bị thúc đẩy bởi áp lực liên tục trả lời các câu hỏi liên quan đến lý do cho mỗi lý do thay đổi.

Theo tôi, tài liệu nên được sản xuất như một chức năng của thông tin được yêu cầu. Ví dụ, thư tín là một hệ thống tài liệu khá tốt. Các câu hỏi nhận được câu trả lời mà sau này có thể được truy xuất, đó là cách danh sách gửi thư và diễn đàn hoạt động trong thực tế như là cơ sở tri thức.

Thật không may, nơi tôi làm việc, thư sẽ tự động bị xóa sau 3 tháng, vì vậy nó không luôn hoạt động trong thực tế.

Tìm kiếm sự tha thứ, không được phép.

Trong khi khắc nghiệt, tôi đã làm điều này. Tôi đã có một sự phân chia 50/50 giữa những người ủng hộ và những người chống đối, hầu hết những người có cùng đẳng cấp với tôi trong nhóm. Các đối số là "Tôi không thể bị làm phiền" và "Vấn đề là gì?". (Cả hai chỉ ra sự thờ ơ và lười biếng, không phải mối quan tâm thực sự).

Tôi đã thêm hook pre-commit chỉ đơn giản là đo chiều dài của chuỗi và đưa ra một thông điệp hơi hài hước trước khi từ chối nó. Tôi ghi tên mình vào tin nhắn để trách nhiệm cho "sự phẫn nộ này" là rõ ràng. Tất nhiên, "phe đối lập" có thể dễ dàng loại bỏ nó, nhưng đào sâu vào các kịch bản sẽ tốn nhiều công sức hơn là thêm một bình luận!

Trong một tuần, tôi nhận được các tin nhắn được thêm vào như * * (đã bị xóa) hoặc kjhfkwhkfjhw. Sau đó, các tin nhắn cơ bản bắt đầu xuất hiện.

Một năm sau và những người hoài nghi sử dụng những bình luận có ý nghĩa và thực sự thừa nhận rằng họ đã thiển cận như thế nào. Tôi không bao giờ có thể có được sự đồng thuận, nhưng tôi chắc chắn đã được tha thứ và có lẽ đáng tin cậy. Nó hoạt động, mọi người sử dụng nó.

Nếu bạn muốn trở nên hòa hợp hơn (hoặc cảm thấy rằng bạn sẽ gặp rắc rối), hãy xin phép để thêm một hook hook trong một thời gian dùng thử. Nói rằng nếu mọi người không thích nó trong 2 tuần hoặc 4 tuần, bạn sẽ lấy nó ra. Rất có thể, họ sẽ mất hứng thú ... hoặc phát triển để thích nó.

Tôi thường thuyết phục mọi người thông qua:

• biện chứng với lý do hỗ trợ tốt
• dẫn đầu bằng ví dụ
• tiêu hao

Nếu tôi muốn đội của chúng tôi làm điều gì đó đủ tồi tệ, tôi sẽ tiếp tục làm phiền cho đến khi tôi đi được. Tôi cố gắng ngậm ngùi trong những khoảng thời gian mà tôi có thể chỉ ra rằng chúng tôi có thể tiết kiệm thời gian / tiền bạc nếu chúng tôi đã làm X.

Thêm lý do tốt để bình luận cam kết:

• Tạo ChangeLog tự động từ các bình luận.
• Dấu vết kiểm toán để sửa lỗi, bổ sung tính năng. Điều này rất hữu ích cả trong và ngoài đội.
• Làm cho thư cam kết hữu ích hơn.
• Ngăn tôi hỏi nhà phát triển cam kết X làm gì (sau hầu hết mọi cam kết).

• Kiểm tra nhật ký SVN của bạn để biết một cái gì đó tối nghĩa được thực hiện 6 tháng trước.
• Đặt một số câu hỏi về điều này mà không nói khi nào nó được thực hiện
• ???
• Lợi nhuận

Làm thế nào để bạn làm cho họ muốn thêm ý kiến ​​tốt?

Từ một kinh nghiệm với một đồng nghiệp tôi vừa có. Vào cuối một dự án, chúng tôi đã phải viết một tài liệu tóm tắt về tất cả những thay đổi được thực hiện trong suốt dự án. Không thực hiện các ghi chú cam kết tốt, đồng nghiệp của tôi thấy nhiệm vụ này khá tốn thời gian và giờ đã chuyển sang thực hiện các nhận xét khá dài với mỗi cam kết.

Vì vậy - việc thực hiện - một giải pháp có thể là để các nhà phát triển viết các tài liệu tóm tắt vào cuối dự án, chi tiết những thay đổi được thực hiện đối với các tệp nào, các tệp nào được thêm / xóa và tại sao.

Đề xuất điều này cho quản lý đằng sau cánh cửa đóng kín:

Trường hợp xấu nhất xảy ra: Tất cả các nhà phát triển cấp cao bước ra khỏi cửa.

Khi công ty tranh giành để lấp đầy các ghế nhà phát triển trống, nhóm quản lý có nhiệm vụ truyền đạt trạng thái của hệ thống cho khách hàng.

Hỏi họ những gì họ nghĩ sẽ làm cho công việc của họ dễ dàng hơn trong việc xây dựng lại lịch sử của ứng dụng:

Đọc tiếng Anh đơn giản cam kết mô tả rõ ràng trạng thái thay đổi của hệ thống?

Hay họ muốn xem xét sự khác biệt về mã và tự tìm ra nó?

Tôi đoán một cách để thuyết phục họ là thực sự trải nghiệm nỗi đau mà bạn đang cảm thấy.

Chẳng hạn, giả sử họ đang giải quyết vấn đề sau: Họ có một lỗi, bằng cách nào đó đã xuất hiện khi một lỗi sửa lỗi khác cho cùng một mã (ôi trớ trêu) được thực hiện. Để có thể tìm kiếm điều này từ việc chỉ tìm kiếm thông qua các thông điệp cam kết sẽ rất tuyệt (và do đó tìm ra ai đã viết nó).

Một cách khác là giải thích cho họ rằng thông điệp cam kết có thể hữu ích để đưa ra gợi ý về lý do tại sao một cái gì đó được thực hiện theo một cách nhất định. Ngay cả khi thông báo cam kết chỉ nói "tính năng X", bạn vẫn có thể nhận được manh mối đã triển khai nó, vì vậy bạn biết phải nói chuyện với ai.

Tuy nhiên, điều này dường như không đủ để chống lại hai phản hồi tôi luôn nhận được:

1. Mất quá nhiều thời gian và tôi chỉ muốn nhận được những thay đổi của mình trong repo.
2. Nó đủ dễ dàng để chỉ nhìn vào khác biệt.

Bạn đã thử đưa ra một thách thức cho các nhà phát triển đồng nghiệp của mình để họ nhận được một số lợi ích khác từ việc đưa ra nhận xét chưa? Người ta có thể nhìn vào điều này từ một trong hai góc độ khác nhau:

1. Upping trò chơi của họ - Đây có thể là viễn cảnh khó khăn hơn nhưng ý tưởng ở đây là họ sẽ làm điều này trong một khoảng thời gian và làm quen với ý tưởng để thói quen sẽ mất nhiều thời gian hơn để đi theo con đường khác. Một điểm khác ở đây là các ý kiến ​​sẽ được xem xét kỹ lưỡng như thế nào? Nếu bạn đang muốn một câu chuyện ngắn trong bình luận tôi có thể hiểu quan điểm của họ.
2. Trợ cấp thay đổi - Đây là nơi bạn có một số loại cuộc thi như một cách để mua lần đầu để thử điều này hoặc cung cấp một số loại khuyến khích khác để thực hiện thay đổi trong một thời gian.

Một điều khác cần xem xét là làm thế nào để bạn biết những gì các nhà phát triển đồng nghiệp của bạn đang quản lý nơi bạn làm việc? Nếu họ đang cố gắng hoàn thành 10 việc ngày hôm qua thì tôi có thể hiểu rằng họ có thể không muốn thay đổi những gì họ thấy là một cái gì đó đã hoạt động. Bạn đang cố nói với họ, "Không, cái này không hoạt động?" Nếu vậy, thì tôi có thể thấy làm thế nào họ có thể phòng thủ một chút hoặc chống lại điều này. Nếu bạn đang cố nói với họ, "Trong khi điều này có thể hoạt động, có một cách khác có thể tốt hơn ..." thì bạn có thể có cơ hội. Có thái độ "Holier than ngươi" ở đây sẽ không giúp bạn, IMO.

Một cách khác để nhìn vào điều này như là một cách để các nhà phát triển (s) tham gia phát triển sự nghiệp của họ - họ nên sở hữu các tài liệu hướng dẫn công việc của họ.

Ngoài các điểm khác được nêu trong bài viết tham khảo ở trên, có khả năng có thể xem lại các thay đổi mã để tìm ra nơi / khi / tại sao một thay đổi được thực hiện. Điều đó có thể rất quan trọng khi theo dõi một lỗi khó nắm bắt.

Sau khi bạn đã thuyết phục họ rằng điều quan trọng là nhận xét các cam kết của bạn, bạn có thể tạo một tập lệnh buộc nhận xét về các cam kết, nếu không nó sẽ thất bại. Bạn thậm chí có thể chỉ định tối thiểu các ký tự để đảm bảo bình luận có ý nghĩa. Điều này sẽ giúp họ "nhớ".

Tuy nhiên, điều quan trọng là họ hiểu Tại sao như @Kevin nói, nếu không họ sẽ chỉ thêm bất kỳ nhận xét ngẫu nhiên nào.

Bạn có đánh giá mã? Một điều có thể giúp là đưa ra một quy tắc rằng bất kỳ cam kết hoặc hợp nhất nào cũng phải được xem xét và phê duyệt bởi nhà phát triển khác. Sau đó, nếu bạn là người đánh giá, bạn sẽ phải yêu cầu nhà phát triển thực hiện cam kết giải thích cho bạn những gì anh ta đã làm. Một khi anh ấy làm, bạn nên yêu cầu anh ấy gõ vào bình luận những gì anh ấy vừa nói với bạn. Thông thường khi người ta không thể giải thích mạch lạc những thay đổi mà họ đã thực hiện, điều đó có nghĩa là những thay đổi đó không nên được thực hiện ngay từ đầu.

Tôi phải nói rằng, làm thế nào mọi người có thể phản đối một cái gì đó rõ ràng hữu ích như cam kết nhận xét? Nó không mất nhiều thời gian, và đó là một thời gian tốt. Viết một bình luận buộc bạn phải suy nghĩ về những gì bạn vừa làm. Nó thậm chí có thể khiến bạn nhìn vào các khác biệt để chắc chắn rằng bạn thực sự đã làm những gì bạn nghĩ bạn đã làm, và bạn chưa làm gì ngu ngốc.

Khi bạn không viết bình luận, bạn đang cẩu thả và vô kỷ luật. Và nếu bạn khăng khăng rằng bạn không cần phải viết bình luận, thì bạn đang cố tình cẩu thả.

Nói với họ cách duy nhất để có cơ hội duy trì mớ hỗn độn 50.000 phương thức thủ tục của bạn, sau đó xem xét viết mã tốt hơn, rõ ràng hơn trong tương lai để bạn không phải đối phó với một loạt các bình luận vô nghĩa làm phình to cơ sở mã của bạn.

Đây là mục thay đổi quy trình: Yêu cầu người quản lý gán mã được phát triển bởi "x" thành "Y" để kiểm tra đảm bảo chất lượng trên mã, bao gồm cả QA của các nhận xét.

Trong tổ chức của riêng tôi, các nhà phát triển không được phép thực hiện QA cuối cùng của mã riêng của họ và kiểm tra nó, điều này phải được thực hiện bởi một nhà phát triển khác. Một phần của Kiểm tra QA là nhận xét, vì vậy không có nhận xét, không đăng ký. Chúng tôi thực hiện nhiều công việc hợp đồng trong đó "nghệ thuật" của chúng tôi thực sự là tài sản trí tuệ theo hợp đồng của người khác, vì vậy những người khác cần có thể hiểu và tận dụng mã của chúng tôi. Ngoài ra, có những lúc các dự án quay trở lại với chúng tôi sau một thời gian gián đoạn dài và chúng tôi cần có thể nhận mã 18-24 tháng sau đó và hiểu lý do tại sao, ở đâu và làm thế nào chúng tôi đến mã hiện vật trước mặt chúng tôi. Điều này cung cấp một động lực tự phục vụ để viết bình luận cam kết.

Yêu cầu và yêu cầu các nhà phát triển đồng nghiệp của bạn thực hiện một số hợp nhất và tìm kiếm lịch sử và so sánh một vài tệp từ lịch sử.

Rất có thể họ sẽ yêu cầu bạn đưa ý kiến ​​vào ngày hôm sau trở đi.

Đây là một số lời khuyên:

1. Đừng cố gắng thay đổi thế giới. Bạn sẽ thất bại.
2. Thay vào đó, bạn nên nhận ra rằng mọi người đều làm việc theo cách hơi khác nhau. Không một kích thước phù hợp với tất cả mọi người.
3. đòi hỏi một số bước cụ thể để quy trình làm việc của mọi người là rất xấu. Thay đổi các quy trình này mất 10 năm. Bạn đang yêu cầu họ làm điều này trước thời hạn tiếp theo.
4. Ngay cả những thay đổi quá trình đơn giản có thể mất nhiều thời gian.
5. Một số nhận xét nhỏ về các cam kết là quá không đáng kể để thay đổi các quy trình này.
6. Bạn có thể cho rằng họ làm công việc có chất lượng, nhưng nên cho đủ tự do để tự mình lựa chọn các bước. Một số bước nặng nề có thể không cần thiết cho các nhà phát triển có kinh nghiệm.
7. Nếu bạn đang trông trẻ người mới, thì các quy trình mạnh hơn có thể là cần thiết, nhưng các nhà phát triển có kinh nghiệm không nên đối phó với sự nhảm nhí.
8. Áp đặt các hạn chế hà khắc về cách thức thực hiện công việc không bao giờ được thực hiện, nó chỉ có thể làm mọi người chậm lại (có thể tốt nếu họ quá nhanh)
9. Có rất nhiều người nghĩ rằng cách của họ là cách duy nhất đúng để làm mọi việc. Hy vọng bạn không phải là một trong số họ.

Nếu kiểm soát nguồn của bạn chứng minh điều đó, hãy bật các bình luận bắt buộc để ngăn chặn mọi cam kết không được bình luận. Đủ đơn giản và mọi người sẽ sớm nhận ra rằng 5 giây gõ một bình luận là không đau.

Nhưng cam kết không bình luận là một trong những tiêu cực nhỏ nhất có. Tôi đã từng là một phần của nhiều dự án thành công mà không một cam kết nào được bình luận. Đừng lấy quần lót của bạn trong một bó trên nó.