Là các mẫu thiết kế nhăn mặt?


135

Tôi đã có một cuộc thảo luận với một trong những nhà phát triển cao cấp của chúng tôi, những người đã kinh doanh trong 20 năm. Anh ấy khá nổi tiếng ở Ontario cho một blog anh ấy viết.

Điều kỳ lạ là những gì anh ấy nói với tôi: anh ấy nói rằng có một đoạn mã là một cơn ác mộng phải làm việc vì nó được viết từ sách giáo khoa, và không tính đến thế giới thực. Việc thêm một trường mới vào lớp UI / cơ sở dữ liệu / Lớp dữ liệu phải mất 2-3 giờ để thực hiện, trong khi đó trong mã của anh ta phải mất 30 phút.

Một điều khác nữa là anh ta tránh các mẫu thiết kế vì hầu hết các lập trình viên không hiểu chúng và chúng không tốt từ góc độ bảo trì.

Sau đó, cũng có ý tưởng rằng hầu hết các nhà phát triển web ở Canada thích mô hình dữ liệu của họ kế thừa từ các lớp Lớp dữ liệu, thay vì giữ nó tách biệt. Tôi hỏi anh ta, "Không phải nó là tiêu chuẩn công nghiệp cho mô hình được tách ra khỏi lớp dữ liệu sao?" Thỉnh thoảng anh nói, nhưng hầu hết mọi người ở đây không thích làm điều đó vì công việc quá nhiều.

Nghe có vẻ như lý do của anh ta về việc không mã hóa bằng cách sử dụng các thực tiễn tốt nhất là vì đó là một cơn ác mộng bảo trì, rất ít nhân viên của chúng tôi hiểu điều đó (ngoài bản thân tôi) và sẽ chậm làm việc nếu bạn cần đưa ra các tính năng hoặc trường mới trong vài ngày ' thời gian.

Thật kỳ lạ khi nghe một ý kiến ​​như thế này, vì cho rằng Stack Overflow chủ yếu khuyến khích mọi người tuân theo các tiêu chuẩn ngành. Có phải vấn đề là chúng ta liên tục bị buộc phải đưa ra các lĩnh vực và tính năng mới trong vài ngày, rằng không thể suy ra một mô hình vững chắc đủ linh hoạt? Đó dường như là ý chính của những gì tôi hiểu từ điều này.

Bạn làm gì của những tuyên bố này?



67
Cá nhân tôi lo lắng về bất cứ điều gì được gọi là "thực hành tốt nhất" (không cần biện minh) bởi vì nó thường có nghĩa là "Tôi không biết tại sao đây là một ý tưởng tốt nhưng tôi muốn bạn thực hiện nó bằng mọi cách; kết thúc cuộc thảo luận"
Richard Tingle

34
tiêu chuẩn ngành, mẫu thiết kế và thực tiễn tốt nhất chỉ là thuật ngữ cho "Những điều mà ai đó nói hoạt động tốt hơn trong bối cảnh của họ để nó cũng phù hợp với bạn. có lẽ" có lẽ "®. quyền của nhà phát triển cấp cao của bạn.
CptEric

86
Điều này không liên quan gì đến Agile.
Các cuộc đua nhẹ nhàng trong quỹ đạo

68
"Nhà phát triển mvc cao cấp" "mẫu thiết kế rất tệ" sự bất đồng về nhận thức
Dan Pantry

Câu trả lời:


239

Đây là những lời của một người đã tìm thấy thành công và phớt lờ những người cố gắng nói cho anh ta biết phải làm gì trong biệt ngữ mà anh ta không hiểu.

Các mẫu thiết kế và thực hành tốt nhất không giống nhau. Một số người nghĩ rằng họ là và lái những người biết họ đang làm gì. Ngay cả khi họ không biết tên thích hợp cho những gì họ đang làm.

Các mẫu thiết kế đã tồn tại trước khi chúng có tên. Chúng tôi đã đặt tên cho họ để làm cho việc nói về họ dễ dàng hơn. Một mô hình có một tên không làm cho nó một điều tốt. Nó làm cho nó một điều dễ nhận biết.

Anh chàng này có khả năng sử dụng các mẫu mà không ai trong các bạn từng nghe đến. Điều đó tốt, cho đến khi bạn cần nói chuyện với anh ấy về cách thực hiện. Anh ấy sẽ phải học cách nói chuyện với bạn hoặc bạn sẽ phải học cách nói chuyện với anh ấy. Không có gì để làm với ai là "đúng".


12
Đồng ý, với lời cảnh báo rằng, khi hầu hết mọi người sử dụng thuật ngữ "mẫu thiết kế" ngày nay, họ thường đề cập đến Gang of Four .
Robert Harvey

35
Phải và tôi thích sử dụng tiếng Anh, nó có ý nghĩa với tôi. Không biết tại sao người Pháp lại mất nhiều thời gian để chấp nhận nó. Cho đến khi họ làm tôi sẽ tìm hiểu một chút về hệ thống số liệu này mà tôi vẫn nghe thấy.
candied_orange

6
Có thể anh ta không hiểu, cũng có thể là anh ta không hiểu nhưng anh ta biết rằng không phải mọi thứ đều áp dụng trong mọi tình huống.
whatsisname

