A- A A+ | Chia sẻ bài viết lên facebook Chia sẻ bài viết lên twitter Chia sẻ bài viết lên google+

22 năm làm lập trình và đây là những điều tôi học được

Thiết kế website/xây dựng cổng thông tin điện tử nói riêng hay lập trình nói chung, tất cả đều là những việc làm cần phải rút kinh nghiệm vì chúng là tập hợp những thao tác không bao giờ trùng lặp. Bỏ túi một số tip dưới đây để công việc lập trình của bạn "đỡ chông gai" nhất có thể! 

"Thoughts on programming..." - suy nghĩ qua việc lập trình. Blogger công nghệ Henrik Warne đã có những chia sẻ rất thực tế và đầy kinh nghiệm về công việc lập trình mà ông đã rút ra trong suốt thời gian 22 năm làm nghề.

I. Nguyên tắc phát triển sản phẩm

1. Đi từng bước nhỏ rồi phát triển dần lên

xây dựng cổng thông tin điện tử

 

Dù là xây dựng hệ thống mới, hay là gắn tính năng mới vào hệ thống sẵn có, thì tôi luôn bắt đầu bằng việc tạo ra một phiên bản đơn giản - phiên bản mà không có hầu hết các chức năng cần thiết.

Sau đó tôi mở rộng giải pháp từng bước một cho đến khi nó đạt được những gì mà tôi mong muốn. Tôi không bao giờ dự tính mọi thứ chi tiết ngay từ lúc bắt đầu, thay vào đó, tôi vừa làm và rút kinh nghiệm qua từng giải pháp.

Có một câu nói của John Gall mà tôi rất thích, đó là: "Một hệ thống phức tạp bao giờ cũng được tạo ra từ chính những tiểu tiết đơn giản nhất".

2. Mỗi lần chỉ thay đổi một thứ

Khi lập trình, sẽ có trường hợp test lỗi hay các tính năng không hoạt động, những lúc này việc bạn thay đổi chỉ một thứ sẽ làm cho việc phát hiện vấn đề đơn giản hơn nhiều. Nói cách khác, hãy sử dụng những vòng lặp (iterations) ngắn. Tác động lên 1 thứ thôi, đảm bảo nó hoạt động rồi hãy làm sang cái khác.

Nguyên tắc này cũng áp dụng được cho commit code. Nếu bạn phải refactor code trước khi gắn tính năng mới vào sản phẩm, thì hãy commit phần code đã được refactor trước, sau đó (trong commit mới) hãy thêm tính năng mới vào sau.

3. Thêm phần logging và xử lý lỗi ngay khi có thể

Khi lập trình hệ thống mới, một trong những việc đầu tiên tôi làm đó là thêm logging và xử lý lỗi bởi vì đây là việc làm vô cùng hữu ích ngay từ lúc bắt đầu. Đối với tất cả các hệ thống lớn hơn một vài dòng code, lập trình viên cần biết rằng điều gì đang xảy ra đối với chương trình của mình.

Trừ khi nó không làm việc như bạn mong đợi, bạn phải tận mắt thấy những gì đang diễn ra. Điều này cũng xảy ra tương tự với xử lý lỗi, việc xử lý một cách hệ thống những lỗi và trường hợp ngoại lệ ngay từ lúc bắt đầu là giải pháp nên làm càng sớm càng tốt.

4. Mọi dòng code mới đều phải chạy thử ít nhất 1 lần

Trước khi hoàn thành xong một tính năng, hãy đảm bảo rằng bạn đã test nó kỹ lưỡng vì bạn đâu thể chắc chắn rằng nó sẽ hoạt động đúng theo ý nuốn nếu không kiểm tra? Thường thì automatic test sẽ là cách tốt nhất (tất nhiên sẽ có ngoại lệ). Nhưng dù sử dụng cách nào đi chăng nữa thì hãy test những dòng code mới của bạn ít nhất 1 lần.

5. Test từng phần trước khi test toàn bộ

