YAGNI - Thực hành nhanh nhẹn không được nêu tên?

Question

Khi tôi ngày càng hấp thu suy nghĩ của Agile vào cách tôi làm việc, yagni ("bạn sẽ không cần nó") dường như ngày càng trở nên quan trọng hơn. Dường như với tôi là một trong những quy tắc hiệu quả nhất để lọc ra các ưu tiên sai lầm và quyết định xem không phải là để làm việc tiếp theo.

Tuy nhiên, yagni có vẻ là một khái niệm hầu như không được nói đến ở đây tại SO. Tôi chạy tìm kiếm bắt buộc, và nó chỉ hiển thị trong một tiêu đề câu hỏi - và sau đó trong vai trò phụ.

Tại sao điều này? Tôi có đánh giá quá cao tầm quan trọng của nó không?

Tuyên bố từ chối trách nhiệm. Để từ chối các câu trả lời, tôi chắc chắn tôi sẽ phản đối, hãy để tôi nhấn mạnh rằng yagni là đối diện với nhanh chóng và bẩn. Nó khuyến khích bạn tập trung thời gian quý báu và nỗ lực của bạn vào việc nhận được các phần bạn cần đúng.

Dưới đây là một số câu hỏi thường gặp nhất mà mọi người có thể hỏi.

Bài kiểm tra đơn vị của tôi có được chọn dựa trên yêu cầu của người dùng hay cấu trúc khung không?

Tôi có đang cài đặt (và kiểm tra và duy trì) Các bài kiểm tra đơn vị chỉ có ở đó vì chúng nằm ngoài khuôn khổ không?

Có bao nhiêu mã được tạo bởi khung của tôi mà tôi chưa bao giờ xem (nhưng vẫn có thể cắn tôi một ngày, mặc dù yagni)?

Tôi dành bao nhiêu thời gian cho công cụ của mình thay vì vấn đề của người dùng?

Khi lập trình ghép nối, giá trị vai trò của người quan sát thường nằm trong "yagni".

Bạn có sử dụng công cụ CRUD không? Nó cho phép (nay, khuyến khích) bạn sử dụng nó như một công cụ _RU_, hoặc một công cụ C__D, hoặc bạn đang tạo ra bốn đoạn mã (cộng với bốn bài kiểm tra đơn vị) khi bạn chỉ cần một hoặc hai?

Answer 1

TDD đã gộp YAGNI theo cách. Nếu bạn thực hiện đúng TDD, nghĩa là, chỉ viết những bài kiểm tra có chức năng cần thiết, sau đó phát triển mã đơn giản nhất để vượt qua bài kiểm tra, sau đó bạn tuân theo nguyên tắc YAGNI theo mặc định. Theo kinh nghiệm của tôi, chỉ khi tôi rời khỏi hộp TDD và bắt đầu viết mã trước khi kiểm tra, kiểm tra những thứ mà tôi không thực sự cần, hoặc viết mã nhiều hơn cách đơn giản nhất có thể để vượt qua bài kiểm tra mà tôi vi phạm YAGNI .

Theo kinh nghiệm của tôi, sau này là giả mạo phổ biến nhất của tôi khi thực hiện TDD - tôi có xu hướng nhảy lên phía trước và bắt đầu viết mã để vượt qua bài kiểm tra tiếp theo. Điều đó thường dẫn đến việc tôi làm tổn hại đến các bài kiểm tra còn lại bằng cách có một ý tưởng được định sẵn dựa trên mã của tôi thay vì các yêu cầu của những gì cần phải được kiểm tra.

YMMV.

Answer 2

Tôi đã thấy rất nhiều bài đăng trên SO đề cập đến tối ưu hóa sớm là một dạng yagni hoặc ít nhất là ydniy (bạn không cần đến nó).

Answer 3

