Bài viết này tôi dịch lại từ chia sẻ của một lập trình viên đã có 15 năm kinh nghiệm trong lập trình, anh đã từng code qua rất nhiều ngôn ngữ, nhiều framework. Anh đưa ra những nguyên tắc để code có thể tốt hơn.
Luôn luôn viết code thật đơn giản, điều đó làm cho các lập trình viên khác nhìn vào code của mình sẽ dễ hiểu hơn. Bởi vì thời gian và công sức bỏ ra để đọc và hiểu được code còn tốn gấp nhiều lần so với thời gian bạn ngồi tối ưu code. Nếu bạn cần phải tối ưu code thì hãy làm nó thành module với DI và 100% coverage test
Tôi có nghe nhiều người nói ” Chúng ta cần làm mọi thứ thật nhanh nên chúng ta không có thời gian để làm kiến trúc cho dự án “. Và 99% trong số những dự án đó gặp phải những vấn đề lớn. Nếu viết code mà không suy nghĩ đến kiến trúc của nó vô dụng như kiểu bạn mơ về ham muốn của mình mà không có kế hoạch gì đạt được nó. Trước khi viết dòng code đầu tiên bạn nên hiểu những gì mình sắp làm, làm như thế nào, nó sẽ được sử dụng như thế nào, module , service nào, kiến trúc nó là gì, làm thế nào để test và debug, làm thế nào để update.
Test cần thiết cho các dự án của bạn nhưng không phải lúc nào cũng vậy Khi nào bạn cần phải test:
Đừng viết code phức tạp. Càng đơn giản bao nhiều thì càng ít bug bất nhiêu. Từ đó bạn sẽ càng tốn ít thời gian để debug chúng. Code nên viết những thứ cần thiết, không dư thừa
Comment cho thấy code kém ư. Code tốt dễ hiểu mà không cần comment dòng nào. Nhưng làm thế nào để tiết kiệm thời gian cho lập trình viên mới tiếp cận đến dòng code đó? – Chỉ cần viết những mô tả cơ bản trong tài liệu mô tả phương thức. Điều đó sẽ tiết kiệm thời gian để hiểu và sử dụng được đoạn code đó.
Review code có những mặt tốt và có những mặt không tốt. Bạn có thể tố chức review code nếu bạn có những lập trình viên mà họ hiểu 95% code, và họ có thể cập nhật code đó bất cứ lúc nào mà không tốn quá nhiều thời gian. Nhiều người cho rằng review code là một cách hay để dạy cho những lập trình viên mới nhiều thứ tốt hơn. Tuy nhiên mục đích chính của review code là đảm bảo chất lượng code. Một team tốt, là một team mà mỗi người đều có vai trò riêng của mình và chịu trách nhiệm chính xác về công việc mình làm. Nếu một thành viên muốn hiểu thêm một đoạn code của người khác, thì thành viên kia phải chỉ cho người này và phải đạt đc 30% hiểu được tất cả.
Tôi từng nghe rất nhiều câu ” Đừng lo tôi sẽ refactor nó lại trong tương lai”. Và trong tương lai có quá nhiều thứ công nghệ lỗi thời khó sửa, rất nhiều người đã đập đi làm lại. Vì vậy đừng cố mang cục nợ đó vào người, trừ khi bạn có tiền để thuê phát triển lại từ đầu
Khi lập trình viên mệt mỏi họ có thể làm tăng khả năng bị bug từ 2 đến 5 lần. Vì vậy 1 số bước cho rằng chỉ nên làm việc 6h/1 ngày. Công việc tinh thần thì không thể so sánh với công việc cơ bắp được
Trước khi viết code vần phân tích và dự đoán, những gì mà khách hàng thực sự cần, sau đó sẽ lựa chọn ra những cái thiết thực nhất như vậy sẽ dễ dàng tạo ra sản phẩm chất lượng và trong thời gian ngắn nhất. Hãy phân tích đi phân tích lại để đánh giá và đưa ra phương án tối ưu nhất.
Làm việc có thể tăng khả năng sáng tạo bằng cách tạm dừng công việc và ra ngoài hít thở không khi trong lành, trò chuyện với bạn bè, chơi guitar…
Khi con người ngừng học hỏi họ bắt đầu suy thoái
Bằng những chia sẽ trên mong rằng bạn rút ra cho mình được những bài học, kinh nghiệm để áp dụng vào công việc và cuộc sống, khiến nó trở nên tốt hơn!
Nguồn: Sưu tầm từ internet via Viblo