Nguyên tắc RẮN so với YAGNI

Khi nào các nguyên tắc RẮN trở thành YAGNI?

Là lập trình viên, chúng tôi luôn luôn đánh đổi, giữa sự phức tạp, khả năng bảo trì, thời gian để xây dựng và vv. Trong số những người khác, hai trong số những hướng dẫn thông minh nhất để đưa ra lựa chọn là trong suy nghĩ của tôi về các nguyên tắc RẮN và YAGNI. Nếu bạn không cần nó; đừng xây dựng nó, và giữ nó sạch sẽ

Ví dụ, khi tôi xem loạt dimecast trên RẮN , tôi thấy nó bắt đầu như một chương trình khá đơn giản và kết thúc là một chương trình khá phức tạp (kết thúc có sự phức tạp cũng nằm trong mắt của kẻ si tình), nhưng nó vẫn làm tôi tự hỏi: khi nào thì các nguyên tắc RẮN biến thành thứ bạn không cần? Tất cả các nguyên tắc vững chắc là cách làm việc cho phép sử dụng để thực hiện các thay đổi ở giai đoạn sau. Nhưng nếu vấn đề cần giải quyết là một vấn đề khá đơn giản và đó là một ứng dụng vứt đi thì sao? Hoặc là các nguyên tắc RẮN một cái gì đó luôn luôn áp dụng?

Như đã hỏi trong các ý kiến:

• Nguyên tắc RẮN
• YAGNI

Luôn luôn khó để đánh giá một cách tiếp cận dựa trên screencast, vì các vấn đề được chọn cho các bản demo thường rất nhỏ đến nỗi việc áp dụng các nguyên tắc như RẮN nhanh chóng làm cho nó có vẻ như giải pháp hoàn toàn bị áp đảo.

Tôi muốn nói rằng các nguyên tắc RẮN hầu như luôn hữu ích. Một khi bạn trở nên thành thạo với họ, sử dụng chúng dường như không phải là điều bạn phải cố tình nghĩ đến. Nó chỉ trở nên tự nhiên. Tôi đã thấy nhiều ứng dụng một lần vứt đi trở nên nhiều hơn thế, vì vậy bây giờ tôi sợ nói rằng tôi sẽ vứt bỏ thứ gì đó, bởi vì bạn không bao giờ biết.

Cách tiếp cận tôi thường làm là nếu tôi đang viết một ứng dụng đơn giản cho một nhiệm vụ cụ thể, đôi khi tôi sẽ từ bỏ các nguyên tắc tên lớn để ủng hộ một vài dòng mã hoạt động. Nếu tôi thấy rằng tôi sẽ quay lại ứng dụng đó để thực hiện các thay đổi tiếp theo, tôi sẽ dành thời gian để làm cho nó RẮN (ít nhất là phần nào, vì việc áp dụng 100% các nguyên tắc hiếm khi khả thi).

Trong các ứng dụng lớn hơn, tôi bắt đầu nhỏ và khi chương trình phát triển, tôi áp dụng các nguyên tắc RẮN nếu có thể. Bằng cách này, tôi không cố gắng thiết kế toàn bộ mọi thứ từ phía trước đến enum cuối cùng. Điều đó, với tôi, là điểm ngọt ngào nơi YAGNI và RẮN cùng tồn tại.

Hãy suy nghĩ về vấn đề trước tiên và quan trọng nhất. Nếu bạn áp dụng một cách mù quáng các nguyên tắc của YAGNI hoặc RẮN, bạn có thể tự làm tổn thương mình sau này. Một điều mà tôi hy vọng tất cả chúng ta có thể hiểu là không có phương pháp thiết kế "một" nào phù hợp với tất cả các vấn đề. Bạn có thể thấy bằng chứng về điều đó khi một cửa hàng bán một chiếc mũ được quảng cáo là "một cỡ vừa với tất cả", nhưng nó không vừa với đầu bạn. Nó quá lớn hoặc quá nhỏ.

Thay vào đó, tốt hơn là nên hiểu các nguyên tắc và vấn đề mà RẮN đang cố gắng giải quyết; cũng như các nguyên tắc và vấn đề mà YAGNI đang cố gắng giải quyết. Bạn sẽ thấy rằng một người quan tâm đến kiến ​​trúc của ứng dụng của bạn và người kia quan tâm đến toàn bộ quá trình phát triển. Mặc dù có thể có sự chồng chéo trong một số trường hợp, chúng là những vấn đề khác nhau rõ rệt.

