Software Architect – Check list những thứ cần có cần phải học

October 9, 2021 0 By Ntech Developers

Đây là bài viết tiếp tục chặng đường trở thành SA của mình mà mình có đề cập đến trong bài viết “Software Architect – Con đường chẳng hề dễ dàng“. Đúng là một con đường chẳng hề dễ dàng. Bài viết này mình đã tổng hợp được những kỹ năng cụ thể cần phải đạt được khi dấn thân vào con đường đầy chông gai này, có thể sau này mình có vững tâm rẽ theo con đường này hay không thì bài viết này mình cũng xin chia sẻ những kỹ năng này tại đây để các bạn cũng có thể nắm được như mình tại thời điểm hiện tại.

Cùng đi tiếp nghiệp Architect sẽ gồm 3 level cơ bản sau:

Application Level: Đây là level thấp nhất, nó tập trung vào một ứng dụng riêng lẻ, thiết kế kiến trúc chi tiết nhưng ở mức thấp, sẽ phải làm việc chủ yếu với team dev của bạn.

Solution Level: Đây là tầng ở giữa của Architecture, nó sẽ phải tập trung vào ứng dụng cùng với những nghiệp vụ xung quanh, cao hơn Application level nhưng chỉ xoay quanh các giải pháp để xử lý nghiệp vụ. Ở mức độ này bạn sẽ phải làm việc với BA và các team dev lớn khác nữa mà không chỉ riêng team dev của bạn.

Enterprise Level: Đây là mức độ cao nhất của Architecture. Nó tập trung vào các giải pháp tối ưu nhất, các thiết kế hệ thống ở mức cao và trừu tượng hóa mà không nhất thiết phải chi tiết đến từng bước làm triển khai. Ở đây bạn sẽ làm trực tiếp với khách hàng và tổ chức dự án ở cấp cao.

Khi trải qua từng level bạn sẽ phải là cầu nối của các bên như: Business – Development, Development – Development, Development – Management, Client – Team, 3rd Team – Internal Team.

Những công việc mà một SA cần phải làm như:

– Xác định và ra quyết định những công nghệ và nền tảng phát triển ứng dụng
– Đưa ra những quy định, tiêu chuẩn code, công cụ, quy trình review code hay các cách tiếp cận kiểm thử…
– Hỗ trợ làm yêu cầu khách hàng với BA
– Thiết kế hệ thống và đưa ra những giải pháp dựa trên yêu cầu khách hàng
– Viết tài liệu thiết kế hệ thống và tích hợp kiến trúc với các bên
– Review và kiểm tra lại kiến trúc thiết kế cũng như code base bên cạnh những patterns và coding standards trước khi thực hiện hóa
– Trao đổi với những SA khác về giải pháp cũng như các công nghệ xử lý
– Hướng dẫn và training cho các lập trình viên khác
– Khác thảo thiết kế từ high level tới detail design
– …

1. Design

Một bản vẽ thiết kế tốt sẽ là tiền đề quan trọng của cả một hệ thống sản phẩm. Nó cần sự tổng hợp của rất nhiều kỹ năng mới có thể có được kinh nghiệm thiết kế.

– Hiểu biết về design patterns. Các mẫu mô hình thiết kế phải nắm chắc được cùng với những ưu và nhược điểm từng mẫu thiết kế là tiền đề quyết định cho sự lựa chọn.

– Nắm được những best practice hay những anti pattern nhằm lường trước được những vấn đề phía sau trong quá trình thực hiện hóa

– Biết được cách đo lường chất lượng sản phẩm. SA không phải chỉ thiết kế xong kiến trúc là hết trách nhiệm họ còn phải đưa ra những hướng dẫn hay quy chuẩn để được áp dụng vào dự án, những cách thức đo lường thế nào là đạt chất lượng code hay những tính chất nằm ngoài yêu cầu như khả năng bảo trì, thay thế, thích ứng, bảo mật, hiệu năng, kiểm thử, mở rộng… Còn vô vàn thứ xung quanh một sản phẩm mà bạn cần phải có những tiêu chuẩn đo lường thế nào là đạt