xây dựng cổng thông tin điện tử

Test từng phần 1 cách kỹ lưỡng sẽ giúp chúng ta tiết kiệm được rất nhiều thời gian. Thông thường, vấn đề luôn xảy ra khi kết hợp các phần khác nhau, ví dụ như lỗi không tương xứng hay hiểu nhau của interface giữa các module.

Nếu lập trình viên xử lý từng phần tốt thì khi tích hợp hệ thống sẽ dễ phát hiện lỗi hơn.

6. Mọi thứ cần nhiều thời gian hơn bạn nghĩ

Vỗn dĩ việc ước lượng mất bao lâu để 1 tính năng có thể chạy mượt mà đã rất khó rồi, đặc biệt lại là trong lĩnh vực lập trình, những vấn đề phát sinh ngoài dự kiến luôn xảy ra “như cơm bữa”. 

Ví dụ như:

  • Một thao tác merge đơn giản có thể gây ra những bug tiềm ẩn.
  • Nâng cấp 1 framework cũng có nghĩa phải thay đổi một vài chức năng.
  • hay API không hoạt động như hứa hẹn.

Tôi nghĩ rằng định luật của Hofstadter hàm chứa kha khá sự thật: “Mọi thứ luôn cần nhiều thời gian hơn bạn tưởng, kể cả khi bạn áp dụng định luật của Hofstadter.”

7. Việc đầu tiên là hiểu những đoạn code đã có

Thay đổi những đoạn code hiện có bằng nhiều cách là một trong những yêu cầu cơ bản của nghề lập trình. Kể cả khi sáng tạo ra một tính năng mới, nó cũng cần phù hợp với hệ thống đã tồn tại. 

Trước khi khớp tất cả những cái mới, lập trình viên cần hiểu rõ những giải pháp hiện thời. Nếu không, bạn có thể “vô tình” phá hỏng một số tính năng đã tồn tại. Điều này cũng có nghĩa rằng kỹ năng “đọc code” là điều vô cùng cần thiết giống như “viết code” vậy. Đây cũng là một phần lý do tại sao việc rà soát những sự thay đổi nhỏ lại mất rất nhiều thời gian - bạn phải hiểu được ngữ cảnh mà mình thay đổi.

8. Đọc và chạy code

May mắn là chúng ta luôn có 2 phương pháp bù trừ lẫn nhau để hiểu những đoạn code viết ra. Hãy đọc code và sau đó chạy thử chúng.

Chạy thử code là một cách hữu hiệu để kiểm tra xem chúng viết ra để làm gì.

Hãy đảm bảo rằng bạn luôn sử dụng cả 2 phương pháp trong khi sáng tạo những đoạn code của mình.

II. Xử lý sự cố

xây dựng cổng thông tin điện tử

9. Sẽ luôn có bug

Tôi không thích những cách tiếp cận với công việc phát triển phần mềm mà cho rằng có thể làm đúng mọi thứ ngay từ lần đầu tiên. Dù bạn có cố gắng bao nhiêu chăng nữa, sẽ vẫn luôn có bugs (định nghĩa về bug đơn giản là: “Chúng tôi đã không nghĩ tới điều đó”). Một cách tiếp cận hay hơn nhiều đó là một hệ thống cho phép bạn xử lý các vấn đề, sửa lỗi và triển khai một cách nhanh chóng.

10. Giải quyết các báo cáo sự cố

Mọi nhà phát triển nên dành một phần thời gian để xử lý các báo cáo sự cố từ khách hàng và sửa lỗi. Nó sẽ khiến bạn hiểu rõ hơn rất nhiều về cái mà khách hàng đang muốn đạt được, cách mà hệ thống được sử dụng, dễ hoặc khó đến mức nào để xử lý lỗi và hệ thống được thiết kế tốt đến mức nào. Đây cũng là một cách để thể thiện sự trách nhiệm đối với những gì bạn phát triển.

11. Mô phỏng lại vấn đề

