Vì sao cần chú thích “Why Not”

• Chú thích có thể dùng ngôn ngữ con người giàu sức biểu đạt hơn định danh, nên phù hợp để lưu lại những lựa chọn không có trong mã và các phương án đã từ bỏ
• “comment the why, not the what” là cách tiếp cận cố gắng đưa tối đa thông tin vào định danh, nhưng gần đây có xu hướng chuyển cả lý do vào tên hàm dài hoặc tên bài kiểm thử
• Trong bản dựng epub của Logic for Programmers, phần triển khai chậm được dùng để thay thế tuần tự 16 ký hiệu toán học theo từng chuỗi, nhưng hiện chỉ có 25 chuỗi toán học nên đủ nhanh
• Những chú thích như vậy về sau sẽ chỉ ra vị trí cần sửa khi số chuỗi toán học tăng lên hàng trăm và trở thành nút thắt cổ chai của quá trình dựng, đồng thời lưu lại rằng đoạn mã chậm là một đánh đổi có chủ ý
• Tên hàm hay bài kiểm thử được gắn với những gì mã thực sự làm, nên khó tự tài liệu hóa thông tin phủ định về các phương án không được chọn và những việc không làm

---

Thông tin mà chú thích dễ chứa hơn mã

• Mã là ngôn ngữ máy có cấu trúc, còn chú thích được viết bằng ngôn ngữ con người giàu khả năng biểu đạt
• “comment the why, not the what” có thể được hiểu là hãy đưa càng nhiều thông tin càng tốt vào định danh
• Định danh gần với ngôn ngữ con người bị giới hạn nằm trong mã; không thể chứa mọi “what”, nhưng trong nhiều trường hợp thì có thể
• Gần đây ngày càng có nhiều quan điểm cho rằng cả “why” cũng có thể được đưa vào tên hàm dài hoặc tên ca kiểm thử, thay vì chú thích
• Các codebase tự tài liệu hóa thường tăng mức độ tài liệu hóa bằng cách thêm định danh
  • Như một ngoại lệ, có trường hợp biến chú thích thành logging để làm cho mã tự tài liệu hóa hơn

Chú thích “Why Not” xử lý điều gì

• Thông tin khó biểu đạt bằng mã là thông tin phủ định
• Thông tin phủ định thu hút sự chú ý đến những gì không có trong hệ thống, hoặc vì sao một phương án cụ thể không được chọn
• “why not” không giải thích việc mã đang làm, mà để lại những lựa chọn mã không làm và lý do của chúng

Ví dụ thay thế ký hiệu toán học trong epub

• Trong bản dựng epub của Logic for Programmers, vì lý do kỹ thuật, các ký hiệu toán học như \forall không được chuyển thành ký hiệu như ∀
• Để giải quyết việc này, một script được viết để thay trực tiếp các token trong chuỗi toán học bằng ký hiệu Unicode tương ứng
• Cách triển khai dễ nhất là gọi string = string.replace(old, new) cho từng 16 ký hiệu toán học cần thiết
• Cách này không hiệu quả vì duyệt mỗi chuỗi 16 lần, nhưng cách xử lý toàn bộ 16 phép thay thế chỉ trong một lượt duyệt thì phức tạp hơn
• Ý chính của chú thích để lại là như sau
  • Duyệt mỗi chuỗi 16 lần
  • Hiện cuốn sách chỉ có 25 chuỗi toán học và hầu hết ngắn hơn 5 ký tự
  • Vì vậy vẫn đủ nhanh
• Chú thích này không chỉ giải thích “vì sao dùng mã chậm”, mà còn giải thích cả “vì sao không dùng mã nhanh”

Biển chỉ dẫn cho người đọc sau này

• Ngay cả khi mã chậm hiện chưa gây vấn đề, về sau nó vẫn có thể trở thành vấn đề
• Nếu trong một phiên bản tương lai của Logic for Programmers, số chuỗi toán học tăng lên hàng trăm, bước dựng này có thể trở thành nút thắt cổ chai của toàn bộ quá trình dựng
• Nếu để lại biển chỉ dẫn ngay bây giờ, về sau sẽ biết ngay cần sửa phần nào
• Ngay cả khi mã tiếp tục chạy không vấn đề gì, chú thích vẫn bảo toàn sự thật rằng tác giả đã biết về đánh đổi
• Khi mở lại epub_math_fixer.py sau 2 năm, sẽ giảm nhu cầu phải điều tra lại xem mã chậm là do non tay, thiếu thời gian hay sai sót
• Chú thích phủ định lưu lại thông tin rằng tác giả đã biết cách triển khai chậm, đã cân nhắc phương án thay thế, và đã quyết định không tối ưu hóa