YAGNI (Bạn không phải là cần thiết khỏe. Nếu chúng ta đang trải qua một con sông rộng một dặm và cần hỗ trợ một số xe đầu kéo, tất nhiên chúng ta sẽ cần công việc nền tảng bổ sung đó. Về bản chất, YAGNI đang bảo bạn nhìn vào bức tranh lớn hơn và thiết kế cho các nhu cầu hiện tại . Nó đang giải quyết vấn đề làm cho một cái gì đó quá phức tạp bởi vì chúng tôi đang dự đoán một số nhu cầu tiềm năng mà khách hàng chưa xác định được.

RẮN quan tâm đến cách chúng tôi đảm bảo các phần của cây cầu khớp với nhau đúng cách và có thể được duy trì theo thời gian. Bạn có thể áp dụng các nguyên tắc RẮN cho cây cầu gỗ cũng như cây cầu bê tông tái nhiễm thép.

Nói tóm lại, hai khái niệm này không nhất thiết là xung đột với nhau. Khi bạn gặp một tình huống mà bạn tin rằng họ đang ở đó, đã đến lúc nhìn vào bức tranh lớn. Tùy thuộc vào kết luận của bạn, bạn có thể quyết định loại bỏ một phần nguyên tắc RẮN hoặc bạn có thể quyết định rằng bạn thực sự cần nó.

Nguyên tắc RẮN không cần thiết khi nó là một ứng dụng vứt đi; nếu không thì chúng luôn luôn cần thiết

RẮN và YAGNI không mâu thuẫn: Thiết kế lớp tốt giúp ứng dụng dễ bảo trì hơn. YAGNI chỉ tuyên bố rằng bạn không nên thêm khả năng cho ứng dụng của mình là sự quái dị có thể định cấu hình này có thể làm mọi thứ dưới ánh mặt trời - trừ khi thực sự cần nó.

Đó là sự khác biệt giữa lớp Xe có ranh giới được xác định rõ (RẮN) và lớp xe có khả năng tự phục hồi (YAGNI) trước khi khách hàng yêu cầu.

Không có gì luôn áp dụng! Đừng để các phi hành gia kiến ​​trúc sợ bạn! Điều quan trọng là cố gắng và hiểu những vấn đề mà các nguyên tắc này đang cố gắng giải quyết để bạn có thể đưa ra quyết định sáng suốt về việc áp dụng chúng.

Gần đây tôi đã cố gắng hiểu khi nào tôi nên sử dụng Nguyên tắc Trách nhiệm duy nhất ( đây là những gì tôi nghĩ ra.)

Hi vọng điêu nay co ich!

Có một câu trích dẫn được gán cho Einstein (có lẽ là một biến thể của một người thật ):

Mọi thứ nên được làm đơn giản nhất có thể, nhưng không đơn giản hơn.

Và đó ít nhiều là cách tiếp cận tôi thực hiện khi đối mặt với sự đánh đổi RẮN vs YAGNI: áp dụng chúng theo cách khác, bởi vì bạn không bao giờ biết liệu chương trình có mã 'vứt đi' hay không. Vì vậy, chỉ cần thêm một lớp bụi bẩn hoạt động, sau đó đánh bóng nó vào một giao diện sạch hơn ... và lặp lại cho đến khi bạn hội tụ đến mức entropy phù hợp. Hy vọng.

Có nhiều cách để thiết kế một chương trình cho một vấn đề nhất định; RẮN là một nỗ lực để xác định các thuộc tính của một thiết kế tốt. Việc sử dụng đúng RẮN được cho là dẫn đến một chương trình dễ dàng lý luận và sửa đổi hơn.

YAGNI và KISS có liên quan đến phạm vi tính năng. Một chương trình giải quyết nhiều loại vấn đề phức tạp và trừu tượng hơn. Nếu bạn không cần tính tổng quát đó, bạn đã dành thời gian và công sức để tạo mã khó hiểu và duy trì hơn nhưng không cung cấp giá trị gia tăng.

Một chương trình được thiết kế tốt không nhất thiết chỉ tập trung vào các tính năng mà nó cần. Một chương trình chỉ tập trung vào các tính năng mà nó cần không nhất thiết phải được thiết kế tốt. Không có sự đánh đổi, chỉ có hai trục trực giao trong không gian ra quyết định. Một chương trình lý tưởng là cả mô-đun và chỉ có các tính năng cần thiết.

Tôi nghĩ bạn nên bắt đầu YAGNI và bất cứ khi nào có nhu cầu, hãy GIẢI QUYẾT nó.

Ý tôi là RẮN ở đó vì vậy khi bạn thêm một lớp mới, bạn sẽ không phải cấu trúc lại, chỉ cần chuyển đổi một triển khai (ví dụ), theo ý kiến ​​của tôi, hãy viết mã của bạn một cách đơn giản và khi bạn thấy rằng bạn đang thay đổi công cụ - thay đổi nó bằng RẮN (tức là việc tái cấu trúc đáng sợ RẮN được cho là sẽ cứu bạn khỏi - điều đó không tệ lắm khi bạn chỉ mới bắt đầu).

Bạn sẽ không lãng phí thời gian vì dù sao bạn cũng phải thực hiện công việc (lúc đầu) và bất cứ khi nào cần, mã của bạn đều đẹp và gọn gàng.

Tôi đoán bạn có thể gọi nó là đánh giá lười biếng của RẮN.