1. Công nghệ chỉ là một PHƯƠNG PHÁP để giải quyết vấn đề, không phải là GIẢI PHÁP
Cộng đồng lập trình viên là một cộng đồng khá phù phiếm, chúng ta chạy theo đủ thứ công nghệ đang họt: NodeJS, AngularJS, NoSQL … Mình không nói chuyện này là xấu, tuy nhiên đôi khi chúng ta quá chú trọng vào công nghệ mà quên mất rằng nó chỉ là 1 phương pháp giải quyết vấn đề.
Đơn cử, nếu làm một trang web mua bán đơn giản, ít người sử dụng, ta có thể dễ dàng sử dụng PHP & MySQL, hoặc sử dụng các framework có sẵn,… không cần phải cố gắng áp dụng công nghệ hầm hố để giải quyết 1 vấn đề đơn giản.
2. Đừng code “thông mình”, hãy code rõ ràng
Có bao giờ bạn gặp trường hợp thế này: Có 1 chức năng cần sửa, hoặc 1 con bug khủng. Bạn nghĩ ra cách hiện thực/ cách giải vô cùng thông minh, ngắn gọn, tự vỗ đùi 1 phát khen mình thông minh. Tuy nhiên, 1 tháng sau, vào xem lại code (của chính mình) và không biết cái đống code “thông minh” của mình chạy như thế nào, làm sao sửa.
Chúng ta là lập trình viên, chất lượng của code được đo bằng tính rõ ràng, tính dễ bảo trì v…v, chứ không phải code càng ít dòng là càng giỏi như thời còn đi thi, đi học. Để biết cách viết code rõ ràng, các bạn có thể tham khảo cuốn Clean Code mà mình đã viết review trước đây.
3. Đừng viết code thừa, hãy viết đúng những gì cần viết
Hơi trái ngược với điều 2 nhỉ? Điều này có nghĩa là: Bạn chỉ cần viết code để hiện thực chức năng cần làm. Có thể code sẽ hơi thừa một chút, để chỗ trống cho sau này có thể bảo trì, nâng cấp v…v. Tuy nhiên, đừng viết code thừa, code sẵn để “trong tương lai dùng tới”. Có thể trong tương lai bạn sẽ chẳng cần tới nó đâu. Ngược lại, nhiều code còn sinh ra nhiều bug hơn, làm việc bảo trì khó khăn hơn.
4. Đừng lạm dụng comment
Comment làm lập trình viên lười hơn. Thay vì đặt tên biến dễ hiểu, viết flow chương trình rõ ràng, họ viết 1 đống sh*t, sau đó dùng comment để mô tả đống sh*t đó làm gì.
Ngoài ra, khi update code, họ rất lười update comment, do đó đôi khi comment chỉ là những dòng chữ thừa, vô dụng, không có tác dụng thực tế gì.
Cá nhân mình thì cũng hạn chế việc sử dụng comment, chỉ dùng nó để mô tả những điều không mô tả được bằng code. Hãy tập code thế nào để không cần nhìn comment bạn cũng hiểu được code chạy thế nào. Tới lúc làm được điều đó, bạn đã lên một “đắng cấp” khác.
5. Trước khi viết code, hãy xác định code sẽ làm gì
Tình huống này khá quen, mình chắc không ít các bạn đọc blog này đều gặp phải. Đôi khi chúng ta cắm đầu vào code trước khi làm rõ vấn đề. Quả thật là có nhiều lúc ta phải code mới biết cần giải quyết chuyện gì, code thế nào. Tuy nhiên, lời khuyên ở đây là: Hãy xác định mục đích code sẽ thực hiện trước khi code.
6. Hãy tự test code của mình trước khi quăng nó cho tester
Dĩ nhiên, test là trách nhiệm của tester. Tuy nhiên, là một lập trình viên “có đạo đức”, hãy tự test những case cơ bản, fix những lỗi ngu ngơ ngớ ngẩn như “validation” v….v trước. Đảm bảo chất lượng là trách nhiệm của mọi người.
7. Mỗi ngày hãy học 1 điều mới
Hồng Thất Công từng nói với Hoàng Lão Tà : “Trong giới võ học, không tiến tức là lùi”. Trong giới develop học cũng thế, nếu mỗi ngày không học 1 điều mới, bạn sẽ thụt lùi. Bạn sẽ cảm thấy càng ngày mình càng già, tụt hậu về công nghệ.
Để giải quyết chuyện này, mỗi ngày hãy dành ra 15p đọc sách (Ở các bài viết sau mình sẽ giới thiệu 1 số sách hay), mỗi năm hãy tự học một công nghệ mới, một ngôn ngữ mới, bạn sẽ nhận ra học cũng là 1 niềm vui đấy.
8. Viết code là chuyện rất thú vị
Thật lòng mà nói, nghề lập trình viên là một nghề có mức lương khá ổn, công việc cũng dễ kiếm (Hãy nhìn các bạn công nhân lương 5,6 triệu/tháng, nhiều bạn kinh tế ngân hàng ra trường không có việc).
Đôi khi nhìn lại, đi làm 1 ngày 8 tiếng ngồi với code và IDE, ta bỗng cảm thấy mệt mỏi. Hãy nhớ lại những ngày đầu tập code, nhớ lại niềm vui khi những dòng code đầu tiên chạy được. Sau đó nhìn lại mình, được code (làm điều mình thích), lại còn được trả tiền, cuộc sống còn gì hơn nữa.
9. Chấp nhận rằng không phải thứ gì mình cũng biết
Đừng cố gắng học hết mọi thứ, đừng cố gắng tỏ ra mình biết mọi thứ. Bạn có thể nói “em không biết”, cũng có thể hỏi người khác khi có vấn đề không rõ.
Càng học nhiều bạn sẽ thấy có nhiều thứ mình không biết, thay vì cố gắng học hết tất cả, hãy học cách tự học, sau đó xác định những kiến thức nào thật sự cần thiết, và tập trung vào nó.
10. Cách giải quyết tốt nhất còn tùy vào hoàn cảnh
Không phải lúc nào cũng nên áp dụng 3 lớp, áp dụng IoC, áp dụng Test Driven Development. Mặc dù chúng được gọi là “best practice” – những cách giải quyết tốt nhất, chúng ta cũng phải áp dụng tùy theo hoàn cảnh, không phải cứ mù quáng áp dụng vào là được.
11. Giữ cho mọi thứ đơn giản
Cách giải hay nhất cho một vấn đề thường là cách đơn giản nhất (Đừng làm với cách giải “thông minh” mình nhắc ở trên). Tuy nhiên, cách “đơn giản” này đôi khi rất tốn công sức mới tìm ra được. Trước khi đưa ra một cách giải quyết phức tạp cho 1 vấn đề, hãy tự hỏi mình “có cách nào giải quyết nó một cách đơn giản hơn không”
nguồn coppy từ 1 anh đi làm đọc để tham khảo
Posts
0 comments:
Post a Comment