Vì sao khó thay thế bằng tên hàm và kiểm thử

• Một tên hàm như RunFewerTimesSlowerAndSimplerAlgorithmAfterConsideringTradeOffs quá dài và không giải thích đầy đủ đánh đổi thực tế
• Nếu về sau tối ưu hóa mã, có thể phải đổi tên đó ở nhiều nơi
• Vấn đề lớn hơn là những tên như vậy không cho biết hàm thực sự làm gì, nên ngược lại còn làm suy yếu khả năng tự tài liệu hóa
• Các định danh như tên hàm và tên biến chỉ có thể chứa một mệnh đề thông tin
• Rất khó đưa đồng thời “việc hàm làm” và “đánh đổi mà hàm chấp nhận” vào một định danh duy nhất

Thông tin phủ định cũng khó lưu lại bằng kiểm thử

• Có thể tạo một bài kiểm thử grep các khối toán học trong sách và thất bại nếu số lượng vượt quá 80
• Nhưng bài kiểm thử như vậy không trực tiếp kiểm thử chính EpubMathFixer
• Bên trong hàm không có điểm nào để bài kiểm thử đó móc vào
• Tự tài liệu hóa bám theo mã đã viết và giải thích việc mã làm
• Vì thông tin phủ định xử lý những việc mã không làm, nó về cơ bản không phù hợp với cách tự tài liệu hóa

Câu hỏi rộng hơn

• Chú thích “why not” có thể được xem là một ví dụ của phản sự thật (counterfactual)
• Vẫn còn câu hỏi liệu các yếu tố trừu tượng trong giao tiếp của con người nói chung có thể tự tài liệu hóa được hay không
• Việc những thông tin như phép ẩn dụ, sự bất định, hay lập luận đạo đức có thể tự tài liệu hóa hay không vẫn còn là nghi vấn

[GN⁺]

Các ý kiến trên Hacker News

• Tôi nhớ một câu đùa hình như từng thấy trên Twitter vài năm trước: “Kỹ sư junior viết chú thích để giải thích code làm gì, kỹ sư trung cấp viết chú thích để giải thích code vì sao làm như vậy, còn kỹ sư senior viết chú thích để giải thích vì sao code không được viết theo cách khác” đại loại vậy

  • Quả thật rất đúng. Có lần tôi phải thêm chú thích dài gấp 5 lần bản thân đoạn code, để ngăn những người không biết code, domain hoặc các điểm cần cẩn trọng khi xử lý phạm vi động lớn, dù có thiện ý, refactor nó
    Ngược lại, nếu chỉ cần tên hàm và tên biến là đã làm rõ được ý nghĩa, tôi cũng từng viết cả những hàm khá lớn mà không cần chú thích
  • Tôi làm cả ba. Chú thích tóm tắt cực kỳ hữu ích và cũng đã được xác nhận bằng nghiên cứu thực nghiệm, nhưng nhiều người đã chìm quá sâu vào lối tư duy kiểu Clean Code nên có vẻ khó cứu
  • Lập trình viên junior thường hoặc không tài liệu hóa gì cả, hoặc tài liệu hóa mọi thứ. Khi có kinh nghiệm hơn, họ hiểu rằng chỉ cần tài liệu hóa những thứ bất thường; rồi khi càng nhiều kinh nghiệm hơn, những thứ bất thường ngày càng ít đi nên chú thích cũng giảm
    Vì vậy phía ít chú thích hơn thường thắng, nhưng khi nhìn vào một codebase không có chú thích, phải tự xem kỹ mới phân biệt được đó là một kiệt tác được trau chuốt đẹp đẽ hay là code thiếu ổn định do người mới làm
  • Cũng có những chú thích giải thích vì sao phải tiếp tục tái hiện một hành vi rõ ràng trông rất ngớ ngẩn. Vì có thứ khác đang phụ thuộc vào hành vi ngớ ngẩn đó
  • Nếu là kỹ sư cấp C thì sẽ để lại chú thích kiểu “Đã lãng phí X giờ để refactor đoạn code này. Nếu bạn đã quyết định đi theo vết xe đổ của tiền bối, hãy tăng bộ đếm này lên”
    Dù trông như một miếng vá tạm bợ hoàn toàn, đôi khi đó thực sự lại là phương án tốt nhất có thể đạt được

