Lập Trình

Con đường trở thành Software Architect chẳng hề dễ dàng!

966

Bài viết được sự cho phép bởi tác giả Vũ Thành Nam

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!

Đầu tiên phải nói là với vị trí này thì mình nhận ra được rằng phong cách việc mỗi người mỗi vẻ, chẳng ai giống ai trong quá trình quan sát các anh chị đi trước, và cũng đã từng làm việc cùng với rất nhiều các anh SA. Giống như việc một kỹ sư thiết kế, không nói đến việc những tiêu chuẩn chung trong một bản vẽ thiết kế hay những quy định cần bắt buộc tuân thủ khi thiết kế thì thường họ sẽ có những cái nhìn khác nhau về những kiến trúc khác nhau hay những công nghệ áp dụng cho những kiến trúc đó.

Mình thấy đó là kiểu phong cách thiết kế của mỗi người cũng như việc mỗi người có cách đánh giá cái đẹp riêng vậy nên cũng không quá khắt khe trong việc ah cứ là SA thì phải có những yếu tố này có những điểm kia để có thể thoả mãn được vị trí trên. Tại sao mình nói vấn đề này lên đầu tiên vì mình biết sẽ có những quan điểm khác nhau về vị trí này nên mình muốn nhẫn mạnh một điều là mỗi kỹ sư thiết kế phần mềm có những phong cách khác nhau nên chúng ta hãy tôn trọng họ. Với mình thì điểm này cũng đáng để mình học hỏi và tổng hợp những thế mạnh của từng người để có thể mở mang được nhiều hơn.

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)

Dù sao thì nghệ luôn thay đổi, nên việc bạn có thể nắm chắc kỹ năng này có lẽ sẽ phải tốn rất nhiều thời gian và kinh nghiệm mới có thể hiểu và vận dụng được nó.

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.

Software Architecture – Tìm hiểu Layers Pattern

Top 5 câu hỏi phỏng vấn Software Architect hàng đầu

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 hướng dẫn

Trước đó có một anh lead mình hay tổ chức một buổi họp trước khi bắt đầu một spint với tên gọi “How to implements” chỉ nhằm mục đích hướng dẫn những thành viên trong team có thể thi công và hiểu đúng ý tưởng trong mẫu thiết kế của anh ý. Việc này giúp cho họ có thể nói ra được những ý đồ thiết kế mà những con chữ sơ đồ chưa diễn đạt hết, một phần là giúp cho các thành viên trong nhóm có thể hình dung được bức tranh tổng quát về toàn bộ những việc của từng người làm, trao đổi với nhau ra sao, phần của ai và ai sẽ phải hợp tác với nhau để có thể hoàn thành.

Đôi khi còn giải thích giúp thành viên rằng tại sao lại làm như vậy, giúp họ học hỏi và cũng giúp bản thân nhận được những feedback đóng góp ngược lại những thiếu sót trong quá trình thiết kế từ đó cập nhật bổ sung để có thể hoàn chỉnh hơn. Mình nghĩ rằng đây là một kỹ năng nên có và khiến người khác có thể thích làm việc với bạn hơn là việc chỉ thiết kế và đem con bỏ chợ không cần biết ai hiểu đúng hiểu sai gì (cái này mình cũng đã từng gặp khi làm việc).

Tham khảo việc làm Solution Architect hấp dẫn trên TopDev

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 sai 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.

Bài viết gốc được đăng tải tại ntechdevelopers.com

Xem thêm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev