Có thể khám phá cho các nhà phát triển một vấn đề khi sử dụng các nguyên tắc RẮN?

Tôi thực hiện các ứng dụng kinh doanh trong đó tất cả các nhà phát triển khác đã quen làm các ứng dụng CRUD cơ bản hoặc chỉ tập trung vào việc tạo các giao diện đẹp / chức năng và tôi đang nhận được rất nhiều điều sau đây.

"Với cách chúng tôi sử dụng để làm điều đó Nhân viên sẽ có tất cả những điều bạn có thể làm với một nhân viên." Và đó là sự thật. Một "Lớp" đó có hàng ngàn dòng mã và bất cứ điều gì bạn có thể làm với một nhân viên đều ở đó. Hoặc, thậm chí tệ hơn, có một bảng dữ liệu nhân viên và mỗi nhà phát triển đã tìm ra cách để làm những gì họ muốn làm trong xử lý sự kiện.

Tất cả những điều tồi tệ về cách tiếp cận đó là đúng nhưng ít nhất nhà phát triển sử dụng nhân viên có thể, mà không cần đến các tài liệu khác, tìm ra cách đăng ký nhân viên vào chương trình sức khỏe, tăng lương, sa thải, thuê, chuyển nhượng, v.v. cho người quản lý và tất cả các ý tưởng lớn khác. Hoặc, nếu họ sử dụng nhân viên các bảng dữ liệu cần thiết khác, chỉ có thể làm những gì họ muốn.

Vâng, đã có nhiều mã trùng lặp. Vâng, đó là mã rất dễ vỡ. Có kiểm tra nó là cách khó khăn hơn cần thiết. Có thay đổi chức năng là sợ gây ra và Copy Paste là một cách tự nhiên do cách tiếp cận.

Nhưng ít nhất họ có thể khám phá những gì có sẵn bằng cách tạo một lớp hoặc họ có thể làm những gì họ cần hoàn thành mà không cần phải hiểu sự khác biệt giữa các giao diện, lớp trừu tượng, lớp cụ thể, v.v. Và họ không phải tìm kiếm gì khác ngoài các phương thức được trả về bởi intellisense hoặc biết các bảng chứa dữ liệu.

Tôi đã googled / beded và thậm chí yahoo! D nhưng tôi không tìm thấy bất kỳ sự thừa nhận về vấn đề này.

Vì vậy, có lẽ không có vấn đề gì và tôi chỉ thiếu một cái gì đó. Tôi đã thử thách trí não của mình khi cố gắng tìm ra một giải pháp trong đó (các) nhà phát triển không thực hiện hành vi / thiết kế thực tế có thể dễ dàng khám phá cách làm một cái gì đó mà không phải tham khảo bất kỳ tài liệu bên ngoài nào hoặc quét tên lớp trong các thành phần khác nhau / các dự án để tìm một dự án có vẻ như nó sẽ hoạt động.

Điều duy nhất tôi có thể nghĩ ra là có những thứ này, vì thiếu một cái tên hay hơn, "Bảng nội dung", không có gì khác trả lại các lớp thực tế (và thực sự hầu hết chúng là các giao diện nhưng chúng không biết sự khác biệt hoặc thậm chí quan tâm) mà các nhà phát triển khác có thể sử dụng để thực hiện các tác vụ thực tế mong muốn. Vẫn kết thúc với các lớp học thực sự lớn nhưng hầu như không có hành vi nào trong đó.

Có cách nào tốt hơn mà không đòi hỏi kiến ​​thức sâu sắc về tầng lớp trung lưu nơi việc triển khai thực tế của RẮN diễn ra không?

Về cơ bản những gì tôi đang hỏi là có cách nào cho phép các nhà phát triển loại CRUD tiếp tục trở thành nhà phát triển CRUD trong một hệ thống rất phức tạp

Dường như những gì bạn đã mô tả (tức là lớp Nhân viên có TẤT CẢ mã có thể bạn có thể làm với nhân viên) là một mô hình cực kỳ phổ biến mà cá nhân tôi đã thấy khá nhiều. Một số mã tôi đã tự viết trước khi tôi biết rõ hơn.

