- Năm 2007, 2000 dòng mã

The Original Macintosh: 36 of 123 - 2000 Lines Of Code

• Đầu năm 1982, nhóm phần mềm Lisa đang tập trung vào giai đoạn nước rút để phát hành phần mềm trong vòng 6 tháng tới.

• Một số quản lý cho rằng việc theo dõi lượng mã mỗi kỹ sư viết ra hằng tuần là một ý tưởng hay, nên đã tạo một biểu mẫu phải nộp vào mỗi thứ Sáu, trong đó có một mục để điền số dòng mã đã viết trong tuần đó.

• Bill Atkinson, tác giả của Quickdraw và là nhà thiết kế giao diện người dùng chủ chốt, cho rằng số dòng mã là một cách ngớ ngẩn để đo năng suất phần mềm, vì nó chỉ khuyến khích việc viết ra những đoạn mã lộn xộn, phình to và đầy lỗi.

• Atkinson gần đây đang tối ưu hóa bộ máy tính toán vùng của Quickdraw, và đã viết lại hoàn toàn region engine bằng một thuật toán đơn giản hơn và tổng quát hơn, sau vài tinh chỉnh đã giúp các thao tác vùng nhanh hơn gần 6 lần.

• Việc viết lại này đồng thời giúp tiết kiệm khoảng 2000 dòng mã.

• Ở giai đoạn cuối của công việc tối ưu hóa, đến lúc lần đầu tiên phải điền biểu mẫu quản lý, khi tới mục số dòng mã, ông suy nghĩ một lúc rồi điền con số -2000.

• Không rõ các quản lý đã phản ứng thế nào, nhưng vài tuần sau đó, họ ngừng yêu cầu Atkinson điền biểu mẫu, và ông sẵn lòng chấp nhận điều đó.

Ý kiến của GN⁺

• Bài viết này đưa ra một bài học quan trọng rằng số lượng mã trong phát triển phần mềm không phản ánh năng suất thực sự. Nó cho thấy việc đo thành quả dựa trên số dòng mã không chỉ kém hiệu quả mà đôi khi còn phản tác dụng.
• Ví dụ của Bill Atkinson nhấn mạnh tầm quan trọng của tối ưu hóa phần mềm. Đạt được hiệu năng nhanh hơn với ít mã hơn là một trong những nguyên tắc cốt lõi của kỹ nghệ phần mềm.
• Câu chuyện này giúp hiểu vì sao các thực hành phát triển hiện đại, đặc biệt là các phương pháp như Agile và tích hợp/triển khai liên tục (CI/CD), lại quan trọng. Những phương pháp này coi trọng chất lượng, khả năng bảo trì và trải nghiệm người dùng hơn là số lượng mã.
• Trong ngành, nhiều công cụ và chỉ số khác nhau được dùng để đo lường và cải thiện chất lượng mã. Ví dụ như công cụ phân tích mã tĩnh, quy trình review code và theo dõi độ bao phủ kiểm thử.
• Bài viết này nhắc nhở các lập trình viên rằng việc tập trung vào chất lượng thay vì số lượng mã, tránh độ phức tạp không cần thiết và tối ưu hóa hiệu năng là quan trọng đến mức nào.

[GN⁺]

Ý kiến trên Hacker News

• Xung đột về số dòng mã giữa Microsoft và IBM

  • Trong loạt chương trình truyền hình PBS "Accidental Empires", có một cảnh Steve Ballmer kể lại trải nghiệm trong thời kỳ hai bên cùng phát triển OS/2. Microsoft xử lý công việc với tác phong của một công ty nhỏ, trong khi IBM lại tập trung nội bộ vào việc lấy số dòng mã (tính theo nghìn dòng, KLoC) làm thước đo năng suất lập trình viên. Ballmer chỉ trích IBM rằng họ chỉ quan tâm đến số lượng hơn là chất lượng mã.