Bước đầu tiên khi sửa một lỗi đó là mô phỏng lại vấn đề đang nảy sinh. Sau đó bạn cần đảm bảo rằng khi phương án sửa chữa được thêm vào, vấn đề sẽ được giải quyết. 

Quy tắc đơn giản này đảm bảo bạn không tự nghĩ rằng một thứ gì đó là vấn đề nhưng thực tế nó lại không phải, và đảm bảo cho phải pháp của bạn thực sự giải quyết cái mà bạn nghĩ rằng nó sẽ giải quyết.

12. Sửa những lỗi đã biết, sau đó tìm xem còn không

xây dựng cổng thông tin điện tử

Thỉnh thoảng sẽ xảy ra một vài vấn đề mà bạn biết tới. Các lỗi khác nhau có thể tương tác với nhau gây nên những thứ không mong muốn. Thay vì cố gắng sửa trong trường hợp đó, hãy sửa những lỗi đã biết trước và xem những triệu chứng còn lại là như thế nào.

13. Giả thiết rằng không có sự trùng hợp ngẫu nhiên

Khi kiểm tra hoặc xử lý sự cố, không bao giờ nên tin vào sự trùng hợp ngẫu nhiên. 

Bạn thay đổi giá trị của một biến đếm, hệ thống khởi động lại thường xuyên hơn. Không phải là một sự trùng hợp ngẫu nhiên. 

Một tính năng mới được thêm vào, đột nhiên một tính năng không liên quan khác trở nên chậm hơn. Không phải một sự trùng hợp ngẫu nhiên. Thay vào đó, hãy điều tra vấn đề.

14. Hãy làm việc kết hợp với các mốc thời gian

Khi xử lý sự cố, hãy sử dụng mốc thời gian của các sự kiện. Hãy tìm kiếm sự tăng lên của các sự kiện. 

Ví dụ, nếu hệ thống tự khởi động lại, và một yêu cầu đã được gửi cách đó 3000 mili giây, có khả năng là một biến đếm đã kích hoạt quá trình khởi động lại.

III. Sự hợp tác

15. Nói chuyện trực tiếp sẽ hiểu nhau nhanh nhất

xây dựng cổng thông tin điện tử

Khi thảo luận để tìm cách giải quyết một vấn đề, gặp trực tiếp vẫn là tốt nhất. Tôi thường bị bất ngờ vì giải pháp đã được cải thiện rất nhiều khi thảo luận trực tiếp với đồng nghiệp thay vì video call hoặc chat.

16. Sử dụng phương pháp sửa lỗi Con vịt cao su (rubber ducking)

Khi bạn bí, hãy tìm tới một đồng nghiệp và giải thích vấn đề với họ. Nhiều khi càng nói với đồng nghiệp, bạn lại càng nhận rõ ra vấn đề đang vướng mắc, ngay cả khi mà đồng nghiệp của bạn chẳng nói lời nào đi nữa. Nghe có vẻ như ma thuật vậy, nhưng phương pháp này hiệu quả đến mức đáng ngạc nhiên.

17. Hỏi

Đọc và chạy code thường rất tốt cho việc tìm hiểu nó làm được những gì và làm bằng cách nào. Nhưng nếu bạn có cơ hội được hỏi ai đó có sự am hiểu tường tận (có thể là tác giả người đã viết code), hãy sử dụng ngay lựa chọn đó. Việc có thể đặt những câu hỏi chi tiết với những người hiểu sâu về tác phẩm của họ sẽ tiết kiệm thời gian cho bạn rất nhiều so với việc chỉ đọc code.

18. Hãy chia sẻ danh tiếng

Hãy đảm bảo rằng bạn dành sự tán dương xứng đáng với những cộng sự đã giúp mình. 

Hãy nói: “Marcus đã nghĩ ra giải pháp này…”, thay vì chỉ nói “Chúng tôi đã cố gắng…”. 

