Một trong nhiều bình luận phổ biến cho bài viết Lập trình viên Ferengi như sau:
Từ những gì tôi có thể thấy, vấn đề “lập trình viên quá ràng buộc vào các quy tắc” là hầu như không quan trọng bằng vấn đề “nhiều lập trình viên thực sự không có một manh mối gì trong việc phát triển phần mềm cả.” Đa số các lập trình viên không tiếp xúc quá nhiều với các design pattern, SOLID, hoặc agile, hay waterfall… Họ thường dùng giải pháp mì ăn liền như những tay cao bồi trong một môi trường hoàn toàn hoang dã, sử dụng kiểu kéo thả đơn giản, hướng dữ liệu (data driven), các kỹ thuật kiểu lập trình VB.
Phương pháp lập trình tốt nhất hiện nay là gì?
Hoàn toàn đúng vậy.
Nhưng đây là một nghịch lý: kiểu lập trình viên sẽ được lợi nhiều nhất từ các hướng dẫn, quy tắc, nguyên tắc… là những người ít nhất phải có khả năng đọc và làm theo chúng. Ném một cuốn sách chứa các quy tắc vào một lập trình viên cùi bắp sẽ chỉ tạo ra một lập trình viên cùi bắp cùng với một vết bầm tím trên trán của họ, nơi cuốn sách đã va vào. Đây là một vấn đề tôi đã thảo luận trước đây trong bài viết Mort, Elvis, Einstein và Bạn:
Vì vậy, nếu bạn đọc bài viết này, thì hầu như chắc chắn bạn đã ở trong nhóm 20% rồi. Nhóm 80% kia không tích cực nghĩ về nghề phát triển phần mềm. Họ sẽ chẳng bao giờ tìm thấy bài viết này, chứ đừng nói là đọc nó. Họ chỉ đơn giản là không đọc các blog về lập trình – mà họ chỉ ngồi tìm kiếm các kết quả trên Google để tìm ra các câu trả lời nhanh chóng cho một vấn đề cụ thể mà họ đang gặp phải. Và họ cũng chẳng đọc bất kỳ cuốn sách nào trong danh sách những cuốn đề xuất của tôi. Cái đặc trưng để định nghĩa về phần lớn của cái gọi là các “lập trình viên tà tà kiếm cơm” đó là họ là những người không thể với tới được. Cho dù những gì mà bạn, tôi hoặc bất kỳ ai viết ra ở đây – thì họ sẽ chẳng bao giờ nhìn thấy.
Trong sự vắng mặt của việc tư vấn và học nghề, việc phổ biến các practice lập trình tốt thường được đóng gói cho thuận tiện thành các quy trình và phương pháp luận. Có bao nhiêu phương pháp trong danh sách dưới đây mà bạn biết đến? Bạn đã từng áp dụng bao nhiêu phương pháp trong số này?
1969 Structured programming
1975 Jackson Structured Programming
1980 Structured Systems Analysis and Design Methodology
1980 Structured Analysis and Design Technique
1981 Information Engineering
1990 Object-oriented programming
1991 Rapid Application Development
1990 Virtual finite state machine
1995 Dynamic Systems Development Method
1998 Scrum
1999 Extreme Programming
2002 Enterprise Unified Process
2003 Rational Unified Process
2004 Constructionist Design Methodology
2005 Agile Unified Process
Và làm thế nào để chúng ta mong đợi các lập trình viên trình độ trung bình tìm hiểu về những điều này? Chỉ gói gọn trong một từ, tiếp thị. Không phải ngẫu nhiên mà có rất nhiều các phương pháp tư vấn và giảng dạy về chúng. Bởi vì hầu hết các lập trình viên là không thể tiếp cận được:
Tôi đang ngồi trong văn phòng của mình trò chuyện với một đồng nghiệp tên là Jeremy Sheeley. Jeremy đứng đầu nhóm phát triển cho Vault và Fortress. Trong quá trình thảo luận của chúng tôi, tôi chợt nhận ra rằng không có một nỗ lực tiếp thị nào của chúng tôi có thể tới được với Jeremy. Anh ta chẳng bao giờ đi đến hội chợ thương mại công nghệ, hội nghị. Anh không đọc các tạp chí. Anh không đọc các blog lập trình. Anh cũng không tham gia các buổi meetup. Mỉa mai thay, Jeremy lại là người đưa ra quyết định về việc nhóm của anh sẽ sử dụng công cụ kiểm soát phiên bản nào, và không có gì chúng tôi đang làm sẽ khiến cho anh ta biết về sản phẩm của chúng tôi. Có bao nhiêu anh chàng Jeremies như thế này ở ngoài kia nhỉ?
Có đến hàng triệu! Như Seth Godin đã lưu ý, tình trạng không thể tiếp cận này đúng là vô phương cứu chữa – ít nhất là không thông qua tiếp thị.
Vì vậy, nếu chúng ta biết được các lập trình viên sẽ được hưởng lợi nhiều nhất từ những quy định, nguyên tắc và hướng dẫn lại:
- không thích đọc chúng một cách tự nguyện
- hầu như không thể vươn tới họ thông qua phương pháp tiếp thị kiểu truyền thống
Điều này làm tôi suy nghĩ – chúng ta viết ra những nguyên tắc, quy tắc, hướng dẫn và phương pháp luận này chính xác là để dành cho ai? Nếu chúng ta chỉ tiếp cận tới được các lập trình viên có đủ chu đáo để quan tâm đến công việc của họ, thì liệu nhiệm vụ của chúng ta đã thực sự hoàn thành? Tôi đồng ý với Jeff R., người đã để lại lời bình luận như thế này:
Không có gì sai trái với các nguyên tắc SOLID cả; chúng có ý nghĩa đối với tôi. Nhưng tôi đã lập trình từ những ngày người ta còn sử dụng các card reader và teletypes. Chúng sẽ không có ý nghĩa với những người có ít kinh nghiệm. Họ không biết khi nào và làm thế nào để áp dụng những nguyên tắc này một cách thích hợp. Họ sẽ bị sa lầy trong các nỗ lực của mình.
Vì vậy, việc cố gắng tuân theo chúng sẽ làm thay đổi trọng tâm từ kết quả tới quy trình. Và đó là sai lầm chết người.
Đó là công việc của các trưởng nhóm (lead programmer) hoặc người quản lý khi nhìn thấy các nguyên tắc tốt để tuân theo, có lẽ bằng cách hướng dẫn những người khác một cách vô hình, mà không có chỉ thị một cách rõ ràng hoặc thậm chí đề cập đến những nguyên tắc này.
Trong nỗ lực của tôi để kỹ năng lập trình bớt tệ hơn sau mỗi năm, tôi đã đọc hàng trăm cuốn sách lập trình. Tôi đã nghiên cứu tất cả các phương pháp lập trình hiện đại. Tôi thậm chí còn đạt được chứng chỉ Certified Scrum Master. Tất cả những thứ trên, đối với tôi, có vẻ như đều củng cố về 4 nguyên tắc cơ bản cốt lõi trong lập trình. Nhưng “4 nguyên tắc cơ bản cốt lõi” đó là những gì?. Tôi sẽ nói ngay sau đây:
Hệ thống các phương pháp lập trình tốt nhất của Atwood
- DRY
- KISS
- YAGNI
- NAMBLA
Tất cả những quy tắc, hướng dẫn, phương pháp, và nguyên tắc vô cùng chi tiết này có ý nghĩa gì? Bạn sẽ không cần đến nó. Nếu nó không thể được giải thích rõ ràng chỉ trên một tờ giấy đôi, thì đó là một sự lãng phí thời gian của bạn. Hãy đọc và viết một số code! Và nếu bạn không thể nằm lòng những nguyên tắc cơ bản trong 3 hoặc 4 năm đầu tiên trong sự nghiệp lập trình của mình, thì vâng – một chút thay đổi trong trích dẫn này của R. Lee Ermey có thể có ích cho bạn.
Techtalk via vinacode
