Giấc mơ nhỏ bé của một lập trình viên

Một lập trình viên đang đi dọc theo bờ sông Sài Gòn. Vô tình anh ta nhặt được một cái chai, khi mở nắp, một bà tiên xuất hiện. “Ta sẽ ban cho con một điều ước,” bà tiên nói.

-          Con muốn đi du lịch sang Mỹ. Nhưng con rất sợ đi máy bay và không thích đi tàu thủy. Con ước có một chiếc cầu nói liền Việt Nam và Mỹ.

-          Việc ấy khó lắm con à. Ta không có khả năng làm điều đó.

-          Vậy xin bà cho con một điều ước nho nhỏ thôi. Hãy cho con có thể làm ra những phần mềm không có lỗi.

-          Thế con muốn chiếc cầu có mấy làn xe.

                                                                                             (Thời báo Vi Tính Sài Gòn- Số 14-06 (44))

 

Nếu bạn là một lập trình viên, chắc hẳn giờ đây bạn đang gật gù tán thưởng: thật chí lý, chí lý…  Truyện chỉ để giải trí nhưng nó lại đặt ra nhiều câu hỏi:

+ Nếu là một developer:

-          Có phải lỗi là một sự tất yếu đối với việc lập trình?

-          Nguyên do vì sao chúng ta hay mắc lỗi?

-          Làm thế nào để giảm thiểu tối đa lỗi?

 

+ Nếu là một nhà quản lý:

-          Có nên để nhân viên mình mắc lỗi trước khi giúp họ sửa chữa, hay là ngăn chặn trước khi lỗi xảy ra?

-          Ngưỡng lỗi có thể chấp nhận được? (Quota for Errors)

 

Tôi là một developer, nên chắc chỉ cần bận tâm hai câu hỏi đầu.

 

Bạn là một lập trình viên và đã tham gia phát triển nhiều phần mềm:

-          Vậy bạn đã bao giờ dừng lại và “ngắm nhìn” lại thành quả mà bạn đã tạo ra sau không ít thời gian miệt mài gõ bàn phím?

-          Tất nhiên là có rồi…

-          Và chắc hẳn trong tất cả các lần nhìn ngắm ấy, không lần nào bạn không tự nhủ rằng ta sẽ viết tốt hơn nếu có cơ hội được viết lại.

 

Thật vậy, các quy trình phát triển phần mềm hiện nay đều nhận thức rất rõ việc sửa chữa lỗi trong quá trình thiết kế và hiện thực. Một trong những kỹ thuật xây dựng phần mềm hiện nay là phát triển theo các bước lặp (iterative design). Tại sao lại là các bước lặp? Phải chăng vì nó cho ta cơ hội sửa chữa sai lầm gây ra ở các bước trước. Không những thế, các phương pháp luận phát triển phần mềm gần đây như là XP, Test Driven… đều quan tâm đến việc xây dựng các phương pháp nhằm giảm thiểu lỗi. Có thể kể ra một số kỹ thuật sau: refactoring trở thành một trong các yêu cầu cơ bản của việc lập trình; unit test được xem trọng và còn viết trước cả mã lệnh…

[ Nếu các bạn muốn tìm hiểu về Refactoring, xin giới thiệu bạn cuốn sách Refactoring: Improving the Design of Existing Code, còn Test Driven Development thì nên đọc Test Driven Development: By Example. ]

 

Các lý luận trên có thể minh chứng rằng:

Công việc lập trình ngày nay về cơ bản là khó.

Việc luôn tìm ra giải pháp tốt nhất ngay ban đầu là không thể.

Do đó:

 Mắc lỗi trong lập trình là tự nhiên và là sửa lỗi một phần của việc lập trình

 

Nguyên do vì sao chúng ta hay mắc lỗi?

 

Khi đã chấp nhận lỗi là vấn đề không thể tránh khỏi, việc tìm hiểu nguyên nhân là một trong các yếu tố giúp các lập trình viên giảm thiểu việc mắc lỗi. Tất nhiên là có rất nhiều nguyên nhân, đó có thể là thiếu kiến thức, thiếu kinh nghiệm, không hiểu rõ yêu cầu… Ở đây tôi không muốn bàn đến các vấn đề “đại sự” này vì nó chỉ được khắc phục thông qua sự nỗ lực của bản thân cũng như của cả đội ngũ phát triển dự án.

Tôi xin “mạn phép” nói đến một vấn đề rất nhỏ, và chúng ta hoàn toàn có thể khắc phục được, đặc biệt là dành cho các bạn lập trình viên trẻ tuổi. Đó là sự lạc quan của tuổi trẻ.

 

Sự lạc quan của tuổi trẻ:

Những lập trình viên trẻ tuổi thường luôn tự tin theo kiểu thế này “chúng ta có thể hoàn tất chúng cuối tuần này”, mà không hề nhận biết hết mức độ phức tạp của vấn đề. Ngoài ra, họ còn quan niệm người lập trình đích thực không cần … ngủ. 

 

Tôi đã làm chung trong nhiều dự án và phát hiện chúng tôi thường gặp phải những lỗi khi ép mình vào công việc:

-          Tiêu tốn rất nhiều giờ đồng hồ nhưng vẫn không debug ra lỗi, trong khi đó ngày hôm sau lại phát hiện ra lỗi chỉ trong vài phút.

-          Đi hiện thực lại những cái đã có sẵn, thậm chí là những hàm được built-in trong ngôn ngữ.

-          Không tin rằng chính mình đã viết ra những đoạn mã như vậy

-          Vấn đề được giải quyết nhưng thiết kế lại vô cùng rối rắm.

-          …

Nếu bạn cũng gặp các vấn đề như vậy, phương châm dưới đây sẽ giúp bạn giảm thiểu được lỗi mắc phải trong khi lập trình:

 

Đối với công việc lập trình:

“Việc nào để được ngày mai thì hãy để ngày mai”

(trích từ tư tưởng của một kẻ lười )

 

Tôi định giới thiệu thêm một vài nguyên nhân khác, chẳng hạn như là “nỗi ám ảnh của design”, hay “việc phức tạp hóa vấn đề”, v.v…

 

Thế nhưng, đó là việc của ngày mai…