148
"Một mô hình có một cái tên không làm cho nó trở thành một điều tốt. Nó làm cho nó trở thành một điều dễ nhận biết." Ôi chúa ơi đây là bản tóm tắt hay nhất về vấn đề tôi từng nghe: D
Các cuộc đua nhẹ nhàng trong quỹ đạo

7
@JanDoggen Chúng được gọi là các mẫu (chống) vì chúng cũng là các mẫu phổ biến trong phát triển phần mềm (một số trong đó là các mẫu liên quan đến thiết kế).
JAB

95

Nhiều mẫu thiết kế, thuộc loại mà bạn và bạn của bạn đang mô tả, thực sự chỉ là cách giải quyết cho những thiếu sót trong ngôn ngữ lập trình . Sử dụng ngôn ngữ lập trình biểu cảm hơn và hầu hết nhu cầu về các mẫu thiết kế này đều biến mất.

Bởi vì các mẫu thiết kế tốt được yêu cầu để phục vụ cho nhiều tình huống sử dụng có thể xảy ra, nên chúng có xu hướng được thiết kế quá mức. Mã quá kỹ thuật có một chi phí: bạn phải đọc nó, hiểu những gì nó làm và hiểu cách thức hoạt động của nó trong bối cảnh của toàn bộ hệ thống phần mềm. Do đó, như với bất kỳ kỹ thuật phát triển phần mềm nào khác, bạn phải đánh giá kỹ thuật này dựa trên chi phí sử dụng kỹ thuật đó và quyết định xem lợi ích có vượt quá chi phí hay không.

Tất cả những thứ khác bằng nhau, ít mã hơn luôn luôn tốt hơn. Tôi đã trải qua các kiến ​​trúc phân lớp, trong đó bạn thực sự phải thực hiện ba đến sáu bước nhảy qua nhiều dự án để tìm bất kỳ mã nào thú vị, nghĩa là, mã thực sự hoàn thành một cái gì đó ngoài việc thêm chi phí.

Các mẫu phần mềm nổi tiếng được cho là cung cấp cho bạn một từ vựng chung để bạn có thể truyền đạt các chiến lược thiết kế. Thật không may, nhiều nhà phát triển phần mềm không hiểu từ vựng mẫu phần mềm đủ tốt để áp dụng đúng vào các vấn đề lập trình của họ. Các nhà phát triển thiếu kinh nghiệm xem các mẫu này là thuộc phạm vi của các chuyên gia; họ muốn được coi là chuyên gia, và vì vậy họ cố gắng học và áp dụng các mô hình quá sớm, trước khi họ sẵn sàng. Điều họ thực sự nên làm thay vào đó là tập trung vào việc học các nguyên tắc cơ bản của lập trình trước, và sau đó cố gắng giải quyết vấn đề mà mỗi mẫu tự giải quyết. Nếu họ làm điều này, họ sẽ ở một vị trí tốt hơn nhiều để hiểu và áp dụng các mô hình chính xác.


19
Chà, đó là một vấn đề khác với vấn đề bạn mô tả trong câu hỏi của bạn. Cửa hàng tôi làm việc bây giờ là bằng chứng sống cho thấy bạn có thể nhanh nhẹn và vẫn có mã nạc rất sạch sẽ, dễ bảo trì, nhưng đó không phải là doanh nghiệp thông thường, nhiều thứ bạn thấy trong hầu hết các cửa hàng Java và khá công bằng "Không chuẩn" trong cách tiếp cận của nó. Chúng tôi không có một năm để xây dựng ứng dụng theo cách "doanh nghiệp".
Robert Harvey

34
@ Igneous01: Lưu ý rằng những gì một giáo sư chưa từng có kinh nghiệm trong thế giới thực coi "tốt" có thể thay đổi hoàn toàn so với những gì một doanh nghiệp cố gắng kiếm tiền coi là "tốt".
Robert Harvey

8
"Thật không may, nhiều nhà phát triển phần mềm không hiểu từ vựng mẫu phần mềm đủ tốt để áp dụng đúng vào các vấn đề lập trình của họ." Đây là tôi trong một tóm tắt. =) Một số ít tôi đã thấy tên của, tôi có một thời gian cực kỳ khó khăn để tìm ra một triển khai thực sự của chúng. Tôi có thể có các khối mã tôi đã viết có thể được phân loại là mẫu triển khai, nhưng tôi chắc chắn không thể cho bạn biết mã nào. Tôi đã nghĩ rằng các mẫu ít quan trọng hơn nhiều so với mã thực sự có thể giải mã được và các yêu cầu thay đổi chỉ ảnh hưởng đến một vài vị trí của mã.
jpmc26

35
Mặc dù tôi sẽ có vấn đề về mặt giáo dục với "ít mã hơn luôn luôn tốt hơn" bởi vì tôi biết nó dẫn đến mã trông giống như brainfuck , tôi sẽ nhiệt tình đồng ý với điểm "bỏ trống mẫu". Đừng phàn nàn rằng mã của tôi là tào lao chỉ vì bạn không thể tìm thấy nó trong sách giáo khoa của bạn. Có rất nhiều lý do hoàn toàn chính đáng để gọi mã của tôi là tào lao, nhưng đó không phải là một trong số đó.
candied_orange

23
"Mã thực sự hoàn thành một cái gì đó ngoài việc thêm chi phí" - Tôi nghĩ mục tiêu của phần mềm doanh nghiệp là không nên có mã thực sự hoàn thành bất cứ điều gì . Bất kỳ hành vi thực tế nào mà phần mềm có thể có, phải là một thuộc tính mới nổi của thiết kế lớp hoặc nếu không thì phải được điều khiển theo bảng từ các quy tắc kinh doanh mà mã coi là dữ liệu. Tôi chỉ nói đùa 50%.
Steve Jessop

86

Stackoverflow.SE và Lập trình viên.SE chủ yếu khuyến khích mọi người tuân theo các thực tiễn tốt nhất như RẮN, chứ không phải các tiêu chuẩn ngành . Và tin hay không, tiêu chuẩn công nghiệp thực tế thường là kiến trúc "quả bóng lớn" - nghiêm túc.

Nhưng để trả lời trực tiếp câu hỏi của bạn: vấn đề với các mẫu thiết kế cũng tương tự như vấn đề thừa kế - rất nhiều nhà phát triển tầm thường lạm dụng chúng, điều này có rủi ro nhất định tạo mã quá mức, khó duy trì. Nhưng câu trả lời cho điều này chắc chắn là không tránh hoặc cấm sử dụng hoàn toàn các mẫu thiết kế (hoặc thừa kế), câu trả lời là học cách sử dụng các công cụ này trong các tình huống có ý nghĩa và chỉ có ở đó. Và điều này là hoàn toàn độc lập với làm việc "nhanh nhẹn" hay không.


Tôi nghĩ rằng tính cụ thể của tuyên bố của bạn "vấn đề với các mẫu thiết kế là một vấn đề tương tự như với thừa kế - rất nhiều nhà phát triển tầm thường lạm dụng chúng" là không cần thiết ... với tất cả các khía cạnh của mã hóa, một nhà phát triển không được giáo dục trong việc sử dụng đúng cách một cái gì đó có thể và thường sẽ sử dụng sai nó và viết mã phụ tối ưu. Đây có thể được coi là một tiên đề của sự phát triển nói chung.
Jeremy Holovacs

1
@JeremyHolovacs: không chính xác. Vấn đề tôi thấy là ngay cả các nhà phát triển có giáo dục cũng lạm dụng chúng. Tôi đã thấy quá thường xuyên các giải pháp trong đó các nhà phát triển có kinh nghiệm đã cố gắng giải quyết vấn đề thành một mô hình phù hợp với "cách nào đó", nhưng không tốt.
Doc Brown

45
  1. Các mẫu thiết kế chỉ là tên được sử dụng để truyền đạt ý tưởng. Tôi thường thấy mình làm những việc mà sau này tôi thấy có một cái tên. Do đó, không có "cách mẫu thiết kế" trái ngược với "cách mẫu phi thiết kế".

  2. Mẫu thiết kế là hướng dẫn. Như tất cả mọi thứ, mỗi người trong số họ có lợi thế và bất lợi. Điều quan trọng không phải là tìm hiểu mẫu và áp dụng nó ở nơi phù hợp mà là để hiểu ý tưởng của mẫu, những ưu điểm và nhược điểm của nó và sử dụng nó để lấy cảm hứng cho giải pháp cho vấn đề của bạn.

  3. Mọi thực hành và hướng dẫn tốt nhất có thể được bỏ qua nếu có một lý do đủ tốt. Lý do hợp lệ bao gồm thời gian phát triển và kỳ vọng từ ứng dụng. Ví dụ, tôi biết rằng điều đó không tốt với các giá trị mã hóa cứng (ví dụ ngu ngốc) nhưng đối với một bằng chứng về khái niệm, các lợi thế có thể vượt xa chi phí (trong trường hợp này, chủ yếu là thời gian phát triển). Tuy nhiên, nếu một quyết định như thế này được đưa ra, nó có thể phản tác dụng và đến một lúc nào đó có thể cần phải tái cấu trúc.


5
RE: số 1, vâng, đã ở đó - Tôi đã phát minh ra mẫu mẫu. Tôi chỉ không làm điều đó đầu tiên. Hoặc bất cứ điều gì như đầu tiên.
Grimm The Opiner

29

Để thêm một phép ẩn dụ khác cho súp, các mẫu thiết kế là Clippy trình trợ giúp Microsoft Office. "Bạn dường như đang làm điều tương tự với cả đống thứ. Tôi có thể giúp bạn điều đó bằng cách cung cấp cho bạn Iterator hoặc Khách truy cập không?"

Việc viết tốt những mẫu đó sẽ cho biết khi nào thì hữu ích khi làm điều gì đó giống như cách mà nó đã được thực hiện nhiều lần trước đây, bạn sẽ mắc lỗi gì khi lần đầu thử và những cách phổ biến đã được tìm thấy để tránh những sai lầm đó . Vì vậy, bạn đọc mẫu thiết kế (hoặc xem lại nó từ bộ nhớ) và sau đó bạn tiếp tục với công việc của mình. Những gì bạn không thể làm được, là có được bằng cách chỉ sử dụng Clippy và trình thuật sĩ.

