Làm các mẫu thiết kế Sáng tạo ngột ngạt

Nhiều năm trước, tôi đã nói chuyện với một giáo sư Kinh tế về các mẫu thiết kế, cách họ thiết lập một ngôn ngữ chung cho các lập trình viên và cách họ giải quyết các vấn đề nổi tiếng một cách tốt đẹp, v.v.

Sau đó, anh ấy nói lại với tôi rằng đây chính xác là cách tiếp cận ngược lại mà anh ấy sẽ sử dụng cho các sinh viên Kinh tế của mình. Anh ấy thường trình bày một vấn đề và yêu cầu họ tìm giải pháp trước, để họ có thể nghĩ về nó trước và cố gắng tìm cách giải quyết vấn đề trước, và chỉ sau đó, anh ấy mới trình bày giải pháp "cổ điển".

Vì vậy, tôi đã suy nghĩ liệu cách tiếp cận "mẫu thiết kế" có thực sự là thứ khiến các lập trình viên thông minh hơn hay ngu ngốc hơn không, vì họ nhiều lần chỉ nhận được "giải pháp đúng cho vấn đề này" thay vì có thể sử dụng sự sáng tạo và trí tưởng tượng để giải quyết vấn đề nào đó cách mới và sáng tạo.

Bạn nghĩ sao?

Giáo sư kinh tế của bạn là hoàn toàn chính xác.

Các mẫu thiết kế phần mềm chủ yếu là một cách để các nhà phát triển phần mềm có kinh nghiệm giao tiếp với nhau . Chúng là một tốc ký cho các giải pháp được thiết lập cho các vấn đề đã biết.

Nhưng chúng chỉ nên được sử dụng bởi những người hiểu cách giải quyết vấn đề mà không có mẫu hoặc tự mình đưa ra một mẫu tương tự. Nếu không, chúng sẽ có cùng một vấn đề như bộ mã hóa sao chép / dán; họ sẽ có mã, nhưng họ sẽ không hiểu cách thức hoạt động của nó và do đó sẽ không thể khắc phục sự cố.

