Software Architect - Con đường chẳng hề dễ dàng
Mình không thực sự có kế hoạch rõ ràng cho cái level này, cái mình muốn ở đây chỉ đơn giản là bắt đầu làm việc và hướng tới mục tiêu...
Mình không thực sự có kế hoạch rõ ràng cho cái level này, cái mình muốn ở đây chỉ đơn giản là bắt đầu làm việc và hướng tới mục tiêu cho công việc này. Thực ra thì mình có một bài viết cách đây nửa năm về trước về việc đau đầu giữa sự lựa chọn theo hướng quản lý hay theo hướng kỹ thuật. Bạn có thể đọc lại bài viết đó để có thể hiểu rõ hơn về cảm xúc và quá trình mình nhìn nhận được career path cũng một đứa lập trình viên non kém có "dã tâm" như mình nhé
Nếu bạn vẫn chưa biết kiến trúc sư phần mềm (Software Architect) là gì và làm những gì thì bạn có thể đọc lại bài viết này để hiểu rõ hơn.
Bài viết sau đây chỉ ra những kỹ năng mà mình cần hướng tới để có thể tiếp tục trên con đường trở thành một Software Architect (SA) của bản thân mình, có thể nó đúng, có thể nó sai, có thể rằng một ngày nào đó mình dừng chân ở một vị trí nào đó khác với vị trí này, nhưng mình vẫn muốn viết lại để có thể lưu lại và chia sẻ những giai đoạn mà mình lựa chọn nó. Sau này đọc lại chắc sẽ vui lắm đây😄

Học cách tìm kiếm, đánh giá, vận dụng những mẫu tiêu chuẩn chung của thiết kế phần mềm. Thật vậy, đây là một kỹ năng rất quan trọng đối với vị trí này. Bạn thử nghĩ xem, thế nào là một công nghệ tốt, thể nào là một đoạn code xấu, thế nào là một kiến trúc chất lượng, làm sao để bản vẽ thiết kế của mình người khác đọc hiểu và thi công...
Có vô vàn những tiêu chuẩn đánh giá và quy chuẩn mẫu chung đối với công việc thiết kế. Việc của bạn là cần khảo sát, tìm hiểu (hiểu thật kỹ) một thành phần kiến tạo (có thể là công nghệ, cách tổ chức, ngôn ngữ, thư viện, framework...) trước khi áp dụng nó vào bản vẽ thiết kế của bạn. Đến đây thì mình có đọc ở nhiều nơi viết về phương pháp Five Whys khi đánh giá một công nghệ nào đó.
Why? – The battery is dead. (First why)Why? – The alternator is not functioning. (Second why)Why? – The alternator belt has broken. (Third why)Why? – The alternator belt was well beyond its useful service life and not replaced. (Fourth why)Why? – The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)

