Làm thế nào để tôi chứng minh hoặc từ chối các đối tượng của God God là sai?

Tóm tắt sự cố:

Tóm lại, tôi được thừa hưởng một cơ sở mã và một nhóm phát triển mà tôi không được phép thay thế và việc sử dụng các Đối tượng Thần là một vấn đề lớn. Đi về phía trước, tôi muốn có chúng tôi tái lập các yếu tố nhưng tôi đang bị đẩy lùi từ các đội muốn làm mọi thứ với God Object "bởi vì nó dễ dàng hơn" và điều này có nghĩa là tôi sẽ không được phép tái lập yếu tố. Tôi đã đẩy lùi việc trích dẫn kinh nghiệm phát triển nhiều năm của mình, rằng tôi là ông chủ mới được thuê để biết những điều này, v.v. và các công ty nước ngoài của bên thứ ba cũng đại diện tài khoản bán hàng, và giờ đây là ở cấp điều hành và cuộc họp của tôi là ngày mai và tôi muốn tiếp tục sử dụng nhiều đạn dược kỹ thuật để ủng hộ các hoạt động tốt nhất vì tôi cảm thấy nó sẽ rẻ hơn trong thời gian dài (Và cá nhân tôi cảm thấy đó là điều mà bên thứ ba lo lắng) cho công ty.

Vấn đề của tôi là ở cấp độ kỹ thuật, tôi biết nó lâu dài nhưng tôi gặp rắc rối với thời hạn cực ngắn và 6 tháng, và trong khi điều gì đó tôi "biết" tôi không thể chứng minh bằng các tài liệu tham khảo và trích dẫn bên ngoài của một người (Robert C. Martin, còn gọi là chú Bob), vì đó là điều tôi đang được yêu cầu làm như tôi đã nói rằng có dữ liệu từ một người và chỉ một người (Robert C Martin) không đủ sức tranh luận .

Câu hỏi:

Một số tài nguyên tôi có thể trích dẫn trực tiếp (Tiêu đề, năm xuất bản, số trang, trích dẫn) của các chuyên gia nổi tiếng trong lĩnh vực nói rõ việc sử dụng Đối tượng / Lớp học / Hệ thống "Thần" này là xấu (hoặc tốt, vì chúng tôi đang tìm kiếm cho các giải pháp hợp lệ nhất về mặt kỹ thuật)?

Nghiên cứu tôi đã thực hiện:

1. Tôi có một số sách ở đây và tôi đã tìm kiếm các chỉ mục của chúng để sử dụng các từ "đối tượng thần" và "lớp thần". Tôi thấy rằng kỳ lạ là nó gần như không bao giờ được sử dụng và bản sao của cuốn sách GoF tôi có, chẳng hạn, không bao giờ sử dụng nó (Ít nhất là theo chỉ số trước mặt tôi) nhưng tôi đã tìm thấy nó trong hai cuốn sách dưới đây, nhưng tôi muốn nhiều hơn nữa Tôi có thể sử dụng.
2. Tôi đã kiểm tra trang Wikipedia cho "God Object" và hiện tại nó vẫn còn sơ khai với ít liên kết tham chiếu nên mặc dù cá nhân tôi đồng ý với điều đó, nhưng tôi không thể sử dụng nhiều trong môi trường mà kinh nghiệm cá nhân không được coi là hợp lệ. Cuốn sách được trích dẫn cũng được coi là quá cũ để có hiệu lực bởi những người mà tôi đang tranh luận về những điểm kỹ thuật này với lý lẽ họ đang đưa ra là "nó từng được cho là xấu nhưng không ai có thể chứng minh được, và bây giờ phần mềm hiện đại nói" "Đối tượng là tốt để sử dụng". Cá nhân tôi tin rằng tuyên bố này là không chính xác, nhưng tôi muốn chứng minh sự thật, bất kể đó là gì.
3. Trong "Nguyên tắc, mô hình và thực tiễn nhanh nhẹn trong C #" của Robert C Martin (ISBN: 0-13-185725-8, bìa cứng) trong đó trên trang 266 có ghi "Mọi người đều biết rằng các lớp thần là một ý tưởng tồi. Chúng tôi không muốn để tập trung tất cả trí thông minh của một hệ thống vào một đối tượng hoặc một chức năng duy nhất. Một trong những mục tiêu của OOD là phân vùng và phân phối hành vi thành nhiều lớp và nhiều chức năng. " - Và sau đó đôi khi nói rằng đôi khi sử dụng God Classes tốt hơn (trích dẫn các bộ điều khiển vi mô làm ví dụ).
4. Trong cuốn "Mã sạch: Cẩm nang về thủ công phần mềm linh hoạt" của Robert C Martin trang 136 (Và chỉ trang này) nói về "lớp Chúa" và gọi nó là ví dụ điển hình cho việc vi phạm quy tắc "các lớp nên nhỏ" ông sử dụng để thúc đẩy Nguyên tắc Trách nhiệm Đơn lẻ "bắt đầu từ trang 138.

