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ố 3, Đơn giản hoá vấn đề.

Đơn giản hoá vấn đề

Hãy nhớ đến nguyên tắc giải quyết vấn đề của Occam’s Razor, nguyên tắc này khuyên chúng ta nên ưu tiên sự đơn giản. Tôi hiểu nguyên tắc này như sau: Nếu bạn có quá nhiều giả định/giả sử/giả thuyết về vấn đề cần giải quyết, giải pháp của bạn có thể sẽ sai hoặc dẫn đến một giải pháp phức tạp không cần thiết. Các giả định nên được giảm bớt (đơn giản hóa) để đưa ra một giải pháp tốt.

Lắc giải pháp:

Để đơn giản hóa các giải pháp, việc "lắc" giải pháp và xem xét chúng từ các góc độ khác nhau thường rất hữu ích. Giống như bạn muốn nghiên cứu một vật, hãy cầm nó lên, và lắc thử nó, xem cách nó phản ứng như thế nào. Hoặc khi cái cây của bạn quá nhiều lá, để thấy được trái, bạn cần lắc cái cây, những lá già sẽ rụng xuống. Hãy cố gắng hình thành giải pháp bằng cách suy nghĩ từ trên xuống và ngược lại từ dưới lên. Nếu bạn có một dòng dữ liệu hoặc quy trình, hãy suy nghĩ từ trái sang phải và ngược lại từ phải sang trái. Đặt các câu hỏi như: "Điều gì sẽ xảy ra với giải pháp của bạn trong một thế giới hoàn hảo?" Hoặc: "Công ty / người X sẽ làm gì?" (Trong đó X có thể không phải là đối thủ cạnh tranh của bạn, mà là một trong những công ty GAFA (Google, Apple, Facebook, & Amazon)). Cả hai câu hỏi này đều buộc bạn phải giảm bớt giả định như Occam’s Razor đã đề xuất.

Lùi lại một bước:

Sau những cuộc thảo luận dài và căng thẳng, kết quả thường là những bản phác thảo phức tạp. Bạn không bao giờ nên coi đây là kết quả cuối cùng. Hãy lùi lại một bước: Nhìn lại bức tranh lớn một lần nữa (ở cấp độ trừu tượng). Nó có còn hợp lý không? Sau đó, xem xét lại nó ở cấp độ trừu tượng và tái cấu trúc. Đôi khi việc dừng cuộc thảo luận và tiếp tục vào ngày hôm sau sẽ có ích. Ít nhất là bộ não của bạn cần thời gian để xử lý và đưa ra những giải pháp tốt hơn, tinh tế hơn và đơn giản hơn. Có thể là nên đi ăn một món gì đó thiệt ngon!!!

Chia để trị:

Đơn giản hóa vấn đề bằng cách chia nó thành những phần nhỏ hơn. Sau đó giải quyết chúng một cách độc lập. Sau đó, xác nhận xem các phần nhỏ có phù hợp với nhau không. Hãy lùi lại một bước để nhìn vào bức tranh tổng thể.

Tái cấu trúc không phải là xấu:

Hoàn toàn ổn để bắt đầu với một giải pháp phức tạp hơn nếu không tìm thấy ý tưởng tốt hơn. Nếu giải pháp gặp rắc rối, bạn có thể sau này suy nghĩ lại về giải pháp và áp dụng những gì bạn đã học được. Tái cấu trúc không phải là xấu. Nhưng trước khi bạn bắt đầu tái cấu trúc, hãy nhớ rằng bạn phải:

• (1) có đủ các bài kiểm tra tự động để đảm bảo chức năng thích hợp của hệ thống
• (2) sự đồng thuận từ các bên liên quan.

Để tìm hiểu thêm về tái cấu trúc, tôi gợi ý bạn đọc cuốn “Refactoring. Improving the Design of Existing Code” của Martin Fowler.