Hế lô anh em, vậy là sắp hết một năm nữa rồi!
Nhân dịp cuối năm ngồi lại chia sẻ với anh em một chút về những kỹ năng mà theo mình nghĩ bất kỳ một lập trình viên nào cũng nên có. Tất nhiên ở mỗi giai đoạn của sự nghiệp chúng ta đều có rất nhiều thứ phải học.
Sau đây chỉ là những chia sẻ của cá nhân mình ở góc độ một người có tuổi nghề chưa quá "già" và chắc chắn sẽ có những thiếu sót. Rất mong anh em góp ý để bài viết hoàn thiện hơn!
1. Đọc hiểu Source Code
Khi đi làm có thể phần lớn các dự án anh em làm đều là những dự án đã được phát triển trước đó và đang trong quá trình bảo trì, nâng cấp.
Những dự án này về mặt công nghệ thì công nghệ không quá mới thậm chí nhiều dự án sử dụng các công nghệ khá cũ và logic nghiệp vụ cũng khá phức tạp.
Ví dụ một chút, hồi mới ra trường mình làm việc với Spring Boot - một Java framework khá tinh gọn, không phải cấu hình quá nhiều. Nhưng sau đó, khi chuyển việc sang công ty mới mình phải làm một dự án tương đối cũ.
Dự án này xây dựng theo mô hình MVC - sử dụng Spring MVC luôn. Ban đầu mình cũng không quen vì code khá là rối và có những hàm dài tới cả nghìn dòng. Nhưng do có kỹ năng đọc source code, mô hình hóa được hệ thống nên chẳng mấy mình thích nghi ngay được với công việc.
Vì vậy các bạn lưu ý kỹ năng đọc hiểu source code là một kỹ năng tương đối quan trọng đó.
2. Sử dụng công cụ (IDE, Tools)
Làm công việc gì cũng cần có những công cụ hỗ trợ cả, làm lập trình này cũng vậy. Công cụ giống như "đồ nghề" vậy, nếu anh em càng thành thạo thì hiệu suất công việc càng cao.
Mình lấy ví dụ, nếu anh em sử dụng một IDE hay tools nào đó mà nắm được các phím tắt (shortcuts) thì mình đảm bảo nó sẽ giúp anh em tiết kiệm rất rất nhiều thời gian đó.
Ví dụ mình code Java và thường xuyên làm việc với IntelliJ Idea.
Đây là môt IDE khá mạnh với một bộ shortcuts đồ sộ. Chẳng hạn mình có thể dùng phím Ctrl + D để nhân đôi dòng thay vì copy và paste. Hoặc sử dụng con lăn chuột để thay đổi nhiều nhiều dòng một lúc...
Hãy sử dụng tool thành thạo nhất có thể.
3. Suy đoán Bugs
Hồi mới đi làm mình hay tự tin nói với đội tester là phần này mình code "không" có bugs đâu, yên tâm! Và kết quả thì anh em biết rồi đấy 🤣
Vì vậy một trong những kỹ năng mình thấy anh em dev nên rèn luyện đó là khả năng suy đoán bugs. Việc suy đoán được bugs sẽ giúp anh em hai việc:
- Một là hạn chế các bugs khác có thể phát sinh
- Hai là giúp quá trình fix bug của anh em nhanh và hiệu quả hơn
Và để có thể suy đoán được bugs anh em phải nắm được một số yếu tố sau: code base, thiết kế source code, logic nghiệp vụ và các mã lỗi hoặc mesg lỗi nếu có.
4. Debug
Debug chắc không còn xa lạ gì với anh em lập trình viên nữa, khi phát hiện ra bugs và phán đoán được bugs đó ở đâu nhưng chưa rõ nguyên nhân chính xác là gì thì đây lúc anh phải ngồi debug.
Mình ví dụ đơn giản như sau:
Thông thường khi làm việc với Java anh em hay gặp một ngoại lệ là NullPointerException
Và một trong những nguyên nhân khá phổ biến để gặp lỗi này là sử dụng hàm equals như sau:
student.getLevel().equals(Const.BASIC_LEVEL);
Trong một số trường hợp vì lý do nào đó đối tượng student bị null và việc sử dụng hàm equals như trên sẽ dẫn đến ngoại lệ NullPointerException.
Giải sử anh em có một danh sách (list) đối tượng Student và anh em không biết đối tượng nào bị null. Lúc này bắt buộc anh em phải debug vào đoạn code đó để biết được đối tượng nào null hoặc sửa lại đoạn code bên trên như sau:
Const.BASIC_LEVEL.equals(student.getLevel());
5. Phân tích vấn đề
Ở đây, không biết có anh em nào từng giống mình cứ nhận task nào là lao đầu vào code luôn mà không đặt câu hỏi hay phân tích xem tính năng đó làm gì không.
Cũng dễ hiểu thôi, nhiều khi quen tay rồi hoặc có suy nghĩ kiểu làm dev cần quan tâm đếch gì nghiệp vụ. Code cứ chạy là được, có bugs thì quay lại fix. Nhưng mình khuyên thật anh em nên bỏ cái suy nghĩ đó đi nhé.
Chưa nói đến việc phát triển sau này, chỉ đơn giản là khi hiểu vấn đề, bài toán hơn anh em xây dựng chức năng đó sẽ tối ưu, nhanh hơn và ít bugs hơn.
6. Unit test
Như mình đã đề cập ở phần 5, nhiều anh em lập trình viên có suy nghĩ mình dev thì không cần quan tâm nghiệp vụ là gì, bảo sao code vậy và đặc biệt là không thèm unit test.
Mình đã từng có giai đoạn như vậy, một phần vì công việc cứ lặp đi lặp lại (viết API CRUD 😅) nên nhiều khi chủ quan chẳng thèm unit test gì luôn.
Hoặc là nhiều khi gấp cũng không có thời gian unit test kỹ mà cứ thế code xong là kêu đội tester vào test. Đây thực sự là một tư duy tai hại, mình chia sẻ thật sự nếu các bạn muốn "nâng tầm" bản thân thì hãy bỏ lối suy nghĩ đó đi.
Hãy cố gắng phân tích và code cẩn thận, unit test để đảm bảo chức năng mình làm chạy thông luồng trước khi bàn giao cho đội kiểm thử.
7. Ghi nhớ các công việc đã làm
Mình tin chắc nhiều anh em dev sau khi code xong một chức năng nếu được hỏi lại vào 1-2 tháng sau thì dường như không còn nhớ gì luôn.
Đây chính là hệ quả của việc lao đầu vào code mà không chịu phân tích chức năng, làm theo kiểu chỉ đâu đánh đó.
Gợi ý cho anh em có thể dùng một số phần mềm như OneNote, Notion hoặc đơn giản như Notepad++ để ghi lại những phân tích về task đó. Khi nhận được một task nếu có thể hãy đặt câu hỏi:
[Why] tại sao lại làm chức năng đó
[How] làm task đó như thế nào và làm trong bao lâu.
Như vậy anh em sẽ ghi nhớ task đó lâu hơn và sau nếu có bugs và được hỏi lại anh em có thể nhớ luôn mà không phải xem lại code nhiều.
8. Quản lý thời gian, đầu việc
Mình đã từng rơi vào trạng thái đi làm mà chơi nhiều hơn làm để rồi đến lúc deadline dí thì lại vắt chân lên cổ chạy. Nguyên nhân cũng từ việc chưa có kỹ năng quản lý thời gian, đầu việc tốt.
Nếu dự án không quá gấp thì còn đỡ, chứ nhiều khi dự án gấp mà làm vậy là dễ "xì trét" lắm. Vậy làm sao để khắc phục?
Đầu tiên mình chia ra:
+ Các task liên quan đến phát triển mới (dev)
+ Các task liên quan đến fix bugs và các task khác.
Đối với các task phát triển mới thì thường cần nhiều thời gian hơn. Anh em hãy làm tốt khâu phân tích trước khi bắt tay vào code (những cũng đừng phân tích quá lâu nha, chán lắm đấy)
Sau khi phân tích thấy okay rồi, anh em hãy triển lên kế hoạch cho từng đầu việc, làm sao càng chi tiết càng tốt (theo mình chia theo giờ sẽ tạo sức ép hơn chia theo ngày). Anh em vẫn có thể dùng Notion hoặc Onenote cho đoạn này nhé.
Còn các task liên quan đến fix bugs và các task khác theo mình anh em nên sử dụng Jira hoặc Redmind để quản lý. Vừa tiện cho đội tester theo dõi vừa tiện cho anh em kiểm soát tiến độ.
9. Chia sẻ công việc
Sau một ngày dài mệt mỏi, hoặc vào một ngày anh em đã xong việc đang ngồi chơi xơi nước thì quay sang thấy đồng đội vẫn đang loay hoay chưa fix xong "chiếc bugs". Lúc đó anh em sẽ làm gì?
A - Kệ đồng nghiệp, tui về với vợ con đây
B - Mua cho đồng nghiệp một ly Highlands rồi vỗ vai cố lên tui về đây
C - Xắn tay ngồi cạnh hai anh em cùng nhau tìm nguyên nhân và fix "chiếc bugs" đó
Anh em chọn đáp án nào nhỉ! A hả 😅 Cũng đúng thôi, ai chả muốn hết một ngày được về với gia đình, được nghỉ ngơi.
Nhưng nếu không quá bận hãy cố gắng nán lại một chút, ngồi cùng và phân tích cùng đồng nghiệp. Dù có fix được hay không việc làm đó cũng giúp họ có thêm động lực và biết đâu sau này anh em cũng gặp những chiếc bugs như thế và họ sẽ sẵn sàng ngồi lại cạnh anh em.
10. Học hỏi kiến thức mới
Thú thật ngày còn đi học mình khá là lười học, đến lúc đi làm rồi mới nhận thấy chả có nhiều thời gian để học nữa.
Tất nhiên việc học tại mỗi thời điểm luôn là khác nhau cả về nội dung lẫn mục đích nhưng làm IT nói chung hay lập trình nói riêng kiến thức thay đổi hàng ngày.
Nếu muốn level up bản thân anh em hãy chủ động học thêm các kiến thức kỹ năng mới. Đối với anh em lập trình thì có một vài nguồn khá hay từ:
Youtube: Free Code Camp, CS Dojo, Java Brains...
Hoặc các blog nổi tiếng về lập trình
Lời kết
Có thể với 10 kỹ năng này không phải là tất cả nhưng theo mình nó là 10 kỹ năng cơ bản nhất đối với một lập trình viên gọi là "mới" vào nghề nên rèn luyện.
Sau này lên các vị trí cao hơn, anh em sẽ phải học hỏi thêm nhiều kiến thức, kinh nghiệm khác nữa và đó là điều tất nhiên đối với những người làm IT.
Chúc anh em thành công và ngày càng hoàn thiện bản thân mình hơn! See Youuuuuu!
Không có nhận xét nào: