RẮN so với tránh trừu tượng sớm

Tôi hiểu những gì RẮN phải hoàn thành và sử dụng nó thường xuyên trong các tình huống mà tính mô đun là quan trọng và các mục tiêu của nó rõ ràng hữu ích. Tuy nhiên, có hai điều ngăn tôi áp dụng nó một cách nhất quán trên cơ sở mã của mình:

• Tôi muốn tránh trừu tượng sớm. Theo kinh nghiệm của tôi, vẽ các đường trừu tượng mà không có trường hợp sử dụng cụ thể (loại tồn tại bây giờ hoặc trong tương lai gần ) dẫn đến chúng bị vẽ sai chỗ. Khi tôi cố gắng sửa đổi mã như vậy, các dòng trừu tượng sẽ gây cản trở hơn là giúp đỡ. Do đó, tôi có xu hướng sai lầm khi không vẽ bất kỳ đường trừu tượng nào cho đến khi tôi có một ý tưởng tốt về nơi chúng sẽ hữu ích.

• Tôi thấy thật khó để biện minh cho việc tăng tính mô đun cho mục đích riêng của mình nếu nó làm cho mã của tôi dài dòng hơn, khó hiểu hơn, v.v. và không loại bỏ bất kỳ sự trùng lặp nào. Tôi thấy mã thủ tục đơn giản, được kết hợp chặt chẽ hoặc mã đối tượng đôi khi dễ hiểu hơn mã ravioli rất được chứng thực bởi vì dòng chảy đơn giản và tuyến tính. Nó cũng dễ viết hơn nhiều.

Mặt khác, suy nghĩ này thường dẫn đến các đối tượng của Thiên Chúa. Tôi thường tái cấu trúc những thứ này một cách bảo thủ, chỉ thêm các dòng trừu tượng rõ ràng khi tôi thấy các mẫu rõ ràng đang nổi lên. Điều gì, nếu có bất cứ điều gì sai với các đối tượng của Chúa và mã được ghép chặt chẽ nếu bạn rõ ràng không cần nhiều mô đun hơn, không có sự trùng lặp đáng kể và mã có thể đọc được?

EDIT: Theo như các nguyên tắc RẮN cá nhân, tôi muốn nhấn mạnh rằng Thay thế Liskov là IMHO một sự chính thức hóa của lẽ thường và nên được áp dụng ở mọi nơi, vì sự trừu tượng không có ý nghĩa nếu nó không có ý nghĩa. Ngoài ra, mỗi lớp nên có một trách nhiệm duy nhất ở một mức độ trừu tượng nào đó, mặc dù nó có thể là một mức rất cao với tất cả các chi tiết triển khai được nhồi nhét vào một lớp 2.000 dòng lớn. Về cơ bản, sự trừu tượng của bạn sẽ có ý nghĩa nơi bạn chọn để trừu tượng. Các nguyên tắc tôi đặt câu hỏi trong trường hợp mô đun hóa không hữu ích rõ ràng là đóng mở, phân biệt giao diện và đặc biệt là đảo ngược phụ thuộc, vì đây là về mô đun hóa, không chỉ có ý nghĩa trừu tượng.

Sau đây là những nguyên tắc đơn giản bạn có thể áp dụng để giúp bạn hiểu cách cân bằng thiết kế hệ thống của mình:

• Nguyên tắc trách nhiệm duy nhất: Strong RẮN. Bạn có thể có một đối tượng rất lớn về số lượng phương thức hoặc số lượng dữ liệu và vẫn duy trì nguyên tắc này. Ví dụ như đối tượng Ruby String. Đối tượng này có nhiều phương thức hơn bạn có thể lắc một thanh, nhưng nó vẫn chỉ có một trách nhiệm: giữ một chuỗi văn bản cho ứng dụng. Ngay khi đối tượng của bạn bắt đầu nhận một trách nhiệm mới, hãy bắt đầu suy nghĩ kỹ về điều đó. Vấn đề bảo trì là tự hỏi "tôi sẽ tìm mã này ở đâu nếu tôi gặp vấn đề với nó sau này?"
• Tính đơn giản: Albert Einstein đã nói "Hãy làm mọi thứ đơn giản nhất có thể, nhưng không đơn giản hơn". Bạn có thực sự cần phương pháp mới đó không? Bạn có thể thực hiện những gì bạn cần với các chức năng hiện có? Nếu bạn thực sự nghĩ rằng cần phải có một phương pháp mới, bạn có thể thay đổi một phương thức hiện có để đáp ứng tất cả những gì bạn cần không? Về bản chất tái cấu trúc khi bạn xây dựng công cụ mới.