Vấn đề tôi có là tất cả các tài liệu tham khảo và trích dẫn của tôi đến từ cùng một người (Robert C. Martin) và đến từ cùng một người / nguồn. Tôi được cho biết rằng vì anh ta chỉ là một quan điểm, nên mong muốn không sử dụng "Lớp học của Chúa" là không hợp lệ và không được chấp nhận như một cách thực hành tốt nhất trong ngành công nghiệp phần mềm. Điều này có đúng không? Có phải tôi đang làm những điều sai trái từ góc độ kỹ thuật bằng cách cố gắng tuân theo lời dạy của chú Bob?

Các đối tượng và thiết kế hướng đối tượng của Chúa:

Càng nghĩ về điều này, tôi càng nghĩ rằng đây là thứ bạn học được nhiều hơn khi bạn học OOP và nó không bao giờ được gọi ra một cách rõ ràng; Ý định của nó đối với thiết kế tốt là suy nghĩ của tôi (Vui lòng sửa tôi, làm ơn, như tôi muốn tìm hiểu), vấn đề là tôi "biết" điều này, nhưng không phải ai cũng làm, vì vậy trong trường hợp này nó không được coi là một đối số hợp lệ bởi vì Tôi thực sự gọi nó là sự thật phổ quát khi trên thực tế hầu hết mọi người đều không biết gì về mặt thống kê vì hầu hết mọi người không phải là lập trình viên.

Phần kết luận:

Tôi không biết nên tìm kiếm gì để có kết quả bổ sung tốt nhất để trích dẫn, vì họ đang đưa ra yêu cầu kỹ thuật và tôi muốn biết sự thật và có thể chứng minh điều đó bằng trích dẫn như một kỹ sư / nhà khoa học thực thụ, ngay cả khi Tôi thiên vị chống lại các đối tượng thần do kinh nghiệm cá nhân của tôi với mã đã sử dụng chúng. Bất kỳ trợ giúp hoặc trích dẫn sẽ được đánh giá sâu sắc.

Trường hợp cho bất kỳ thay đổi thực hành được thực hiện bằng cách xác định các điểm đau được tạo ra bởi thiết kế hiện có. Cụ thể, bạn cần xác định những gì khó hơn so với thiết kế hiện có, những gì dễ vỡ, những gì đang bị phá vỡ, những hành vi nào không thể được thực hiện theo cách đơn giản là kết quả trực tiếp (hoặc thậm chí hơi gián tiếp) của việc triển khai hiện tại, hoặc, trong một số trường hợp, hiệu suất phải chịu như thế nào, mất bao nhiêu thời gian để đưa một thành viên nhóm mới tăng tốc, v.v.