– Cố gắng hiểu được thật kỹ càng những công nghệ nền tảng mà mình áp dụng cho dự án, điểm mạnh điểm yếu, những giải pháp khắc phục và bù đắp lại những khuyết điểm của công nghệ. Nó sẽ ảnh hưởng đến quá trình thiết kế và thi công của một sản phẩm nếu đã được triển khai

– Phân tích và hiểu rõ những patterns cho từng nền tảng được áp dụng, trả lời những câu hỏi tại sao dùng nó và một vài mẫu thiết kế dự phòng khi trường hợp xấu xảy ra.

– Phân tích được yêu cầu người dùng để có thể lựa chọn và phác thảo bản thiết kế một cách phù hợp nhất cho người dùng.

2. Quyết định

Một điều kiện kiên quyết là SA là người ra quyết định, người chốt kèo và cũng là người chịu trách nhiệm cho quyết định của mình trong một sản phẩm. Level càng cao thì trách nhiệm càng cao.

– Khả năng đánh giá được cái gì là quan trọng. Có thể tại thời điểm ngày sẽ có những giải pháp phù hợp trong ngắn hạn, trung hạn, dài hạn. Nhưng phải đánh giá được thời điểm cũng như cái gì là quan trọng nhất trong thời điểm đó để xử lý

– Ngoài khả năng đánh giá thì còn phải sắp xếp thứ tự quan trọng, mức độ ưu tiên để thực hiện. Có thể tại thời điểm đó team sẽ không thể xử lý được nhưng phải biết được sự ưu tiên của từng công việc cho team.

– Đánh giá năng lực của team cũng như bản thân. Đôi khi phải nắm được khả năng của đội ngũ phát triển còn định hướng và thay đổi chiến lược, có thể là đổi người hay là tuyển dụng sao cho phù hợp với công nghệ và dự án đang xây dựng

– Khả năng phân tích nhiều phương án khác nhau. Đối với một vấn đề phải luôn đặt ra những giải pháp hay những sự dự phòng, có những phân tích chặt chẽ những sự lựa chọn tốt xấu, phù hợp hay không thì mới có thể đưa ra quyết định chính xác.

3. Sự đơn giản hóa

Thực sự thì những vấn đề phức tạp sẽ thường được xử lý bởi những thứ đơn giản. Cố gắng làm sao biến những thứ phức tạp trở nên đơn giản hơn để có thể dễ dàng xử lý.

– Dung hòa những giải pháp. Khó có thể tìm được một giải pháp nào là hoàn hảo cả, đôi khi còn phải kết hợp nhiều phương án khác nhau để có thể giải quyết được vấn đề. Cần phải có sự cân bằng và chắt lọc những thế mạnh của từng phương án để có được một giải pháp tốt nhất có thể.

– Ném đá dò đường. Có thể nói đây là một kỹ thuật sử dụng khá nhiều khi chính những SA đó không thật sự chắc chắn về giải pháp của họ, họ sẽ phải thử từng bước một. mò mẫm và dò ra được phương án để giải quyết vấn đề trước mắt mà không làm ảnh hưởng đến tiến độ hay quá trình vận hành dự án

– Chia để trị. Đây cũng là một phương pháp hay dùng, khi một vấn đề quá phức tạp không thể xử lý. Khi này SA sẽ thường chia nhỏ chúng ra và đưa ra những giải pháp cho từng vấn đề một. Đơn giản hóa sự phức tạp thông qua một cách thức vô cùng truyền thống.

– Tái kiến trúc một cách dứt khoát. Một sản phẩm về mặt tổng thể có thể ổn nhưng khi bắt đầu một giải pháp phức tạp và cồng kềnh nếu không có giải pháp nào tốt hơn nó. Khi gặp vấn đề sau một quá trình kiển khai để đáp ứng những yêu cầu mới phát sinh thì bạn phải đưa ra một sự tái kiến trúc và đưa ra một giải pháp mới hoàn toàn. Khi này thì giải pháp mới phải được tiến hành một cách triệt để tuy nhiên vẫn phải cân nhắc về chi phí, thời gian, kiểm thử tính năng cũ… rồi mới thay thế dần cho đến khi thay thế hoàn toàn.

4. Code

