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

VietCold
Lại là e, cám ơn anh đã tiếp tục làm về Kĩ sư phần mềm, cảm ơn a rất nhiều
- Báo cáo

Ntech 

Cám ơn bạn đã ủng hộ mình nhé. Series về kỹ sư phần mềm này dự là có hơn 10 bài cơ. Hi vọng bạn tiếp tục ủng hộ
- Báo cáo

VietCold
Mong anh tiếp tục làm tiếp thôi ạ
- Báo cáo
kevin_
Cảm ơn những chia sẻ tâm huyết của bạn, bài viết rất chất lượng
- Báo cáo

Ntech 

Hi vọng bạn sẽ tiếp tục ủng hộ mình cho các bài viết sắp tới
- Báo cáo
Nguyên
Bác cho em hỏi dùng phần mềm nào để vẽ cái giản đồ như hình ạ
- Báo cáo

Ntech 

draw io và start uml
- Báo cáo
Nguyen Huy Chung
Bài viết thiếu chiều sâu quá. Quá nông nếu nói 1 Sa cần những ki năng trên kia
- Báo cáo

Ntech 

Ngay mở bài mình có nói đây là bài viết mở đầu cho các bài viết sau mà. Mỗi kỹ năng đều có một bài viết riêng nhé. Hơn nữa mình cũng đang theo đuổi con đường này nên thiếu chiều sâu là bình thường bạn
- Báo cáo

Philip Le
Tôi chỉ góp ý về hình ảnh đầu tiên trong bài thôi. Quá nhiều buzz words, không thể hiện được nội dung trọng tâm. Cá nhân tôi thấy ở level càng cao thì 1 swe nên biết cách để nói về 1 vấn đề càng đơn giản và dễ hiểu càng tốt.
- Báo cáo

Ntech 

Hình ảnh đẹp mình để lên đầu làm thumbnail bài viết thôi ạ. Mình đặt ảnh đó vào đoạn văn k có mô tả gì nên không có ảnh hưởng đến bài viết. Mình đồng ý là càng level cao càng phải diễn đạt làm sao cho người khác hiểu. Tuy nhiên phải làm rõ đối tượng nghe trước. Phần kỹ năng hướng dẫn mình có đề cập qua nhưng chưa được chi tiết. Cám ơn bạn đã góp ý nhé
- Báo cáo