- vừa được xem lúc

[Software Architect][Ra quyết định] Những kĩ năng cần học (Bài viết #2)

0 0 16

Người đăng: Nguyễn Trí Tài

Theo Viblo Asia

Nội dung bài viết được dịch từ https://roadmap.sh/, ở khía cạnh của một người đang làm Frontend Developer, đang học để trở thành Software Architect, mỗi vài viết là 1 kĩ năng. Vào vấn đề, ...

Để trở thành một software architect, bạn cần có các kĩ năng sau:

  • Thiết kế và Kiến trúc
  • Ra quyết định
  • Đơn giản hoá vấn đề
  • Biết code
  • Viết tài liệu
  • Giao tiếp
  • Ước lượng và đánh giá
  • Cân bằng
  • Tư vấn và hướng dẫn
  • Kĩ năng marketing

Sau đây là kĩ năng số 2, Ra quyết định.

Ra quyết định

Biết điều gì là quan trọng:

Đừng lãng phí thời gian với những quyết định hoặc hoạt động không quan trọng. Học hỏi để biết điều gì là quan trọng. Theo kiến thức của tôi, không có cuốn sách nào chứa thông tin này, nó hoàn toàn dựa trên kinh nghiệm. Hai đặc điểm mà tôi thường xem xét khi đánh giá một việc có quan trọng hay không:

  • Tính toàn vẹn khái niệm: Nếu bạn quyết định làm theo một cách, hãy kiên trì với nó, ngay cả khi có cách làm tốt hơn. Thường thì điều này dẫn đến một khái niệm tổng thể rõ ràng hơn, dễ hiểu hơn và dễ bảo trì hơn. Đừng đánh đổi sự tiện lợi với sự toàn vẹn.
  • Tính thống nhất: Ví dụ, nếu bạn định nghĩa và áp dụng quy tắc đặt tên, điều quan trọng không phải là chữ hoa hay chữ thường, mà là phải áp dụng nhất quán ở mọi nơi.

Ưu tiên:

Một số quyết định rất quan trọng. Nếu chúng không được đưa ra sớm, các giải pháp tạm thời sẽ được hình thành, thường khó có thể loại bỏ sau này và là một cơn ác mộng cho việc bảo trì, hoặc tồi tệ hơn, các nhà phát triển phải ngừng làm việc cho đến khi có quyết định được đưa ra. Trong những tình huống như vậy, đôi khi chọn một quyết định "xấu" sẽ tốt hơn thay vì không có quyết định. Nhưng trước khi tình huống đó xảy ra, hãy cân nhắc ưu tiên các quyết định sắp tới. Có nhiều cách để làm điều này. Tôi đề nghị bạn xem xét mô hình Weighted Shortest Job First (WSJF), được sử dụng rộng rãi trong phát triển phần mềm linh hoạt. Đặc biệt, các biện pháp về tính kịp thời và giảm rủi ro là quan trọng để ước tính mức độ ưu tiên của các quyết định kiến trúc.

Biết rõ năng lực của mình:

Đừng quyết định những việc không thuộc về năng lực của bạn. Điều này rất quan trọng vì nó có thể làm hại đến vị trí của bạn (dễ bị đuổi việc á bro) nếu không được xem xét. Để tránh điều này, hãy làm rõ với đồng nghiệp về trách nhiệm của bạn và những gì thuộc về vai trò của bạn. Nếu có nhiều hơn một kiến trúc sư, thì bạn nên tôn trọng mức độ kiến trúc mà bạn đang tham gia. Với tư cách là một kiến trúc sư cấp thấp, bạn nên đưa ra đề xuất cho kiến trúc cấp cao hơn thay vì quyết định. Hơn nữa, tôi khuyên bạn nên luôn tham khảo ý kiến từ một đồng nghiệp trước khi đưa ra quyết định quan trọng.

Đánh giá nhiều lựa chọn:

Luôn trình bày nhiều hơn một lựa chọn khi đưa ra quyết định. Trong hầu hết các trường hợp tôi tham gia, luôn có nhiều hơn một lựa chọn tốt. Nếu chỉ-có-một-lựa-chọn thì có thể bạn đang:

  • Thứ nhất, có vẻ như bạn đã không làm công việc của mình đúng cách
  • Thứ hai, nó cản trở việc đưa ra quyết định đúng đắn

Các lựa chọn có thể được so sánh dựa trên thực tế bằng cách đo lường, định lượng thay vì cảm giác. Điều này thường dẫn đến các quyết định tốt hơn và bền vững hơn. Hơn nữa, điều này giúp dễ dàng thuyết phục các bên liên quan khác nhau. Ngoài ra, nếu bạn không đánh giá các lựa chọn một cách đúng đắn, bạn có thể bỏ lỡ các lập luận khi thảo luận.

Bình luận

Bài viết tương tự

- vừa được xem lúc

Nguyên tắc thứ ba trong SOLID: Liskov Substitution Principle

Năm 1988, Barbara Liskov đã phát biểu những điều sau như một cách để định nghĩa các subtype:. .

0 0 35

- vừa được xem lúc

Nguyên tắc thứ hai trong SOLID: Open-Closed Principle

Đây là bài tiếp theo của Nguyên tắc thứ nhất trong SOLID: Single Responsibility Principle. . Open-Closed Principle (OCP) được đặt ra năm 1988 bởi Bertrand Meyer. Nguyên tắc này nói rằng:.

0 0 47

- vừa được xem lúc

Nguyên tắc thứ nhất trong SOLID: Single Responsibility Principle

Trước tiên cho ai chưa biết SOLID là gì thì đây là bộ gồm 5 nguyên tắc trong thiết kế nói chung (không chỉ trong thiết kế phần mềm đâu nhé) với mỗi chữ cái đầu trong từ S-O-L-I-D thể hiện một nguyên tắc. Không sai, đúng là có một nguyên tắc như vậy.

0 0 31

- vừa được xem lúc

Nguyên tắc thứ tư trong SOLID: Interface Segregation Principle

Câu chuyện về cái tên Interfact Segregation Principle (ISP) có thể kể bắt đầu từ cái đồ thị dưới đây:. .

0 0 36

- vừa được xem lúc

Nguyên tắc thứ năm trong SOLID: The Dependency Inversion Principle

The Dependency Inversion Principle (DIP) nói rằng những hệ thống có tính mềm dẻo là khi source code dependency của nó chỉ trỏ tới các thành phần trừu tượng (abstraction), chứ không phải là các thành p

0 0 92

- vừa được xem lúc

Hexagonal Architecture là gì và ứng dụng của nó

I. Tổng quan về kiến trúc phần mềm. . Application without architecture (nguồn: Internet).

0 0 42