Cái bắt đầu là một lớp được cho là đại diện cho một thực thể duy nhất với tập phương thức có thể quản lý được, biến thành một thứ ác mộng cần duy trì bởi vì mỗi tính năng và mỗi bản phát hành tiếp tục thêm nhiều hơn vào cùng một lớp. Điều này không đi ngược lại các nguyên tắc RẮN nói rằng bạn nên viết một lớp một lần và chống lại sự thôi thúc phải sửa đổi nó nhiều lần.

Cách đây một thời gian (trước khi tôi phát hiện ra các mẫu thiết kế hoặc RẮN như được quảng bá bởi những người khác), tôi đã quyết định cho dự án tiếp theo của mình để lật mọi thứ một chút. Tôi đã làm việc trên một máy chủ phục vụ như một giao diện giữa hai nền tảng rất lớn. Lúc đầu, chỉ cần đồng bộ hóa cấu hình, nhưng tôi có thể thấy rằng đây sẽ là nơi hợp lý cho nhiều tính năng khác.

Vì vậy, thay vì viết một lớp tiếp xúc với các phương thức, tôi đã viết các lớp đại diện cho các phương thức (hóa ra là mẫu "Lệnh" từ GoF). Thay vì thực hiện công việc cho khách hàng, tất cả các lớp ứng dụng chính của tôi đã trở thành chủ sở hữu nhà nước liên tục và chúng trở nên ngắn hơn nhiều. Mỗi lần tôi phải thêm một phương thức giao diện mới vào chính dịch vụ, tôi chỉ cần tạo một lớp mới có phương thức Execute () để bắt đầu mọi thứ. Nếu nhiều lệnh có điểm chung, chúng xuất phát từ lớp cơ sở chung. Cuối cùng, thứ này có hơn 70 lớp lệnh khác nhau và toàn bộ dự án vẫn rất dễ quản lý và thực sự là một niềm vui để làm việc.

"Lớp TOC" của bạn không quá xa so với những gì tôi đã làm. Tôi đã có một nhà máy trừu tượng (GoF) chịu trách nhiệm khởi tạo các lệnh. Bên trong lớp nhà máy, tôi đã giấu hầu hết các chi tiết đằng sau lớp cơ sở và macro kiểu ATL, vì vậy khi một lập trình viên phải thêm hoặc tìm kiếm một yêu cầu, họ đã đi vào đó và tất cả những gì họ thấy là:

BEGIN_COMMAND_MAP()
    COMMAND_ENTRY( CChangeDeviceState )
    COMMAND_ENTRY( CSetConfiguration )
    ....
END_COMMAND_MAP()

Ngoài ra (hoặc ngoài), bạn có thể đặt tất cả các lớp lệnh thực tế của mình vào một không gian tên riêng để khi mọi người đang mã hóa và cần chạy một cái gì đó, họ chỉ cần nhập tên không gian tên và Intellisense liệt kê tất cả các lệnh mà bạn đã xác định. Sau đó, mỗi lệnh bao gồm tất cả các phương thức get / set xác định chính xác các tham số đầu vào và đầu ra.

Bạn cũng có thể khám phá việc sử dụng mẫu Facade (GoF). Thay vì để lộ hơn 1000 lớp cho các kỹ sư CRUD của bạn. Ẩn tất cả chúng đằng sau một lớp duy nhất chỉ hiển thị những gì cần thiết. Tôi vẫn sẽ giữ mỗi "hành động" là lớp riêng của mình, nhưng lớp Facade của bạn có thể có các phương thức khởi tạo từng hành động của bạn và một lần nữa, với Intellisense họ sẽ thấy ngay những gì có sẵn. Hoặc Facade có các phương thức thực tế, nhưng bên trong làm cho chúng khởi tạo các lệnh, xếp hàng chúng và chờ phản hồi. Sau đó trả về như thể một cuộc gọi phương thức thông thường đã được thực hiện.

