Kiến trúc tiến hóa và thiết kế nổi dần: Nghiên cứu điều tra kiến trúc và thiết kế Khám phá kiến trúc và thiết kế dễ bảo trì hơn Neal Ford, Kiến trúc phần mềm, ThoughtWorks docx

Kiến trúc tiến hóa và thiết kế nổi dần: Nghiên cứu điều tra kiến trúc và thiết kế Khám phá kiến trúc và thiết kế dễ bảo trì hơn Neal Ford, Kiến trúc phần mềm, ThoughtWorks Tóm tắt: Thiết kế và kiến trúc phần mềm phát sinh ra nhiều sức nóng tranh luận nhưng không phát sinh nhiều ánh sáng. Để bắt đầu một cuộc trò chuyện mới về những cách nghĩ khác đi về chúng, bài viết này khởi đầu loạt bài Kiến trúc tiến hóa và thiết kế nổi dần. Kiến trúc tiến hóa và thiết kế nổi dần (Evolutionary architecture and emergent design) là các kỹ thuật khéo léo để lùi các quyết định quan trọng cho đến thời điểm hợp lý cuối cùng. Trong bài giới thiệu này, tác giả Neal Ford của loạt bài viết sẽ định nghĩa kiến trúc và thiết kế rồi sau đó xác định các mối quan tâm bao quát sẽ nảy sinh trong suốt cả loạt bài viết này. Kiến trúc và thiết kế phần mềm đã chống lại mọi định nghĩa vững chắc trong một thời gian dài do việc phát triển phần mềm, như một lĩnh vực chuyên môn, vẫn còn chưa được nắm bắt đầy đủ tất cả những rắc rối và các mối liên quan của chúng. Nhưng để tạo ra một cuộc đàm luận đúng mức về những chủ đề này, bạn phải bắt đầu từ đâu đó. Loạt bài viết này quan tâm đến kiến trúc tiến hóa và thiết kế nổi dần, do đó cần mở đầu cho loạt bài viết này bằng một loạt các định nghĩa, xem xét cân nhắc và thiết lập nền tảng khác. Về loạt bài viết này Loạt bài này nhằm mục đích cung cấp một cách nhìn mới mẻ về các khái niệm thường được bàn luận nhưng khó nắm bắt ý nghĩa, đó là thiết kế và kiến trúc phần mềm. Thông qua các ví dụ cụ thể, Neal Ford sẽ mang lại cho bạn một nền móng vững chắc về các biện pháp thực hành nhanh trong kiến trúc tiến hóa và thiết kế nổi dần. Bằng cách lùi các quyết định kiến trúc và thiết kế quan trọng đến thời điểm hợp lý cuối cùng, bạn có thể ngăn ngừa không để những phức tạp không cần thiết hủy hoại các dự án phần mềm của bạn. Định nghĩa kiến trúc Kiến trúc trong phần mềm là một trong những khái niệm được nói đến nhiều nhất nhưng lại được hiểu ít nhất mà các nhà phát triển phải đánh vật với nó. Tại các hội nghị, các cuộc thảo luận và tụ họp của những người cùng chí hướng về kiến trúc chật cả tòa nhà, nhưng chúng ta vẫn chỉ có các định nghĩa mơ hồ về nó. Khi chúng ta thảo luận về kiến trúc, chúng ta thực sự đang nói về một số mối quan tâm khác nhau nhưng có liên quan đến nhau, thường rơi vào những phạm trù rộng rãi của kiến trúc ứng dụng và kiến trúc doanh nghiệp. Kiến trúc ứng dụng Kiến trúc ứng dụng mô tả các mảnh ở mức chi tiết thô làm thành một ứng dụng. Ví dụ như trong thế giới Java, kiến trúc ứng dụng mô tả hai điều: sự kết hợp của các khung công tác được sử dụng để xây dựng một ứng dụng cụ thể — mà tôi gọi là kiến trúc mức khung công tác — và sự phân tách các mối quan tâm logic truyền thống hơn mà tôi luôn gắn cho biệt danh là kiến trúc ứng dụng. Việc tách kiến trúc khung công tác như một sự phân biệt là có ý nghĩa vì hầu hết các nhà thực hành ngôn ngữ hướng đối tượng đã phát hiện ra rằng các lớp riêng lẻ không làm việc tốt như là một cơ chế tái sử dụng. (Lần cuối cùng bạn đã tải về chỉ một lớp đơn từ Internet để sử dụng trong một dự án là khi nào?) Đơn vị tái sử dụng trong các ngôn ngữ hướng đối tượng hiện đại là một thư viện hay một khung công tác. Khi bạn bắt đầu một dự án mới trong các ngôn ngữ giầu khung công tác như Java, một trong các mối quan tâm về kiến trúc đầu tiên là kiến trúc mức khung công tác của ứng dụng. Phong cách tái sử dụng kiểu này thắng thế hơn hẳn trong thế giới Java đến mức mà tôi đã bắt đầu nói rằng chúng ta sẽ nên thôi không gọi lập trình Java là một ngôn ngữ hướng đối tượng mà chỉ nên gọi nó là một ngôn ngữ hướng khung công tác. Theo nhiều cách, kiến trúc mức khung công tác biểu diễn một kiến trúc vật lý được mô tả bởi các khối xây dựng nền tảng cụ thể. Một khía cạnh thú vị khác của kiến trúc ứng dụng là mô tả cách làm thế nào để các mảnh lô gic của ứng dụng ăn khớp với nhau. Đây là lĩnh vực của các mẫu thiết kế và các mô tả cấu trúc khác và vì vậy có xu hướng trở nên vừa trừu tượng hơn vừa mang tính logic hơn là kiến trúc vật lý. Ví dụ, bạn có thể nói rằng một ứng dụng web trung thành với mẫu Mô hình -Khung nhìn -Trình bày mà không cần chỉ rõ bạn sử dụng khung công tác nào để thực hiện được sự sắp xếp lô gic đó. Sự sắp xếp lô gic này là cái có vẻ thích hợp nhất để trang trí các bảng trắng của vùng làm việc của bạn khi bắt đầu làm việc trên các phần mới của ứng dụng. Kiến trúc doanh nghiệp Kiến trúc doanh nghiệp bản thân nó quan tâm đến cách làm thế nào để doanh nghiệp như là một tổng thể (thường có nghĩa là các ứng dụng đang chạy bên trong một tổ chức lớn) sử dụng các ứng dụng. Một phép ẩn dụ hữu ích thường dùng về mối quan hệ giữa kiến trúc doanh nghiệp và kiến trúc ứng dụng là ví kiến trúc doanh nghiệp như việc quy hoạch thành phố và kiến trúc ứng dụng là xây dựng các công trình kiến trúc. Các nhà quy hoạch thành phố phải suy nghĩ về việc cấp nước, điện, thoát nước thải và các dịch vụ khác để cho phép thành phố hoạt động. Bạn không thể có một tòa nhà tiêu thụ nhiều nước hơn lượng nước được chia sẻ cho nó. Kiến trúc doanh nghiệp suy nghĩ về các vấn đề giống như thế nhưng cho các ứng dụng: bạn không thể cho phép một ứng dụng tiêu thụ tất cả băng thông của mạng thông tin và nếu các dịch vụ cơ sở hạ tầng bị sụp đổ, nước thải (ảo) lại dâng lên. Kiến trúc doanh nghiệp đã được chú ý rất nhiều trong vài năm gần đây nhờ có kiến trúc hướng dịch vụ (SOA). SOA bản thân nó đã là một chủ đề lớn, do đó các bài viết sắp tới của loạt bài này sẽ đề cập đến SOA như là một trường hợp riêng. Nó cũng có những khía cạnh đáng quan tâm riêng bởi vì nó làm mờ đi đường biên giới giữa kiến trúc doanh nghiệp và kiến trúc ứng dụng khi nó áp đặt các đặc trưng kỹ thuật của cấu trúc ứng dụng. Các đoạn trên đây đưa ra những định nghĩa hời hợt bên ngoài về các khái niệm quan trọng này, nhưng chúng sẽ là bệ phóng xuất phát cho các định nghĩa khác đáng chú ý hơn, nhiều sắc thái hơn về kiến trúc bao gồm cả một vài định nghĩa thu hoạch được từ những định nghĩa khác. Các định nghĩa hiện có Nhiều người thông minh đã thử định nghĩa kiến trúc phần mềm, do đó tôi sẽ để họ đưa ra một vài điều đáng suy nghĩ. Trong bài tham luận kinh điển của mình "Ai cần một kiến trúc sư?" (xem Tài nguyên), Martin Fowler bàn luận về một số định nghĩa. Ông trích dẫn định nghĩa đầu tiên từ một bài đăng tải trên danh sách thư chung Lập trình đỉnh cao (Extreme Programming mailing list): " RUP, cố thoát khỏi định nghĩa của IEEE, định nghĩa kiến trúc như là 'quan niệm mức cao nhất về một hệ thống trong môi trường của nó. Kiến trúc của một hệ thống phần mềm (tại một thời điểm đã cho) là tổ chức hoặc cấu trúc của các thành phần quan trọng của nó, tương tác với nhau qua các giao diện; các thành phần đó đến lượt mình lại bao gồm những thành phần và giao diện nhỏ hơn.'" Định nghĩa này vừa vặn nằm trong lĩnh vực của kiến trúc ứng dụng như tôi đã mô tả ở trên. Còn hơi mơ hồ, nhưng nó nắm bắt được bản chất của trọng trách kiến trúc: quan niệm mức cao nhất. Fowler sau đó trích dẫn Ralph Johnson, người đã tranh luận về định nghĩa trên đây khi trả lời trên danh sách thư chung: "Định nghĩa tốt hơn sẽ là: 'Trong hầu hết các dự án phần mềm thành công, các nhà phát triển lão luyện đang làm việc trên dự án đó chia sẻ một hiểu biết chung về thiết kế của hệ thống được thiết kế. Sự hiểu biết chung này được gọi là "kiến trúc". Sự hiểu biết này bao gồm cách thức hệ thống được chia ra thành các thành phần như thế nào và các thành phần ấy tương tác với nhau thông qua giao diện như thế nào.'" Johnson nhấn mạnh một điểm tuyệt vời rằng việc phát triển phần mềm dựa trên trao đổi thông tin nhiều hơn là dựa trên công nghệ và kiến trúc thực sự là hiện thân của kiến thức chung về hệ thống, chứ không phải một cái gì đặc biệt về ngôn ngữ, về khung công tác hay những phù du công nghệ khác. Trong bài báo vừa nói đến ở trên, chính Fowler cung cấp một trong những định nghĩa về kiến trúc mà tôi yêu thích: "Kiến trúc là về một thứ quan trọng. Dù đó là bất cứ thứ gì". Điều này đủ mơ hồ nhưng đồng thời cũng đủ diễn tả. Nhiều tranh luận về kiến trúc và thiết kế nhằm phân giải sự hiểu lầm điều gì là quan trọng. Cái quan trọng đối với các nhà phân tích nghiệp vụ khác cái quan trọng đối với kiến trúc sư doanh nghiệp. Định nghĩa này gói ghém rằng bạn phải định nghĩa bằng ngôn từ của bạn trong môi trường của bạn trước khi bạn có thể cố gắng định nghĩa các thứ khác. Định nghĩa của Fowler cũng làm nổi bật khía cạnh quan trọng khác của việc định nghĩa một thứ nhiều sắc thái như kiến trúc. "Cái quan trọng", không chỉ khác nhau giữa các cá nhân và các nhóm; những sự khác biệt ấy trong thực tế có thể loại trừ lẫn nhau. Ví dụ, hầu như tất cả các SOA phải thực hiện một sự thỏa hiệp giữa tính linh hoạt và tốc độ. Hệ thống khách - chủ xưa cũ mà bạn hiện đang sử dụng hầu như chắc chắn sẽ nhanh hơn các phiên bản thay thế nó mà dựa trên Web, dựa trên máy portlet hay dựa vào dịch vụ. Trừ khi ứng dụng mới được các nhà phát triển rất kém viết ra, các tầng bổ sung thêm cung cấp tính linh hoạt cũng có nghĩa là thời gian đáp ứng cho những người dùng tăng lên, làm cho nó chậm hơn với người dùng. Có lẽ kiến trúc sư là người sẽ phải nói với những người sử dụng, "Ôi, nhân đây tôi muốn nói rằng, cái SOA mới mà chúng tôi vừa cài đặt sẽ làm việc tốt hơn cho chúng tôi, nhưng bây giờ thì công việc của bạn sẽ mất nhiều thì giờ hơn đấy. Xin lỗi nhé". Có lẽ đó là lý do tại sao các kiến trúc sư được trả tiền nhiều hơn các nhà phát triển. Còn lại định nghĩa kiến trúc yêu thích của tôi như sau: "Điều khó có thể thay đổi sau này". Định nghĩa này phù hợp nhất với ý tưởng về một kiến trúc tiến hóa. Một trong những ý tưởng cốt lõi đằng sau kiến trúc tiến hóa là trì hoãn quyết định, càng chậm càng tốt, nó cho phép bạn chọn những cách thay thế mà các trải nghiệm vừa mới đây cho thấy là tốt hơn. Nhiều khối nền tảng của phong cách kiến trúc này xuất hiện trong suốt loạt bài này và là động cơ thúc đẩy tạo ra loạt bài viết này. Trước khi rời cuộc thảo luận về kiến trúc, sẽ là tắc trách nếu tôi không bàn về chức danh "kiến trúc sư". Nó chọc tức các phòng nhân sự vì lẽ đã là một ngành công nghiệp mà chúng ta lại có những chức danh công việc định nghĩa mơ hồ đến như thế. Nhiều tổ chức muốn thăng cấp các nhà phát triển tốt nhất của họ — những người đưa ra các quyết định quan trọng về những điều khó có thể thay đổi sau này — nhưng không có thuật ngữ công nghiệp nào phù hợp hơn ngoài "kiến trúc sư". Cũng không có bản mô tả công việc chung nào, do đó mỗi công ty tự định nghĩa vai trò này có nghĩa là gì. Một số kiến trúc sư giống với ông Kiến trúc sư ở phần cuối của bộ phim Ma trận thứ hai (mà Fowler xếp loại là Architectus Reloadus). Các kiến trúc sư này đã viết những dòng mã cuối cùng khoảng một thập kỷ trước và bây giờ họ đang thực hiện các quyết định quan trọng đối với công ty của bạn. Công cụ phát triển phần mềm duy nhất mà họ sử dụng là Visio. Một vai trò khác của kiến trúc sư là cái mà Fowler gọi là Architectus Oryzus ((do David Rice, một trong những đồng nghiệp của tôi đặt tên). Các kiến trúc sư này đã tích cực viết mã cho dự án, sát cánh với các nhà phát triển khác trong những phần việc khó nhất. Trách nhiệm của họ cũng bao gồm cả việc tương tác với các bên liên quan khác của dự án để đảm bảo rằng tất cả mọi người nói cùng một ngôn ngữ, sử dụng cùng các định nghĩa và hiểu rõ các phần của hệ thống mà họ cần phải hiểu được. Rõ ràng, vai trò tích cực như thế này là trọng yếu để thực hiện các mục tiêu của kiến trúc tiến hóa và vì vậy sẽ xuất hiện lặp đi lặp lại trong loạt bài này. Định nghĩa thiết kế Hầu hết các nhà phát triển đã có một ý niệm khá đúng về thiết kế, vì vậy tôi sẽ không dành nhiều thời gian định nghĩa nó. Nó là các đai ốc và các bu lông trong việc ghép các mảnh phần mềm lại với nhau như thế nào. Nó bao trùm toàn bộ các lĩnh vực đã được xử lý tốt như các mẫu thiết kế, tái cấu trúc, các khung công tác và các mối quan tâm hàng ngày của nhà phát triển. Đại khái, thiết kế rơi vào một phạm vi giữa BDUF (Big Design Up Front - thiết kế lớn làm trước) và Cowboy Hacking (việc cưỡi ngựa của anh cao bồi- với ý là thiết kế tự do), như được hiển thị trong Hình 1: Hình 1. Phổ các kiểu thiết kế Phần bên trái của dải phổ trong hình 1 ám chỉ rằng bạn có thể dự đoán trước tất cả hàng trăm và hàng ngàn mối quan tâm sẽ bật lên khi bạn phát triển phần mềm và cố gắng để hạn chế câu trả lời của bạn dành cho chúng. Bạn sẽ đọc nhiều hơn về vấn đề này trong các bài viết tiếp theo. Bởi vì tôi không dành nhiều thời gian định nghĩa thiết kế không có nghĩa là tôi sẽ không dành nhiều thời gian nói chuyện về nó. Phần chính của loạt bài này trình bày các khía cạnh khác nhau về cách làm thế nào để bạn có thể cho phép thiết kế nổi dần lên khi bạn phát triển chứ không phải là khắc nó vào đá trước khi bạn viết dòng mã đầu tiên của mình. Các mối quan tâm về kiến trúc và thiết kế Tiến hóa so với nổi dần Lưu ý rằng loạt bài này được đặt tên là Kiến trúctiến hóa và thiết kế nổi dần. Tại sao có sự phân biệt giữa tiến hóa và nổi dần? Kiến trúc nổi dần, như một trong những đồng nghiệp của tôi nói với tôi, không phải là một ý tưởng nóng hổi lắm. Nếu bạn chấp nhận tiền đề rằng kiến trúc là về những gì đó khó thay đổi sau này, thì thật là khó cho phép một kiến trúc nổi dần lên. Kiến trúc quan tâm đến các yếu tố cơ sở hạ tầng phải tồn tại trước khi bạn có thể bắt đầu ứng dụng. Tuy nhiên, chỉ vì bạn không thể cho phép kiến trúc nổi dần lên không có nghĩa là nó không thể tiến triển. Nếu bạn đã tạo ra một kiến trúc linh hoạt và đã chú ý không để tạo ra các quyết định không thể thay đổi được, thì bạn có thể cho phép nó tiến triển theo thời gian khi các mối quan tâm mới lại xuất hiện. Bây giờ khi đã có các định nghĩa để làm việc về kiến trúc và thiết kế trong tay, tôi muốn xoáy sâu vào toàn bộ các lĩnh vực quan tâm. Tất cả những chủ đề này giao cắt với cả kiến trúc lẫn thiết kế ở cấp độ cơ bản, do đó việc trình bày trước cho phép tôi nhắc lại chúng về sau trong loạt bài này. Trước tiên, tôi bàn luận về nợ kỹ thuật (technical debt), sau đó là về độ phức tạp, và cuối cùng là về tính bao quát tràn lan. Món nợ chính và lãi phát sinh Mỗi nhà phát triển đều ý thức được khái niệm nợ kỹ thuật, khi bạn thỏa hiệp trong thiết kế của bạn vì một số sức ép bên ngoài, ví dụ như sức ép về lịch trình công việc. Nợ kỹ thuật giống như nợ thẻ tín dụng: bạn không có đủ tiền vào lúc này, vì vậy bạn vay nợ rồi trả lại trong tương lai. Tương tự, dự án của bạn hiện không có đủ thời gian để làm một cái gì đó đúng cách, vì vậy bạn phải dùng tạm một giải pháp vừa kịp có và hy vọng lúc nào đó trong tương lai sẽ quay lại và làm mới lại nó. Thật không may, rất nhiều nhà quản lý có vẻ không hiểu về nợ kỹ thuật, phản đối việc quay về xem xét lại công việc trong quá khứ. Việc xây dựng phần mềm không giống như việc đào mương. Nếu bạn thỏa hiệp khi bạn đào mương, bạn chỉ bị chiều rộng không đồng đều hoặc chiều sâu không bằng phẳng. Mương có sai sót ngày hôm nay không ngăn cản bạn đào một con mương không sai sót ngày mai. Nhưng phần mềm mà bạn xây dựng hôm nay là cơ sở cho những gì bạn sẽ xây dựng vào ngày mai. Các thỏa hiệp phải làm bây giờ vì lý do thực dụng sẽ gây ra entropi tích tụ dần trong phần mềm của bạn. Trong cuốn Nhà lập trình thực dụng (Pragmatic Programmer), Andy Hunt và Dave Thomas nói về entropi trong phần mềm và tại sao nó gây hậu quả thiệt hại đến như vậy (xem Tài nguyên). Entropi là một độ đo mức phức tạp và nếu bạn tăng thêm độ phức tạp hiện nay vì một giải pháp tạm vừa kịp có cho một vấn đề, bạn phải trả một giá nào đó cho điều này trong vòng đời còn lại của dự án. Giả dụ rằng bạn muốn thêm các tính năng mới cho một dự án dài hạn hiện có. Những tính năng mới này có một độ phức tạp vốn có nhất định kèm với chúng. Tuy nhiên, nếu bạn đã có nợ kỹ thuật rồi, bạn phải vòng tránh tất cả những phần đã thỏa hiệp trong hệ thống đó để thêm các tính năng mới. Do đó, chi phí bổ sung thêm phản ánh phần ẩn về tài chính. Hình 2 cho thấy sự khác biệt giữa các nỗ lực cần thiết để thêm một tính năng mới vào một hệ thống được thiết kế sạch (ví dụ, một hê thống có ít hoặc không có nợ kỹ thuật), so với một hệ thống điển hình có nhiều nợ kỹ thuật. Hình 2. Nợ kỹ thuật và lãi phát sinh Bạn có thể suy nghĩ về độ phức tạp vốn có như là món nợ chính và các nỗ lực phát sinh thêm gây ra bởi thủ thuật làm tắt thích hợp nêu trên như là lãi phát sinh. Chính bản thân độ phức tạp là một chủ đề thú vị. Độ phức tạp bản chất so với độ phức tạp ngẫu nhiên Các vấn đề mà chúng ta giải quyết trong phần mềm có một độ phức tạp vốn có, mà tôi gọi độ phức tạp bản chất. Độ phức tạp phát sinh từ các thỏa hiệp mà chúng ta thực hiện làm mắc nợ kỹ thuật là chuyện khác. Nó bao gồm tất cả các cách đã áp đặt từ bên ngoài làm cho phần mềm trở nên phức tạp và nó sẽ không tồn tại trong một thế giới hoàn hảo. Tôi gọi đó là độ phức tạp ngẫu nhiên. Tôi định nghĩa và thảo luận về các thuật ngữ này tỷ mỉ và cẩn thận trong cuốn sách Nhà lập trình năng suất cao (The Productive Programmer) của tôi (xem Tài nguyên). Các thuật ngữ này nói chung không phải là không có gì mới mẻ: chúng tồn tại trên một dải phổ, giống như thiết kế. Một vài ví dụ sẽ giúp làm rõ sự khác biệt này. Một trong những đồng nghiệp của tôi làm việc với một hệ thống bảng lương cho một công ty có tổ chức công đoàn. Một trong những sự nhượng bộ mà công đoàn đã đạt được dành cho một số trong các thành viên của họ là được thêm một ngày nghỉ làm nữa vào đầu mùa săn bắn. (Này, họ chắc phải có những người đàm phán tốt đấy chứ). Những công nhân đang nói đến ấy làm việc tại chỉ một nhà máy, nhưng phụ cấp thêm cho một ngày nghỉ nữa là một phần hợp pháp của hệ thống bảng lương cho toàn công ty. Việc thay đổi này làm tăng thêm khá nhiều tính phức tạp của phần mềm, nhưng nó là độ phức tạp bản chất vì nó đã là một phần vấn đề nghiệp vụ cần giải quyết. Một ví dụ khác, đi xa hơn một chút trong phạm vi thiết kế, luôn luôn xuất hiện: bảo mật ở mức các trường của các biểu mẫu nhập dữ liệu. Rất nhiều doanh nhân nghĩ họ muốn có quyền kiểm soát các đặc tính bảo mật của mỗi trường với độ chi tiết cao. Trong thực tế, họ hầu như luôn luôn ghét nó khi nó được thực thi bởi vì nó tạo ra một gánh nặng cho những người sử dụng, những người cần phải định nghĩa và duy trì tất cả các siêu dữ liệu này. Các doanh nhân ở một trong các dự án của chúng tôi thực sự muốn có tính năng này, do đó chúng tôi thực thi một phần của nó trên một trong các màn hình dành cho họ. Một khi họ lần đầu tiên tận mắt nhìn thấy cần bao nhiêu nỗ lực để làm cho nó hoạt động, họ đã quyết định rằng, do chỉ có quyền truy cập vào ứng dụng này từ một văn phòng có khóa, họ có thể đồng ý với bảo mật có mức chi tiết thô hơn. Đây là một ví dụ hay về một quyết định thiết kế xuất hiện ngay khi doanh nhân nhìn thấy thực tế những gì mà họ nghĩ rằng họ muốn có. Tại đầu mút bên kia của dải phổ theo hướng độ phức tạp ngẫu nhiên là các bài tập đo độ sâu thuần túy giống như hai phiên bản đầu tiên của công nghệ Enterprise JavaBeans (EJB) và các công cụ như BizTalk. Một vài dự án cần làm thêm công việc mà các công cụ này đưa vào, nhưng chúng chẳng làm được bất kỳ điều gì ngoài việc tăng thêm độ phức tạp cho hầu hết các dự án có sử dụng chúng. Ba điều có khuynh hướng sinh ra độ phức tạp ngẫu nhiên. Tôi đã thảo luận điều thứ nhất: dùng tạm một giải pháp vừa kịp có để viết mã vì lý do lịch trình công việc hoặc vì các áp lực bên ngoài khác. Điều thứ hai là sao chép, điều mà cuốn sách Những nhà lập trình thực dụng gọi là sự vi phạm nguyên tắc không lặp lại chính mình (DRY - Don't Repeat Yourself). Sao chép là cách xảo quệt nhất làm giảm công sức trong việc phát triển phần mềm bởi vì nó có thể luồn vào nhiều chỗ đến mức thậm chí các nhà phát triển không thể nhận biết. Các ví dụ hiển nhiên là các mã lệnh cắt và dán, nhưng cũng có rất nhiều các ví dụ tinh vi hơn. Chẳng hạn, hầu như mọi dự án có sử dụng một công cụ lập sơ đồ đối tượng-quan hệ (ví dụ như Hibernate hoặc iBatis) có rất nhiều chỗ sao chép lại. Lược đồ cơ sở dữ liệu của bạn, các tệp tin ánh xạ XML và các POJO hậu thuẫn, chứa các thông tin hơi khác nhau một chút, nhưng chồng chéo nhau. Có thể sửa lỗi này bằng cách tạo ra một nguồn chuẩn tắc các thông tin này và sau đó sinh ra các phần khác. Bản sao gây hại cho các dự án vì nó chống lại các cố gắng để làm thay đổi cấu trúc hoặc tái cấu trúc lại theo hướng tạo mã tốt hơn. Nếu bạn biết rằng bạn cần phải thay đổi một thứ gì đó ở ba chỗ khác nhau, bạn hãy tránh làm điều này ngay cả khi nó sẽ làm cho mã tốt hơn trong dài hạn. Điều thứ ba có thể làm phát sinh độ phức tạp ngẫu nhiên là tính không đảo ngược được. Bất kỳ quyết định nào mà bạn thực hiện không thể đảo ngược, cuối cùng sẽ dẫn đến một độ phức tạp ngẫu nhiên nào đó. Tính không đảo ngược được tác động đến cả hai việc kiến trúc lẫn thiết kế, mặc dù các ảnh hưởng của nó là vừa phổ biến hơn và vừa gây tổn hại nhiều hơn ở mức độ kiến trúc. Hãy cố gắng tránh các quyết định không có khả năng hay rất khó đảo ngược. Một câu thần chú Ấn độ mà tôi đã nghe một số đồng nghiệp của tôi sử dụng là chờ cho tới thời điểm hợp lý cuối cùng. Điều này không có nghĩa là bạn để lại các quyết định quá kéo dài mà chỉ vừa đủ dài. Thời điểm hợp lý cuối cùng mà bạn có thể đưa ra một quyết định về một mối quan tâm kiến trúc nào đó là gì? Bạn còn có thể tránh ra quyết định càng lâu, thì các khả năng còn mở cho chính bạn càng nhiều. Hãy tự hỏi: "Tôi có cần phải đưa ra quyết định ngay bây giờ không?" và "Tôi có thể làm gì để cho phép tôi trì hoãn quyết định đó?" Bạn sẽ ngạc nhiên về những điều mà bạn có thể trì hoãn cho đến sau này nếu bạn chỉ cần áp dụng một số tài khéo léo cho quá trình ra quyết định của bạn. Sự khác biệt mà tôi đã nêu ở trên giữa kiến trúc mức khung công tác và kiến trúc ứng dụng buộc chặt vào nguyên tắc về thời điểm hợp lý cuối cùng. Kiến trúc ứng dụng có khuynh hướng trở thành một kiến trúc logic. Ví dụ, giả sử bạn biết rằng bạn muốn phân tách các mối quan tâm về Mô hình-Khung nhìn-Trình bày. Rất thông thường, bạn thực hiện bước nhảy ngay đến việc thực thi vật lý của kiến trúc logic đó bằng cách chọn một khung công tác đáp ứng được một số hoặc tất cả các yêu cầu. Hãy xem xem bạn có thể trì hoãn quyết định đó không vì một khi bạn đã có thực thi vật lý triển khai rồi, nó khống chế các loại quyết định khác mà bạn phải xem xét kỹ. Việc tạm để ra ngoài chưa xét một quyết định về khung công tác cho đến khi còn có thể, sẽ để lại cho bạn những khả năng mở đối với các tùy chọn tốt hơn, ít bị ô nhiễm bởi hoàn cảnh thực tế. Tính bao quát tràn lan Điều cuối cùng trong số các mối quan tâm bao trùm dành cho kiến trúc và thiết kế là một cụm từ tôi đã tạo ra được gọi là tính bao quát tràn lan (rampant genericness). Chúng ta hình như có một căn bệnh trong thế giới Java: bày ra quá nhiều các giải pháp bằng cách cố gắng làm cho chúng càng bao quát chung càng tốt. Động lực cho điều này là rõ ràng: Nếu chúng ta xây dựng sẵn nhiều tầng dành cho việc mở rộng, chúng ta có thể xây dựng thêm bên trên chúng một cách dễ dàng hơn về sau này. Tuy nhiên, đây là một bẫy nguy hiểm. Bởi vì tính bao quát làm tăng thêm entropi, gây tổn hại đến khả năng làm tiến triển thiết kế theo những cách đáng quan tâm ngay từ đầu trong dự án. Thêm quá nhiều tính linh hoạt làm cho mọi thay đổi đối với cơ sở mã nguồn thành phức tạp hơn. Tất nhiên, bạn không thể bỏ qua khả năng mở rộng. Phong trào ủng hộ thiết kế nhanh nhẹn (agile) có một cụm từ thú vị tóm tắt quá trình quyết định việc thực thi các đặc tính: YAGNI (Bạn sẽ không cần nó). Đây là một câu thần chú Ấn độ để cố gắng tránh bày ra quá nhiều cho một đặc tính đơn giản. Chỉ cần thực thi chính xác những gì bạn cần bây giờ và nếu sau này bạn cần thêm nhiều thứ khác thì bạn có thể thêm nó sau. Tôi đã thấy có một số dự án Java phình to ra với các thỏa hiệp trong cả kiến trúc lẫn thiết kế để hiến tế cho tính bao quát và khả năng mở rộng đến nỗi làm cho dự án thất bại. Tất nhiên điều này thật là mỉa mai vì chính việc lên kế hoạch cho dự án trường tồn lại rút ngắn cuộc sống của nó. Việc tìm hiểu cách [...]... mọi người ở trên cùng một trang Tôi đã thiết lập khung cảnh cho phần còn lại của loạt bài này, ở đó tôi sẽ xoáy sâu vào các lĩnh vực cụ thể liên quan đến kiến trúc tiến hóa và thiết kế nổi dần Mỗi bài viết sẽ đi sâu vào một khía cạnh minh họa cụ thể của một hoặc cả hai khái niệm này với khá nhiều chi tiết và mã nguồn Phần tiếp theo: Tôi nói về thiết kế nổi dần thông qua việc phát triển dựa theo thử nghiệm,... nhiều chi tiết và mã nguồn Phần tiếp theo: Tôi nói về thiết kế nổi dần thông qua việc phát triển dựa theo thử nghiệm, mà tôi đã đổi tên thành thiết kế dựa theo thử nghiệm Mục lục  Định nghĩa kiến trúc  Định nghĩa thiết kế  Các mối quan tâm về kiến trúc và thiết kế  Bản đồ chỉ đường ... giữa khả năng mở rộng và bày ra quá nhiều là rất khó và nó là một chủ đề mà tôi sẽ trở lại thường xuyên Bản đồ chỉ đường Bài viết này chứa rất nhiều cái phẩy tay (hàm ý tạm cho qua) và không có mã nguồn làm cho nó không giống như tất cả các bài viết khác sắp tới trong loạt bài này Một trong những vấn đề vốn có trong việc thảo luận các chủ đề phức tạp như kiến trúc và thiết kế là việc thiết lập bối cảnh . Kiến trúc tiến hóa và thiết kế nổi dần: Nghiên cứu điều tra kiến trúc và thiết kế Khám phá kiến trúc và thiết kế dễ bảo trì hơn Neal Ford, Kiến trúc phần mềm, ThoughtWorks Tóm tắt: Thiết. về kiến trúc và thiết kế Tiến hóa so với nổi dần Lưu ý rằng loạt bài này được đặt tên là Kiến trúctiến hóa và thiết kế nổi dần. Tại sao có sự phân biệt giữa tiến hóa và nổi dần? Kiến trúc nổi. là thiết kế và kiến trúc phần mềm. Thông qua các ví dụ cụ thể, Neal Ford sẽ mang lại cho bạn một nền móng vững chắc về các biện pháp thực hành nhanh trong kiến trúc tiến hóa và thiết kế nổi