Về bản chất, bạn đang cố gắng làm những gì có thể để không tự bắn vào chân mình khi đến lúc phải bảo trì phần mềm. Nếu các đối tượng lớn của bạn là trừu tượng hợp lý, thì có rất ít lý do để phân tách chúng chỉ vì ai đó đã đưa ra một số liệu nói rằng một lớp không nên nhiều hơn X dòng / phương thức / thuộc tính / vv. Nếu bất cứ điều gì, đó là những hướng dẫn và quy tắc không khó và nhanh.

Tôi nghĩ phần lớn bạn đã trả lời câu hỏi của riêng bạn. RẮN là tập hợp các hướng dẫn về cách cấu trúc lại mã của bạn, khi các khái niệm cần được tăng lên mức độ trừu tượng.

Giống như tất cả các ngành học sáng tạo khác, không có sự tuyệt đối - chỉ là sự đánh đổi. Bạn càng làm điều đó thì "càng dễ" quyết định khi nào là đủ cho miền yêu cầu hoặc yêu cầu hiện tại của bạn.

Đã nói rằng - trừu tượng hóa là trái tim của sự phát triển phần mềm - vì vậy nếu không có lý do chính đáng nào để không làm điều đó, thì thực hành sẽ giúp bạn làm tốt hơn và bạn sẽ có cảm giác tốt cho sự đánh đổi. Vì vậy, ủng hộ nó trừ khi nó trở nên bất lợi.

I want to avoid premature abstraction.In my experience drawing abstraction lines without concrete use cases... 

Điều này đúng một phần và sai một phần.

Sai
Đây không phải là lý do để ngăn người ta áp dụng các nguyên tắc OO / RẮN. Nó chỉ ngăn chặn việc áp dụng chúng quá sớm.

Đó là ...

Phải
Không tái cấu trúc mã cho đến khi nó có thể tái cấu trúc; khi nó là yêu cầu hoàn thành Hoặc, khi "trường hợp sử dụng" đều ở đó như bạn nói.

I find simple, tightly coupled procedural or God object code is sometimes easier to understand than very well-factored...

Khi làm việc một mình hoặc trong một silo
Vấn đề không làm OO không rõ ràng ngay lập tức. Sau khi bạn viết phiên bản đầu tiên của chương trình:

Code is fresh in your head
Code is familiar
Code is easy to mentally compartmentalize
You wrote it

3/4 những điều tốt đẹp này nhanh chóng chết trong một thời gian ngắn.

Cuối cùng, bạn nhận ra rằng bạn có các đối tượng Thiên Chúa (Đối tượng có nhiều chức năng), vì vậy bạn nhận ra các chức năng riêng lẻ. Đóng gói. Đặt chúng trong các thư mục. Sử dụng giao diện một lần trong một thời gian. Làm cho mình một ưu tiên cho bảo trì dài hạn. Đặc biệt là vì các phương pháp không được tái cấu trúc có xu hướng nở rộ vô tận và trở thành phương pháp của Chúa.

Trong một nhóm
Các vấn đề không làm OO ngay lập tức đáng chú ý. Mã OO tốt ít nhất là phần nào tự viết tài liệu và có thể đọc được. Đặc biệt khi kết hợp với mã xanh tốt. Ngoài ra, việc thiếu cấu trúc khiến việc phân tách các nhiệm vụ và tích hợp trở nên phức tạp hơn nhiều.

Không có gì sai với các đối tượng lớn và mã được ghép chặt chẽ khi chúng phù hợp và khi không có gì được thiết kế tốt hơn . Đây chỉ là một biểu hiện khác của một quy tắc ngón tay cái biến thành giáo điều.

Khớp nối lỏng lẻo và các vật thể nhỏ, đơn giản có xu hướng mang lại lợi ích cụ thể trong nhiều trường hợp phổ biến, do đó, nói chung nên sử dụng chúng. Vấn đề nằm ở những người không hiểu lý do căn bản đằng sau những nguyên tắc mù quáng cố gắng áp dụng chúng một cách phổ biến, ngay cả khi họ không áp dụng.

Tôi có xu hướng tiếp cận điều này nhiều hơn từ quan điểm của You Ain't Gonna Need It. Bài đăng này sẽ tập trung vào một mục cụ thể: kế thừa.

Trong thiết kế ban đầu của tôi, tôi tạo ra một hệ thống phân cấp những thứ tôi biết sẽ có hai hoặc nhiều hơn. Rất có thể họ sẽ cần nhiều mã giống nhau, vì vậy, đáng để thiết kế nó ngay từ đầu. Sau khi mã ban đầu được đặt ra và tôi cần thêm nhiều tính năng / chức năng, tôi nhìn vào những gì tôi có và nghĩ, "Có phải cái gì đó tôi đã thực hiện cùng chức năng hoặc tương tự không?" Nếu vậy, đó rất có thể là một sự trừu tượng mới đang cầu xin được phát hành.

