Nối tiếp phần 1, bài viết này bao gồm 35 bài học tiếp theo trong số 70 bài học rút ra từ cuốn The Pragmatic Programmer mà mình đã nhắc tới ở bài trước.

35 bài học còn lại:

1. Giảm thiểu quan hệ giữa các module: Tránh sự chồng chéo, dính chùm bằng cách hạn chế việc các module gọi nhau quá nhiều (Nên đưa ra interface v…v).
2. Config chứ đừng tích hợp: Hiện thực theo cách mà ta có thể tích hợp các lựa chọn về công nghệ 1 cách dễ dàng (Bằng cách config), chứ ko phải dùng code hay tích hợp bằng tay.
3. Tập trung vào abtraction: Code cần tập trung giải quyết theo hướng tổng quát, trừu tượng (Mình thấy cái lời khuyên này hơi vô lý, khá khó thực hiện).
4. Nghiên cứu kĩ luồng chạy, tăng tính phân luồng của code.
5. Thiết kế theo service: Mỗi component nên nằm trong 1 service riêng, giao tiếp với nhau thông qua interface (Đây là ý tưởng mở đầu cho khái niệm Dependency Inversion trong SOLID).
6. Thiết kế cho việc phân luồng: Thiết kế để hệ thống có thể chạy được phân luồng nếu yêu cầu.
7. Tách biệt giữa view và model: Tách biệt view và model ra sẽ làm tăng tính linh hoạt của thiết kế lên rất nhiều.
8. Dùng design pattern blackboards để quản lý các luồng chạy.
9. Đừng code kiểu “hên xui”: Đừng code theo kiểu “hên xui”, không biết vì sao code chạy, hoặc dùng các trò “chích choát”. (Nói vậy thôi, các bạn xem source code của Windows vẫn 1 đống trò hack hoặc chích choát đấy thôi).
10. Đánh giá thuật toán: Trước khi code, hãy thử đánh giá thuật toán/code bạn sử dụng sẽ chạy mất bao lâu.
11. Thử nghiệm lại đánh giá: Để xác thực đánh giá của mình, đừng tin vào thuật toán hay báo cáo, hãy chạy code trong môi trường thực tế và đo đạc lại.
12. Refactor sớm và thường xuyên: Code cũng giống như làm vườn, phải thường xuyên tỉa tót, thay đổi thiết kế thì mới tốt được. (Mình thì không đồng tình với lời khuyên này lắm, đôi khi trễ deadline, code chết mợ, thời gian đâu mà refactor).
13. Thiết kế để test: Trước khi code, hãy nghĩ mình sẽ test thế nào.
14. Test phần mềm cho kĩ, nếu không người dùng sẽ làm điều đó: Test kĩ càng và quyết liệt, đừng để người dùng nhặt bug cho bạn.
15. Cẩn thận với tool sinh code: Hãy hiểu đống code mà tool sinh ra trước khi sử dụng chúng (Một số bạn bây giờ khoái dùng code tự sinh mà ko hiểu, đến lúc có lỗi hoặc cần sửa chữa lại chả biết làm thế nào).
16. Đừng tổng hợp requirement, hãy đào sâu mà tìm: Requirement không có sẵn để bạn đi vòng vòng mà “tổng hợp”. Phải chịu khó đào sâu, làm phiền, quấy rối, tra tấn, móc họng khách hàng để họ “ói” requirement ra cho bạn.
17. Làm việc với người dùng, đặt mình vào vị trí người dùng, suy nghĩ như người dùng.
18. Tập trung vào abstraction: Những thứ trừu tượng như interface v…v sẽ sống lâu hơn implementation. Kể cả khi ta có thay đổi công nghệ hoặc thay đổi cách hiện thực, abstraction vẫn giữ nguyên.
19. Hãy có 1 cuốn sổ tổng hợp: Tập trung những từ ngữ chuyên biệt, ý nghĩa của chúng vào sổ. Sau này mỗi khi team cần tra v…v thì rất dễ dàng.
20. Tìm cách giải quyết vấn đề “bất khả thi”: Khi gặp vấn đề “bất khả thi”, hãy xác định các giới hạn, sau đó tự hỏi “Có bắt buộc phải làm cách này ko? Có thật sự phải giải quyết vấn đề này không?”
21. Bắt đầu ngay sau khi bạn đã sẵn sàng.
22. Có nhiều thứ làm thì dễ hơn giải thích: Đừng quá sa đà vào giải thích, mô tả, viết document, hãy code ngay khi có đủ dữ liệu bạn cần.
23. Đừng quá gò bó vào phương pháp: Đừng ép mình sử dụng các phương pháp lập trình một cách cứng nhắc, hãy áp dụng linh hoạt dựa theo khả năng của team và bản thân.
24. Tool mắc tiền chưa chắc đã tốt.
25. Hãy chia team như chia code: Đừng tách team ra thành các bộ phận như designer, tester, developer. (Đây là một trong những ý tưởng mở đầu cho kỉ nguyên Agile).
26. Hạn chế làm tay: Những process như copy file, chạy bản build, lặp đi lặp lại, chúng ta không nên làm bằng tay. Hãy lập trình để script làm điều đó.
27. Test, test nữa, test mãi: Chạy test mọi nơi mọi lúc, với mọi bản build (Test nên là test tự động).
28. Code chưa tính là xong cho tới khi toàn bộ test đã pass.
29. Vọc bug để kiểm tra test: Hãy copy source code của bạn ra một vài bản khác, sau đó cố tình tạo bug để xem test của bạn có bắt được những bug đó ko.
30. Test trạng thái của chương trình, không chỉ test code: Đừng chỉ kiểm xem test có cover hết các dòng code hãy ko, hãy để ý xem test có cover được các trạng thái của chương trình hay ko
31. Tìm bug 1 lần: Tester chỉ test và tìm bugs 1 lần đầu tiên và duy nhất. Từ những lần sau, hãy để automation test chạy và verify bug đó.
32. Tiếng Anh cũng chỉ là ngôn ngữ: Hãy viết document như viết code: Dễ hiểu, đừng lặp lại, có thể sinh bằng tool nếu cần.
33. Viết document, tách riêng với code: Đừng để mỗi lần sửa code lại phải sửa document.
34. Hãy vượt qua kì vọng của người dùng: Code để chương trình đáp ứng kì vọng của người dùng, sau đó hơi quá kì vọng 1 chút, người dùng sẽ rất thích điều này.
35. Kí tên trên code: Nếu code làm bạn tự hào, hãy kí tên (Bằng comment). Nếu code như shit, bạn cũng nên kí tên, điều này giúp tăng tinh thần trách nhiệm của bạn với code mình viết ra.

Bài viết đến đây là hết rồi, rất mong nhận được sự góp ý, nhận xét từ các bạn (Ai góp ý comment gì đi, tui buồn là tui bỏ không viết blog nữa đó).

Bản gốc: http://blog.codinghorror.com/a-pragmatic-quick-reference/