Trong ngành lập trình, có rất nhiều bài học xương máu được rút ra từ kinh nghiệm thực tiễn. 09 bài học sau đây là cực kỳ quan trong, nhưng có thể các lập trình viên phải trải qua “đau thương” mới thấm nhuần được.

1. Không tồn tại các component vừa rẻ nhất, nhanh nhất lại vừa đáng tin cậy nhất

Điều này đã từng được Gordon Bell khẳng định. Bài học rút ra ở đây là bạn nên giữ cho hệ thống hoặc phần mềm càng đơn giản càng tốt. Giảm độ phức tạp để giảm số lượng lỗi.

Điều này cũng đã được đề cập trong bài: 40 mẹo giúp thay đổi kỹ năng code của bạn mãi mãi

2. Lập trình Voodoo

Đôi khi, bạn cố gắng sửa một bug nhưng không hiểu tại sao con bug đó lại xuất hiện. Hầu hết các lập trình viên đã từng như vậy, nhưng điều này là tuyệt đối không nên. Hãy luôn đảm bảo rằng bạn hiểu code của mình và tìm hiểu lý do tại sao sự thay đổi này hoặc kia lại thành công.

Tư duy này sẽ dạy bạn nhiều hơn những cuốn sách có thể. Đừng xấu hổ và hãy hỏi người khác nếu bạn cần. Tại một thời điểm nào đó, bạn sẽ nhận thấy mình đã trở thành người mà mọi người tìm đến.

Tương tự đối với các đoạn code copy-paste. Đúng là chúng ta đều thỉnh thoảng sử dụng Stack Overflow. Không có gì xấu hổ về điều đó! Nhưng nếu bạn không hiểu code đó, đừng sử dụng nó hoặc hãy nhờ người khác giúp đỡ.

Lập trình voodoo chính là như vậy. Khi bạn tạo hoặc sử dụng những đoạn code mà bạn không thực sự hiểu vấn đề tiềm ẩn. Nói cách khác, khi lập trình voodoo, hãy chuẩn bị tinh thần vì một con bug đang chờ sẵn để “ú òa” bạn.

3. Code không bao giờ dối bạn, các nhận xét thì đôi khi có

Nhận xét (comment) có một chức năng quan trọng, nhưng nếu có thể, đừng sử dụng nhận xét và thay vào đó hãy viết thêm descriptive code (mã mô tả).

"Ủa, tại sao?"

Nhận xét thường bị bỏ qua khi bạn thay đổi code của mình. Do đó: Các nhận xét đôi khi cũng… xạo (không chính xác) vì code xung quanh chúng đã thay đổi và nhận xét đó thì không được cập nhật.

Có ba cách để ghi lại code:

1. Sử dụng nhận xét bên trong code của bạn.
2. Ghi lại documentation trong một file tài liệu riêng biệt.
3. Viết self-documenting code (mã tự ghi).

Phân tích rõ hơn về điểm cuối cùng, vì đó là lý do chính bạn nên viết descriptive code nhiều hơn:

• Sử dụng một thiết kế tốt giúp codebase của bạn dễ điều hướng và được cấu trúc hợp lý.
• Đừng cố lưu các ký tự. Sử dụng tên đầy đủ cho các biến, lớp và hàm của bạn. Vì vậy, thay vì wm, hãy đặt tên là windowManager. Thay vì rf, hãy gọi nó là readFileToString. Tên này giúp ích rất nhiều khi bạn hoặc những người khác cố gắng hiểu chuyện gì đang xảy ra sau vài tháng không nhìn vào code.
• Trích xuất càng nhiều càng tốt vào các hàm và cho chúng làm cùng một việc. Bên cạnh đó, đặt tên chúng cho phù hợp. Ví dụ: tạo một hàm đọc một tệp thành một chuỗi và đặt tên cho nó là readFileToString(String fileName). Không cần đọc code một cách chi tiết để biết nó làm gì. Lý tưởng nhất, code của bạn là một chuỗi các lệnh gọi hàm như thế này sẽ đọc gần giống như ngôn ngữ của con người. Chỉ khi cần, người đọc mới phải tìm hiểu sâu hơn. Code này tự tài liệu hóa!

4. Regular Expressions (Biểu thức chính quy)

Khi đối mặt với một vấn đề, một số người nghĩ, "Biết rồi, tôi sẽ dùng regular expression!" Và thế là họ có hai vấn đề.

Một trò đùa cũ thôi, nhưng là thật đấy, regular expression là một niềm đau. Khi bạn nghĩ rằng cuối cùng bạn đã làm đúng cho một trường hợp thì nó chỉ khớp với 70% trường hợp tiếp theo mà bạn áp dụng vào thôi.