Một ví dụ điển hình của việc này là một khung MVC. Bắt đầu từ đầu, bạn tạo một trang lớn với mã phía sau. Nhưng sau đó bạn muốn thêm một trang khác. Tuy nhiên, một mã phía sau đã triển khai rất nhiều logic mà trang mới yêu cầu. Vì vậy, bạn trừu tượng hóa một Controllerlớp / giao diện sẽ triển khai logic cụ thể cho trang đó, để lại những thứ phổ biến trong mã "thần" ban đầu.

Nếu BẠN biết là nhà phát triển khi nào KHÔNG áp dụng các nguyên tắc vì tương lai của mã, thì tốt cho bạn.

Tôi hy vọng RẮN vẫn ở trong tâm trí bạn để biết khi nào mọi thứ cần được trừu tượng hóa để tránh sự phức tạp và cải thiện chất lượng của mã nếu nó bắt đầu giảm giá trị mà bạn đã nêu.

Quan trọng hơn, hãy xem xét rằng phần lớn các nhà phát triển đang làm công việc hàng ngày và không quan tâm nhiều như bạn. Nếu ban đầu bạn đặt ra các phương thức chạy dài, các nhà phát triển khác đi vào mã sẽ nghĩ gì khi họ duy trì hoặc mở rộng nó? ... Vâng, bạn đã đoán, các hàm BIGGER, các lớp chạy lâu hơn và THÊM các đối tượng thần, và họ không có các nguyên tắc trong tâm trí để có thể bắt được mã đang phát triển và gói gọn nó một cách chính xác. Mã "có thể đọc được" của bạn giờ trở thành một mớ hỗn độn.

Vì vậy, bạn có thể lập luận rằng một nhà phát triển tồi sẽ làm điều đó bất kể, nhưng ít nhất bạn có lợi thế tốt hơn nếu mọi thứ được giữ đơn giản và được tổ chức tốt ngay từ đầu.

Tôi không đặc biệt quan tâm đến "Bản đồ đăng ký" toàn cầu hoặc "Đối tượng của Chúa" nếu chúng đơn giản. Nó thực sự phụ thuộc vào thiết kế hệ thống, đôi khi bạn có thể thoát khỏi nó và vẫn đơn giản, đôi khi bạn không thể.

Chúng ta cũng đừng quên rằng các chức năng lớn và các Đối tượng Thần có thể chứng minh cực kỳ khó kiểm tra. Nếu bạn muốn duy trì Agile và cảm thấy "An toàn" khi bao thanh toán lại và thay đổi mã, bạn cần thử nghiệm. Các bài kiểm tra rất khó để viết khi các chức năng hoặc đối tượng làm nhiều việc.

Vấn đề với một đối tượng thần là bạn thường có thể phá vỡ nó thành nhiều mảnh. Theo định nghĩa, nó làm nhiều hơn một điều. Toàn bộ mục đích của việc chia nó thành các lớp nhỏ hơn là để bạn có thể có một lớp thực hiện tốt một việc (và bạn cũng không nên kéo dài định nghĩa về "một điều"). Điều này có nghĩa là, đối với bất kỳ lớp cụ thể nào, một khi bạn biết một điều cần phải làm, bạn sẽ có thể đọc nó một cách khá dễ dàng và nói liệu nó có làm đúng một điều hay không.

Tôi nghĩ rằng có là một điều như vậy là có quá nhiều mô đun, và quá nhiều sự linh hoạt, nhưng mà của nhiều hơn một vấn đề trong thiết kế và quá kỹ thuật, nơi bạn đang kế toán cho các yêu cầu mà bạn thậm chí không biết khách hàng muốn. Rất nhiều ý tưởng thiết kế được định hướng xung quanh giúp dễ dàng kiểm soát các thay đổi về cách mã được chạy, nhưng nếu không ai mong đợi sự thay đổi, thì việc bao gồm tính linh hoạt là vô nghĩa.

Tôi sử dụng một hướng dẫn đơn giản hơn: nếu bạn có thể viết các bài kiểm tra đơn vị cho nó và không có sự sao chép mã, nó đủ trừu tượng. Thêm vào đó, bạn đang ở một vị trí tốt để tái cấu trúc sau này.

Ngoài ra, bạn nên ghi nhớ RẮN, nhưng là một hướng dẫn hơn là một quy tắc.

Điều gì, nếu có bất cứ điều gì sai với các đối tượng của Chúa và mã được ghép chặt chẽ nếu bạn rõ ràng không cần nhiều mô đun hơn, không có sự trùng lặp đáng kể và mã có thể đọc được?