Kỹ năng đọc, không chỉ là một kỹ năng dành riêng cho vị trí kiến trúc phần mềm này mà nó còn là một kỹ năng không thể thiếu được đối với lập trình viên. Công nghệ thì thay đổi từng ngày, những vấn đề issues mà các công nghệ gặp phải, điểm mạnh điểm yếu ra sao, hạn chế và chi phí nó thế nào, cách xây dựng và bảo trì có dễ dàng không, tất cả đều phải đọc, phân tích và đánh giá. Không ai có thể trước khi dùng được những công nghệ trong bản thiết kế của mình mà lúc nào cũng phải thử, chứng minh, đo lường được những khó khăn tiềm ẩn. Mà họ phải đọc, tìm hiểu, case study những dự án trước của mình từng làm, những đồng nghiệp từng sử dụng, diễn đàn cộng đồng đã gặp phải để tổng hợp đánh giá nhằm rút ngắn thời gian xây dựng bản thiết kế cũng như đảm bảo thiết kế của mình được chất lượng. Tất nhiên là sẽ có những phần không chắc chắn bạn buộc phải tự mình thử nghiệm trước khi áp dụng. Suy cho cùng thì mọi kênh thông tin đều là tham khảo, nhưng mà kiến trúc đã xây dựng rồi thì chính bạn là người phải chịu trách nhiệm cho thiết kế ban đầu của mình.
Kỹ năng viết, đây là một kỹ năng rất rất quan trọng để có thể diễn đạt ý tưởng thiết kế kiến trúc của mình trong một dự án. Ừ thì cứ tuân theo những nguyên tắc tiêu chuẩn chung bên trên là có thể thể hiện được ý đồ của mình đối với những kỹ sư phần mềm khác. Nhưng thưa rằng không phải ai cũng có cùng một trình độ hay am hiểu về công nghệ, domain, term used (khái niệm, đối tượng, thuật ngữ...) để có thể hiểu được những gì bạn viết. Chưa kể rằng bạn phải viết để làm tài liệu cho đội ngũ phát triển sau này, viết để giải trình cho khách hàng duyệt bản thiết kế trước khi thi công xây dựng. Không những thế bạn phải viết sao cho mọi đối tượng tham gia vào dự án để có thể hiểu được, làm được, vận dụng được, điều này khá là khó khăn và cần phải tập luyện nhiều hơn.
Bên cạnh việc diễn đạt bằng những con chữ thì đối với ngành thiết kế phần mềm này bạn cần phải thành thạo cách sử dụng các sơ đồ (diagrams) hay hình ảnh (images) điều này có thể giúp bạn diễn đạt tốt hơn và giúp người đọc có thể hiểu rõ ràng hơn về ý tưởng thiết kế của bạn. Điều này đồng nghĩa với việc bạn cần học và tuân theo những tiêu chuẩn thiết kế như UML, ERD... (Mình xin phép có một bài viết khác để nói về các sơ đồ này trong thiết kế phần mềm)

Kỹ năng cuối cùng mà mình nhận được chính là kỹ năng dọn rác. Bạn không đọc nhầm đâu, đây chính là kỹ năng mệt mỏi nhất mà không phải ai cũng muốn làm. Bạn vào một dự án mới hoàn toàn thiết kế mới thì chẳng vấn đề gì, nhưng nếu bạn vào một dự án đang bảo trì, hay thi công sa lệch rất nhiều đối với ý tưởng ban đầu của bạn. Việc bạn đảm nhận lúc này là refactoring (sửa lại, kiến trúc lại...) để lái dẫn thiết kế cũ sang hướng thiết kế mà bạn mong muốn mà không ảnh hưởng quá nhiều đến sản phẩm, dự án, tổ chức. Những thư viện thay thế, những liên kết các thành phần, những phần lõi của sản phẩm,... Tất cả đều phải được điều chỉnh và thay thế dần dần để giảm thiểu chi phí và rủi ro tức thời. Trước khi làm những việc này bạn cần làm nữa là đánh giá những ảnh hưởng (impact), chi phí xây dựng lại (cost + effort), những điểm lợi điểm hại sau khi thay thế những thành phần mới, thiết kế mới, công nghệ mới. Nợ kỹ thuật (technical debt) không phải là một cái nợ mà dễ dàng trả được, chưa kể nó lại không phải là một cái mà đích thân bạn thiết kế từ đầu mà là nhận từ một anh thanh niên đẹp trai nào trước đó. Không thể trách anh đẹp trai đó được vì anh ta chỉ thiết kế đáp ứng tại thời điểm của anh ta và cùng lắm chỉ đáp ứng được nhu cầu phát triển của vài năm sau đó mà thôi.

Trên đây là những kỹ năng mà mình nhìn nhận được trong quá trình quan sát và học hỏi được trong suốt thời gian làm việc trong ngành công nghệ phần mềm vừa rồi. Mình vẫn đang cố gắng từng ngày để hoàn thiện những kỹ năng này và hi vọng có thể làm chủ nó vào một ngày không xa.
Nếu bạn có những ý kiến nào khác giúp mình bổ sung những thiếu sót thì bạn có thể comments dưới phần bình luận nhé! Mình sẽ tiếp thu và ghi nhận mọi sự góp ý của các bạn.
--
Reference:

Người trong muôn nghề
/nguoi-trong-muon-nghe
Bài viết nổi bật khác
- Hot nhất
- Mới nhất