Hotline

0963 801 047
APEX Global
ACADEMY FOR PROFESSIONAL EXCELLENCE

Bạn có phải là một Software Architect chuyên nghiệp?

2016-11-23  (1971)

Phân định ranh giới giữa phát triển phần mềm và kiến trúc phần mềm là một trong những việc khó khăn. Một số người sẽ nói với bạn rằng công việc kiến trúc phần mềm không tồn tại và kiến trúc là một phần mở rộng của quy trình thiết kế được thực hiện bởi các nhà phát triển phần mềm. Một số khác thì có thể nói với bạn rằng kiến trúc phần mềm là một cái gì đó mơ hồ và tin tưởng rằng nó được thực hiện bởi một nhóm các developer giàu kinh nghiệm thiết kế để hoá giải sự trừu tượng của kiến trúc. Hãy đọc bài viết này để biết được bạn có phải là một software architect chuyên nghiệp hay không?

software-architect-chuyen-nghiep

Một số yếu tố quan trọng thường sử dụng để phân biệt sự khác biệt của kiến trúc phần mềm từ thiết kế phần mềm và phát triển phần mềm là:

  • Sự gia tăng trên độ lớn
  • Sự gia tăng trên các cấp độ khác nhau của sự phức tạp
  • Sự gia tăng của tầm quan trọng trong việc quyết định thiết kế đúng

Kiến trúc phần mềm là tất cả các công việc cần có một cái nhìn toàn diện và nhìn một bức tranh lớn hơn để làm thế nào hệ thống phần mềm hoạt động như là một tổng thể.  Điều này giúp mọi người phân biệt sự khác nhau giữa phát triển phần mềm và kiến trúc phần mềm. Nó cần thiết để giúp người đang tham gia phát triển phần mềm có thể hình dung rõ cách dịch chuyển sang thiết kế kiến trúc. Ngoài ra, việc phân biệt rõ ràng sẽ giúp nhà tuyển dụng tìm kiếm ứng viên cho vị trí kiến trúc sư phần mềm.

Trở thành một kiến trúc sư phần mềm (Software Architect – SA) không phải là một giấc mơ chỉ diễn ra trong một đêm. Đó là một vai trò, không phải cấp bậc. Mà nó cần một quá trình phấn đấu và trưởng thành của người làm nghề thông qua việc tham gia thiết kế và tích luỹ kinh nghiệm.

Thông thường, kiến trúc phần mềm trong các dự án sẽ có 2 giai đoạn:

1/ Định nghĩa kiến trúc phần mềm

2/ Chuyển giao kiến trúc phần mềm.

Và bây giờ chúng ta hãy cùng tìm hiểu nhé.

Định nghĩa kiến trúc phần mềm

Nhìn từ bên ngoài thì quá trình định nghĩa kiến trúc phần mềm trông có vẻ khá đơn giản. Tất cả những gì họ phải làm là tìm ra các yêu cầu đầu vào và thiết kế một hệ thống thoả mãn các yêu cầu đó. Nhưng trong thực tế công việc này không đơn giản chút nào, vai trò kiến trúc sư phần mềm có thể tạo ra sự thay đổi lớn tùy thuộc vào cách bạn đang tiếp cận và sự tập trung vào công việc định nghĩa kiến trúc từ cách nhìn của bạn. Phần định nghĩa kiến trúc này có thể chia thành các phần khác nhau như:

1) Quản lý các yêu cầu phi chức năng (non-functional requirements)