Thứ hai, mã làm việc bỏ qua bất kỳ đối số về lý thuyết hoặc thiết kế tốt. Điều này đúng ngay cả đối với mã xấu, thật không may. Vì vậy, bạn sẽ phải cung cấp một giải pháp thay thế tốt hơn, có nghĩa là bạn, với tư cách là người ủng hộ các mô hình và thực tiễn tốt hơn, sẽ cần phải cấu trúc lại để trêu chọc một thiết kế tốt hơn. Tìm một mặt phẳng hẹp, theo dõi viên đạn thông qua thiết kế hiện có và thực hiện một giải pháp, có lẽ, cho phép lặp, giữ cho việc thực hiện đối tượng thần hoạt động, nhưng trì hoãn việc triển khai thực tế cho thiết kế mới. Sau đó, viết một số mã lợi dụng thiết kế mới này và thể hiện những gì bạn giành được nhờ thay đổi này, cho dù đó là hiệu suất, khả năng bảo trì, tính năng, sửa lỗi hoặc điều kiện cuộc đua hoặc giảm tải nhận thức cho nhà phát triển.

Việc tìm một diện tích bề mặt đủ nhỏ để tấn công trong các hệ thống có kiến ​​trúc kém thường là một thách thức, có thể mất nhiều thời gian hơn bạn muốn cung cấp một số giá trị ban đầu và mức chi trả ban đầu có thể không ấn tượng với mọi người, nhưng bạn cũng có thể làm việc về việc tìm kiếm một số người ủng hộ cách tiếp cận mới của bạn nếu bạn kết hợp nó với các thành viên trong nhóm ít nhất là một chút thông cảm.

Ca ngợi Thiên Chúa chỉ hoạt động khi bạn đang giảng cho dàn hợp xướng. Đó là một công cụ để đặt tên cho một vấn đề và chỉ hoạt động để giải quyết vấn đề khi bạn có đối tượng tiếp nhận cao cấp và có đủ động lực để làm điều gì đó. Sửa đối tượng Chúa thắng cuộc tranh luận.

Vì mối quan tâm trước mắt của bạn dường như là mua vào điều hành, tôi nghĩ rằng tốt nhất bạn nên đưa ra một trường hợp thay thế mã này cần phải là một mục tiêu chiến lược và gắn kết chúng với các mục tiêu kinh doanh mà bạn chịu trách nhiệm. Tôi nghĩ rằng bạn có thể tạo ra một trường hợp mà bạn có thể cung cấp một số hướng kỹ thuật bằng cách đầu tiên làm việc trên một đột biến kỹ thuật về những gì bạn nghĩ nên làm để thay thế nó, tốt nhất là liên quan đến tài nguyên từ một hoặc hai người kỹ thuật có đặt trước về thiết kế hiện tại.

Tôi nghĩ rằng bạn đã tìm thấy đủ tài nguyên để biện minh cho lập luận của mình; những người trong các cuộc họp như vậy sẽ chỉ chú ý đến tóm tắt nghiên cứu của bạn và họ sẽ ngừng lắng nghe sau khi bạn đề cập đến hai hoặc ba nguồn chứng thực. Ban đầu, bạn nên tập trung vào việc mua lại để giải quyết vấn đề mà bạn thấy, không nhất thiết phải chứng minh người khác sai hay chính mình đúng. Đây là một vấn đề xã hội, không phải là một vấn đề hợp lý.

Trong vai trò lãnh đạo công nghệ, bạn cần gắn kết bất kỳ sáng kiến ​​nào của mình với các mục tiêu kinh doanh, vì vậy điều quan trọng nhất để đưa vụ việc của bạn lên giám đốc điều hành là công việc sẽ làm gì cho những mục tiêu đó. Bởi vì bạn cũng được coi là "chàng trai mới", bạn không thể mong đợi mọi người sẽ vứt bỏ công việc của họ hoặc hy vọng sẽ nhanh chóng xếp hàng; bạn cần xây dựng một số niềm tin bằng cách chứng minh rằng bạn có thể cung cấp. Là một mối quan tâm lâu dài, trong vai trò lãnh đạo, bạn cũng cần học cách tập trung vào kết quả, nhưng không nhất thiết phải gắn liền với các chi tiết cụ thể của kết quả. Bây giờ bạn đang ở đó để đưa ra định hướng chiến lược, loại bỏ các chướng ngại chiến thuật từ tiến trình của nhóm của bạn và cung cấp sự cố vấn cho đội của bạn, không giành chiến thắng trong các trận chiến uy tín với các thành viên trong nhóm của bạn.

Đưa ra quyết định từ trên xuống sẽ hiếm khi đáng tin trừ khi bạn có một số giao diện trong trò chơi; nếu bạn lại rơi vào tình huống tương tự, bạn nên tập trung nhiều hơn vào việc xây dựng sự đồng thuận trong tổ chức của mình thay vì leo thang một khi bạn cảm thấy tình hình vượt khỏi tầm kiểm soát.

Nhưng xem xét bạn đang ở đâu, tôi muốn nói rằng cách tốt nhất của bạn là lập luận rằng cách tiếp cận của bạn sẽ mang lại lợi ích lâu dài có thể đo lường được dựa trên kinh nghiệm của bạn và nó phù hợp với công việc của các học viên nổi tiếng như chú Bob và đồng nghiệp. và bạn muốn dành một vài ngày / tuần dẫn đầu bằng cách tái cấu trúc hẹp khía cạnh bang-for-buck cao nhất, để chứng minh quan điểm của bạn về thiết kế tốt sẽ như thế nào. Tuy nhiên, bạn sẽ cần phải căn chỉnh bất cứ trường hợp nào của bạn với các mục tiêu kinh doanh cụ thể ngoài sở thích cá nhân của bạn.

Trước tiên, bạn cần trình bày rằng bất kỳ tổ chức có thể đo lường nào cũng cần áp dụng các thực tiễn tốt nhất trong ngành. Nói rằng "nó chỉ làm việc cho chúng tôi!" không thể đo lường được, cả về thời gian hay tài nguyên vì nó đơn giản là không thể đoán trước được. Công nghệ phần mềm là một môn khoa học nhiều như bất kỳ lĩnh vực khoa học nào khác, và những khái niệm này đã được nghiên cứu, nghiên cứu, thử nghiệm và ghi lại.

1. các đối tượng Thiên Chúa là một anti-pattern trong đó nêu rằng

   Trong công nghệ phần mềm, một mô hình chống (hoặc phản mẫu) là một mô hình được sử dụng trong các hoạt động xã hội hoặc kinh doanh hoặc công nghệ phần mềm có thể được sử dụng phổ biến nhưng không hiệu quả và / hoặc phản tác dụng trong thực tế.

2. Trong hội nghị Google IO năm 2009 , chủ đề này đã được giải thích một phần khi mẫu MVP được giải thích. Nó có thể không liên quan đến Thần, nhưng có thể cung cấp cho bạn một số đạn.

3. Ngoài ra, sử dụng mô hình chống này vi phạm nguyên tắc trách nhiệm duy nhất trong các thiết kế hướng đối tượng, trong đó nêu rõ:

   mỗi lớp nên có một trách nhiệm duy nhất và trách nhiệm đó phải được gói gọn trong lớp. Tất cả các dịch vụ của nó nên được liên kết hẹp với trách nhiệm đó.

4. Các đổ nát Mã blog cũng nói về vấn đề này và về điều đó giải pháp là.

5. Chúng ta không thể nói về nguyên tắc trách nhiệm duy nhất mà không nói về khớp nối đối tượng .

   [...] Ghép nối hoặc phụ thuộc là mức độ mà mỗi mô-đun chương trình phụ thuộc vào từng mô-đun khác.

   Trong trường hợp có một hệ thống liên kết chặt chẽ có thể gây ra assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.mức độ ghép đối tượng cao hơn có nghĩa là ít sự gắn kết hơn và ngược lại. Các đối tượng của Chúa là một ví dụ điển hình về khớp nối chặt chẽ vì họ biết nhiều hơn mức cần thiết, do đó làm quá tải trách nhiệm của họ, do đó hạn chế rất nhiều khả năng tái sử dụng mã.

6. Khi thiết kế một ứng dụng phức tạp, sự đơn giản phải xuất hiện trong tâm trí. Các vấn đề lớn phải được phân tách thành các vấn đề nhỏ hơn, dễ quản lý, kiểm tra và tài liệu hơn. Điều này đặc biệt đúng trong một mô hình hướng đối tượng.

   Với đối số này, chúng tôi lặp lại đối số chống mẫu, nhưng mô hình này là tất cả về các mẫu, biểu diễn đối tượng trong thế giới thực và, tối ưu hóa, đóng gói dữ liệu.

7. Bạn đúng một phần khi bạn nói rằng những "thực hành tốt" này tồn tại nhiều hơn trong các lớp học. Tuy nhiên, tôi có kinh nghiệm giảng dạy ở trường đại học (và một số trường đại học) và tôi chỉ thấy những nguyên tắc này được dạy trong các trường đại học, đặc biệt là trong các khoa kỹ thuật. Mà buồn. Nhưng giống như bất kỳ thực hành tốt nào, những người cố gắng cải thiện bản thân thường học một số mẫu thiết kế cơ bản và cuối cùng hiểu cách đi rừng giữa khớp nối và sự gắn kết.

   Những gì tôi thường dạy cho các học sinh là, nó có thể dường như đòi hỏi nhiều nỗ lực để áp dụng các tiêu chuẩn lập trình tốt, nhưng nó luôn mang lại lợi ích lâu dài. Một ví dụ điển hình là ai đó yêu cầu lập trình viên viết một hàm sắp xếp. Lập trình viên có hai sự lựa chọn; 1) viết hàm sắp xếp bong bóng nhanh (dưới 5 phút) sẽ không bền vững khi danh sách các phần tử tăng lên hoặc 2) viết thuật toán sắp xếp phức tạp hơn (còn gọi là tối ưu hóa), sắp xếp nhanh hơn, v.v.) sẽ mở rộng tốt hơn với danh sách lớn hơn.

Ồ tôi đi đây, tìm hiểu một câu hỏi cũ khác nhưng tôi đoán bạn sẽ không thắng được cuộc tranh luận này và đây là lý do.

Nghe có vẻ như một vấn đề văn hóa

Bạn là người quản lý của họ nhưng bạn không thể thay thế họ và bạn phải đến gặp người quản lý của mình để khiến họ làm điều mà bạn tin rằng họ nên làm trong trường hợp này tôi cho rằng ít nhất là đánh gục nó với chúa đối tượng di chuyển về phía trước. Nghe có vẻ như tôi là một trường hợp mã cổ điển phản ánh văn hóa mà nó được sinh ra. Nói cách khác, đối tượng của thần là cách công ty này hoạt động. Bạn muốn thực hiện bất kỳ loại thay đổi có ý nghĩa? Cuối cùng, bạn sẽ luôn đi đến cùng một vị trí cho nó vì tất cả các quyết định rõ ràng phải được xóa ở trên cùng.

Đã từng có nhiều lần thất bại trong việc dọn sạch mã kế thừa và thay đổi chính sách mã, tôi cho rằng bạn không thể chống lại văn hóa đã tạo ra mã có thể ngay từ đầu khi văn hóa đó vẫn còn cố thủ hoặc ít nhất là chiến đấu văn hóa là một khẩu hiệu khó khăn rất khó mà không ai có thể trả đủ cho tôi hoặc cho tôi đủ sức mạnh để cảm thấy như đó là một nỗ lực đáng giá có khả năng thành công một lần nữa.