Trường hợp người thiếu kinh nghiệm có thể sai và viết mã không tính đến thực tế, là khi họ nghĩ rằng danh sách các mẫu thiết kế của họ là danh sách đầy đủ tất cả các cách tiếp cận có thể để giải quyết vấn đề trong phần mềm và cố gắng thiết kế mã bằng cách liên kết thiết kế với nhau mô hình cho đến khi nó hoàn thành. Một chiến thuật kém khác được quan sát thấy trong tự nhiên là cắm sừng một mẫu thiết kế vào tình huống không thực sự phù hợp, trên cơ sở mẫu thiết kế "là cách thực hành tốt nhất". Không, nó có thể hoặc không phải là cách thực hành tốt nhất cho lớp vấn đề mà nó thực sự giải quyết , nhưng chắc chắn đó không phải là cách thực hành tốt nhất cho các vấn đề mà nó không giải quyết được, hoặc cho các vấn đề mà nó chỉ giải quyết bằng cách đưa ra sự phức tạp không cần thiết khi có giải pháp đơn giản hơn .

Tất nhiên, ai đó cũng có thể tránh một mô hình trên cơ sở YAGNI, sau đó nhận ra rằng họ cần nó và tìm kiếm giải pháp bình thường. Điều này thường (nhưng không phải luôn luôn) tệ hơn là nhận ra yêu cầu ngay từ đầu, và đó là lý do tại sao ngay cả trong sự phát triển nhanh, nó vẫn bực bội khi các yêu cầu hoàn toàn có thể dự đoán được không được phát hiện sớm. Tôi không thể là lập trình viên C ++ duy nhất rất thích thú khi Java ban đầu từ chối các thùng chứa chung là phức tạp không cần thiết, sau đó đẩy chúng trở lại sau đó.

Vì vậy, gần như chắc chắn là một sai lầm khi tránh viết Iterator theo nguyên tắc vì bạn thích tránh các mẫu thiết kế.

Việc thêm một trường mới vào lớp UI / cơ sở dữ liệu / Lớp dữ liệu phải mất 2-3 giờ để thực hiện, trong khi như trong mã của anh ta thì phải mất 30 phút.

Bạn thực sự không thể tranh luận với điều đó: theo số liệu này, thiết kế của anh ấy tốt hơn nhiều so với số liệu khác. Dù đó là vì anh ta tránh các mẫu thiết kế có đáng nghi hay không, tôi nghĩ nhiều khả năng là vì anh ta đã xem xét đúng các vấn đề "thế giới thực" khi thiết kế nó, và với lợi ích của kinh nghiệm là công việc của anh ta tốt hơn so với ai đó chỉ trang bị sách giáo khoa và lý tưởng cao.

Vì vậy, anh ấy nhận ra rằng bất kỳ mẫu nào yêu cầu bạn chạm vào nhiều điểm khác nhau trong mã để thêm trường là một mẫu xấu cho công việc, "làm cho nó dễ dàng thêm các trường" và anh ấy đã không sử dụng các mẫu đó. Kiến trúc lớp thực sự có thể bị ảnh hưởng trong khía cạnh đó, và thật sai lầm khi sử dụng các mẫu thiết kế mà không đánh giá cao những nhược điểm của chúng.

Đối với điều đó, mất bao lâu để viết một giao diện người dùng mới trong thiết kế của anh ta và mất bao lâu trong một kiến ​​trúc phân lớp? Nếu dự án kêu gọi anh ta liên tục xây dựng và triển khai các UI mới trên một mô hình dữ liệu cố định, thay vì liên tục thêm các trường, hy vọng anh ta đã thiết kế cho điều đó thay vào đó. Hoặc là tốt. Nhưng đối với tất cả các lợi ích của nó, nói rằng "chúng tôi đang làm việc nhanh nhẹn" không có nghĩa là bạn sẽ không bao giờ phải đánh đổi!

Chọn từ một menu các mẫu thiết kế chắc chắn có thể khiến bạn ngừng suy nghĩ về những mối quan tâm quan trọng nhất. Nhưng nhận ra khi bạn viết một Khách truy cập, và ghi lại hoặc đặt tên là "Khách truy cập" để giúp người đọc có được nó một cách nhanh chóng, không ảnh hưởng nhiều đến bất cứ điều gì. Viết "đây là khách truy cập" thay vì ghi lại đúng cách là một sai lầm khủng khiếp vì lý do nhà phát triển cấp cao của bạn đưa ra - các lập trình viên sẽ không hiểu điều đó. Ngay cả các lập trình viên biết những gì Khách truy cập cũng cần nhiều thông tin hơn là "đây là Khách truy cập".


5
"Các mẫu thiết kế là Clippy người trợ giúp Microsoft Office" Tôi sẽ gặp ác mộng tối nay.
MetalMikester

"Trường hợp những người thiếu kinh nghiệm có thể sai [là khi họ] cố gắng thiết kế mã bằng cách liên kết các mẫu thiết kế với nhau cho đến khi hoàn thành." Nghe nghe. Tôi ước tôi có nhiều upvote để cung cấp. :)
Quuxplusone