• Các liên kết đến những cuộc thảo luận trước đây

  • Các cuộc tranh luận về việc dùng số dòng mã làm chỉ số năng suất xuất hiện khá thường xuyên. Bài đăng cung cấp các liên kết cho thấy đã có nhiều thảo luận khác nhau từ năm 2010 đến 2022.

• Lấy số dòng mã làm chỉ số năng suất là điều cực kỳ ngớ ngẩn

  • Có người nhắc đến trải nghiệm sửa một lỗi tồn tại suốt 20 năm chỉ bằng một dòng mã, hoặc sửa một lỗi tồn tại 3 năm bằng order by, rồi đặt câu hỏi làm sao có thể đo được tác động của chỉ một dòng mã. Họ cũng chia sẻ kinh nghiệm rằng lập trình viên kém thường viết ra nhiều mã hơn, đồng thời giới thiệu trường hợp một lập trình viên Microsoft đã viết lại 33.000 ký tự mã của IBM thành 220 ký tự. Vì vậy mà công việc của Microsoft lại bị đánh giá là "âm".

• Những câu hỏi đơn giản đôi khi tạo ra tác động lớn nhất

  • Một câu hỏi đơn giản về việc nên triển khai một tính năng như thế nào ("X sẽ được xử lý ra sao?") có thể dẫn đến quyết định không làm tính năng đó, và kết quả là tiết kiệm toàn bộ chi phí của việc thử triển khai. Những đóng góp như vậy không thể đo bằng con số, đôi khi còn khiến bạn mất lòng người khác, nhưng dù vậy vẫn bày tỏ sự kính trọng với những ai dám làm điều đó.

• Chia sẻ trải nghiệm tối ưu hóa mã ở giai đoạn đầu sự nghiệp

  • Có người chia sẻ trải nghiệm tối ưu một chương trình C dài hơn 10.000 dòng xuống còn dưới 500 dòng. Với giả định đơn giản rằng lập trình viên trước đó có thể không biết cách dùng hàm hoặc cách truyền dữ liệu biến vào câu truy vấn SQL, họ phát hiện cùng một câu lệnh SQL đã bị viết inline lặp đi lặp lại. Sau đó họ viết lại các lời gọi SQL thành lời gọi hàm, rồi thay thế phần mã trùng lặp bằng cách lấy các giá trị bind đã thay đổi từ một mảng và gọi hàm trong vòng lặp.

• Thiếu định hướng rõ ràng khi bắt đầu dự án

  • Có những lúc bắt đầu dự án mà không biết chính xác phải đi theo hướng nào; khi dấn sâu vào dự án, người ta hiểu vấn đề và lời giải mong muốn rõ hơn, từ đó có thể loại bỏ những phần lớn và thay bằng thứ nhỏ hơn, tốt hơn. Trong bối cảnh đó, các lập trình viên từng phải nhét mọi thứ vào ROM 64KB đã chịu áp lực rất lớn để làm mã nhỏ lại.

• Một thí nghiệm tư duy về việc dùng số dòng mã bị xóa làm chỉ số

  • Có đề xuất một thí nghiệm tư duy: nếu một quản lý đọc bài này và đơn giản quyết định dùng số dòng mã bị xóa làm chỉ số đánh giá, thì tình hình sẽ tốt hơn hay tệ hơn?

• Atkinson Dither của Bill Atkinson

  • Có cung cấp liên kết về Bill Atkinson và kỹ thuật Atkinson Dither của ông.

• Nhận thức về số dòng mã

  • Có người đặt câu hỏi về việc dùng công thức "số dòng thêm vào - số dòng xóa đi" khi viết mã. Cũng như không ai gọi một lần chạy 10 km bắt đầu và kết thúc ở cùng một chỗ là chạy 0 km, họ cho rằng số dòng mã cũng nên được nhìn nhận tương tự.

• Vai trò của một nhân viên

  • Có người chia sẻ bài học rằng dù bạn có thông minh như Einstein thì bạn vẫn là một nhân viên, và với tư cách nhân viên thì vẫn có những việc phải làm.