Trước khi có thể thay đổi, họ phải có động lực để thay đổi và thật không may là các lập trình viên đã dành đủ thời gian để đọc Stack, đôi khi chúng ta khó hiểu rằng không phải ai cũng bị thúc đẩy bởi cùng một thứ. Tôi đã giành được rất nhiều lý lẽ hợp lý trong kinh nghiệm của mình nhưng vào cuối ngày công ty phải chịu đựng những nhà phát triển lười biếng về trí tuệ vì một lý do.

Có lẽ các mối quan tâm kinh doanh đã được thúc đẩy để chỉ nghĩ về ngày mai thay vì tuần tới hoặc năm năm tới (một kịch bản đặc biệt khó chịu khi bạn là con của những người nhập cư từ một quốc gia xây dựng một hầm chứa hạt giống ở Bắc Cực trong trường hợp tận thế). Có lẽ họ sợ thay đổi. Có lẽ họ coi trọng thâm niên quá mức đến mức chuỗi mệnh lệnh là vô nghĩa ngay cả khi họ phải thuê từ bên ngoài để mang về một đội trưởng hoặc người quản lý đội dev vì họ nhận ra không ai trong đội ngũ trọn đời của họ đã phát triển đủ trong thời gian của họ ở đó (hoặc bởi vì những người nói không muốn rủi ro liên quan đến trách nhiệm). Hoặc, và tôi đã thấy điều này, có lẽ đó là hiện tượng rất thực tế và đáng buồn của sự tầm thường vô địch vì nó biết sâu bên trong rằng nó có thể '

Làm thế nào để bạn chống lại các vấn đề mà cuối cùng bắt nguồn từ sự sợ hãi hoặc các số liệu bị phá vỡ để thành công? Tôi sẽ nói với bạn điều này, nó đòi hỏi nhiều hơn cả một nhóm phát triển chất lượng đã cam kết và bạn đã có ít hơn rất nhiều so với âm thanh tại thời điểm Q này được đăng.

Trong sự kiện không thể xảy ra, đó không phải là vấn đề văn hóa khó hiểu ...

Bây giờ giả sử mọi người ở phía trên rất dễ chấp nhận thay đổi và họ thực sự sẵn sàng tin tưởng bạn để thực hiện, bạn thực sự chỉ cần chấm dứt tất cả các cuộc tranh luận của bạn bằng tiền và mất cơ hội.

Mỗi lần mất nhiều thời gian hơn để đào tạo ai đó mới về cơ sở mã vô lý này, mỗi lần mất nhiều thời gian hơn để sửa đổi hoặc thêm một tính năng mới vào một thứ gì đó, mỗi khi nó trở nên cực kỳ khó khăn để đưa các điểm cuối đến một hệ thống khác từ một công ty mà bạn muốn hợp tác , đó là chi phí tiền. Rất nhiều tiền kỳ dị. Quan trọng nhất là nó để một cửa sổ mở cho một đối thủ nhanh nhẹn hơn nhỏ hơn, lao vào, đặt bạn vào vị trí mà tất cả những gì bạn có thể làm là phản ứng với chúng quá chậm, và cuối cùng là lấy nó ra khỏi bạn.

Chỉ cần nhận ra rằng một nền văn hóa đặc biệt bướng bỉnh và ngu ngốc sẽ duy trì hiện trạng bằng mọi giá ngay cả khi mái nhà thực tế của công ty thực sự bị cháy vì nó.

Bạn có thể trích dẫn một số nguyên tắc OOP cơ bản nhất như khớp nối lỏng lẻo và độ gắn kết cao. Một "đối tượng của Chúa" nghe có vẻ như nó kết hợp các lớp không liên quan và có độ gắn kết thấp.

Bạn luôn có thể tự hỏi chú Bob.