• Nếu tôi nghĩ nó sẽ hữu ích cho mình khi xem lại code sau 1 năm, tôi đều để lại bằng chú thích. Thường là vì sao và vì sao không được, còn khi code phức tạp thì tôi cũng ghi ngắn gọn “cái gì” để dễ nhìn luồng hơn
  Thứ không hữu ích là chú thích bắt buộc. API public cần được tài liệu hóa đầy đủ, nhưng có tổ chức còn bắt buộc mọi hàm, kể cả hàm private, đều phải có chú thích, đến mức mục đích quá hiển nhiên và chú thích chỉ lặp lại tên hàm. Điều đó không chỉ lãng phí thời gian mà còn khiến người ta chai lì với chú thích, dạy họ thói quen bỏ qua chúng
  Tôi cũng ghét các chú thích lãng phí do công cụ thêm vào. Kiểu gắn //for hay //try cho mọi vòng lặp thì đặc biệt tệ

  • Lạ là rất nhiều bảng màu tô sáng cú pháp làm chú thích mờ đi và giảm độ tương phản. Có lẽ vì chú thích bắt buộc hoặc chú thích sinh tự động thường có ít thông tin
    Tốt hơn là loại bỏ chú thích bắt buộc và chú thích sinh tự động, còn trong theme tối thì đổi chú thích thành màu neon sáng để chúng nổi bật. Nếu đã có chú thích, điều đó phải có nghĩa là nó quan trọng
  • Trước đây tôi theo quan điểm “mọi chú thích đều là code smell”, và đến giờ phần lớn vẫn vậy, nhưng sau khi làm việc trên một codebase rất lớn với hàng trăm người tích cực phát triển và bảo trì, quan điểm của tôi đã dịu đi một chút
    Khi bảo trì các hệ thống lớn lâu đời trong môi trường kinh doanh với lịch trình gấp gáp, có lúc phải làm những việc kỳ lạ, và khi đó cần giải thích vì sao
    Lý do lớn khiến tôi phản đối chú thích là chú thích cũng trở thành một phần của code và cần được bảo trì. Nhưng hầu hết mọi người chỉ đọc chú thích khi bị mắc kẹt, còn các editor cũng làm chú thích mờ màu xám khiến về mặt tâm lý chúng gần như vô hình. Vì vậy chú thích rất dễ lỗi thời
    Tôi tự hỏi liệu ngữ cảnh dành cho “tôi trong tương lai” có hữu ích trong một codebase dùng chung mà nhiều lập trình viên chạm vào hay không, hay đó là cách chỉ hiệu quả khi chỉ có một số ít người đụng đến code
  • Hoàn toàn đồng ý. Nếu chú thích quá nhiều, sẽ khó nhìn thấy bên trong class hay hàm có gì. Một class hoặc hàm vốn nằm gọn trong một màn hình mà vì chú thích phải vượt quá một màn hình thì sẽ phát sinh chi phí về khả năng đọc
  • Hôm qua trong dự án cá nhân, tôi thấy một dòng có chú thích “cái này có thật sự hữu ích không?”, và trông có vẻ có thể dễ dàng xóa đi. Tôi đã thử dùng một class mới, sạch sẽ hơn, nhưng hóa ra một cách làm cũ cụ thể lại thực sự cần thiết
    Vì vậy tôi thêm “=> yes!” vào chú thích hiện có, và biết ơn bản thân trong quá khứ đã ghi lại câu hỏi đó. Trong công việc, đặc biệt khi sửa bug, tôi thường để lại một hai dòng chú thích kèm mã ticket phía trên những thay đổi không rõ ràng

• Dạng chú thích tôi thích nhất từng để trong code là mẫu này: “DEAR MAINTAINER: Code này được viết như vậy vì [lý do]. Nếu bạn cố ‘sửa’ nó rồi nhận ra đó là một sai lầm khủng khiếp, hãy tăng bộ đếm total_hours_wasted_here = n lên để cảnh báo cho người tiếp theo”
  Tôi không phải tác giả gốc, nhưng đã biết ơn dùng nó một hai lần, và thấy khá thú vị khi nhìn thấy những commit một dòng chỉ tăng bộ đếm

  • Giá mà tôi có cái này vài năm trước. Tôi từng viết code sinh SQL phải dùng đệ quy khá thoải mái để đáp ứng yêu cầu, và tuy nhiều chỗ đệ quy lẫn nhau khiến code hơi bừa bộn, đó là điều xấu cần thiết
    Một kỹ sư senior hơn tiếp quản codebase và “sửa” toàn bộ sang cách dùng vòng lặp, còn định lên lớp tôi qua email rằng vì sao đệ quy là xấu, nhưng code của anh ta không đáp ứng được tất cả yêu cầu thực tế và cuối cùng về cơ bản đã tái tạo lại những gì tôi từng làm bằng đệ quy
    Sau đó anh ta có xin lỗi về một số phát ngôn, nhưng nếu tôi đã đặt một chú thích như thế ở đầu thì có lẽ đã tránh được toàn bộ việc này

• Tôi đồng ý rằng tiêu đề mơ hồ, và chính vì vậy tôi đã đọc bài. Cá nhân tôi nhìn chung thích dùng ít chú thích, nhưng chú thích giải thích trong bài rõ ràng có giá trị. Đó là một lời nhắc tốt rằng hãy giải thích vì sao làm như vậy, và vì sao không làm theo cách khác
  Điều này đặc biệt áp dụng cho code của chính bạn mà vẫn phải bảo trì sau 5, 10, 15 năm. Gần đây khi review code mới của đồng nghiệp, tôi nghĩ “sao lại làm thế này?”, thì hóa ra 10 dòng phía trên có lý do mà 8 năm trước chính tôi cũng đã làm y như vậy. Người đồng nghiệp đó đã tuân theo quy tắc cốt lõi của bảo trì: làm cho nó trông giống code hiện có

  • Khi bảo trì codebase cũ, việc làm cho nó trông giống code hiện có bị đánh giá quá thấp. Vì sức khỏe tinh thần của những người đến sau, xin hãy làm cho nó trông giống code hiện có

• Đây chỉ là một trường hợp đặc biệt của một nguyên tắc rộng hơn: khi đọc code, hãy chú thích những điều gây bất ngờ
  Khi viết code, nếu trong đầu bạn liên tục tự hỏi “sau này mình có hiểu được đoạn code này không?” và lần nào cũng theo bản năng trả lời “có”, thì người đó đang kiêu ngạo và thường sai. Nếu câu trả lời là “không chắc”, câu hỏi tiếp theo tự nhiên sẽ là “vì sao?”, và câu trả lời đó chính là nội dung cần viết vào chú thích
  Đôi khi câu trả lời là “vì người đọc có thể thắc mắc tại sao không viết theo cách khác”, và đó là trường hợp đặc biệt mà bài này bàn tới. Nhưng đôi khi lại là “vì không rõ nó hoạt động thế nào hoặc vì sao nó đúng”, khi đó cần một loại chú thích khác

  • Nếu ban đầu bạn đã thử viết code theo một cách nhưng không chạy, nên phải dùng cách tiếp cận thứ hai, đó là tín hiệu mạnh cho thấy chỗ đó cần chú thích. Nếu lúc viết bạn đã bất ngờ, thì một năm sau bạn có khả năng quên mất điều bất ngờ đó và lại bất ngờ lần nữa khi đọc code
  • Một nguyên tắc tương tự là lấy câu “nếu cái này không hoạt động như mong đợi thì phải xem ở đâu?” làm tiêu chí. Nếu câu trả lời không có trong tài liệu, hoặc nằm cách quá 10 dòng trên đường dẫn wiki → package/module → file → class → function/method, thì hãy thêm chú thích inline hoặc cập nhật tài liệu
    Điều này thường xảy ra khi cắt chuỗi hoặc duyệt một cấu trúc dữ liệu đặc biệt làm bước trung gian

