Khung năng lực cho Developer - Competency Matrix
Junior hay Senior?
Đây là câu hỏi không chỉ mình mà khá nhiều anh em cũng có chung thắc mắc. Như nào thì được gọi là Junior, như nào được gọi là Senior? Liệu rằng số năm kinh nghiệm có phải là một thang đo để xác định cấp bậc này hay không? Và làm như nào để trở thành Senior trong ngành? Sau một thời gian tìm hiểu, mình đã tìm ra một phương pháp để có thể tìm câu trả lời cho câu hỏi trên. Phương pháp có tên: Khung năng lực (Competency matrix).
Khung năng lực
Định nghĩa: Khung năng lực là bảng mô tả tổ hợp các kiến thức, kĩ năng, thái độ của một cá nhân tại vai trò làm việc. Áp dụng khung năng lực, anh em có thể biết rõ hơn việc mình đang ở “level” nào trong ngành, và để tiến tới level tiếp theo thì sẽ cần những kiến thức gì. Bài viết hôm nay mình sẽ giới thiệu Khung năng lực của Sijin Joseph dành riêng cho Developer, nội dung được tham khảo từ quyển DevUp của tác giả Nguyễn Hiển. Sijin Joseph phân chia năng lực và kỹ năng của một Dev thành 4 cấp độ theo big annotation. Các cấp độ này có thể hiểu là mức độ trường thành của một Dev. Các kiến thức và kỹ năng của một Dev được tổ chức thành các nhóm:
- Computer Science: những kiến thức căn bản, bao gồm cấu trúc dữ liệu và giải thuật.
- Software Engineering: kiến thức và kỹ năng xây dựng phần mềm
- Programming: kĩ năng giải quyết vấn đề và hiện thực hóa ý tưởng qua việc lập trình
- Experience: kinh nghiệm thực tế trên một nền tảng, công nghệ hoặc một lĩnh vực cụ thể
- Knowledge: năng lực liên tục cập nhật và chia sẻ kiến thức
Bài viết đã được lược dịch theo quan điểm của cá nhân mình trên nền tảng kinh nghiệm với UnityEngine, anh em khác có thể tham chiếu sang công nghệ riêng mà anh em sử dụng. Bài viết có rất nhiều keyword của ngành công nghệ thông tin bằng tiếng Anh nên mình sẽ giữ nguyên văn (vì dịch ra tiếng Việt nghe rất củ chuối)
Các tài liệu tham khảo mình sẽ để ở cuối bài, có đánh dấu (*x) với x là tài liệu tương ứng với từ khóa trong nội dung đó.
| 2^n (Level 0) | n^2 (Level 1) | n (Level 2) | log(n) (Level 3) | |
|---|---|---|---|---|
| Computer Science | ||||
| data structures | Không biết sự khác nhau giữa Array and LinkedList | Có thể giải thích và sử dụng Arrays, LinkedLists, Dictionaries,... trong quá trình làm việc lập trình | Biết được công sức và thời gian khi triển khai các cấu trúc dữ liệu như Array vs LinkedLists. Có thể giải thích và ứng dụng hashtable. Biết cách sử dụng Stack, Priority Queues | Có kiến thức về các cấu trúc dữ liệu nâng cao như B-trees, Binomial and Fibonacci heap, AVL/Red Black trees, Splay Trees, Skip Lists |
| algorithms | Không biết cách tìm giá trị trung bình của 1 mảng số int | Biết thuật toán cơ bản về sắp xếp, tìm kiếm, truy xuất | Hiểu và áp dụng được Cây, đồ thị, giải thuật tham lam, thuật toán chia để trị | Có khả năng nhận biết và code quy hoạch động, đồ thị, giải tích số, nhận biết được các bài toán NP |
| system programming | Không biết thế nào là Compiler, Linker, Interpreter (*1) | Hiểu cơ bản về Compilers, Linker Interpreters. Biết được assembly code là gì cách chúng giao tiếp với phần cứng (hardware). (*2) Có hiểu biết 1 chút về bộ nhớ ảo và paging. (*3) | Hiểu về kernel mode vs user mode, multi threading, synchronization primitives, biết được chúng đọc mã assembly code nhu nào. Hiểu về cách hoạt động của networks, network protocols, socket level programming. | Hiểu tất cả các lớp của chương trình, bao gồm phần cứng (CPU + Memory + Cache + Interrupts + microcode), binary code, assembly, static and dynamic linking, compilation, interpretation, JIT compilation, garbage collection, heap, stack, memory addressing… |
| Software Engineering | ||||
| source code version control | Tạo ra các Folder Backup theo thời gian (hồi sinh viên mình cũng làm theo cách này) | Biết dùng VSS và CVS (Concurrent Version System), SVN | Sử dụng thành thạo các tính năng của CVS và SVN. Biết làm thế nào để tách branch và merge code, sử dụng patches để cài đặt repository, etc | Có kiến thức về hệ thông quản lý mã nguồn phân tán. Đã dùng thử Bzr / Mercurial / Darcs / Git |
| build automation | Chỉ biết build từ IDE | Biết cách build từ command line | Biết cách build từ script | Có thể setup để build system từ script, viết tài liệu, tạo các release notes và đánh tag trong các trình source control |
| automation testing | Nghĩ rằng tất cả công việc test là của bộ phận tester | Luôn viết unit test cho mỗi đoạn code viết ra | Viết code theo tư tưởng TDD (Test driven development) | Hiểu và có khả năng setup hệ thống test tự động các functional, load/performance và UI test |
| Programming | ||||
| problem decomposition | Copy paste code từ chỗ này sang chỗ khác để giải quyết bài toán | Có khả năng phân tách các vấn đề thành nhiều function nhỏ | có khả năng viết các function/object có tính tái sử dụng cao và giải quyết được những bài toán tổng quát | Sử dụng cấu trúc dữ liệu và giải thuật hợp lý, viết ra những đoạn code có khả năng đóng gói để giải những bài toán tương tự ở nơi khác |
| communication (Đây là một tiêu chí thường bị đánh giá thấp nhưng lại rất quan trọng để đánh giá một lập trình viên. Với sự gia tăng việc outsoucing các công việc lập trình ở những nơi mà tiếng Anh không phải tiếng mẹ đẻ, vấn đề này càng trở nên nổi bật hơn. Tôi biết một số dự án đã thất bại vì lập trình viên không hiểu mục đích của việc giao tiếp (cuộc họp) là gì.) | Không thể diễn đạt suy nghĩ/ý tưởng với đồng nghiệp. | Đồng nghiệp có thể hiểu được những gì bạn nói. | Có khả năng giao tiếp với đồng nghiệp | Có thể hiểu và truyền đạt những suy nghĩ / thiết kế / ý tưởng một cách rõ ràng và linh hoạt trong nhiều trường hợp |
| code organization within a file | Không biết tổ chức code trong một file. | Các method được gom nhóm lại theo khả năng truy cập. | Code được nhóm thành các vùng (region) có comment cụ thể và reference đến các source files khác. | Code có header, có summary (thường được dùng để tóm tắt nội dung của đoạn code đó), có comment. Về tổng thể thì nhìn code rất sạch đẹp. |
| code organization within across files | Không biết tổ chức các file code. | Các file code liên quan được nhóm chung vào một folder. | Mỗi file code có một mục đích duy nhất. Ví dụ: định nghĩa một Class, triển khai một tính năng nào đó etc. | Các file được tổ chức theo các level, phối hợp chặt chẽ với thiết kế. Nhìn vào tên file và cách phân bổ folder thể hiện được thông tin chi tiết của thiết kế. |
| source tree organization (Sự khác biệt giữa mục này và mục trước là ở quy mô tổ chức, Cách tổ chức source tree sẽ liên quan đến toàn bộ tập hợp các sản phẩm (artifacts *5) xây dựng nên hệ thống.) | Đặt tất cả các file trong cùng một folder. | Cơ bản biết chia các folder theo logic code. | "No circular dependencies" (không có phụ thuộc vòng tròn), Binary, Libs, Docs, Build, third-party plugin được xếp vào các folder thích hợp. | Tên folder và cách tổ chức folder cung cấp thông tin chi tiết về thiết kế của hệ thống. |
| code readability | Đặt các tên dạng đơn giản Ví dụ: int x, string y..… | Đặt tên các files, variables, class, method đúng với định nghĩa và mục đích sử dụng. Tuân thủ naming convention. Phần này anh em có thể tham khảo chương 2, quyển Clean code của tác giả Robert C.Martin | Code function ngắn, có comment giải thích các đoạn code khó hiểu, fix bug hoặc code giả định. Code không bốc mùi, phần này anh em tham khảo trong https://sourcemaking.com/ | Như bên trái, nhưng làm tốt hơn |
| Defensive coding (*6) | Không biết khái niệm này là gì | Kiểm tra tất cả các đối số, dữ liệu truyền vào và biết cách giả định tình huống gây ra lỗi trong code. | Đảm bảo kiểm tra các giá trị trả về và kiểm tra các exception xung quanh code có thể bị lỗi. | |
| error handling | Chỉ code cho những trường hợp chạy đúng, còn sai thì không quan tâm. | Biết cách dùng try/catch, throw exception cho các đoạn code có khả năng gây lỗi. | Đảm bảo error/exception không làm chương trình bị force stop. Các connections và memory được dọn dẹp đúng cách. | Code có thể phát hiện các exception trước khi nó có thể xảy ra. Duy trì chiến lược xử lí exception nhất quán trong tất cả các layers of code. Đưa ra các hướng dẫn về xử lí exception cho toàn bộ system. |
| IDE | Chỉ sử dụng IDE để soạn thảo code. | Có tìm hiểu về giao diện của IDE, biết cách sử dụng các menu để làm việc hiệu quả hơn. | Sử dụng các phím tắt để các thao tác hay sử dụng nhanh hơn. | Tự tạo các phím tắt riêng cho bản thân. |
| API | Thường xuyên phải đọc lại documents của API | Nhớ được những API sử dụng nhiều lần. | Có sự hiểu biết sâu rộng về API mà mình sử dụng. | Viết các thư viện nhằm đơn giản hoá những API phức tạp bằng những method, function dễ hiểu, dễ sử dụng hơn. Có thể tìm ra những điểm sai hoặc thiếu để bổ sung vào API. |
| framework | Không sử dụng bất kỳ framework nào. | Đã nghe về nó những không sử dụng. | Sử dụng thành thạo nhiều framework. | Là tác giả của một framework. |
| requirements | Nhận yêu cầu và code theo mô tả trong tài liệu. | Có thể đặt ra các câu hỏi liên quan tới thông tin bị bỏ sót trong tài liệu mô tả. | Hoàn toàn hiểu về các yêu cầu và đưa ra tất cả vấn đề cần được giải quyết. | Có thể đề xuất những lựa chọn thay thế tốt hơn và đề ra các requiment dựa trên kinh nghiệm. |
| scripting | Không có kiến thức về việc viết script tool. | Biết viết batch file/shell scripts | Perl/Python/Ruby/VBScript/Powershell | Viết và xuất bản các script có thể tái sử dụng. |
| database | Nghĩ rằng Excel là một cơ sở dữ liệu (CSDL). | Có hiểu biết các khái niệm cơ bản về CSDL, chuẩn hoá, ACID, transactions và các câu truy vấn cơ bản. | Thiết kế CSDL tốt, được chuẩn hoá, có thể ghi nhớ và sử dụng các câu truy vấn, thành thạo sử dụng views, stored procedures, triggers và user-defined type. Hiểu biết sự khác nhau giữa clustered và non-clustered indexes. Sử dụng thành thạo các công cụ ORM. | Có thể quản trị CSDL cơ bản, tối ưu hoá hiệu suất, tối ưu index, viết được các câu truy vấn nâng cao, có thể thay thế cách sử dụng con trỏ với CSDL quan hệ, hiểu bản chất dữ liệu được lưu trữ, hiểu bản chất những index được lưu trữ, hiểu cách tạo bản sao CSDL (Database mirroring) etc. Hiểu cách two-phase commit hoạt động. |
| Experience | ||||
| kinh nghiệm chuyên môn về ngôn ngữ lập trình. | Imperative (lập trình mệnh lệnh) & Object Oriented | Imperative, Object Oriented và declarative (SQL), hiểu về kiểu dữ liệu static so với dynamic, kiểu dữ liệu yếu & mạnh, kiểu dữ liệu static inferred là một lợi thế | Functional, hiểu về lazy evaluation, currying, và continuation là một lợi thế | Hiểu về Concurrent (Erlang, Oz, Golang) and Logic (Prolog) |
| số flatforms có kinh nghiệm chuyên môn | 1 | 2-3 | 4-5 | 6+ |
| số năm kinh nghiệm chuyên môn | 1 | 2-5 | 6-9 | 10+ |
| Kiến thức chuyên ngành | không có | đã làm việc trên ít nhất một sản phẩm liên quan tới chuyên ngành | đã làm việc với nhiều sản phẩm liên quan tới chuyên ngành | Là chuyên gia trong ngành. Đã thiết kế & tích hợp một số sản phẩm/các giải pháp chuyên ngành. Thông thạo các thuật ngữ tiêu chuẩn, các quy tắc được sử dụng trong ngành. |
| Knowledge | ||||
| kiến thức sử dụng công cụ lập trình | Bị giới hạn với một IDE chính (VS.Net, Eclipse etc.) | Biết các công cụ thay thế phổ biến & công cụ tiêu chuẩn khác | Có kiến thức tốt về về các editor, debuggers, IDÉ, open source thay thế etc. Sử dụng đc các tool quản trị (ORM tool) | Viết ra được các tools & script và publish chúng. |
| languages exposed to | … | |||
| kiến thức về codebase | Chưa bao giờ xem codebase | Có kiến thức cơ bản về codebase, cách bố trí & xây dựng hệ thống | Có kiến thức tốt về codebase, thực hiện một số việc sửa lỗi và có thể làm một vài tính năng nhỏ. | Có thể tích hợp nhiều tính năng lớn vào codebase, có thể dễ dàng hình dung những thay đổi cần thiết cho hầu hết các tính năng hoặc sửa lỗi |
| Cập nhật các công nghệ mới | Chưa nghe nói gì về các công nghệ sắp tới. | Đã nghe nói về các công nghệ sắp ra mắt trong ngành | Đã download các bản alpha/CTP/beta & đọc một vài bài viết/hướng dẫn sử dụng | Đã test các bản preview và thực sự đã xây dựng thứ gì đó với nó và chia sẽ nó người khác. |
| platform internals (*6) | Không có kiến thức về các platform nội bộ | Có kiến thức cơ bản về cách hoạt động của platform nội bộ | có hiểu biết sâu sắc về platform, có thể nhìn ra được cách platform xử lý chương trình và chuyển đổi nó thành mã có thể thực thi được. | Đã viết các công cụ để tăng cường hoặc cung cấp thông tin về platform nội bộ. Ví dụ, bao gồm trình dịch mã (disassembler), trình giải mã (decompliers), và bộ gỡ lỗi (debuggers). |
| books | series miễn phí, 21 days series, 24 hour series, dummies series… | Code Complete, Don’t Make me Think, Mastering Regular Expressions | Design Patterns, Peopleware, Programming Pearls, Algorithm Design Manual, Pragmatic Programmer, Mythical Man month… | Structure and Intepretation of Computer Programs, Conceptss Techniques, Models of Computer Programming, Art of Computer Programming, Database systems, by C.J Date, Thinking Forth , Little Schemer |
| blogs | Đã nghe nói về các blog nhưng không có thời gian xem | Đọc các blog về tech/programming/ software engineering, thường xuyên nghe podcast | Dùy trì một blog liên kết với một bộ sưu tập các bài viết và công cụ hữu ích mà anh/chị đã thu thập được | Duy trì một blog trong đó chia sẻ những hiểu biết và suy nghĩ cá nhân về lập trình |
Tác giả khuyến nghị các bạn tự chấm điểm bản thân thông qua thang năng lực này qua từng tiêu chí và tính tổng số điểm bạn đạt được. Qua đó, bạn sẽ biết mình là junior hay senior một cách rõ ràng và được đo lường cụ thể.
Link bài viết gốc: https://blog.bravestars.com/2021/01/27/khung-nang-luc-cho-developer-competency-matrix/
Reference:
- Bài viết trên được mình trích dẫn từ link gốc, có sửa đổi/bổ sung thêm một số ý mà mình cho là cần thiết vào để làm rõ thêm ý nghĩa.
- Sách DevUp của tác giả Nguyễn Hiển: https://shope.ee/7KV0EwL5Pc
- Tài liệu tham khảo cho các thuật ngữ trong bài:
(*1) https://calavikevin.wordpress.com/2016/07/13/su-khac-nhau-giua-interpreter-compiler-va-code-script-program/
(*2) https://topdev.vn/blog/lap-trinh-vien-co-nen-hoc-assembly-khong/
(*3) https://vimentor.com/vi/lesson/bo-nho-ao-virtual-memory
(*4) https://stackoverflow.com/questions/17826380/what-is-difference-between-functional-and-imperative-programming-languages
(*5) https://daydore.com/giai-thich-artifact-la-gi-no-duoc-su-dung-trong-linh-vuc-nao-nhieu.html
Artifact (được dịch ra từ tiếng anh có nghĩa là: sự giả tạo, giả tượng, giả lập ) là một trong nhiều loại sản phẩm hữu hình được tạo ra trong quá trình phát triển phần mềm. Cụ thể đó là Artifact (ví dụ: use case, sơ đồ lớp, các mô hình UML khác, yêu cầu và các tài liệu thiết kế) đóng vai trò là giúp mô tả chức năng, kiến trúc và thiết kế cho thiết kế phần mềm. Mỗi artifact khác nhau thì liên quan với quy trình phát triển riêng của nó – chẳng hạn như kế hoạch dự án, các business case, và đánh giá rủi ro hay kiểm thử phần mềm .
Ngoài ra chúng ta có thể hiểu ngắn gọn hơn đó là Artifact là các sản phẩm được tạo ra trong quá trình phát triển phần mềm như requirement, design document, test case, test plan, test script,…
(*6) Defensive coding là một phong cách lập trình tập trung vào việc viết mã nguồn một cách cẩn thận để đảm bảo tính ổn định và an toàn của ứng dụng. Mục tiêu chính của defensive coding là ngăn ngừa và giảm thiểu các lỗi, sự cố và lỗ hổng bảo mật trong phần mềm.
Các nguyên tắc chính của defensive coding bao gồm:
- Kiểm tra dữ liệu đầu vào: Đảm bảo rằng dữ liệu nhập vào từ người dùng hoặc từ các nguồn bên ngoài đã được kiểm tra và xác thực để ngăn chặn các tấn công như lỗ hổng XSS (Cross-Site Scripting) hoặc SQL injection.
- Xử lý ngoại lệ (exception handling): Xử lý các ngoại lệ (exceptions) và lỗi một cách cẩn thận để tránh crash ứng dụng và hiển thị thông báo lỗi thân thiện với người dùng.
- Kiểm tra giới hạn và kiểm tra ranh giới: Đảm bảo rằng dữ liệu không vượt quá giới hạn và ranh giới được định sẵn để tránh tràn bộ đệm (buffer overflow) hoặc các vấn đề liên quan đến quản lý bộ nhớ.
- Ghi log (logging): Sử dụng hệ thống ghi log để theo dõi và phân tích lỗi trong quá trình chạy ứng dụng.
- Bảo mật dữ liệu: Bảo vệ dữ liệu quan trọng bằng cách sử dụng mã hóa và các biện pháp bảo mật khác.
- Kiểm tra và thử nghiệm: Thực hiện kiểm tra và thử nghiệm thường xuyên để phát hiện và sửa lỗi sớm, trước khi chúng gây ra vấn đề cho người dùng cuối.
Defensive coding giúp tăng tính ổn định, an toàn và đáng tin cậy của phần mềm, giảm thiểu rủi ro và lỗ hổng bảo mật, đồng thời cải thiện trải nghiệm người dùng và sự tin tưởng từ phía người dùng.
(*7) "Platform internal" là một thuật ngữ có nghĩa là các khía cạnh, chi tiết hoặc thông tin nội bộ liên quan đến một nền tảng, hệ thống, hoặc môi trường cụ thể. Thông tin "platform internal" thường không được công bố hoặc chia sẻ rộng rãi với công chúng mà chỉ được biết đến và quản lý bởi các chuyên gia, nhà phát triển, hoặc nhóm nội bộ có liên quan đến nền tảng đó.
Ví dụ, trong lĩnh vực phát triển phần mềm, "platform internal" có thể ám chỉ các chức năng, giao diện lập trình ứng dụng (API), cơ chế hoạt động bên trong của một hệ thống hoặc framework cụ thể. Các thông tin như này thường được xem xét như là kiến thức nội bộ của nhóm phát triển và không được tiết lộ công khai để bảo vệ bản quyền, bảo mật hoặc các lý do kinh doanh khác.
1 Comment
thezil Posted on 02.03.2024 10:35
hi