Vấn đề là, nó quá rõ ràng với mọi người với bất kỳ ý nghĩa nào mà một khi được đánh vần, nó không cần phải được giới thiệu lại bởi vô số tác giả. Chỉ cần có một nguồn.

Các thuật ngữ khác bạn có thể muốn bắt đầu khi tìm kiếm các nguồn là:

• CHẤT RẮN
• Luật của Demeter
• Quả bóng lớn

Tất cả các khái niệm liên quan rõ ràng này có thể mang lại nguồn tham khảo khả thi, mặc dù họ không thực sự đặt tên như vậy.

Cuối cùng, bạn là ông chủ. Lý do để làm điều đó là bởi vì bạn nói như vậy, và mặc dù để được coi là một người quản lý tốt, bạn thực sự nên chuẩn bị để biện minh cho các quyết định của mình; bạn đã làm điều đó và nếu vẫn còn sự kháng cự, thì hành động đúng đắn là nhóm của bạn sẽ làm như họ đã nói.

Làm thế nào để tôi chứng minh hoặc từ chối các đối tượng của thần God là sai?

Bạn không thể.

Loại phỏng đoán này không phù hợp với chứng minh toán học, và bằng chứng toán học là loại bằng chứng duy nhất là âm thanh.

Ngay cả khi bạn cố gắng thay thế từ "sai" bằng các biện pháp định lượng về tác động của việc sử dụng các đối tượng thần, bạn sẽ thấy rằng:

1. các biện pháp có sẵn là thô,
2. có một vài nghiên cứu đáng tin cậy trong đó các biện pháp đó đã được định lượng cho mã được tạo bởi các lập trình viên chuyên nghiệp
3. có rất ít nếu có bất kỳ nghiên cứu đáng tin cậy nào trong đó các cấu trúc ngôn ngữ hoặc thiết kế (chống) đã được gắn với các biện pháp đó.

Và đó là bỏ qua vấn đề quyết định khi một đối tượng cụ thể là một đối tượng "thần".

Tốt nhất, những loại nghiên cứu này chỉ có thể chứng minh mối tương quan theo kinh nghiệm. Không phải là một bằng chứng xác thực.

Những gì bạn đang thực sự làm là tranh luận về ưu và nhược điểm của các đối tượng "thượng đế" với quan điểm thay đổi ý kiến của người khác ... và sau đó là thực tiễn của tổ chức bạn.

Đừng sử dụng những từ như "bằng chứng" hoặc những người bạn đang tranh luận có thể cười vào mặt bạn.

Bạn có thể muốn xem guru của tuần # 84 . Đó là tất cả về các đối tượng thần (nguyên khối) và làm thế nào chúng là xấu.

Trích xuất:

(Major) Nó cô lập chức năng độc lập tiềm năng trong một lớp [...] (Nhỏ) Nó có thể ngăn cản việc mở rộng lớp với chức năng mới [...]

Tôi không chắc chắn nếu nhóm của bạn thực sự quan tâm đến dự đoán học thuật rằng "các đối tượng của Chúa là sai".

Từ quan điểm tâm lý học, aproach tái cấu trúc của bạn có thể bị hiểu nhầm là tấn công vào năng lực của đội a la: "nhóm đã làm một công việc tồi tệ" mặc dù chương trình đang hoạt động như mong đợi.

Những gì bạn thực sự muốn làm là để đối phó với các tác dụng phụ tiêu cực của "mã spagetti" và "đối tượng của Chúa": chi phí khám phá để thêm các tính năng mới do tăng lỗi do tác dụng phụ.

Nuôi ong rất cụ thể và đặt câu hỏi thay vì cung cấp câu trả lời có thể hữu ích hơn:

manager > Why did implement the new tax-calculation schema took more than 4 weeks
team > because {reason a}
manager > And why was {reason a}?
team > because {reason b}
manager > And why was {reason b}?
...
team > because {reason z}
manager > what could we do to avoid {reason z} ?
team > refactor code