Trong các dự án phần mềm, người làm nghiệp vụ và cả đội phát triển tập trung vào những chức năng mà họ muốn, nhưng hiếm khi họ được hỏi đến các yêu cầu, hoặc đặt câu hỏi về những yêu cầu phi chức năng (hoặc các yêu cầu chất lượng của hệ thống) mà họ cần thiết cho dự án. Đôi khi các bên liên quan sẽ nói với chúng ta rằng “hệ thống phải được nhanh chóng” hoặc “hệ thống phải đảm bảo chạy tốt khi có lượng kết nối cao cùng một thời điểm”,… mọi thứ rất chung chung và điều đó thể hiện sự quá chủ quan. Các yêu cầu phi chức năng cần phải được cụ thể hoá, đo lường được, có tính khả thi, gắn liền các yêu cầu mục tiêu của dự án và có thể kiểm chứng được để đáp ứng cho nhu cầu kinh doanh của khách hàng. Hầu hết các yêu cầu phi chức năng là kỹ thuật trong tự nhiên, thường có một sự ảnh hưởng rất lớn đến kiến trúc phần mềm. Hiểu rõ các yêu cầu phi chức năng là một phần quan trọng của vai trò kiến trúc sư phần mềm, nhưng có một sự khác biệt giữa những giả định về những yêu cầu đang có của khách hàng, thách thức của khách hàng. Sau tất cả, có bao nhiêu hệ thống bạn thấy rằng thực sự cần phải hoạt động 24×7?

Trong hoạt động thiết kế kiến trúc phần mềm thì những yêu cầu phi chức năng thường được gọi là thuộc tính chất lượng (Quality Attribute). Luôn có một danh sách dài nhưng các kiến trúc sư chỉ tập trung vào những thuộc tính chất lượng cụ thể theo bối cảnh của dự án và những thách thức cần được giải quyết cho khách hàng.

2) Định nghĩa kiến trúc

Sau khi các yêu cầu phi chức năng được phân tích và chọn lựa dựa trên yêu cầu đặc thù của dự án, bước tiếp theo là bắt đầu suy nghĩ về cách bạn đang giải quyết các vấn đề được đặt ra bởi các bên liên quan và xác định cấu trúc. Công bằng mà nói tất cả các hệ thống phần mềm đều có một kiến trúc, nhưng không phải mọi hệ thống phần mềm đều có một kiến trúc được xác định trước. Và đây cũng là điểm gây nhiều thất bại hoặc thách thức trong giai đoạn triển khai sản phẩm thực tế cho khách hàng. Quá trình định nghĩa kiến trúc cho phép bạn suy nghĩ về cách bạn đang hướng đến để có những yêu cầu cùng với những sự ràng sự buộc và vấn đề cần giải quyết.

Định nghĩa kiến trúc là bao gồm việc giới thiệu cấu trúc của phần mềm, các hướng dẫn thiết kế, các nguyên tắc và dẫn dắt đến các khía cạnh kỹ thuật của một hệ thống phần mềm. Xác định kiến trúc là công việc của bạn sẽ thực hiện như một kiến trúc sư phần mềm, nhưng có một sự khác biệt lớn giữa thiết kế một hệ thống phần mềm từ đầu và mở rộng một hệ thống đã tồn tại.

3) Lựa chọn công nghệ

Lựa chọn công nghệ thường là một bài tập thú vị, nhưng nó không có cách thức chuẩn để giúp bạn vượt qua thách thức khi bạn xem xét các yêu tố như: chi phí, giấy phép, các mối quan hệ với nhà cung cấp, chiến lược công nghệ, tính tương thích, khả năng tích hợp, sự hỗ trợ, khả năng triển khai, chính sách nâng cấp, môi trường người dùng cuối,…

Tổng hợp các yêu tố trên có thể biến một công việc tưởng chừng như đơn giản trở nên cực kỳ phức tạp. Và sau đó là những câu hỏi liệu công nghệ mà bạn đang chọn lựa có thực sự đáp ứng được nhu cầu của bạn không? Lựa chọn công nghệ bao gồm công việc quản lý rủi ro, giảm thiểu rủi ro, những giai đoạn có độ phức tạp cao hoặc không chắc chắn, giới thiệu giai đoạn có những nguy cơ có thể bị xâm hại lợi ích.

Quyết định công nghệ cần phải được thực hiện bằng cách phân tích tất cả các yếu tố liên quan, và tất cả các quyết định công nghệ cần phải được xem xét và đánh giá cẩn thận. Điều này bao gồm các khối xây dựng chính cho một hệ thống phần mềm phải phân rã xuống các thư viện và các framework, các giải thuật hoặc các patterns để giới thiệu cho các bên liên quan trong giai đoạn phát triển.