Yagni và KISS (giữ cho nó đơn giản, ngu ngốc) về cơ bản là cùng một nguyên tắc. Thật không may, tôi thấy KISS đã đề cập đến thường xuyên như tôi thấy "yagni".

Trong phần hoang dã của tôi, nguyên nhân phổ biến nhất của sự chậm trễ và thất bại của dự án là việc thực hiện kém các thành phần không cần thiết, vì vậy tôi đồng ý với ý kiến ​​cơ bản của bạn.

Answer 4

Tôi không thấy YAGNI như là đối diện của nhanh chóng và bẩn, thực sự. Nó đang làm chỉ là những gì là cần thiết và không có nhiều hơn và không lập kế hoạch như phần mềm ai đó viết đã kéo dài 50 năm. Nó có thể hiếm khi xảy ra bởi vì không có nhiều câu hỏi để hỏi xung quanh nó, ít nhất là trong tâm trí tôi. Tương tự như quy tắc "không lặp lại chính mình" và "giữ cho nó đơn giản, ngu ngốc" trở nên phổ biến nhưng không nhất thiết phải được phân tích và phân tích theo 101 cách. Một số điều đơn giản là nó thường được nhận ngay sau khi thực hành một chút. Một số điều được phát triển đằng sau hậu trường và nếu bạn quay lại và nhìn bạn có thể nhận thấy chúng có thể là một cách khác để nêu ra mọi thứ.

Answer 5

Vấn đề tôi thấy là mọi người có xu hướng xô thậm chí viết các nhà máy, sử dụng DI container (trừ khi bạn đã có sẵn trong codebase của bạn) theo YAGNI. Tôi đồng ý với JB King ở đó. Đối với nhiều người, tôi đã làm việc với YAGNI dường như là giấy phép để cắt góc/viết mã sloppy.

Ví dụ: tôi đã viết API PinPad để tóm tắt nhiều mô hình/PINPad của nhà sản xuất. Tôi tìm thấy trừ khi tôi có cấu trúc tổng thể, tôi không thể viết ngay cả Bài kiểm tra Đơn vị của mình. Có thể tôi không phải là một người dày dạn kinh nghiệm của TDD. Tôi chắc rằng sẽ có những ý kiến ​​khác nhau về việc liệu tôi có làm gì không YAGNI hay không.

Answer 6

Tự do thay đổi ổ đĩa YAGNI. Trong một dự án thác nước, câu thần chú là phạm vi kiểm soát. Phạm vi được kiểm soát bằng cách thiết lập một hợp đồng với khách hàng. Do đó, khách hàng nhồi nhét tất cả những gì họ có thể nghĩ đến trong tài liệu phạm vi biết rằng những thay đổi về phạm vi sẽ rất khó khăn khi hợp đồng đã được ký kết. Kết quả là, bạn kết thúc với các ứng dụng có danh sách các tính năng giặt là, không phải là một tập hợp các tính năng có giá trị.

Với dự án nhanh nhẹn, chủ sở hữu sản phẩm sẽ xây dựng một phần tồn đọng sản phẩm được ưu tiên. Nhóm phát triển xây dựng các tính năng dựa trên giá trị ưu tiên, tức là. Kết quả là, những thứ quan trọng nhất được xây dựng trước tiên. Bạn kết thúc bằng một ứng dụng có các tính năng được người dùng đánh giá cao. Những thứ không quan trọng rơi khỏi danh sách hoặc không được hoàn thành. Đó là YAGNI.

Trong khi YAGNI không phải là thực tế, đó là kết quả của danh sách backlog được ưu tiên. Các đối tác kinh doanh đánh giá tính linh hoạt dành cho doanh nghiệp cho rằng họ có thể thay đổi và reprioritized sản phẩm tồn đọng từ lặp lại để lặp lại. Đủ để giải thích rằng YAGNI là lợi ích thu được khi chúng tôi sẵn sàng chấp nhận thay đổi, thậm chí vào cuối quá trình.