[pic 1]

Bạn nên tránh các regex như tránh bệnh dịch trừ khi bạn thực sự không thể làm được nếu không có chúng. Thông thường, sự kết hợp của các hàm như split, substring, endsWith, indexOf, v.v. sẽ thực hiện thủ thuật và đem lại code dễ đọc hơn.

5. Phần mềm giống như nhà thờ vậy: Đầu tiên, chúng ta xây chúng - Sau đó, chúng ta cầu nguyện

The Cathedral and the Bazaar là cuốn sách đối lập giữa hai mô hình phát triển khác nhau. Theo Wikipedia: 

“Mô hình Cathedral, trong đó mã nguồn có sẵn với mỗi bản phát hành phần mềm (software release), nhưng mã được phát triển giữa các bản phát hành bị hạn chế đối với một nhóm nhà phát triển phần mềm độc quyền.
Mô hình Bazaar, trong đó mã được phát triển qua internet để công chúng có thể nhìn thấy rõ ràng. Linus Torvalds, lãnh đạo của dự án Linux kernel, được xem là người phát minh ra quy trình này ”.

Cả hai mô hình đều có ưu và nhược điểm của chúng. Tuy nhiên, người ta thường chấp nhận rằng phần mềm là thứ cần một quá trình phát triển lặp đi lặp lại trong đó chức năng được bổ sung dần dần. Thế nên tốt hơn là người dùng cuối (end user) được tham gia vào quá trình phát triển từ rất sớm.

6. Rẻ, nhanh, đáng tin cậy: Chọn 02 thứ thôi

Điều này sẽ khiến một số người (ví dụ như quản lý của bạn) phải suy nghĩ:

• Muốn phần mềm đáng tin cậy và nhanh chóng? Được thôi, nhưng bạn sẽ cần phải trả tiền cho những nhà phát triển tốt nhất.
• Giá rẻ và nhanh chóng? Chắc chắn rồi, nhưng đừng mong đợi nó đáng tin cậy!
• Đáng tin cậy và giá rẻ? Có lẽ ổn nếu bạn may mắn. Nhưng sẽ mất nhiều thời gian hơn để tìm một người có thể “làm phát ăn luôn” với mức giá đó, hoặc sẽ đòi hỏi nhiều lần lặp lại (do đó sẽ mất nhiều thời gian hơn) để làm đúng.

7. Có 02 điều khó khăn trong kỹ thuật phần mềm

1. Đặt tên cho sự vật (thường là biến)
2. Vô hiệu hóa bộ nhớ cache
3. Lỗi off-by-one 

Con người chúng ta thường bắt đầu đếm từ một. Máy tính bắt đầu từ 0. Sự thật đơn giản này đã là ngọn nguồn cho vô số lỗi và khó khăn. Rất có thể bạn đã từng mắc phải các lỗi off-by-one. Nếu chưa, thì một ngày nào đó bạn cũng sẽ gặp thôi.

8. Một lập trình viên giỏi nhìn cả hai phía trước khi băng qua đường một chiều

Phần mềm tốt nhất có thể xử lý tất cả các lỗi, tất cả luôn ấy. Ngay cả những lỗi tưởng như “sẽ không bao giờ xảy ra."

Hầu hết phần mềm được viết để thực hiện "quy trình hạnh phúc", trong đó mọi thứ hoạt động như mong đợi và người dùng không làm những điều kỳ lạ. Thế giới thực rất lộn xộn, và theo thời gian, những thứ có thể sai sẽ trở nên sai. Cố gắng phát hiện càng nhiều lỗi càng tốt - đặc biệt là khi phần mềm của bạn đang thực hiện đầy đủ các chức năng quan trọng.

9. Đo lường tiến độ lập trình bằng các dòng code giống như đo tiến độ chế tạo máy bay theo trọng lượng

Càng nhiều dòng code không có nghĩa là mọi thứ đang tiến triển. Vì lý do tương tự, viết nhiều code hơn những người khác không có nghĩa là bạn làm việc hiệu quả hơn.

Code tốt nhất là sử dụng ít dòng nhất để hoàn thành công việc và cũng là code khó viết nhất. Đây là một nguyên tắc phần mềm nổi tiếng được gọi là KISS - viết tắt của Keep It Simple, Stupid.

Phương pháp này cũng đã được đề cập trong bài viết 40 mẹo giúp thay đổi kỹ năng code của bạn mãi mãi.

Tổng hợp việc làm IT - Software trên VietnamWorks
VietnamWorks InTECH
Xem bài viết gốc trên Medium