Nếu bạn đang định nghĩa một kiến ​​trúc, bạn cũng cần phải tin tưởng rằng các lựa chọn công nghệ đang được thực hiện là sự lựa chọn đúng, phù hợp với yêu cầu. Một lần nữa có một sự khác biệt lớn giữa việc đánh giá công nghệ cho một hệ thống mới so với cách thêm công nghệ vào một hệ thống đã tồn tại.

4) Đánh giá kiến trúc

Nếu bạn đang thiết kế phần mềm, bạn cần phải tự hỏi bản thân rằng “liệu kiến trúc của bạn sẽ hoạt động tốt hay không?”. Đối với tôi, một kiến trúc làm việc tốt nếu đáp ứng các yêu cầu phi chức năng quan trọng, cung cấp nền tảng cần thiết cho phần còn lại của việc triển khai code, cung cấp một nền tảng đủ để giải quyết các vấn đề kinh doanh cơ bản và tiết kiệm được nguồn lực để phát triển lẫn nguồn lực ở khâu bảo trì.

Một trong những vấn đề lớn nhất của phần mềm là sự phức tạp và trừu tượng, làm cho các bên liên quan khó hình dung những đặc điểm tại thời điểm chạy từ sơ đồ UML hoặc các dòng lệnh. Chúng tôi thực hiện một số thử nghiệm khác nhau trong suốt vòng đời phát triển phần mềm để tạo sự tự tin rằng hệ thống của chúng ta đang cung cấp sẽ làm việc tốt khi triển khai vào thực tế.

Vậy tại sao bạn không làm như vậy cho các kiến trúc của bạn? Nếu bạn có thể kiểm tra kiến trúc của bạn, sau đó bạn có thể chứng minh rằng nó hoạt động tốt. Nếu bạn làm điều này càng sớm càng tốt, thì bạn có thể giảm rủi ro gây ra thất bại cho dự án chứ không phải đơn giản chỉ là sự hy vọng sẽ triển khai tốt nhất.

Nhưng trong thực tế có một số chủ quan rằng “Hệ thống sẽ luôn làm việc tốt mà không cần kiểm tra thử, đánh giá trong giai đoạn thiết kế kiến trúc”. Giai đoạn phát triển và triển khai thực tế gặp rất nhiều khó khăn, và đôi khi gây thất bại cho dự án.

Ví dụ như đối với một hệ thống website thương mại điện tử, sẽ đòi hỏi website phải chạy nhanh và có thời gian trả lời trong vòng 3 seconds thì việc thử nghiệm và đánh giá tính khả thi của kiến trúc hệ thống trong giai đoạn thiết kế kiến trúc và tiếp tục đánh giá lại trong giai đoạn phát triển hệ thống là đúng đắn.

5) Sự cộng tác thiết kế kiến trúc

Thiết kế kiến trúc không phải là công việc độc lập mà kết quả đầu ra của hoạt động sẽ tương tác với nhiều đối tượng khác nhau như: nhóm phát triển cần biết những flat-form, library nào của kiến trúc mà họ sẽ được sử dụng, hoặc tái sử dụng, những tài liệu kiến trúc quan trọng nào họ cần được đào tạo hoặc nắm rõ trước khi phát triển hệ thống. Ngoài ra, những nhóm lợi lích liên quan cần nắm về kiến trúc như: security, database, đội hỗ trợ kiến trúc hạ tầng, đội vận hành, đội hỗ trợ,… Để dự án phần mềm thành công, ở vai trò kiến trúc sư bạn cần tham gia phối hợp với tất cả các bên liên quan để đảm bảo kiến trúc sẽ tích hợp thành công với môi trường của dự án, dễ triển khai thiết kế chi tiết, và triển khai code,…

Thật không may, sự cộng tác thiết kế kiến trúc hiếm khi xảy ra, hoặc xảy ra không thường xuyên ở các dự án phần mềm.

Chuyển giao kiến trúc phần mềm

Vai trò kiến trúc sư phần mềm có thể tuỳ thuộc vào mức độ gắn kết để có đóng góp cho thành công của dự án phần mềm. Việc chuyển giao thiết kế cho đội phát triển và các bên liên quan không có nghĩa là công việc của bạn trong dự án đã kết thúc. Vậy công việc kế tiếp của bạn là gì để đảm bảo kiến trúc được triển khai tốt nhất?

1) Sở hữu những bức tranh lớn hơn