(*) Tôi không muốn có quá nhiều chi tiết, nhưng tôi thực sự có tập hợp các lớp "Command" và "CommandHandler". Điều này tách biệt trách nhiệm quản lý / xếp hàng / tuần tự hóa các tham số vào / ra khỏi các lớp thực sự "xử lý" các lệnh đó.

Nó có thể là một vấn đề. Đặc biệt nếu bạn đặt tên xấu. Nhưng có một số giải pháp cho nó mà không cần dùng đến các lớp phức tạp. Heck, một lớp có quá nhiều phương thức có thể khó điều hướng bằng Intellisense.

Hãy thử sử dụng không gian tên (C #) hoặc gói (Java) hoặc bất kỳ khái niệm tương tự nào mà ngôn ngữ của bạn có (tôi sẽ gọi tất cả chúng là không gian tên), để đơn giản hóa vấn đề.

Bắt đầu với tên công ty của bạn. Điều đó giới hạn Intellisense chỉ các không gian tên được viết bởi chính bạn. Sau đó, nếu bạn có nhiều ứng dụng, hãy sử dụng phần thứ hai của không gian tên để phân chia chúng. Bao gồm một không gian tên Core, cho những thứ tồn tại trên các ứng dụng. Tiếp theo chia mọi thứ thành các loại chức năng. Và như thế.

Nếu bạn làm điều này đúng, bạn sẽ kết thúc với các mục rất dễ khám phá.

Lấy ví dụ của bạn, nếu tôi muốn xác thực Người dùng, tôi nhập "MyCo." và nó cho tôi một danh sách các không gian tên ứng dụng. Tôi biết cơ sở dữ liệu người dùng được sử dụng trong tất cả các ứng dụng của chúng tôi, vì vậy tôi nhập "Core". sau đó tôi nhận được một danh sách các loại chức năng. Một trong số đó là "Xác nhận" vì vậy đó dường như là một lựa chọn rõ ràng. Và ở đó, trong Xác thực, là "UserValidator" với tất cả chức năng của nó.

Khi điều đó xảy ra, đối với những thứ tôi sử dụng nhiều, tôi sẽ nhanh chóng nhớ tên, hoặc ít nhất là các quy ước. Vì tôi thực hiện nhiều thay đổi đối với quy tắc xác thực, tôi sẽ biết rằng tất cả các lớp xác thực của tôi được gọi là FooValidator, trong đó Foo là tên của bảng. Vì vậy, tôi thực sự sẽ không cần phải đi qua các không gian tên. Tôi sẽ chỉ gõ UserValidator và để IDE thực hiện phần còn lại của công việc.

Nhưng đối với những điều tôi không thể nhớ, nó vẫn khá dễ dàng để tìm thấy chúng. Và khi tôi làm, tôi có thể loại bỏ tiền tố không gian tên.

Vì về cơ bản, bạn giới thiệu họ là nhà phát triển "CRUD", chúng tôi sẽ cho rằng bạn không nghĩ họ rất giỏi. Chúng tôi không biết điều này có nghĩa là họ cũng không hiểu lĩnh vực kinh doanh của bạn. Nếu họ hiểu tên miền, các lớp sẽ có ý nghĩa với họ. Biết một số lớp đã được xây dựng, họ nên xem trước, hỏi thứ hai, xem xét xây dựng từ đầu như một lựa chọn thứ ba.

Theo như biết cách tự động biết cách sử dụng / tái sử dụng một lớp chỉ bằng cách nhìn vào nó thì không nên mong đợi ngay lần đầu tiên. Bạn sẽ cần phải ghi lại và có thể cung cấp giải thích bổ sung thông qua đào tạo hoặc có thể trong quá trình xem xét mã.

Nhiều dự án nguồn mở và API cung cấp tài liệu, ví dụ mã và các giải thích khác. Bạn có thể không cần phải thân thiện với người dùng, nhưng không có xung quanh nó. Dạy chúng tốt.