Tôi cũng muốn tôi có nhiều upvote cho đoạn cuối cùng. Các mẫu thiết kế là từ vựng của lập trình: bạn sẽ trở thành một nhà văn giỏi hơn và rõ ràng hơn nếu bạn có vốn từ vựng lớn. Tôi có thể nói với Factory từ một Builder khi tôi nhìn thấy chúng, nhưng tôi đã không nhận được điều đó từ việc đọc sách về các mẫu thiết kế, bất kể tôi đã học được cách nói một lời nguyền từ một cách vô tội vạ bằng cách đọc từ điển tiếng Anh.
Quuxplusone

20

Đồng nghiệp của bạn dường như bị hội chứng NIH ("Không được phát minh ở đây").

Điều hoàn toàn hợp lý là mã của anh ấy giúp dễ dàng thêm các trường mới: Tôi cũng nhanh hơn để cập nhật mã của riêng mình so với mã được viết bởi những người khác. Nhưng tốc độ ngắn hạn này không nói lên điều gì về khả năng duy trì và tính di động của mã. Tôi sẽ cho anh ta lợi ích của sự nghi ngờ: Mã hiện tại thực sự có thể có cấu trúc xấu nếu nó đã theo một cuốn sách giáo khoa tồi hoặc theo một công thức tốt trong bối cảnh sai.

Tránh các mẫu thiết kế thực sự đáng ngạc nhiên. Trong 30 năm cuối cùng của tôi về mã hóa và quản lý các lập trình viên, các mẫu thiết kế đã giúp đưa các từ vào những thứ được thực hiện theo bản năng, giúp hiểu nhanh hơn ý định, lợi thế, sự bất tiện, rủi ro, cơ hội và các mẫu liên quan. Các mẫu thiết kế đã được chứng minh là máy gia tốc thực sự để làm chủ sự phức tạp!

  • Có lẽ đồng nghiệp của bạn thực sự thông minh hơn nhiều so với hầu hết chúng ta và anh ta có thể đủ khả năng chi trả cho các mẫu tái tạo mà không làm giảm năng suất đáng chú ý?

  • Các lập luận rằng "lập trình viên không hiểu các mẫu thiết kế" nghe có vẻ như "Tôi thực sự không thể giải thích những gì tôi đang làm". Hoặc "Tôi không muốn tranh luận về thiết kế của riêng tôi". Tôi thực sự nghĩ rằng mô hình hóa có thể thúc đẩy sự hiểu biết tổng thể, và nó có thể cho phép các đồng nghiệp cấp cao hơn chia sẻ ý kiến ​​có giá trị. Nhưng có lẽ đồng nghiệp cấp cao của bạn muốn tránh điều đó.

Phương pháp tiếp cận nhiều lớp đã được chứng minh là vượt trội so với các kiến ​​trúc khác trong hầu hết các ứng dụng doanh nghiệp. Các gói hàng đầu thế giới được cấu trúc xung quanh ý tưởng này và vượt trội hơn các kiến ​​trúc thủ công theo các đơn đặt hàng lớn. Martin Fowler trình bày phương pháp này trong cuốn sách xuất sắc của mình về "Các mô hình kiến ​​trúc doanh nghiệp". Oh! Xin lỗi lần nữa: Đó là về các mẫu đã được chứng minh; không có cơ hội trong quan điểm NIH của đồng nghiệp của bạn ;-)


Hội chứng NIH, thật thú vị, tôi chưa từng nghe về điều này trước đây. Rõ ràng đó là vấn đề mà hầu hết các nhà tuyển dụng ở Bắc Mỹ đang phải đối mặt với cách quản lý nhân viên của họ!
thanh toán

@pay Tôi không chắc chắn rằng điều này chỉ giới hạn ở Bắc Mỹ ;-) Luôn luôn hấp dẫn để tìm giải pháp mà chúng tôi đã sử dụng trong quá khứ với một số thành công. Đó là vùng thoải mái. Nhưng người ta phải luôn luôn mở cho những ý tưởng mới và đối thoại mang tính xây dựng với các đồng nghiệp đầy thách thức. Rốt cuộc, " Bạn đi du lịch nhanh hơn một mình, nhưng cùng nhau đi xa hơn. "
Barshe

16

Một cái nhìn sâu sắc mà nhiều người bỏ lỡ là thiết kế phần mềm theo ngữ cảnh. Nó tồn tại để đạt được các mục tiêu kinh doanh và các mục tiêu khác nhau có thể yêu cầu các cách tiếp cận khác nhau. Nói cách khác, không có thiết kế nào luôn tốt nhất, mặc dù luôn có một thiết kế tốt nhất.

Các mẫu thiết kế là giải pháp tiêu chuẩn cho các vấn đề tiêu chuẩn. Tuy nhiên, nếu bạn không có vấn đề, giải quyết nó là một sự lãng phí công sức.

Sự khác biệt chính giữa thiết kế phần mềm thác nước và nhanh nhẹn là khi các quyết định thiết kế được đưa ra. Trong thác nước, chúng tôi thu thập tất cả các yêu cầu, xác định mẫu thiết kế nào chúng tôi cần và chỉ sau đó bắt đầu mã hóa. Trong kiến ​​trúc nhanh nhẹn, chúng tôi tuân theo nguyên tắc YAGNI để trì hoãn các quyết định thiết kế cho đến thời điểm chịu trách nhiệm cuối cùng, khi chúng tôi biết càng nhiều về sự lựa chọn càng tốt.

