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

[Software Architect][Biết code] Những kĩ năng cần học (Bài viết #4)

0 0 11

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ố 4, Biết code.

Biết code

Ngay cả khi là một Kiến trúc sư Doanh nghiệp, mức độ trừu tượng nhất của kiến trúc, bạn vẫn nên biết những gì các nhà phát triển làm hàng ngày. Nếu bạn không hiểu cách thực hiện điều này, bạn có thể đối mặt với hai vấn đề lớn:

  • Các nhà phát triển sẽ không chấp nhận những điều bạn nói.
  • Bạn không hiểu được những thách thức và nhu cầu của các nhà phát triển.

Có một dự án phụ:

Mục đích của việc này là để thử nghiệm các công nghệ và công cụ mới để tìm hiểu cách phát triển được thực hiện ngày nay và trong tương lai. Kinh nghiệm là sự kết hợp của quan sát, cảm xúc và giả thuyết (“Quản lý Kinh nghiệm và Kiến thức trong Kỹ thuật Phần mềm” của Kurt Schneider). Nếu chỉ đọc về hướng dẫn hay một số ưu và nhược điểm của chúng, đó chỉ là “kiến thức sách vở”. Chỉ khi bạn tự mình thử nghiệm, bạn mới có thể trải nghiệm cảm xúc và xây dựng các giả thuyết về lý do tại sao điều gì đó tốt hoặc xấu. Và càng làm việc lâu với một công nghệ, giả thuyết của bạn càng trở nên tốt hơn. Điều này sẽ giúp bạn đưa ra quyết định tốt hơn trong công việc hàng ngày. Khi tôi bắt đầu lập trình, tôi không có tính năng tự động hoàn thành mã và chỉ có một số thư viện tiện ích để tăng tốc quá trình phát triển. Rõ ràng, với nền tảng này, tôi sẽ đưa ra những quyết định sai lầm. Ngày nay, chúng ta có hàng tấn ngôn ngữ lập trình, framework, công cụ, quy trình và thực tiễn. Chỉ khi bạn có một số kinh nghiệm và cái nhìn tổng quát về các xu hướng chính, bạn mới có thể tham gia vào cuộc trò chuyện và điều hướng phát triển theo hướng đúng.

Tìm những điều đúng đắn để thử nghiệm:

Bạn không thể thử nghiệm mọi thứ. Điều đó đơn giản là không thể. Bạn cần một cách tiếp cận có cấu trúc hơn. Một nguồn tôi mới phát hiện gần đây là Radar Công nghệ của ThoughtWorks. Họ phân loại công nghệ, công cụ, nền tảng, ngôn ngữ và khung làm việc vào bốn danh mục:

  • Chấp nhận: Cảm giác mạnh mẽ rằng đã sẵn sàng cho việc sử dụng doanh nghiệp.
  • Thử nghiệm: Doanh nghiệp nên thử trong một dự án có thể xử lý rủi ro.
  • Đánh giá: Khám phá cách nó ảnh hưởng đến doanh nghiệp của bạn.
  • Tạm dừng: Tiến hành với sự thận trọng.

Với sự phân loại này, việc có được cái nhìn tổng quan về những điều mới mẻ và mức độ sẵn sàng của chúng để đánh giá tốt hơn xu hướng nào cần khám phá tiếp theo trở nên dễ dàng hơ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