• Chỉ riêng định danh cũng có thể đưa ta đi rất xa, nhưng không thể đi đến cùng. Cá nhân tôi thích yêu cầu chú thích tài liệu kiểu jsdoc/xmldoc cho các method, biến, field và tham số công khai
  Đặt tên method tốt cũng quan trọng, nhưng thử viết ngắn gọn nó làm gì sẽ khiến mọi thứ rõ ràng hơn, đặc biệt là làm lộ ra các khiếm khuyết hiển nhiên. Thường thì ngay lúc viết câu đầu tiên, bạn sẽ nghĩ ra một cái tên tốt hơn; còn nếu trong phần mô tả bắt đầu xuất hiện từ “và”, đó là dấu hiệu method đang làm quá nhiều việc và có thể được tách ra hợp lý hơn
  Với thuộc tính, rất dễ nghĩ rằng chúng quá rõ ràng nên không cần tài liệu, nhưng những thứ như /** The API key */ string ApiKey; còn thiếu quá nhiều. Không biết key này đến từ đâu, chỉ dùng nội bộ hay được trao đổi với hệ thống bên ngoài, có bắt buộc không, có thể là null hoặc rỗng không, có độ dài tối đa không, giá trị sai thì chuyện gì xảy ra, và có code hay tài liệu nào khác cần đọc thêm không
  Với tác giả ban đầu, đây là thông tin có thể viết trong 1–2 phút, nhưng người mới đến có thể mất nhiều giờ để tìm ra khi cần sửa, sử dụng, hoặc vài năm sau được giao vào sửa bug

• Trong code review, nếu đoán trước được một reviewer quá soi mói sẽ nói gì, tôi thường viết chú thích kiểu “không làm X vì Y”. Mục đích là giảm các vòng trao đổi phiền phức

  • Theo kinh nghiệm, số vòng trao đổi vẫn như cũ, nhưng ít ra có thể viết vài lần “như đã ghi trong chú thích”
  • Tôi sẽ chủ động thêm những nội dung như vậy vào PR, nhưng không chắc chúng có đáng để lưu lại trong code hay không

• Những chú thích kiểu “mỗi chuỗi được duyệt 16 lần, nhưng đến nay sách chỉ có 25 chuỗi công thức và hầu hết dưới 5 ký tự nên vẫn đủ nhanh” cũng có một biến thể khác
  Đó là thêm debug log kích hoạt khi input lớn hơn nhiều so với ràng buộc thiết kế ban đầu. Nó gửi gần như cùng một thông điệp cho lập trình viên tương lai, nhưng giúp phát hiện sớm hơn và giảm thêm thời gian chẩn đoán, debug

  • Trong nhiều trường hợp, đây là ý hay. Đôi khi ta dùng một vòng lặp hiện tại vẫn chạy được nhưng rất chậm; có thể đặt timer và “nếu mất hơn X giây thì ghi log cảnh báo”
    Trong một hệ thống logging và observability lý tưởng, mọi thành phần của ứng dụng đều được đo thời gian và thường xuyên ghi lại thông tin debug, nhưng thực tế có mấy ai dùng một hệ thống hoàn hảo như vậy. Quan trọng hơn là nỗ lực đặt log cụ thể ở những phần về sau có thể suy giảm hiệu năng hoặc từng không có thời gian tối ưu
    Nhìn lại thì đây là ý tưởng hiển nhiên, nhưng trước giờ tôi thường để lại chú thích ở những chỗ sau này cần xem lại, rồi hy vọng mình sẽ nhớ đến chú thích đó khi mọi chuyện trở nên tệ hơn
  • Các công cụ có ý tốt như bazel thường coi output không phải lỗi là nhiễu cần bị ẩn đi. Chúng hay gửi những thông điệp như vậy thẳng vào thùng rác gần nhất, nên trong một số lĩnh vực, log trở thành một phương tiện rất không ổn định để truyền đạt ràng buộc

• Bất kể ai nói gì, tôi vẫn viết rất nhiều chú thích và doc comment khắp nơi trong code. Chỉ là tôi tiếp cận ngược lại: trước tiên phác thảo danh sách các bước của ứng dụng bằng chú thích, rồi trong lúc phát triển thì tách các bước lớn thành bước nhỏ, có khi xóa chú thích ban đầu, có khi giữ lại, và tiếp tục chia nhỏ chú thích cho đến khi gần như thành một thuật toán hoàn chỉnh
  Vì thường code từ ngoài vào trong, nên trong lúc tách nhỏ chú thích tôi cũng viết code cùng lúc. Đôi khi tôi code một mạch rồi sau đó thêm chú thích nhiều đến mức hầu hết mọi người sẽ thấy phiền. Tôi gắn mô tả cho mọi hàm và biến, thậm chí với hàm deg_to_rad cũng thêm """Converts degrees to radians.""". Dung lượng lưu trữ rẻ mà
  Tôi biết đa số không thích, nhưng không sao. Nếu không muốn nhìn thì có thể dùng script để loại bỏ, hoặc xóa trong code review. Dù vậy, đọc code cũ của chính tôi vẫn thú vị hơn nhiều so với đọc code của người khác mà không có chú thích. Trong Python, các đoạn mã boilerplate đơn giản như Flask API thường khá tự mô tả, nhưng chính các boilerplate như vậy đôi khi lại thay đổi nhiều và cần chú thích quan trọng. Trong ngành, phần thuật toán thường bị viết lại toàn bộ nhiều hơn
  Tôi sẽ tiếp tục thích chú thích và doc comment

  • Tôi cũng làm tương tự, nhưng chủ yếu chỉ với các thành phần cấp cao nhất. Vì ở những nơi đó chú thích hữu ích nhất
    Tôi thích hình dung toàn bộ khái niệm trong đầu, và lúc đầu tôi thấy việc thử nghiệm nhiều lựa chọn thiết kế bằng cách thật sự viết ra khá chậm. Vì vậy khi đã chốt một lựa chọn thiết kế, nhất định phải ghi tài liệu lại. Bởi người khác vẫn chưa thể truy cập vào những gì trong đầu tôi
    Với chi tiết, tôi kỳ vọng rằng khi người khác cũng đã khái niệm hóa xong thì chúng sẽ trở nên rõ ràng hơn. Tuy nhiên nếu vì lý do nào đó việc khái niệm hóa đó không xảy ra, code có thể khó đọc hơn, nên tôi sẽ chỉnh thêm để giữ mức dễ đọc cơ bản tối thiểu
  • Chú thích rất tuyệt khi được bảo trì tốt. Nhưng trừ những trường hợp như mã nguồn mở, nơi số người đọc so với số người quản lý chú thích là rất lớn, cuối cùng mọi người đều quên hoặc ngại mà không duy trì nữa
    Việc cập nhật chú thích thường cũng là một công việc ngang với sửa code. Vì vậy trên thực tế, chú thích thường là thứ đang chờ để trở thành lời nói dối. Cuối cùng chú thích và code lệch nhau, và điều đó thậm chí có thể tệ hơn code không có chú thích
    Thà dùng các kiểm thử tự động thể hiện ý định còn hơn. Vì kiểm thử nhìn chung không thể nói dối; nếu có thì đáng lẽ đã không được merge. Nếu có một bộ test tốt cho thấy code được dự định sử dụng như thế nào, tôi muốn xem nó, vì nó vừa có tính giải thích vừa gần như được bảo đảm là đúng
  • Tôi thấy ổn cho đến chỗ “nếu không thích thì dùng script xóa trong phiên bản của mình hoặc xóa trong code review”, nhưng từ đó trở đi thì với tư cách đồng đội, đây có vẻ là một tín hiệu cảnh báo lớn
  • Tôi cũng tương tự. Khoảng một nửa thời gian, tôi viết chú thích trước để mô tả việc mình định làm, rồi sau đó bổ sung những điểm không diễn ra như dự kiến và những việc đã phải làm để khiến nó thật sự chạy được
    Khi phải xem lại sau 5 tuần, nó giúp ích cực nhiều
  • Tôi không nghĩ mọi trường hợp đều cần doc comment, cũng không cho rằng phải tài liệu hóa mọi tham số và giá trị trả về của mọi hàm. Nhưng với API phức tạp thì chắc chắn hữu ích

• Tôi theo quan niệm “chú thích là lời xin lỗi gửi cho bản thân trong tương lai”
  Nếu code kỳ lạ hoặc chậm, hoặc là phần mà khi giải thích cho ai đó tôi sẽ phải nói “chỗ này hơi lộn xộn”, thì tôi thường để lại chú thích. Đặc biệt nếu trước đây từng thử thay đổi nó, tôi sẽ ghi lại các trường hợp không hoạt động hoặc những gì đã sửa
  Nếu tiếp cận theo tiêu chí này, các chú thích không cần thiết sẽ tự nhiên biến mất, và thường bạn sẽ chỉ tài liệu hóa vì sao khi thật sự cần. Thử áp dụng trong codebase của mình khoảng một tháng là sẽ cảm nhận được