Để công việc thiết kế kiến trúc đi đến thành công, điều quan trọng là kiến trúc sư phải sở hữu bức tranh lớn và chia sẻ tầm nhìn với đội phát triển xuyên suốt vòng đời phát triển phần mềm đó. Tiếp tục phát triển nó trong suốt dự án nếu cần thiết, chịu trách nhiệm đảm bảo rằng kiến trúc được chuyển giao thành công cho đội phát triển và những đối tượng liên quan. Nếu bạn đã thiết kế được một kiến trúc phần mềm, nó tạo ra cảm giác thôi thúc tiếp tục tham gia và phát triển kiến trúc của bạn chứ không phải là lựa chọn để trao kiến trúc đó cho một “đội ngũ triển khai tính năng”.

Quá trình triển khai tính năng trên nền kiến trúc của bạn sẽ có những trở ngại nhất định và bạn cần tiếp tục duy trì để đảm bảo kiến trúc tiếp tục được triển khai đúng, và tiếp tục điều chỉnh nếu có những phát sinh xảy ra.

2) Lãnh đạo

Sở hữu bức tranh lớn hơn là một khía cạnh của lãnh đạo kỹ thuật, nhưng có những thứ khác mà cần phải được thực hiện trong giai đoạn chuyển giao kiến trúc và phát triển phần mềm. Chúng bao gồm việc chịu trách nhiệm, hướng dẫn kỹ thuật, đưa ra quyết định về kỹ thuật. Có trách nhiệm với những quyết định bạn đã đưa ra.

Ở vai trò một kiến trúc sư phần mềm, bạn cần phải là một lãnh đạo kỹ thuật để đảm bảo mọi thứ đưa ra được chăm sóc và đội dự án đang đi đúng hướng trên cơ sở cải tiến liên tục. Các vị trí kiến trúc sư phần mềm vốn dĩ là lãnh đạo và trong khi điều này nghe có vẻ hiển nhiên, nhưng nhiều đội dự án không có được sự lãnh đạo kỹ thuật mà họ cần, với một số kiến trúc sư khác thì lập luận rằng nếu chuyển giao thành công thì công việc của họ đã kết thúc.

Điều này ít khi mắc phải bởi các kiến trúc sư phần mềm giàu kinh nghiệm.

3) Huấn luyện và cố vấn

Huấn luyện và cố vấn là một hoạt động bị bỏ qua trên nhiều dự án phát triển phần mềm, mà nhiều thành viên trong đội phát triển không nhận được sự hỗ trợ mà họ cần. Trong khi lãnh đạo kỹ thuật tập trung chỉ đạo dự án một cách tổng thể, nhưng nhiều lúc các thành viên trong đội dự án cần thêm sự giúp đỡ. Thêm vào đó, huấn luyện và tư vấn cung cấp cách để nâng cao kỹ năng mềm và giúp các kiến trúc sự phần mềm nâng cao sự nghiệp của mình. Đây là công việc cần được định nghĩa trong vai trò kiến trúc sư phần mềm, và rõ ràng là có một sự khác biệt lớn giữa huấn luyện team của bạn trong phạm vi kiến trúc và thiết kế so với việc giúp đội phát triển giải quyết các vấn đề được tạo ra trong giai đoạn triển khai mã nguồn.

> Đọc thêm: Lời khuyên của một lập trình viên sau tuổi 40

4) Đảm bảo chất lượng

Ngay cả với kiến ​​trúc tốt nhất trên thị trường thì việc chuyển giao kém cũng có thể là nguyên nhân gây ra thất bại cho dự án. Đảm bảo chất lượng là một phần rất quan trọng của vai trò kiến trúc sư phần mềm. Cho dù bản thiết kế của bạn đã được kiểm tra thử và đánh giá tốt, nhưng quá trình phát triển có những sự thay đổi nhất định liên quan đến thay đổi công nghệ, hoặc phụ thuộc vào chất lượng code. Do đó bạn cần đánh giá lại xem sản phẩm thực tế có tốt như lúc bạn thiết kế không?

