MUỐN LÀM VIỆC HIỆU QUẢ, DEVELOPER HÃY TẬP NHỮNG THÓI QUEN SAU ĐÂY

13-03-2019 23:12

Nhiều người cho rằng, để phát triển từ Junior Developer lên Mid-junior Developer cần nhiều thời gian và kinh nghiệm. Tuy nhiên, thực tế cho thấy, thói quen mới chính là thứ giúp Developer có thể thay đổi và phát triển nhanh nhất.

Bài viết dưới đây ITPlus Academy chia sẻ với bạn một số thói quen mà mỗi Developer cần rèn luyện hàng ngày để có thể đạt được những tiến bộ và thành công trong sự nghiệp.

1. Viết các method nhỏ

Nhiều người vẫn thích viết các method lớn với nhiều thụt đầu dòng (nhiều if, for loops, …) vì nó có vẻ đơn giản, tuy nhiên, những method đó thường lãng phí, không thể tái sử dụng do nó thường đáp ứng một nhu cầu cụ thể trong một project cụ thể nào đó.

Do đó, hãy tập viét các method với độ dài tối đa là 20-30 dòng code. Thói quen viết các method nhỏ vô cùng quan trọng bởi nó buộc bạn viết code gọn hơn và suy nghĩ cũng theo đó dần trở lên logic hơn.

2. Đặt tên có nghĩa

Nên đặt tên có nghĩa cho cả method và variable. Không nên sử dụng tên “x”, “xyz” hay thậm chí “object”. Đặt tên Tiếng Anh cho variable là để chúng có nghĩa.

Hiểu code quan trọng hơn nhiều so với hiểu documentation hoặc comment. Mục đích của các comment là để giải thích “tại sao”, chứ không phải “làm thế nào”. Do đó, để giúp người khác đọc code dễ hơn và giảm bớt số lượng lớn comment, hãy đặt tên có nghĩa cho variable. Điều này hoàn toàn tương tự đối với method.

Nếu bạn cảm thấy đặt tên cho method tốn quá nhiều thời gian, hãy thử tái cấu trúc code để method trở nên đơn giản hơn. Đặt tên method tốt giúp cho việc clean dễ dàng hơn nhiều so với tên một method lộn xộn.

3. Càng nhiều tham số, method càng dễ lộn xộn

Một method hiệu quả và sạch khi chỉ làm một việc duy nhất. Điều này không được đảm bảo khi có nhiều tham số trong một method. Bới đó là dấu hiệu của tái cấu trúc, và method với nhiều tham số là vi phạm SRP (Single Responsibility Principle), đồng nghĩa với bạn đang làm quá nhiều việc.

Uncle Bob cho rằng chỉ nên dùng tối đa 3 đối số. Dù đó không phải chuẩn mực và bắt buộc nhưng cũng cho bạn một cái nhìn tương đối tổng quát về số lượng đối số trong một method.

Hãy kiểm soát mong muốn thay đổi một số tham số local của method thành các class field. Xem xét việc tái cấu trúc code để method thực hiện ít việc hơn hoặc tách method đó thành 2 phần riêng biệt

Rober C. Martin nói rằng: “Các function nên có một số lượng nhỏ các đối số. Không có đối số nào là tốt nhất, sau đó là một, hai và ba. Hơn ba là nên xem xét lại.”

4. Kiểm soát số lượng method trong một class

Các class lớn có nhiều method thường là biểu hiện của một component “biết quá nhiều” hoặc “làm quá nhiều”. Tôi gọi các component này là các God Class để mô tả về một anti-pattern khi viết coupled code.

Nếu bạn có nhiều method trong một class, hãy xem xét mật độ bạn cần phải enter class này để thay đổi hành vi của nó, vì code tiến triển theo thời gian. Việc này có thể vi phạm nguyên tắc Open-closed: “Các software entities (classes, modules, functions, v.v.) nên được mở cho việc mở rộng, nhưng được đóng để sửa đổi”.

5. Sử dụng các release LTS / ổn định khi sử dụng library của bên thứ 3

Bởi vì “người đi sau” sẽ sử dụng code của bạn và compile lại project nên đừng sử dụng tool phiên bản mới nhất và cứ tiếp tục phiên bản an toàn và ổn định nhất. Mặc dù các phiên bản LTS (Long Term Support) của các library, plugin và framework có thể không phải là lựa chọn tốt nhất khi có các tính năng mới nhưng sẽ rất cần thiết khi cần build lại hoặc compile lại code trong tương lai.

6. Xác định các design pattern phổ biến nhất

Các project lớn thường được xây dựng bởi một hoặc nhiều Design Pattern. Mỗi Design Pattern mô tả, cho biết mối quan hệ hay mức độ trừu tượng trong một component. Mặc dù bạn không cần giỏi tất cả chúng nhưng bạn cần nắm được những thứ cần thiết nhất để phục vụ quá trình tư duy và xác định chúng trong một code base. Hơn nữa, khi bạn có thể xác định một Design Pattern trong một code base, nó cũng đồng thời giúp bạn mở rộng hoặc bổ sung nhiều chức năng hơn cho nó khi bạn hiểu rõ nơi tìm các class và object.

Một Design Pattern được triển khai tốt khiến mọi người trong một project giao tiếp hiệu quả hơn thông qua code.

7. Nghĩ cho “người sau”

Có thể bạn đã quen với làm việc độc lập, viết code theo yêu cầu và không có sự can thiệp của người khác vào quá trình làm việc của bạn. Nhưng đó không phải phong cách làm việc tại môi trường chuyên nghiệp. Tại đó, bạn được đồng nghiệp, sếp hay một developer khác yêu cầu mở rộng code hoặc thêm nhiều chức năng cho nó. Điều đó cũng đồng nghĩa với việc, bạn có thể được giao nhiệm vụ hoàn thiện code cho một dự án từ nhiều năm trước hay code của bạn sẽ được sử dụng cho những người đi sau trong tương lai.

Do đó, để tráng đem đến các “Technical debt” cho ai đó sau này, bạn không nên tạm thời hack chỉ để cho cái gì đó hoạt động, hay thêm cái gì đó vào build process và tránh document nó, hoặc bỏ qua việc tái cấu trúc.

Hãy xem lại công việc của bạn mỗi ngày, loại bỏ những phần thừa và đừng ngần ngại tìm kiếm lời khuyên từ những đồng nghiệp đi trước. Bạn cũng nên làm quen với việc bị chê nhiều và phải thay đổi, đó thực sự sẽ bạn cải thiện khả năng viết code cũng như xử lí nhiều tình huống tương tự trong tương lai.

Các bạn thấy đấy, để trở thành Mid-junior developer từ một Junior developer không hẳn quá khó, nhưng cũng cần một quá trình hình thành thói quen chuyên nghiệp. Hy vọng bài viết trên đây đã đưa ra cho bạn những lời khuyên đúng đắn.

Ban Truyền thông ITPlus Academy