Nếu ứng dụng đủ nhỏ, mọi thứ đều có thể duy trì. Trong các ứng dụng lớn hơn, các đối tượng của Chúa nhanh chóng trở thành một vấn đề. Cuối cùng thực hiện một tính năng mới đòi hỏi phải sửa đổi 17 đối tượng Chúa. Mọi người không làm rất tốt theo các thủ tục 17 bước. Các đối tượng Thần liên tục được sửa đổi bởi nhiều nhà phát triển và những thay đổi đó phải được hợp nhất nhiều lần. Bạn không muốn đến đó.

Tôi chia sẻ mối quan tâm của bạn về sự trừu tượng quá mức và không phù hợp, nhưng tôi không nhất thiết phải quá quan tâm đến sự trừu tượng quá sớm.

Điều đó có vẻ như mâu thuẫn, nhưng sử dụng một sự trừu tượng không có khả năng gây ra vấn đề miễn là bạn không quá quan tâm đến nó quá sớm - tức là miễn là bạn sẵn sàng và có thể tái cấu trúc nếu cần thiết.

Điều này ngụ ý là một số mức độ tạo mẫu, thử nghiệm và quay lui trong mã.

Điều đó nói rằng, không có quy tắc xác định đơn giản để tuân theo sẽ giải quyết tất cả các vấn đề. Kinh nghiệm được tính rất nhiều, nhưng bạn phải có được kinh nghiệm đó bằng cách phạm sai lầm. Và luôn có nhiều sai lầm hơn để làm cho những sai lầm trước đó sẽ không giúp bạn chuẩn bị.

Mặc dù vậy, hãy coi các nguyên tắc trong sách giáo khoa là điểm khởi đầu, sau đó học lập trình rất nhiều và xem các nguyên tắc đó hoạt động như thế nào. Nếu có thể đưa ra những hướng dẫn tốt hơn, chính xác và đáng tin cậy hơn những điều như RẮN, thì có lẽ ai đó đã làm như vậy ngay bây giờ - và ngay cả khi họ có, những nguyên tắc cải tiến đó vẫn sẽ không hoàn hảo, và mọi người sẽ hỏi về những hạn chế trong những điều đó .

Cũng rất tốt - nếu bất cứ ai cũng có thể cung cấp một thuật toán xác định, rõ ràng để thiết kế và mã hóa chương trình, thì chỉ có một chương trình cuối cùng để con người viết - chương trình sẽ tự động viết tất cả các chương trình trong tương lai mà không cần sự can thiệp của con người.

Vẽ các đường trừu tượng thích hợp là điều mà người ta rút ra từ kinh nghiệm. Bạn sẽ phạm sai lầm khi làm điều đó là không thể phủ nhận.

RẮN là một hình thức tập trung của trải nghiệm đó được trao cho bạn bởi những người có được trải nghiệm này một cách khó khăn. Bạn đã đóng đinh nó rất nhiều khi bạn nói rằng bạn sẽ không tạo ra sự trừu tượng trước khi bạn thấy cần nó. Vâng, kinh nghiệm RẮN cung cấp cho bạn sẽ giúp bạn giải quyết các vấn đề mà bạn chưa từng tồn tại . Nhưng hãy tin tôi ... có rất thật.

RẮN là về tính mô đun, tính mô đun là về khả năng bảo trì và khả năng bảo trì là cho phép bạn giữ một lịch trình làm việc nhân đạo một khi phần mềm đạt đến sản xuất và khách hàng bắt đầu nhận thấy các lỗi mà bạn không mắc phải.

Lợi ích lớn nhất của tính mô đun là khả năng kiểm tra. Hệ thống của bạn càng nhiều mô-đun thì càng dễ kiểm tra và bạn có thể xây dựng nền tảng vững chắc nhanh hơn để giải quyết các khía cạnh khó khăn hơn của vấn đề. Vì vậy, vấn đề của bạn có thể không đòi hỏi tính mô đun này, nhưng thực tế nó sẽ cho phép bạn tạo mã kiểm tra tốt hơn nhanh hơn là không có gì phải cố gắng để mô đun hóa.

Nhanh nhẹn là tất cả về nỗ lực để đạt được sự cân bằng tinh tế giữa vận chuyển nhanh và cung cấp chất lượng tốt. Agile không có nghĩa là chúng ta nên cắt giảm, trên thực tế, các dự án nhanh nhẹn thành công nhất mà tôi đã tham gia là những dự án rất chú ý đến các hướng dẫn như vậy.

Một điểm quan trọng dường như đã bị bỏ qua là RẮN được thực hành cùng với TDD. TDD có xu hướng làm nổi bật những gì "phù hợp" trong bối cảnh cụ thể của bạn và giúp giảm bớt rất nhiều sự tương đồng có vẻ như trong lời khuyên.