14 thói quen để làm việc hiệu quả cao (Phần 1)
Giới thiệu
Nhiều người nghĩ rằng việc phát triển từ Junior developer lên Mid-junior developer chỉ là vấn đề thời gian và kinh nghiệm thôi
Nhưng sự thật là sự khác biệt của 2 loại developer này là rất ít và thường mang tính chủ quan.
Thành thật mà nói, tôi tin rằng thứ có thể thay đổi mindset và giúp các developer nhanh phát triển từ một Junior lên Mid-junior hay Senior là THÓI QUEN :
Thói quen là khi bạn bắt đầu thực hiện một việc hoàn toàn mới một cách có hệ thống cho tới khi bạn quen với nó và thực hiện nó một cách tự nhiên.
Hình thành thói quen liên quan đến code và công việc rất quan trọng đối với quá trình phát triển cá nhân và sự nghiệp.
Dưới đây là danh sách các thói quen bạn cần tập luyện hàng ngày để tiến bộ hơn và đạt được vị trí cao hơn trong sự nghiệp:
1. Viết các method nhỏ
Hãy tập viết các methods dài tối đa 20-30 dòng code. Thói quen này là cực kỳ quan trọng vì nó không chỉ buộc bạn viết code gọn hơn mà còn giúp bạn suy nghĩ logic hơn khi mô-đun hóa code.
Các method lớn với nhiều thụt đầu dòng (nhiều if, for loops, … ) thì không tốt. Viết một method như vậy có vẻ dễ dàng và đơn giản nhưng vài ngày sau bạn sẽ gặp khó khăn trong việc tìm ra method đó dùng để làm gì.
Cụ thể hơn, các method lớn thường không thể tái sử dụng. Chúng chỉ đáp ứng một nhu cầu cụ thể trong một project và khó sử dụng ở nơi khác.
2. Đặt tên có nghĩa
Việc này dành cho cả các method và variable. Đừng đặt variable bằng những tên như “x” hay “xyz” hay thậm chí là “object”. Mục đích của việc đặ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”.
Những variable có nghĩa giúp người khác đọc code dễ hơn và giảm bớt số lượng lớn comment.
Và điều này tương tự cho cả variable và method.
Ngoài ra, khi bạn tốn quá nhiều thời gian để đặt tên cho method, hãy xem xét việc tái cấu trúc code để method trở nên đơn giản hơn. Đặt tên cho một method tốt, clean sẽ dễ hơn tên cho một method lộn xộn
Khi bạn đang vật lộn với việc đặt tên, hãy dừng lại một chút và cân nhắc việc bạn đang đặt tên quá phức tạp và cần tái cấu trúc
3. Đừng làm lộn xộn các method với nhiều tham số
Có nhiều tham số trong một method là dấu hiệu cho việc tái cấu trúc. Viết kiểu method như vậy là đang vi phạm SRP (Single Responsibility Principle), và đó có nghĩa là bạn đang làm quá nhiều việc.
Một method hiệu quả, và sạch khi chỉ làm một việc duy nhất.
Như Uncle Bob đã nói rằng, ba là đối số tối đa có thể chấp nhận được. Mặc dù cái này không bắt buộc nhưng nó cung cấp cho bạn một cái nhìn tổng quan về số lượng đối số cần thiết 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
Quote của Rober C. Martin:
“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. Tránh quá nhiều method trong một class
Cũng như số lượng tham số, số lượng method trong một class cũng rất quan trọng.
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
Luôn luôn nhớ rằng “người đi sau” sẽ sử dụng code của bạn và compile lại project.
Sử dụng 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.
Đừ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.
6. Học cách xác định các design pattern phổ biến nhất
Hầu hết các project lớn đều được build bằng một hoặc nhiều Design Pattern. Một Design Pattern xác định mô tả, các mối quan hệ và mức độ trừu tượng trong một component. Bạn không cần phải biết tất cả chúng hoặc giỏi tất cả chúng, nhưng biết những cái cần thiết nhất sẽ giúp ích không chỉ về khả năng tư duy và thiết kế mà còn trong việc xác định chúng trong một code base.
Khi có thể xác định một Design Pattern trong một code base, bạn cũng có thể mở rộng hoặc thêm nhiều chức năng hơn cho nó bằng cách biết nơi tìm các class và object cụ thể.
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. Luôn nghĩ cho “người đi sau”
Cho dù đó là bạn, một đồng nghiệp khác, một nhân viên mới hay thậm chí là một developer ở một công ty khác thì sẽ đều cần mở rộng code của bạn hoặc thêm nhiều chức năng cho nó.
Việc này thật sự rất khó vì hầu hết các Junior developer đã quen với việc viết code theo yêu cầu và không ai tham gia vào khi học ở các chương trình Đại học.
Nhưng làm việc trong một môi trường chuyên nghiệp thì lại khác. Bạn sẽ được yêu cầu viết code cho một project từ nhiều năm trước và code của bạn sẽ được dùng cho “người đi sau” trong vài năm tiếp theo.
Vì vậy, bất cứ khi nào bạn tạm thời “hack” chỉ để làm 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, bạn đang thêm một “Technical debt” mà ai đó sẽ phải xử lý trong tương lai.
Dành thời gian để xem lại công việc của bạn mỗi ngày. Thêm documentation cần thiết vào các README file, xóa code không còn sử dụng nữa và xoá cả các file bạn thêm tạm thời vào dự án. Khi không chắc về các quyết định kiến trúc hoặc lập trình, hãy hỏi người có kinh nghiệm hơn tại nơi làm việc của bạn.
Bạn sẽ không chỉ cải thiện khả năng viết code mà còn giỏi xử lý các tình huống tương tự trong tương lai hơn, và quen với việc các sản phẩm của bạn bị chê
Kết luận
Phát triển từ một Junior lên Mid-junior developer không phải là chuyện ngày một ngày hai. Để thúc đẩy sự nghiệp và trở thành một developer chuyên nghiệp hơn thì cần phải hình thành thói quen tốt. Bài viết đã phần nào chỉ ra những thói quen quan trọng nhất và có ảnh hưởng nhất để trở thành một Software Developer chuyên nghiệp.
Happy Coding!
Via Techtalk.vn