Cố gắng đề cập nhiều hơn tới những người đã giúp và đóng góp cho bạn.

IV. Những thứ khác nhau

19. Hãy thử nó

xây dựng cổng thông tin điện tử

Nếu bạn không chắc chắn về cách một ngôn ngữ hoạt động, hãy viết một chương trình nhỏ để hiểu cách nó hoạt động ra sao. Điều này cũng tương tự khi kiểm tra hệ thống bạn đang phát triển. 

Điều gì sẽ xảy ra nếu tôi đặt tham số này bằng 1? 

Điều gì sẽ xảy ra nếu service này không hoạt động khi tôi khởi động lại hệ thống? 

Hãy khám phá cách nó hoạt động – nghịch linh tinh một chút thường sẽ tìm ra nhiều lỗi và đồng thời sẽ khiến bạn hiểu sâu hơn về hệ thống.

20. Hãy ngủ cùng nó

Nếu bạn đang đối đầu với một vấn đề khó, hãy cố gắng nghĩ về nó, mơ về nó ngay cả khi ngủ. Và tiềm thức của bạn sẽ tiếp tục làm việc với vấn đề đó ngay cả khi bạn không chủ động nghĩ về nó. Kết quả là vấn đề sẽ trở nên dễ dàng hơn nhiều vào ngày hôm sau.

21. Thay đổi

xây dựng cổng thông tin điện tử

Đừng ngại việc chuyển vai trò hoặc công việc của bạn. Việc làm việc với những con người khác, sản phẩm khác hoặc ở công ty khác sẽ khuấy động khả năng trong bạn. Theo quan điểm của tôi, quá nhiều người ở lại công việc của họ một cách bị động ngày qua ngày và chỉ thay đổi khi họ bị ép buộc.

22. Hãy tiếp tục học hỏi

Một trong những điều thú vị ở công việc phát triển phần mềm đó là luôn có những kiến thức mới để học hỏi. Hãy thử những ngôn ngữ lập trình và công cụ khác nhau, đọc sách về phát triển phần mềm, tham gia các khóa học MOOC. Những cải tiến nhỏ sẽ dần tích lũy lại để tạo nên một sự khác biệt ở kiến thức và khả năng của bạn.

Người dịch: Phan Trung Đức 

 

Nếu Quý khách hàng có nhu cầu xây dựng cổng thông tin xin vui lòng liên hệ theo thông tin dưới đây, để Văn Hóa Việt có thể tư vấn cho Quý khách rõ hơn về hiệu quả của cổng thông tin điện tử, qua đó Quý khách hàng có thể chọn được các giải pháp phù hợp cho mình.

Trân trọng!

Mr. Hưng: ☏ Hotline: 0911.05.44.88  - ✉ Email: hunghq@vhv.vn

Ms. Hiền: ☏ Hotline: 0125.72.33.055  - ✉ Email: hienlt@vhv.vn

Hoặc liên hệ:

CÔNG TY CỔ PHẦN TRUYỀN THÔNG VĂN HÓA VIỆT

Website: webportal.vn

✉ Email: Contact@vhv.vn

☏: 024 22 11 1997 - 024 22 11 1996

Địa chỉ: P. 604, Tầng 6, 15-17 Ngọc Khánh, Ba Đình, Hà Nội


Nguồn: https://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/
Tổng số điểm của bài viết là: 0 trong 0 đánh giá
Click để đánh giá bài viết
Công ty cổ phần truyền thông Văn hóa việt

Bản quyền © 2017 Webportal. Giữ toàn quyền.

Webportal.vn là một sản phẩm của Công ty Cổ phần Truyền thông Văn Hóa Việt, nhà cung cấp hàng đầu về lĩnh vực giải pháp phần mềm.

Địa chỉ: 604ĐN2, 15-17 Ngọc Khánh, Ba Đình, Hà Nội - Điện thoại: 04 2211 1997

Tạo web dùng thử

Copyright © 2017 Webportal.vn. All rights reserved.