Đó là, trong thác nước, các mẫu thiết kế có xu hướng được áp dụng nếu nhu cầu của chúng được dự đoán , nhanh nhẹn, khi chúng thực sự cần thiết . Kết quả là, các dự án nhanh có xu hướng áp dụng các mẫu thiết kế ít thường xuyên hơn, bởi vì không phải tất cả các nhu cầu dự đoán là thực tế.


1
+1 cho Design patterns are standard solutions to standard problems. Tôi hơi thất vọng khi không thấy điều đó trong các câu trả lời nâng cao hơn. Điều này đòi hỏi trước tiên để xác định xem vấn đề của bạn có phù hợp với một vấn đề tiêu chuẩn hay không và thực sự thường xuyên, họ sẽ giải quyết.
Walfrat

8

Các mẫu thiết kế không thực sự được gọi là mẫu thiết kế vì chúng quy định phải làm gì. Các mẫu thiết kế là các mẫu thiết kế vì chúng mô tả những gì đã được thực hiện trước đó . Một số nhà phát triển hoặc nhà phát triển đã thiết kế một phương pháp hoàn thành tốt một nhiệm vụ cụ thể và có thể áp dụng nó cho các tình huống tương tự có kết quả tương tự. Đó là tất cả. Nhiều mẫu có điểm mạnh và điểm yếu cố hữu, và tùy thuộc vào nhà phát triển có giáo dục để đánh giá nhu cầu công nghệ và kinh doanh để xác định một mẫu phù hợp để áp dụng.

Trong ánh sáng đó, trừ khi bạn thực sự cam kết viết mã 100% một lần, trong đó không có khái niệm hoặc triển khai nào có thể sử dụng được từ trường hợp sử dụng này sang trường hợp tiếp theo, bạn gần như chắc chắn sử dụng ít nhất một số mẫu thiết kế. Họ có thể không có những cái tên hào nhoáng, phổ biến như "Kho lưu trữ" hoặc "Đơn vị công việc" hoặc thậm chí là "MVC", nhưng điều đó không làm cho họ "không phải là một mẫu thiết kế".


6

Tôi thường thích nghĩ về nó theo cách - nói - "điều hướng" bằng cách sử dụng GPS. Khi tìm hiểu 'thực tiễn tốt nhất' và 'mẫu thiết kế' - bạn học cách đi theo lộ trình định vị GPS. Nhưng khi bạn biết khu vực này, bạn sẽ thường biết rằng lái xe xuống đường phụ sẽ đưa bạn qua các khu vực có vấn đề, đưa bạn đến đó nhanh hơn và / hoặc tốt hơn. Điều này cũng tương tự khi nói đến những điều này - kinh nghiệm giúp bạn có thể giải cấu trúc hộp công cụ của mình và rút ngắn.

Học các mẫu thiết kế và học "thực hành tốt nhất" có nghĩa là bạn hiểu được ý tưởng đằng sau để bạn có thể chọn trong một tình huống nhất định. Bởi vì các tình huống thực tế thường phức tạp hơn so với các tình huống lý thuyết - bạn sẽ thường có những ràng buộc và các vấn đề không được tìm thấy trong sách giáo khoa. Khách hàng / Khách hàng muốn sản phẩm của họ nhanh và thường rẻ; Bạn cần phải làm việc với mã kế thừa; Bạn cần tương tác với các công cụ của bên thứ ba rất có thể là hộp đen và không hiệu quả; và tất cả các loại. Tình hình của bạn là cụ thể - thực tiễn tốt nhất và các mẫu nói chung hơn.

Một lý do chính mà nhiều người trên các trang web như SE sẽ cung cấp cho bạn câu trả lời 'thực tiễn tốt nhất' và 'mẫu thiết kế' là vì họ trả lời theo một giải pháp chung và trừu tượng và do đó nó giúp cung cấp một ngôn ngữ chung để giải quyết một loại các vấn đề. Và để giúp bạn học hỏi.

Vì vậy - không - các mẫu thiết kế không được tán thành trong môi trường phát triển Agile; tuy nhiên phát triển hiếm khi chung chung và đủ trừu tượng để phù hợp với một mô hình hoàn hảo và nhà phát triển (có kinh nghiệm) biết điều này.


5

Việc thêm một trường mới vào lớp UI / cơ sở dữ liệu / Lớp dữ liệu phải mất 2-3 giờ để thực hiện, trong khi như trong mã của anh ta thì phải mất 30 phút.

Nếu bạn muốn "tối ưu hóa" một thiết kế, bạn cần nói những gì bạn đang cố gắng tối ưu hóa.

Ví dụ: xe đạp đua là một phương tiện được tối ưu hóa ... và Boeing 747 cũng là một phương tiện được tối ưu hóa ... nhưng chúng được tối ưu hóa cho một loạt các yêu cầu khác nhau.