Một người thiết kế hệ thống, SA cấp cao đi chăng nữa thì vẫn phải nắm được những anh em lập trình viên bên dưới đang và sẽ phải làm gì, triển khai nó như thế nào. Đừng vẽ một bản thiết kế mà không thể thực hiện hóa nó được. Có 2 trường hợp có thể xảy ra với những anh em cấp dưới: Họ không chấp nhận và không tin những giải pháp bạn đưa ra và họ không hiểu những gì bạn đưa ra. Vấn đề nảy sinh lúc này là bạn phải làm sao để họ phục và tin tưởng vào giải pháp của bạn. Những người sếp đi lên từng những nhân viên quèn sẽ hiểu được điều này. Họ trải qua và biết được những gì cần phải làm thì mới có được những kinh nghiệm mà thiết kế.

– POC mà mình có nhắc tới trong bài viết “POC là gì? Câu chuyện không chỉ riêng phát triển phần mềm” là một cách để bạn chứng minh giải pháp của mình.

– Đưa ra những nguồn dẫn hay những case study thuyết phục, có thể nó không đúng cho mọi trường hợp nhưng nó sẽ giải quyết được những vấn đề trước mắt. Code mẫu, tiếp cận trước và tham khảo những anh em dự án đã từng triển khai sẽ làm tiền đề cho những quyết định của sếp.

5. Document

Kiến trúc thiết kế luôn đi liền với tài liệu, nó thật sự rất quan trọng để quyết định xem giải pháp đó có khả thi và được triển khai hay không. Khi sản phẩm chưa được hình thành thì tài kiệu kiến trúc sẽ là những thái nghén quyết định thành bại của dự án. Sự lựa chọn các giải pháp cũng phải được đề cập trong các tài liệu liên quan.

– Clean code. Có thể bạn đã nghe ở đâu đó chính những dòng mã nguồn là những tài liệu đúng đắn nhất. Code tốt là phải dành cho người hiểu máy móc chỉ thực thi mà thôi. Kiến trúc sao để tự bản thân những thứ mình vẽ ra ai cũng hiểu được là một điều hoàn hào nhất.

– Tự động hóa sinh những tài liệu nếu có thể. Một số công nghệ hay công cụ Apis có thể giúp bạn tự động tạo ra cho bạn những tài liệu Apis của hệ thống. Việc bạn tổng hợp và chỉnh sửa chúng sẽ giúp bạn tiết kiệm nhiều thời gian.

– Viết những gì cần thiết và đủ để có thể hiểu một cách cô đọng trước mắt và cập nhật dần dần. Thật sự khó khăn khi mới bắt đầu mà phải tổ chức tất cả mọi thứ. Để có thể triển khai nhanh và tối ưu thì bạn sẽ phải làm những gì cần thiết để thi công trước sau đó bổ sung dần sau.

– Học thêm những nền tảng công nghệ. Việc nắm được những thứ trong công nghệ bạn sử dụng để phát triển phác thảo những công nghệ đó cần một lượng kiến thức rất sâu. Để làm được vậy thì bạn phải học và tìm hiểu mỗi ngày.

6. Giao tiếp

Phần đầu mình có đề cập là SA là cầu nối của rất nhiều bên nên giao tiếp với họ là một kỹ năng cần thiết.

– Học cách làm sao để diễn đạt ý tưởng của mình cho người khác. Ý tưởng chỉ mãi là ý tưởng nếu chỉ nằm trong đầu bạn và không thể thoát ra ngoài và triển khai thực tế.

– Trao đổi với các nhóm lớn. Dừng biến mình thành ếch ngồi đáy giếng, và không ai có thể nắm chắc được tất cả mọi thứ. Trao đổi với các nhóm lớn hơn có thể giúp bạn có giải pháp và nhiều góc nhìn khác nhau cho một vấn đề.

– Xác định đúng đối tượng và level khi nói chuyện. Cách giao tiếp với mỗi role hay mỗi vị trí là khác nhau. Không phải vị trí nào cũng hiểu cùng một cách diễn đạt của bạn. Nên bạn phải xác định đúng đối tượng trước khi trao đổi vấn đề

– Giao tiếp thường xuyên. Có khi nào là khi thiết kế sau một thời gian thì sản phẩm đi một hướng hoàn toàn khác. Nên theo sát dự án và trao đổi gỡ bỏ những vấn đề trong quá trình thực thi một cách kịp thời.

