70 điều các developer giỏi thuộc nằm lòng – Phần 1

bài trước, trong số sách đã giới thiệu, mình giới thiệu 1 cuốn sách gọi The Pragmatic Programmer. Như mình đã quảng cáo, cuốn sách này tập hợp rất nhiều kinh nghiệm được các tiền bối đúc kết lại qua bao nhiêu năm phát triển phần mềm. Vì sách khá dài, để tiện cho mọi người đọc, bác Jeff, chủ blog codinghorror đã rút gọn cuốn sách thành 70 điều dưới đây. 90% những điều này sẽ giúp ích cho sự nghiệp lập trình của bạn, do đó mình mạn phép dịch ra để chia sẻ lại. Bạn nào muốn có thể xem link gốc của cuối blog.

Danh sách 70 bài học đúc kết được từ The Pragmatic Programmer:

  1. Code có lương tâm: Nếu đã quyết định lựa chọn sự nghiệp developer, hãy có bằng hết sức, đừng code dối hoặc làm xong cho qua việc.
  2. Code có suy nghĩ: Hãy sử dụng đầu óc khi code. Biết tự đánh giá code của mình, khen khi code hay, chê khi code xấu.
  3. Đưa ra lựa chọn, đừng kiếm cớ: Đừng kiếm cớ theo kiểu: “cái này không làm được”, hãy đưa ra lựa chọn kiểu : “Có thể ko làm được A, thay vào đó ta có thể làm B,C”.
  4. Đừng bỏ qua những lỗi vụn vặt: Khi gặp các design tệ, code bựa,… hãy sửa ngay. Để lâu ngày, những lỗi nhỏ trong code sẽ tăng lên theo cấp số nhân.
  5. Sẵn sàng thay đổi: Nếu không thể bắt mọi người thay đổi, hãy chỉ cho họ thấy nhũng điều cần làm trong tương lại, cũng như nhờ họ góp sức thực hiện.
  6. Giữ cái nhìn toàn cục: Đừng quá để tâm tới chi tiết, hãy giữ cái nhìn tổng thể.
  7. Chất lượng cũng là requirement: Hãy để chính người dùng góp sức vào việc đánh giá chất lượng của phần mềm.
  8. Không ngừng học hỏi: Hãy biến việc học (ngôn ngữ mới, kiến trúc mới …) thành thói quen.
  9. Đừng tin những gì mình nghe và đọc: Đừng chạy theo số đông, chạy theo công nghệ. Hãy lựa chọn, phân tích dựa trên kiến thức bản thân + cấu trúc dự án.
  10. Điều bạn nói và cách bạn nói đều quan trọng như nhau: Không cần biết bạn điều bạn nói hay tới mức nào, nếu bạn không biết cách diễn đạt nó ra, tất cả chỉ là vô nghĩa.
  11. Đừng lập lại: Với code cũng như document, hãy tập trung chúng lại 1 và chỉ 1 chỗ.
  12. Tái sử dụng: Tìm mọi cách để thứ bạn làm ra dễ dàng tái sử dụng (tạo library, v…v), mọi người sẽ tái sử dụng nó.
  13. Component nên tách biệt: Mỗi component nên được thiết kế chỉ nhằm 1 mục đích duy nhất, không nên phụ thuộc vào component khác.
  14. Mọi thứ luôn thay đổi: Mọi thứ đều có thể thay đổi: Requirement, design, công nghệ sử dụng …. hãy luôn sẵn sàng cho những thay đổi đó.
  15. Thử và sai: Đôi khi requirement, kiến trúc chưa rõ ràng, đừng ngại thử và sai. Nếu bạn có sai, ít ra nó cũng sẽ đưa bạn đến gần cái đúng.
  16. Dựng prototype để tìm hiểu: Như trường hợp trên, đôi khi ta dựng 1 prototype để tìm hiểu công nghệ, hoặc tìm hiểu requirement. Thứ ta thu được là kiến thức ta đã tìm hiểu, chứ không phải là prototype đó.
  17. Lập trình theo từ ngữ chuyên ngành: Khi lập trình một hệ thống, hãy làm cho code và design của bạn giống từ ngữ thuộc lĩnh vực của hệ thống đó. VD như khi code hệ thống cho 1 trường học, ta dùng các class teacher, student, cho rạp chiếu phim thì dùng class cinema, ticket.
  18. Tập ước lượng: Hãy thử ước lượng đánh giá thời gian, công sức bỏ ra khi code. Quá trình ước lượng này sẽ giúp bạn phát hiện 1 số vấn đề có khả năng phát sinh.
  19. Ước lượng dựa theo code: Sau 1 thời gian code, bạn sẽ có thể ước lượng thời gian code chính xác hơn, dựa theo các số liệu trong quá khứ.
  20. Lưu trữ lại kinh nghiệm và kiến thức: Trong quá trình code, team và bạn sẽ học được 1 số kinh nghiệm, 1 số trò “chích choát” để code chạy. Hãy lưu những kinh nghiệm này dưới dạng văn bản, trong tương lai nó sẽ có ích khi tìm lỗi, hoặc hướng dẫn thành viên mới.
  21. Hãy học cách dùng command shell: Hầu như mọi chương trình: Window, Visual Studio, Git, v…v đều có cửa sổ command. Các cửa sổ này khá mạnh mẽ, có thể thực hiện những chức năng mà UI ko làm được thông qua các câu lệnh.
  22. Sử dụng Text Editor thành thạo: Bạn có thể code bằng nhiều editor: Notapad++, VIM, VS,… không cần biết nó là editor nào, hãy học cách dùng nó thành thạo (Sử dụng hotkey, v…v).
  23. Luôn luôn sử dụng Source Code Control (Git, SVN): Hiện tại 90% bạn nào cũng biết cái này rồi, ko cần nhắc lại.
  24. Gặp bug thì fix: Không cần biết bug là lỗi của bạn hay của ai khác, nếu nó cần được fix thì hãy fix trước đã, truy cứu trách nhiệm tính sau.
  25. Dùng não khi debug: Khi debug, nhất là những lúc bị deadline dí, ta thường hay rối. Hãy HÍT SÂU, THỞ NHẸ, suy đoán nguyên nhân gây bug, sau đó bắt đầu tìm.
  26. Nguyên nhân gây lỗi: Khả năng rất thấp là lỗi nằm ở hệ điều hành hoặc compiler, cũng như cái library (Điều này hiện tại ko đúng lắm, vì open-source mọc lên như nấm, không test hết được). Do đó, khi fix lỗi, hãy tập trung vào code do team mình tự code trước.
  27. Đừng dự đoán, hãy chứng minh: Bạn đoán rằng transaction sẽ chạy mất 3 giây, database phục vụ 1000 users … Đừng dự đoán suông, hãy dùng code, chạy test, đo đạc, tính thời gian để chứng minh điều bạn đoán.
  28. Học một ngôn ngữ xử lý text: Hằng ngày bạn làm việc với text, sau không viết code để máy tính xử lý chúng giùm bạn.
  29. Viết code để tạo code: Tương tự ý trên, nếu thấy code mình viết lặp đi lặp lại, sau ko tạo 1 chương trình tự sinh code (Hiện tại các IDE như Visual Studio, Eclipse đều hỗ trợ việc tự sinh code này).
  30. Không có phần mềm hoàn hảo: Không có phần mềm nào hoàn hảo. Tuy vậy, hãy giảm thiểu những lỗi mà code hoặc người dùng có thể gặp phải
  31. Design và làm theo design: Hãy chắc chắn rằng code của bạn chỉ làm những điều mà nó phải làm, ko hơn không kém. (VD code gửi mail active thì đừng block account, code mua hàng thì đừng block thẻ của người dùng).
  32. Chương trình nên crash: Một chương trình crash sẽ gây thiệt hại, tuy nhiên thiệt hại không nhiều bằng một chương trình chạy sai, chạy nhầm.
  33. Sử dụng Assert: Dùng Assert để tránh những lỗi có thể xảy ra trong code (Assert là một kiểu giống như throw Exception, ngày xưa thường hay dùng. Gần đây thì mình chỉ thấy Assert trong unit test).
  34. Sử dụng Exception: Chỉ dùng Exception đúng lúc, đúng chỗ, dùng lung tung sẽ khiến code thành spaghetti code.
  35. Hãy code “có đầu có cuối”: Nhớ giải phóng resource sau khi bạn đã dùng xong (Mở connection thì phải đóng, lấy bộ nhớ thì phải clear). Hiện tại 1 số ngôn ngữ bậc cao đã tự làm việc này, tuy nhiên lâu lâu nhớ + cẩn thận vẫn hơn.

35 điều tiếp sau sẽ được đăng trong phần 2 nhé, mong các bạn đón xem.

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s