Từ góc độ người phát triển phần mềm, có thể những tiêu chí bảo mật, các nguyên tắc thiết kế không được tuân thủ theo thiết kế, việc tích hợp liên tục gây ra những khó khăn nhất định trong việc đảm bảo chất lượng. Bạn cần tham gia cùng đội dự án để đảm bảo thiết kế được triển khai sẽ đạt chất lượng như lúc thiết kế.

5) Thiết kế, phát triển và thử nghiệm

Là một kiến trúc sư phần mềm, không nhất thiết bạn phải làm công việc thiết kế chi tiết tính năng, phát triển và kiểm tra thử ngày-qua-ngày. Công việc này không có nghĩa là bạn sẽ liên tục tham gia vào dự án. Có một số quan điểm khác cho rằng công việc triển khai code là một phần công việc của một kiến trúc sư phần mềm?

Phần lớn các kiến trúc sư có kinh nghiệm lập trình thì công việc lập trình giúp cho bạn nâng cao kỹ năng lập trình, việc kiểm tra thử được cập nhật liên tục đến thời điểm hiện tại. Ngoài ra các kiến trúc sư có thể trải nghiệm sự thất bại như những thành viên trong dự án, từ đó giúp bản thân bạn hiểu rõ hơn về cách thiết kế sao cho dễ dàng triển khai, thực tế hơn từ góc nhìn của các nhà phát triển và chính công việc này sẽ giúp các bản thiết kế trong tương lai trở nên tốt hơn.

Đa số các công ty có chính sách ngăn chặn kiến ​​trúc sư phần mềm tham gia vào các hoạt động thực hiện thiết kế chi tiết, và triển khai code bởi vì các kiến ​​trúc sư của họ là “quá đắt giá để thực hiện công việc có vẻ bình thường”. Rõ ràng đây là một thái độ sai … tại sao không để cho các kiến ​​trúc sư của bạn đặt tất cả những nỗ lực vào việc xác định các kiến ​​trúc và không để cho họ đóng góp vào thành công của mình?

Tất nhiên, có những tình huống không thực tế để được sự tham gia của kiến trúc sư ở mức độ coding. Ví dụ, một dự án lớn thường có một cái gì đó lớn hơn “big picture” để chăm sóc và khi bạn không có thời gian. Nhưng nói chung, một kiến ​​trúc sư coding hiệu quả hơn sẽ cảm thấy hạnh phúc hơn nhiều so với một kiến ​​trúc sư chỉ nhìn từ bên ngoài.

Bạn có phải là một kiến ​​trúc sư phần mềm?

Bất kể bạn đang xem sự phân định giữa phát triển phần mềm và kiến trúc phần mềm như là một sự hoành tráng hoặc một vực thẳm, thì các thành phần nổi bật được nêu ở trên sẽ tuỳ thuộc rất nhiều vào mức độ kinh nghiệm thiết kế kiến trúc của bạn đến đâu. Và sự cuốn hút của kiến trúc, sự đầu tư thời gian một cách nghiêm túc vào vai trò của mình.

Hầu hết các nhà phát triển phần mềm không thức dậy vào sáng thứ hai đầu tuần và tuyên bố mình là một kiến trúc sư phần mềm. Sự thành công của vai trò này đòi hỏi một trải nghiệm thực tế, sự trưởng thành trong một thời gian dài. Bạn có thể nghe thấy, một số nhà phát triển phần mềm đảm nhận một phần vai trò kiến trúc sư phần mềm mà không có một chức danh chính thống.

Có một sự khác biệt lớn giữa đóng góp vào kiến trúc của một phần mềm và chịu trách nhiệm xác định vai trò công việc cho chính bản thân bạn. Một công việc mà đòi hỏi bạn phải liên tục nâng cao các kỹ năng, cập nhật kiến thức, tích luỹ kinh nghiệm qua các dự án thực tế và học các kỹ năng khác nhau để tiếp tục thành công với vai trò kiến trúc sư phần mềm. Muốn vượt qua ranh giới giữa nhà phát triển phần mềm và kiến trúc sư phần mềm là tuỳ thuộc vào bản thân của bạn. Nhưng với một sự hiểu biết rộng, sở hữu kinh nghiệm thiết kế là khởi đầu cho một cuộc hành trình đầy thú vị.

Tuỳ Phong – APEX Global Corporation