– Linh hoạt khi đưa ra quyết định, có thể tại thời điểm nói chưa có giải pháp nhưng bạn sẽ suy nghĩ và đưa ra cách giải quyết sau. Điều này có những khi phải trao đổi với mọi người. Có những khi phải tìm cách trì hoãn thêm thời gian. Linh hoạt trong từng hoàn cảnh.

7. Estimate

Định lượng ước tính những vấn đề trong dự án, về tiến độ, chi phí, khả năng thực hiện, đội ngũ,…

– SA đôi khi phải biết những nguyên tắc hay cách thức vận hành của một quản lý dự án mặc dù không hẳn phải quản lý. Dù sao đi chăng nữa thì cũng là sếp, là cán bộ cấp cao, là người nắm quyền sinh quyền sát trong tay. Kỹ năng quản lý con người cũng cần phải biết

– Xác định đánh giá thời gian và chi phí kiến trúc mình đưa ra. Điều này không phải là dễ dàng gì, nó phụ thuộc vào rất nhiều yếu tố, nhưng SA vẫn phải hoạch định được sát nhất có thể cho team.

8. Balance

Cân bằng về mọi mặt.

– Chất lượng và giá cả, chi phí, ngân sách. Không thể nào ôm hết mọi thứ chỉnh chu mọi mặt trong khi giá hữu nghị và thời gian quá ngắn được. Ai cũng vẫn biết không 1 bà bầu sinh con trong vòng 9 tháng nhưng khó có thể bắt 9 người làm sinh trong vòng 1 tháng được. Cân nhắc.

– Giải quyết mâu thuẫn trong mục tiêu. Mục tiên ngăn hạn, dài hạn sẽ có thể bị thay đổi và đôi khi SA phải đánh đổi, và trả một chi phí không hề nhỏ khi đưa ra một giải pháp cái nhìn dài hạn cho khách hàng. Có những giải pháp biết là tốt hơn trong dài hạn nhưng trước mắt thì khó có thể thực thi. Sự đánh đổi và quyết định là ở SA lúc này.

– Xung đột trong quản lý. Việc là cầu nối giữa nhiều bên khiến nhiều khi SA bị kẹt ở giữa nhiều bên. Họ hay phải cân bằng lợi ích giữa các bên và có những giải pháp hợp tình hợp lý, đối nội, đối ngoại tốt nữa.

9. Phát triển team

SA đâu chỉ là đưa ra giải pháp dự án đâu. Họ còn có những sứ mệnh riêng để build up lên một đội ngũ phát triển lớn mạnh hơn mỗi ngày.

– Hướng dẫn và định hướng cho đội ngũ bên dưới hiểu được những bước đi trong tương lai. Có thể thời gian đầu họ sẽ phải là người chỉ dẫn chi li tiểu tiết từng chút một nhưng dần dần khi đội ngũ cứng cáp thì họ có thể nhẹ nhàng hơn.

– Tạo ra những buổi chia sẻ kiến thức cho nhau, brainstorming, để có những giải pháp cho dự án. Mở rộng tư duy và hạ thấp cái tôi xuống để có thể phát triển hơn.

10. Quảng bá thương hiệu

Ngoài việc truyền động lực cho anh em trong team ra đôi khi SA phải có những niềm tin từ các bên khiến họ phục và tin tưởng giải pháp của mình.

– Trong một thời giai ngắn có thể thuyết phục được khách hàng hay team về giải pháp mình đưa ra khá khó khăn. Nhưng nếu đã có niềm tin và uy tín trước đó thì sẽ dễ dàng hơn với những lời nói của bản thân.

Trên đây là những ý kiến cá nhân đúc kết của bản thân sau khi đọc cuốn sách “Become A Better Software Architect“. Do là ý hiểu của bản thân dựa trên những quan sát thực tế trong ngành công nghệ thông tin ở Việt Nam. Có thể nó sẽ khác so với nước ngoài hay mình hiểu sai ý tác giả. Bạn nào đã đọc rồi thì có thể bổ sung và đính chính giúp mình nếu mình hiểu sai nhé.