Ngoài ra, nhiều mẫu thiết kế là mẫu doanh nghiệp , mẫu được sử dụng trong các hệ thống phần mềm doanh nghiệp lớn. Nếu bạn tìm hiểu những điều kỳ diệu của bộ điều khiển Inversion of Control, bạn sẽ muốn sử dụng nó trong mọi chương trình bạn viết, mặc dù hầu hết các chương trình không thực sự cần nó (có nhiều cách tốt hơn để đưa phần phụ thuộc của bạn vào các chương trình nhỏ hơn, theo cách đó 't yêu cầu một container IoC).

Tìm hiểu các mẫu. Hiểu các mô hình, và sử dụng thích hợp của họ. Biết cách giải quyết vấn đề tương tự mà không có mẫu (tất cả các mẫu phần mềm là trừu tượng hơn các thuật toán cơ bản). Sau đó, bạn sẽ có thể sử dụng các mẫu phần mềm một cách tự tin, khi nó có ý nghĩa để làm như vậy.

Cách mà Mẫu thiết kế mọi người muốn bạn nhìn vào Mẫu thiết kế là một bộ giải pháp mà bạn có thể áp dụng nếu các vấn đề tương tự xuất hiện. Họ không muốn bạn nghĩ về chúng như những giải pháp khả thi duy nhất, được Chúa ban cho Moses được khắc trên những phiến đá trên núi.

Thật không may, một số người coi chúng như một cái gì đó gần với tác phẩm thánh hơn là một loạt các thiết kế ví dụ có thể học được. Điều đó không giết chết sự sáng tạo, và thiết lập một giáo phái vận chuyển hàng hóa.

Giáo sư kinh tế của bạn đã đề cập đến việc trình bày cho sinh viên vấn đề và yêu cầu họ cố gắng giải quyết nó trước, đây là một kỹ thuật giáo dục tốt, nhưng ông đã có một giải pháp để chỉ ra cho họ. Có một loạt các giải pháp cho nhiều vấn đề khác nhau trong đầu bạn là một điều tốt, và đó là điều mà các Mẫu thiết kế cố gắng trở thành. Tôi nghĩ rằng nó thất bại trong một số cách (Singleton khuyến khích các cách tiếp cận xấu, tập trung cận thị vào OO bắt buộc, v.v.), nhưng nó có thể được sử dụng tốt với trí thông minh và mùi vị. Tuy nhiên, thật sai lầm khi nghĩ rằng mọi giải pháp ví dụ có thể có trong phần mềm đều phải là Mẫu thiết kế chính thức.

Nếu bạn nhìn vào một vấn đề và tự hỏi mình "Mẫu thiết kế cho vấn đề này là gì?", Thì bạn đã làm sai và bạn sẽ ít thấy giải pháp đang nhìn chằm chằm vào bạn.

Nếu bạn nhìn vào một vấn đề và tự hỏi mình "Làm thế nào tôi có thể giải quyết vấn đề này?", Thì nếu có một giải pháp phi mẫu, bạn sẽ thấy nó và nếu có một mẫu phù hợp, bạn cũng sẽ thấy điều đó.

Tôi cũng nghĩ rằng giáo sư kinh tế của bạn là chính xác và đó là cách để học bất cứ điều gì ngay từ đầu; Tuy nhiên, hãy nhìn vào như thế này: Bạn có giữ bí mật về Bánh xe và để mọi người phát minh lại, vì mục đích Sáng tạo không? Tôi mong bạn nói Không, bởi vì không phải tất cả mọi người được tạo ra / có khả năng phát minh ra bánh xe của họ - và nếu họ, họ sẽ làm điều đó vào một lúc nào đó, không quan trọng nếu họ biết về sự tồn tại của bánh xe hay không phải.

Hãy quay trở lại với các lập trình viên; Tôi là một nhà phát triển web vào ban ngày, vì vậy MVC là một trong những thứ mà tôi tương tác hàng ngày. Nhiều lần tôi đã cố gắng xây dựng các cấu trúc của riêng mình, tôi đã học được rất nhiều nhưng tất cả chúng đều không thành công. Tôi đã cố gắng hết sức nhưng điều gì sẽ xảy ra nếu không có MVC ngoài kia? Vâng, đơn giản, mã nguồn của tôi rất tệ - về độ tin cậy, khả năng bảo trì và khả năng mở rộng.

Tôi nghĩ đó là giống nhau cho hầu hết chúng ta. Nếu không ai nói với bạn về DI - như một cách thực hành tốt, thì có bao nhiêu ứng dụng doanh nghiệp nên vật lộn hoặc thất bại cho đến khi các nhà phát triển của họ học bài học?

Điểm thứ hai là Tiêu chuẩn ngành . Nếu bạn không dạy MVC cho các nhà phát triển web thì bạn đã sẵn sàng đối mặt với tất cả các cấu trúc không chuẩn đó mà bạn cần dành thời gian để tìm hiểu cách làm việc của họ trước, và sau đó bạn nhận ra rằng một số cấu trúc đó có thể có một ý tưởng hay, nhưng hầu hết trong số chúng sẽ có những lỗi thiết kế nghiêm trọng có thể gây hậu quả nghiêm trọng cho dự án phần mềm của bạn - ngay cả các khung công tác nổi tiếng vẫn luôn phải vật lộn với lỗi thiết kế theo thời gian.

Nhưng điều gì sẽ xảy ra nếu chúng ta có tất cả những ý tưởng hay đó và kết hợp chúng lại với nhau và những nhà phát triển thông minh đó đã lấy những điều tốt đẹp từ tất cả những thử nghiệm đó và tạo ra một cấu trúc thực sự tuyệt vời phù hợp nhất cho vấn đề cụ thể đó? Sau đó, bạn vừa tạo ra các mẫu thiết kế . Nếu bạn là một sinh vật sống, thì không còn cách nào khác; Ngay cả động vật cũng tuân theo các thực hành tốt nhất và các mẫu thiết kế trong cuộc sống hàng ngày của chúng.

Đừng phát minh lại một cái búa, nhưng đừng coi mọi vấn đề như cái đinh

Các mẫu lập trình là một trình tiết kiệm thời gian tuyệt vời, bởi vì chúng cung cấp cho bạn các giải pháp sẵn sàng sử dụng, tài liệu tốt và được thử nghiệm với các trường hợp trung bình mà bạn có thể dễ dàng quên đi. Nhưng bạn cần học (và suy nghĩ) khi sử dụng chúng.

Diễn giải câu hỏi của bạn: học lái xe sẽ khiến tôi di chuyển nhanh hơn, hay chỉ đi chậm hơn?

Học cách sử dụng mẫu lập trình không có nghĩa là bạn không nên tìm giải pháp riêng. Vẫn sẽ có đủ vấn đề để thực hiện sự sáng tạo của bạn. Biết các mẫu lập trình sẽ chỉ cho phép bạn nhanh chóng với các vấn đề nổi tiếng và tập trung vào những vấn đề ít tầm thường hơn.

Quay trở lại phần thứ hai của câu hỏi của bạn - là proffesor của bạn phải không?

Vâng, anh ấy đúng . Mục tiêu chính của nghiên cứu là học sinh suy nghĩ . Họ cần cố gắng tìm giải pháp riêng cho vấn đề, và sau đó đối đầu với họ bằng các giải pháp hiện có. Chỉ bằng cách đó họ có thể thực sự hiểu chúng. Nếu bạn học chúng theo mô hình trước, bạn có nguy cơ chúng sẽ chỉ học một cách máy móc để áp dụng chúng, và không hiểu, cái gì đứng sau.

Đây là lý do đầu tiên bạn dạy sinh viên lập trình và các mẫu được giới thiệu trong các học kỳ tiếp theo.

Tôi hoàn toàn sẽ khuyên chống lại việc dạy lập trình bằng cách dạy các mẫu thiết kế. Bạn không thể áp dụng chúng tốt mà không hiểu các nguyên tắc đằng sau chúng, vì vậy việc dạy các nguyên tắc đó quan trọng hơn nhiều.

Dù sao, tôi có xu hướng nghĩ rằng các mẫu thiết kế không thực sự có giá trị đối với các lập trình viên làm việc. Nếu bạn hoàn toàn hiểu các nguyên tắc liên quan đến một mẫu thiết kế nhất định, thì trong tình huống đó là một giải pháp tốt, bạn sẽ có xu hướng tự nhiên xây dựng nó (hoặc một cái gì đó tương tự) dù chỉ là vấn đề, ngay cả khi bạn không biết rằng đó là một mô hình với một cái tên. Bất cứ lúc nào bạn dành thời gian cho việc học các mẫu có thể tốt hơn là học cách nghĩ về mã nói chung. Nếu các kỹ năng "giải quyết vấn đề nói chung" của bạn không thành công, thì bạn không thể viết mã tốt cho dù bạn có giỏi đến đâu khi áp dụng một số mẫu. Và nếu kỹ năng "giải quyết vấn đề nói chung" của bạn tốt, thì bạn có thể giải quyết vấn đề ngay cả khi bạn không biết một mẫu nào.

Tôi cũng nghĩ rằng trong một thế giới lý tưởng sẽ không có bất kỳ mẫu thiết kế nào, bởi vì những ý tưởng đủ phổ biến để được gọi là một mẫu sẽ được triển khai tốt trong các thư viện và chúng tôi thực sự sẽ sử dụng lại mã thay vì liên tục viết lại nó. Hãy tưởng tượng nếu có một "mẫu thiết kế biểu thức chính quy", yêu cầu bạn phải thực hiện một công cụ regex nhỏ mỗi khi bạn muốn sử dụng nó. Các mẫu thiết kế chỉ là các thư viện không thể được viết vì ngôn ngữ không cung cấp các phương tiện trừu tượng đúng.

Đó thực sự là một lý do khác để không quan tâm nhiều đến họ; chúng không phải là bất cứ nơi nào gần như phổ biến như đôi khi được tuyên bố, nhưng trên thực tế gắn liền với các cách thức cấu trúc chương trình cụ thể mà một ngôn ngữ cụ thể cho phép / khuyến khích. Một cuốn sách mẫu thiết kế được viết cho Python sẽ hoàn toàn khác với một cuốn được viết cho Java và thậm chí còn khác với một cuốn được viết cho một ngôn ngữ không bắt buộc như Haskell. Hiểu rõ hơn ở cấp độ sâu hơn và bạn sẽ có thể tự mình khám phá các mẫu thiết kế bằng bất kỳ ngôn ngữ nào bạn quen thuộc.

Thương mại và giáo dục có những mục tiêu khác nhau. Nếu tôi đang dạy sinh viên thiết kế mẫu, tôi sẽ có cách tiếp cận tương tự. Nhưng trong một môi trường sản xuất, thời gian và hiệu quả là tất cả.

Hơn nữa, kinh tế (vĩ mô) bên ngoài lớp học là một điều khác biệt. Bạn có thấy các chính phủ nói, "Whoa! Bây giờ chúng tôi rất chán với việc làm thuế và tất cả theo cùng một cách, vì vậy chúng ta hãy thử một cái gì đó siêu kỳ quặc lần này"? Không, bạn không, bởi vì những thí nghiệm hoang dã như vậy có thể phá vỡ nền kinh tế sau khi sửa chữa. Thay vào đó, họ có xu hướng dính vào các phương pháp thử và thử: tăng lãi suất, thông báo ngày lễ thuế, v.v. Nói cách khác, họ đang dựa vào các mẫu thiết kế.

Câu trả lời là, tất nhiên, có.

Bản thân các mẫu thiết kế là một công cụ học tập tuyệt vời, miễn là người ta dành thời gian để tìm ra cách họ làm việc và lý do tại sao họ mang lại giá trị mà họ mang lại.

Chúng cũng có thể là những tên lửa đẩy năng suất tuyệt vời bằng cách theo dõi nhanh quá trình thiết kế, bởi vì chúng cung cấp các giải pháp quen thuộc cho các vấn đề xuất hiện mọi lúc.

Tuy nhiên, nếu họ thiết kế ngắn mạch quá nhiều, hoặc mọi người trở nên giáo điều và quá chính xác về việc sử dụng của họ, thì họ có tác dụng ngược lại.

Mẫu thiết kế tất nhiên là ít sáng tạo. Đó là toàn bộ ý tưởng. Sáng tạo là một nguồn tài nguyên khan hiếm. Bạn không nên lãng phí nó vào những vấn đề không cần sáng tạo. Nó dễ dàng hơn nhiều, nhanh hơn và có nhiều khả năng làm việc hơn, nếu bạn giải quyết vấn đề theo cách tương tự như hàng trăm nhà phát triển trước bạn. Nhàm chán, mã không hấp dẫn mà thực hiện công việc của nó là thực sự tốt.