Ý tưởng về mẫu "MVC", ví dụ, tối ưu hóa cho những thứ như:

  • Các khung nhìn khác nhau của cùng một mô hình (khung nhìn độc lập với mô hình)
  • Mỗi lớp có thể được phát triển riêng (ví dụ bởi các nhóm khác nhau) và được kiểm tra riêng (kiểm tra đơn vị) trước khi tích hợp
  • Vân vân.

Trong khi đó mã của anh ta có thể được tối ưu hóa cho thứ khác, ví dụ:

  • Dòng mã tối thiểu
  • Một người dễ dàng thực hiện một thay đổi có ảnh hưởng đến tất cả các lớp (bằng cách không có các lớp thực sự khác biệt)
  • Vân vân.

Mô tả mẫu bắt đầu bằng một mô tả về vấn đề mà mẫu dự định sẽ giải quyết. Nếu anh ta nghĩ rằng đó là "cách tốt nhất" không sử dụng một mẫu cụ thể, thì (giả sử đó không phải là một mẫu ngu ngốc, giả sử đó là một mẫu đôi khi hữu ích) Tôi cho rằng anh ta không có / gặp phải vấn đề cụ thể mà mẫu đó tuyên bố để giải quyết, và / hoặc anh ấy đã có một vấn đề khác (lớn hơn hoặc cấp bách hơn, cạnh tranh) mà anh ấy đang cố gắng tối ưu hóa để thay thế.


"Bằng cách không có các lớp thực sự khác biệt" - hoặc, công bằng hơn, bằng cách có "hành vi mặc định" chấp nhận được truyền qua các lớp. Ví dụ: ứng dụng quản trị SQL dựa trên web là lớp trình bày tự động cập nhật khi lớp cơ sở dữ liệu thay đổi. Chỉ là, ngoài việc sử dụng hạn chế, họ không thực sự trình bày dữ liệu của bạn theo cách bạn muốn trình bày cho người dùng :-) Nửa giờ dường như cực kỳ nhanh chóng để thêm một trường mới, cho thấy rằng không có giao diện người dùng quan trọng nào để thiết kế kết nối với lĩnh vực mới, lớp hoặc cách khác.
Steve Jessop

4

Mẫu thiết kế là công cụ. Giống như các công cụ, có hai cách để sử dụng chúng: cách chính xác và cách không chính xác. Ví dụ, nếu tôi đưa cho bạn một cái tuốc nơ vít và một cái đinh, và yêu cầu bạn nối hai miếng gỗ lại với nhau, bạn nên yêu cầu tôi lấy một cái búa. Búa được sử dụng cho đinh, trong khi tua vít được sử dụng cho ốc vít.

Quá thường xuyên, một mẫu thiết kế được quảng cáo là One True Way, thường chỉ đúng khi có vấn đề cụ thể phát sinh. Các nhà phát triển cơ sở thường giống như trẻ em khi họ tìm thấy thứ gì đó mới để chơi cùng; họ muốn áp dụng mô hình thiết kế đó cho mọi thứ . Và không có gì sai với nó, miễn là cuối cùng họ biết rằng Mẫu A áp dụng cho Vấn đề B và Mẫu C áp dụng cho Vấn đề D. Giống như bạn không sử dụng tuốc nơ vít để lái đinh, bạn không sử dụng cụ thể mô hình chỉ vì nó tồn tại; bạn sử dụng mô hình vì đó là công cụ tốt nhất (được biết đến) cho công việc.

Mặt trái của các mẫu là chống mẫu. Những thứ đã được chứng minh hết lần này đến lần khác là xấu, thường là về thời gian thực hiện hoặc bộ nhớ. Tuy nhiên, cả mẫu và mẫu chống đều không tốt cho nhà phát triển mà không hiểu tại sao chúng tồn tại. Các nhà phát triển muốn nghĩ rằng những gì họ đang làm là mới và sáng tạo, nhưng hầu hết thời gian, họ không làm. Nó có thể đã được nghĩ đến trước đây. Những người trước họ đã tạo ra các mô hình vì kinh nghiệm.

Tất nhiên, các nhà phát triển cơ sở thường dường như nghĩ ra những cách mới để làm những việc cũ, và đôi khi những cách đó tốt hơn. Tuy nhiên, quá thường xuyên, nó trở thành một trường hợp của hiệu ứng Dunning-Kruger; nhà phát triển biết chỉ đủ để tạo ra một chương trình chức năng, nhưng không hiểu giới hạn của chính họ. Cách duy nhất để vượt qua điều này dường như là thông qua kinh nghiệm, cả tích cực và tiêu cực. Họ bỏ qua các mẫu vì họ tin rằng mình vượt trội, nhưng không biết rằng, trên thực tế, 10.000 nhà phát triển đã sử dụng một thiết kế cụ thể và sau đó loại bỏ nó vì nó thực sự xấu.

Agile ủng hộ "hoàn thành công việc một cách nhanh chóng" liên quan đến việc điều chỉnh nhanh chóng để phát triển nhu cầu của khách hàng. Nó không ủng hộ các mẫu thiết kế cũng không coi thường chúng. Nếu một mẫu là phương pháp nhanh nhất, đáng tin cậy nhất, thì nhà phát triển nên sử dụng nó. Nếu một mẫu cụ thể sẽ tốn nhiều thời gian hơn chỉ đơn giản là "hoàn thành nó", sử dụng một thứ không phải là mẫu có thể sẽ ổn (tất nhiên, giả sử, hiệu suất đó không bị suy giảm nghiêm trọng, v.v.). Nếu không tìm thấy mô hình đã biết nào, thiết kế riêng của họ được ưu tiên hơn là nói với khách hàng "không." Khách hàng, đặc biệt là khách hàng trả tiền, thường đúng.

