Bài viết được dịch từ blog Coding Horror

Tôi mới tìm thấy đoạn trích này, và cũng giống như Wes, tôi nhớ là mình đã từng đọc nó, nhưng không thể nhớ chính xác đã đọc nó ở đâu:

Software Architect giỏi phải thực sự viết code nguyên mẫu cho sản phẩm, chứ không chỉ đơn giản là ngồi vẽ các UML diagram

Điều này xuất phát từ một bình luận trong một bài blog tôi đọc gần đây nhưng không thể nhớ rõ tác giả. Những lập trình viên giỏi nên đặt mông của họ xuống. Các lập trình viên thông thường sẽ không viết code cho tới khi họ giải quyết được những vấn đề trong việc thiết kế kiến trúc phần mềm, nhưng quãng thời gian đó có thể trở nên lãng phí chỉ bởi một chút thay đổi trong bản thiết kế. Ngược lại, những nhà phát triển phần mềm hiệu quả thường sẽ viết một số code, thậm chí mặc dù lúc đó bản thiết kế còn đang rất mơ hồ, bởi vì phát triển phần mềm là một quá trình lặp lại.

Tôi không thể đếm xuể bao nhiêu lần mình đã tiến hành thiết kế phần mềm hoàn chỉnh, sau đó trong quá trình thực thi đã phải ném nó đi hoặc thay thế hoàn toàn bản thiết kế của mình, bởi vì..

• Tôi quên mất một điều gì đó thực sự quan trọng
• Tôi tìm thấy một hướng tiếp cận khác dễ hơn
• Cái mà tôi đang làm thì không có ý nghĩa gì cả
• Tôi đang phát minh lại cái bánh xe, và nên tìm kiếm để download phần code người ta đã viết rồi cho nhanh
• Hey, tôi thậm chí không cần phải làm điều này trước tiên!

Trong thế giới thực, có một vòng lặp khép kín các phản hồi giữa lập trình và thiết kế kiến trúc. Khi bạn đang sử dụng Photoshop như là một công cụ thiết kế giao diện, thì mọi thứ đều có thể. Nhưng không may là Visual Studio sẽ không tha thứ cho những sai lầm.

Không phải là tôi đang đề xuất một phương pháp code mới nào đó. Tôi chỉ đơn thuần quan sát theo kinh nghiệm của bản thân mình và thấy rằng: việc lập trình mà không lên kế hoạch thì cũng kém hiệu quả như là có quá nhiều kế hoạch vậy. Phát triển phần mềm là một vấn đề hóc búa; bạn đừng bao giờ tạo ra các kế hoạch mà không có một vài dạng code nguyên mẫu (prototype) để đảm bảo rằng bạn đang tạo ra những quyết định đúng đắn. Nếu bạn lên kế hoạch quá xa so với code thực tế, thì tôi đảm bảo rằng bạn đang làm công việc mà sẽ vứt đi hoặc sẽ bị thay thế cho tới khi nó không còn nhận ra được nữa.

Hầu hết triệu chứng của việc lên kế hoạch quá nhiều là bạn lao vào ý tưởng rằng trở thành một Software Architect nghĩa là ngồi vẽ ra một đống các diagram UML và chuyển chúng tới một nhóm các nhà phát triển tại Bangalore, Ấn Độ. UML thì rất tuyệt nếu bạn không muốn làm bất kỳ công việc nào khác; bạn chỉ việc ngồi vẽ mấy bức hình và trông có vẻ như là công việc đã thực sự hoàn thành rồi vậy. Điều này không chỉ gần như là lười biếng, nó cũng là một công thức của thảm họa. Bạn không thể kiến trúc một ứng dụng thực tế chỉ trên một cái bảng trắng. Bạn phải prototype (tạo nguyên mẫu) nó trong code để thu thập dữ liệu về thực thi và thiết kế của lựa chọn mà bạn đã tạo ra. Mặt khác bạn thực sự không thể biết liệu mình có đang tạo ra một cái gì đó có ý nghĩa hay không– hoặc liệu nó thậm chí có khả thi hay không! Robert Glass cũng đã ghi chú trong cuốn sách Facts and Fallacies of Software Engineering (Những thực tế và ảo tưởng của kỹ nghệ phần mềm), trong thiết kế kiến trúc phần mềm thì việc phải đụng tay viết code là một yếu tố bắt buộc:

Rất khó để có thể đoán được, cấu trúc được, hoặc lên được quy trình thiết kế– theo như nghiên cứu của Curtis và Soloway (1987)– đó là một cái gì đó bừa bộn kiểu thử-và-sai. Và nên nhớ rằng, đây là kết quả của việc nghiên cứu trên rất nhiều các nhà thiết kế kiến trúc phần mềm đang làm việc. Người ta thấy có một số nhà thiết kế kiến trúc phần mềm hàng đầu sử dụng một quá trình thiết kế rất lộn xộn. Hướng tiếp cận thiết kế tồi tệ nhất và được dùng bởi hầu hết các nhà thiết kế phần mềm mới vào nghề là “phần-dễ-làm-trước”. Mặc dù rất dễ thiết kế theo hướng tiếp cận này, tất cả chúng thường dẫn đến kết quả là các giải pháp nhỏ không thể tích hợp vào một giải pháp tổng thể lớn hơn. Và cuối cùng những giải pháp nhỏ đó thường phải bỏ đi.

Rất dễ nhận thấy từ tất cả điều này đó là thiết kế kiến trúc phần mềm là công việc phức tạp và lặp lại. (Ý kiến này được nêu rõ trong cuốn sách Wiegers [1996].) Trong thực tế, nó có lẽ là hoạt động trí óc có chiều sâu nhất của quy trình phát triển phần mềm. Cũng rất dễ nhận thấy rằng giải pháp thiết kế ban đầu thường sẽ bị sai. Thế còn sự tối ưu thì sao? Vâng, chắc chắn là các giải pháp thiết kế ban đầu hiếm khi mà tối ưu được. Nhưng điều đó cũng làm nảy sinh một câu hỏi hết sức thú vị– liệu có một thứ gì đó gọi là giải pháp thiết kế tối ưu không?

Là các nhà phát triển phần mềm– và đặc biệt nếu chúng ta có mong muốn trở thành một người được gọi là “architect”– thì chúng ta nên tạo ra những quyết định dựa trên kinh nghiệm và dữ liệu. Và dù muốn hay không, thì điều đó nghĩa là chúng ta phải đặt mông xuống ghế và ngồi viết code.

Về tác giả bài viết:

Jeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack Exchange và Discourse.

Nguồn: vinacode.net