Bất cứ ai tuyên bố rằng các mẫu là The Way, hoặc tuyên bố rằng các mẫu đó là The Bane Of Existence, đều sai. Các mẫu là các công cụ, có nghĩa là được áp dụng cho các tình huống cụ thể và có mức độ thành công khác nhau dựa trên hoàn cảnh. Đây là một Sự thật, một điều không phụ thuộc vào việc bạn có chọn MVC hay không, nếu bạn sử dụng Đối tượng truyền dữ liệu hay không, v.v. Điều quan trọng là triển khai mã trong khung thời gian ngắn hợp lý, hoạt động tốt cho người dùng, và là hợp lý không có lỗi logic.

Thông thường , các mẫu sẽ cho phép một hình thức thiết kế mạch lạc và sẽ hoạt động tốt hơn là bỏ qua tất cả các mẫu có lợi cho việc viết 100% ý tưởng ban đầu, nhưng bạn không thể tránh tất cả các mẫu. Ví dụ: nếu y = x + 5, bạn có thực sự sẽ viết y = x + (5 * 3 + 15/3) / 4, chỉ để tránh mô hình viết x + 5? Số bạn không. Bạn sẽ viết y = x + 5 và chuyển sang vấn đề tiếp theo.

Mọi người sử dụng các mẫu mỗi ngày, và điều đó không sao . Điều quan trọng nhất là có mã có chức năng logic, hiếm khi gặp sự cố và thân thiện với người dùng. Không có gì khác quan trọng hơn thế.


Tôi nghĩ rằng sự cảnh báo với điều này là các tình huống, dựa trên sự hiểu biết về vấn đề và miền hiện tại của bạn, bạn có thể tạo một lớp mới hoặc theo một mô hình áp dụng cho tình huống, nhưng rồi ngày hôm sau, một khách hàng mong muốn bạn thực hiện các tùy chỉnh cho chúng theo một số khía cạnh nhỏ mà các khách hàng khác sẽ không muốn trong phiên bản của họ. Hợp nhất một cơ sở mã phục vụ cho nhu cầu của 2 tá khách hàng và tránh việc sao chép mì ống dường như là không thể thực hiện được. Tôi vừa gặp phải vấn đề này ngày hôm nay khi tái cấu trúc một quy trình hợp nhất thư cũ.
Igneous01

2

Bạn không thể 'tránh các mẫu thiết kế', ngoại trừ tôi đoán bằng cách tránh thiết kế bất kỳ hai phần nào trong hệ thống của bạn theo cùng một cách (mà tôi không khuyến nghị và tôi nghi ngờ nhà phát triển cấp cao của bạn đang làm). Điều anh ta có lẽ có nghĩa là 'tránh mù quáng khi sử dụng một thiết kế chỉ vì nó tuân thủ một mẫu thiết kế'. Suy nghĩ về những gì bạn đang làm chắc chắn là một 'cách thực hành tốt nhất' và một trường đại học nên tồn tại để giảng dạy; thật đáng buồn, điều đó dường như không xảy ra.


2

Các mẫu thiết kế không đối nghịch với các thực hành nhanh. Điều gì là phản đối với các thực hành nhanh là sử dụng các mẫu thiết kế vì mục đích sử dụng các mẫu thiết kế, cách làm phổ biến giữa sinh viên mới tốt nghiệp và sinh viên để suy nghĩ theo cách "chúng ta sẽ giải quyết vấn đề này bằng cách sử dụng mẫu nhà máy".

Agile có nghĩa là chọn công cụ tốt nhất cho công việc, KHÔNG cố gắng định hình công việc để phù hợp với công cụ bạn đã chọn.
Và đó là những gì TẤT CẢ các thực tiễn phát triển ý thức thông thường (mặc dù tất nhiên bạn thường phải thỏa hiệp vì việc lựa chọn các công cụ bạn có thể chọn thường bị hạn chế bởi các tiêu chuẩn của công ty, hạn chế giấy phép (như GPL và đôi khi các công cụ nguồn mở khác thường không thể được sử dụng, đặc biệt là khi xây dựng phần mềm để bán lại) và những thứ tương tự.

Đồng nghiệp / bạn bè của bạn có thể phản đối mã của bạn không phải vì nó sử dụng các mẫu thiết kế, mà bởi vì đó là một cấu trúc nhân tạo được thiết kế để hiển thị việc sử dụng một mẫu cụ thể khi một thiết kế khác sẽ tốt hơn (mặc dù thường chủ quan, tôi (và chủ quan) nhiều người với tôi không nghi ngờ gì) đã thấy rất nhiều ví dụ trong đó việc sử dụng bắt buộc một mẫu thiết kế cụ thể dẫn đến mã xấu, khó bảo trì và mã kém hiệu quả).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.