“신의 대상”이 잘못되었다는 것을 어떻게 증명하거나 반증합니까?

문제 요약 :

간단히 말해서, 나는 코드베이스와 개발 팀을 물려 받았으며 대체 할 수 없으며 God Objects의 사용은 큰 문제입니다. 계속해서, 나는 우리가 일을 리팩토링하기를 원하지만 "더 쉬워지기 때문에"God Objects로 모든 것을하고 싶은 팀으로부터 푸시 백을 받고 있습니다. 이것은 리팩토링을 할 수 없다는 것을 의미합니다. 나는 수년간의 개발 경험을 인용하면서, 나는 이런 것들 등을 알기 위해 고용 된 새로운 상사이며, 제 3 자 해외 회사들도 영업 담당자를 고용하고 있으며, 이제 경영진 수준과 회의에 있습니다. 나는 내일이며, 회사를 위해 장기적으로 더 저렴하다고 생각하기 때문에 (그리고 개인적으로 제 3자가 걱정하는 바라고 생각하기 때문에) 모범 사례를 옹호하기 위해 많은 기술 탄약을 가지고 가고 싶습니다.

내 문제는 기술 수준에서 왔지만 장기적으로는 좋지만 초단기 및 6 개월 기간에 문제가 있으며 "알고있는"것은 외부에서 참조 및 인용 된 자료로 증명할 수 없습니다. 한 사람 (Robert C Martin)은 한 사람의 데이터를 가지고 있다는 말을 들었으므로 한 사람 (Robert C Martin)은 논쟁에 충분하지 않기 때문에 .

질문:

"신"개체 / 클래스 / 시스템의 이러한 사용이 잘못되었다고 명시 적으로 언급하는 해당 분야의 유명한 전문가가 직접 인용 할 수있는 자료 (제목, 출판 년도, 페이지 번호, 견적)는 무엇입니까? 가장 기술적으로 유효한 솔루션)?

내가 이미 수행 한 연구 :

1. 여기에 여러 권의 책이 있으며 "god object"와 "god class"라는 단어를 사용하기 위해 색인을 검색했습니다. 나는 이상하게도 거의 사용하지 않았고 예를 들어 GoF 책의 사본을 사용하지 않았다는 것을 알았지 만 (적어도 내 앞의 색인에 따르면) 아래 두 권의 책에서 찾았지만 더 많이 원합니다. 사용할 수 있습니다.
2. 나는 확인 "하나님 개체"에 대한 위키 백과 페이지 나는 개인적으로 말한다 동의하지만, 훨씬 내가 개인적인 경험이 유효한 것으로 간주되지 않는 환경에서 사용할 수 없습니다 있도록 작은 참조 링크와의 현재 스텁을. 인용 된이 책은 또한 그들이 주장하고있는 주장으로 내가이 기술적 인 점들을 토론하고있는 사람들에 의해 유효하기에는 너무 오래 된 것으로 간주됩니다. "개체를 사용하는 것이 좋습니다". 나는 개인적으로이 진술이 잘못되었다고 믿지만 그것이 무엇이든간에 진실을 증명하고 싶습니다.
3. Robert C Martin의 "C #의 민첩한 원칙, 패턴 및 실습"(ISBN : 0-13-185725-8, 하드 커버)에서 266 페이지의 "모든 사람은 신 수업이 나쁜 생각임을 알고 있습니다. 우리는 원하지 않습니다. OOD의 목표 중 하나는 행동을 많은 클래스와 많은 기능으로 분할하고 분배하는 것입니다. " 그리고 때로는 어쨌든 때때로 신 클래스를 사용하는 것이 더 좋습니다 (예 : 인용 마이크로 컨트롤러).
4. Robert C Martin의 "Clean Code : Agile Software Craftsmanship 핸드북"136 페이지 (이 페이지에서만)는 "하나님 클래스"에 대해 이야기하고 "클래스가 작아야합니다"규칙을 위반 한 주요 사례라고합니다. 그는 138 페이지부터 시작하는 단일 책임 원칙을 홍보하는 데 사용합니다.

내가 가진 문제는 모든 참고 문헌과 인용이 동일한 사람 (Robert C. Martin)에서 왔으며 동일한 단일 사람 / 출처에서 온 것입니다. 나는 그가 단지 하나의 견해이기 때문에 "하나님 클래스"를 사용하지 않으려는 나의 소망은 유효하지 않으며 소프트웨어 산업에서 표준 모범 사례로 받아 들여지지 않는다고 들었습니다. 이것이 사실입니까? 밥 삼촌의 가르침을 지키려고 노력하면서 기술적 인 관점에서 잘못하고 있습니까?

신 객체와 객체 지향 프로그래밍 및 디자인 :

내가 이것을 더 많이 생각할수록 이것은 OOP를 공부할 때 더 많이 배우는 것이라고 생각하며, 명시 적으로 언급되지 않습니다. 좋은 디자인에 내재하는 것은 내 생각입니다 (배우고 싶습니다. 제발 배우고 싶습니다). 문제는 이것을 "알고"있지만 모든 사람이하지는 않으므로이 경우 유효한 주장으로 간주되지 않기 때문에 통계적으로 대부분의 사람들이 프로그래머가 아니기 때문에 실제로 대부분의 사람들이 통계적으로 무지 할 때 나는 그것을 보편적 진리로 효과적으로 부릅니다.

결론:

그들이 기술적 인 주장을하고 있기 때문에 나는 최고의 추가 결과를 인용하기 위해 무엇을 찾아야할지 모르겠다. 나는 진실을 알고 실제 엔지니어 / 과학자와 같은 인용으로 그것을 증명할 수 있기를 원한다. 나는 그것을 사용하는 코드에 대한 개인적인 경험으로 인해 신의 대상에 대해 편견이 있습니다. 도움이나 인용은 깊이 감사하겠습니다.

실습 변경의 경우는 기존 설계에서 생성 된 문제점을 식별하여 이루어집니다. 구체적으로, 기존 디자인으로 인해 어려운 것, 깨지기 쉬운 것, 지금 깨지는 것, 동작을 직간접적인 (또는 다소 간접적 인) 결과로 간단한 방식으로 구현할 수없는 것이 무엇인지 파악해야합니다. 현재 구현 또는 경우에 따라 성능이 저하되는 방식, 새 팀 구성원을 빠르게 처리하는 데 걸리는 시간 등

둘째, 작업 코드는 이론이나 좋은 디자인에 대한 논쟁보다 우선합니다. 안타깝게도 잘못된 코드에서도 마찬가지입니다. 따라서 더 나은 대안을 제공해야합니다. 즉, 더 나은 패턴과 실습을 옹호하는 사람은 더 나은 디자인을 만들기 위해 리팩토링해야합니다. 기존 디자인을 통해 좁고 추적기-글 머리 기호 스타일 평면을 찾고, 아마도 반복 디자인의 경우 신 객체 구현을 계속 유지하지만 실제 구현을 새로운 디자인으로 연기하는 솔루션을 구현하십시오. 그런 다음이 새로운 디자인을 활용하는 코드를 작성하고 성능, 유지 관리 성, 기능, 버그 또는 경쟁 조건의 수정, 개발자의인지 부하 감소 등이 변경으로 인해 얻는 결과를 보여줍니다.

제대로 설계되지 않은 시스템에서 공격하기에 충분한 작은 표면적을 찾는 것은 종종 어려운 일이며, 초기 가치를 제공하려는 것보다 시간이 오래 걸릴 수 있으며, 초기 보수는 모든 사람에게 그렇게 인상적이지 않을 수도 있지만, 일할 수도 있습니다 최소한 약간 동정심이있는 팀원과 짝을 이루어 새로운 접근 방식에 대한 옹호자를 찾는 것에 대해

신의 대상을 애도하는 것은 합창단에게 설교 할 때만 작동합니다. 이 도구는 문제의 이름을 지정하는 도구이며, 선임적이고 문제에 대해 무언가를 할 수있는 동기를 가진 수용적인 청중이있는 경우에만 문제를 해결합니다. 신의 대상을 고치면 논쟁이 이깁니다.

귀하의 즉각적인 관심은 경영진의 인수 인 것으로 보이므로이 코드를 교체하는 것이 전략적 목표가되어야하며이를 책임이있는 비즈니스 목표와 연계시켜야한다는 것이 최선의 방법이라고 생각합니다. 나는 당신이 그것을 대체하기 위해해야한다고 생각하는 것에 대해 기술 스파이크를 먼저 수행함으로써 기술적 인 방향을 제시 할 수 있다고 생각합니다.

나는 당신이 당신의 주장을 정당화하기에 충분한 자원을 찾았다 고 생각합니다. 그러한 회의에 참석 한 사람들은 연구 요약에만주의를 기울일 것이며 2 ~ 3 개의 확증적인 출처를 언급 한 후에는 듣기를 멈출 것입니다. 처음에는 다른 사람이나 자신의 옳은 것을 증명할 필요가없는 문제를 해결하기 위해 매입에 초점을 두어야합니다. 이것은 논리적 문제가 아니라 사회적 문제입니다.

기술 리더십 역할에서는 모든 이니셔티브를 비즈니스 목표와 연계해야하므로 경영진에게 사례를 제시하는 가장 중요한 것은 해당 목표를 위해 작업을 수행하는 것입니다. 당신은 "새로운 사람"으로 간주되기 때문에 사람들이 자신의 작업을 포기하거나 빠르게 줄을 기대할 수는 없습니다. 전달할 수 있음을 증명하여 신뢰를 구축해야합니다. 장기적인 관심사로서, 리더십 역할에서는 결과에 집중하는 법을 배워야하지만 결과의 세부 사항에 반드시 첨부되는 것은 아닙니다. 이제 팀원과의 전략적 방향을 제시하고 팀의 전술적 장애물을 제거하며 팀 멘토링을 제공해야합니다.

게임에 스킨이 없으면 하향식 결정을 내리는 것이 거의 불가능합니다. 비슷한 상황에 처해 있다면 상황이 통제 불능이라고 느끼면 확대하지 말고 조직 내 합의 구축에 더 집중해야합니다.

그러나 현재 위치를 고려할 때 최선의 방법은 귀하의 접근 방식이 귀하의 경험에 따라 측정 가능한 장기적인 이점을 가져오고 Bob과 공동 삼촌과 같은 잘 알려진 실무자의 작업과 일치한다고 주장하는 것입니다. 좋은 디자인에 대한 견해를 보여주기 위해 벅스 밴 (Buck-for-Buck) 측면의 좁은 리팩토링에 대해 며칠 / 주를 보내고 싶을 것입니다. 그러나 개인의 취향을 넘어서 특정 비즈니스 목표에 맞게 사례를 조정해야합니다.

먼저, 측정 가능한 모든 조직이 업계 모범 사례를 채택해야 함을 제시해야합니다. "그냥 우리를 위해 일한다!" 단순히 예측할 수 없으므로 시간이나 자원으로 측정 할 수 없습니다. 소프트웨어 공학은 다른 과학 분야와 마찬가지로 과학이며 이러한 개념은 연구, 연구, 테스트 및 문서화되었습니다.

1. 하나님 개체 입니다 안티 패턴 한다고

   소프트웨어 엔지니어링에서, 안티 패턴 (또는 안티 패턴)은 일반적으로 사용될 수 있지만 실제로는 비효율적이고 반 생산적인 소셜 또는 비즈니스 운영 또는 소프트웨어 엔지니어링에 사용되는 패턴입니다.

2. 에서 2009 년 구글 IO 대회 MVP에 패턴을 설명 할 때,이 주제는 부분적으로 설명했다. 신의 대상과 관련이 없지만 탄약을 줄 수 있습니다.

3. 또한이 안티 패턴을 사용하면 객체 지향 디자인 의 단일 책임 원칙 을 위반하게되며 다음 과 같은 내용이 나타납니다.

   모든 수업은 하나의 책임이 있어야하며, 그 책임은 전적으로 수업에 의해 캡슐화되어야합니다. 모든 서비스는 그 책임과 좁게 조정되어야합니다.

4. 썩 코드 블로그는이에 대해 이야기하고 그것에 대해 솔루션입니다.

5. 우리는 객체 결합 에 대해 이야기하지 않고 단일 책임 원칙에 대해 이야기 할 수 없습니다 .

   [...] 커플 링 또는 종속성은 각 프로그램 모듈이 다른 모듈 중 하나에 의존하는 정도입니다.

   밀접하게 결합 된 시스템을 가질 수있는 경우 assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.높은 수준의 물체 결합은 응집력이 떨어지고 그 반대도 마찬가지입니다. God 객체는 필요한 것보다 더 많이 알고 있기 때문에 밀접한 결합의 좋은 예입니다.

6. 복잡한 응용 프로그램을 설계 할 때는 단순성을 고려해야합니다. 큰 문제는 더 작은 문제로 분해해야하므로 관리, 테스트 및 문서화가 더 쉽습니다. 이것은 객체 지향 패러다임에서 특히 그렇습니다.

   이 논증으로 우리는 반 패턴 논증으로 되돌아 가지만,이 패러다임은 패턴, 실제 객체 표현 및 전체적으로 데이터 캡슐화에 관한 것입니다.

7. 이러한 "좋은 관행"이 강의실에 더 존재한다고 말할 때 귀하는 일부입니다. 그러나 저는 대학 (및 일부 대학)에서 강의 경험이 있으며 이러한 원칙이 대학, 특히 공학 교수에서 강의되는 것만 보았습니다. 슬프다. 그러나 다른 모범 사례와 마찬가지로 더 나은 방식으로 노력하는 사람들은 일반적으로 몇 가지 기본 디자인 패턴을 배우고 결국 커플 링과 응집력 사이에서 정글을 형성하는 방법을 이해합니다.

   학생들에게 일반적으로 가르치는 것은 좋은 프로그래밍 표준을 채택하기 위해 더 많은 노력이 필요할 수 있지만 장기적으로는 항상 돈을 지불한다는 것입니다. 좋은 예는 프로그래머에게 정렬 기능을 작성하도록 요청하는 것입니다. 프로그래머는 두 가지 선택이 있습니다. 1) 요소 목록이 증가함에 따라 지속될 수없는 빠른 버블 정렬 기능 (5 분 미만)을 작성하거나 2) 더 확장 가능한 더 복잡한 (일명 최적화 된) 정렬 알고리즘 (빠른 정렬 등) 작성 더 큰 목록으로.

아, 여기에 또 다른 오래된 질문이 있지만, 당신 이이 논쟁에서 이기지 못했다고 추측 할 것입니다.

문화 문제처럼 들린다

당신은 그들의 관리자이지만 당신은 그들을 대체 할 수 없으며 당신이 그들이해야한다고 생각하는 일을하도록하기 위해 관리자에게 가야합니다.이 경우에는 적어도 신과 그것을 넘어 뜨려야한다고 가정합니다. 앞으로 움직이는 물체. 그것이 탄생 한 문화를 반영하는 고전적인 코드 사례처럼 들립니다. 다시 말해 신의 대상은이 회사의 작동 방식입니다. 의미있는 변화를 원하십니까? 모든 결정은 분명히 최상위에서 지워 져야하므로 궁극적으로 항상 같은 장소로갑니다.

레거시 코드 정리 및 코드 정책 변경에 대한 여러 번의 실패한 시도에 자부심을 느꼈기 때문에 이제는 문화가 여전히 확고하게 자리 잡았거나 최소한 싸울 때 코드를 가능하게 한 문화와 싸울 수 없다는 의견에 동의합니다. 문화는 매우 어려운 오르막 슬로 그로, 누군가가 나를 충분히 지불하거나 다시는 성공할만한 가치가있는 노력으로 느낄만큼 힘을 줄 수 없을 것입니다.

변화가 있기 전에, 그들은 스택을 읽을 정도로 망할 정도로 프로그래머에게 변화에 대한 동기를 부여하고 불행히도 동기를 부여 받아야합니다. 때때로 우리 모두가 같은 것에 동기를 부여하는 것은 아니라는 것을 이해하기가 어렵습니다. 나는 내 경험에서 많은 합리적 논증을 얻었지만 하루가 끝날 때 회사는 지적 게으른 개발자들로 인해 어려움을 겪습니다.

아마도 비즈니스 우려가 다음 주나 5 년이 아닌 내일에 대해서만 생각하도록 동기를 부여했을 수도 있습니다 (종말의 경우 북극에 종자 금고를 지은 나라에서 온 이민자의 자녀 인 경우 특히 실망스러운 시나리오). 아마도 그들은 변화를 두려워 할 것입니다. 어쩌면 그들은 팀 전체의 팀에서 아무도 자신의 시간에 충분히 성장하지 않았기 때문에 개발 팀장이나 관리자를 데려 오기 위해 외부에서 고용해야 할 때조차도 연쇄 명령이 의미가 없다는 점에서 고위직을 중시합니다. 거기에 (또는 생명이 책임과 관련된 위험을 원하지 않기 때문에). 또는 나는 이것을 보았습니다. 아마도 평범한 챔피언 자체의 매우 현실적이고 우울한 현상 일 것입니다.

궁극적으로 성공에 대한 두려움이나 실패한 지표에 뿌리를 둔 문제에 어떻게 대처하십니까? 나는 이것이 당신에게 헌신적 인 품질 개발 팀보다 훨씬 더 많이 걸리며이 Q가 게시 될 당시의 사운드보다 훨씬 적었습니다.

다루기 힘든 문화 문제가 아닌 불가능한 사건에서 ...

이제 정상에있는 사람들이 변화를 매우 수용하고 있다고 가정하고 실제로 그들이 당신을 신뢰한다고 믿으면, 모든 논증을 돈과 기회를 잃어 버리기 만하면됩니다.

이 어리석은 코드베이스에서 새로운 사람을 훈련시키는 데 시간이 오래 걸리거나, 새로운 기능을 수정하거나 추가하는 데 시간이 더 걸릴 때마다, 파트너가 되고자하는 회사의 다른 시스템에 엔드 포인트를 노출하는 것이 엄청나게 어려워 질 때마다 비용이 많이 듭니다. 엄청난 돈. 가장 중요한 것은 더 작은 민첩한 경쟁자가 빠져 나올 수 있도록 창문을 열어두고, 당신이 할 수있는 모든 것이 너무 느리게 반응하고 궁극적으로 당신에게서 멀어지게하는 위치에 당신을 배치하십시오.

특히 완고하고 어리석은 문화는 회사의 실제 물리적 지붕이 실제로 불에 태워도 모든 비용으로 현 상태를 유지할 것임을 인식하십시오.

느슨한 결합 및 높은 응집력과 같은 가장 기본적인 OOP 주체를 인용 할 수 있습니다. "하나님 대상"은 관련없는 클래스를 결합하고 응집력이 낮은 것처럼 들립니다.

당신은 항상 밥 삼촌 자신에게 요청할 수 있습니다.

문제는 사람들이 이해하기 쉬우므로 일단 철자가되면 많은 저자가 다시 언급 할 필요가 없다는 것입니다. 하나의 소스 만 있으면됩니다.

소스를 찾을 때 시작할 수있는 다른 용어는 다음과 같습니다.

• 고체
• 데메테르의 법칙
• 진흙의 큰 공

이러한 모든 표현은 실제로 이름을 밝히지 않아도 실행 가능한 참조 소스를 생성 할 수있는 관련 개념을 표현합니다.

궁극적으로, 당신은 보스입니다. 그렇게하는 이유는 귀하가 그렇게 말했기 때문이며, 훌륭한 관리자로 간주 되기는하지만 실제로는 귀하의 결정을 정당화 할 준비가되어 있어야합니다. 그렇게했지만 여전히 저항이있는 경우 팀이 지시 한대로 올바른 조치를 취해야합니다.

“신”대상이 잘못되었음을 어떻게 증명하거나 반증합니까?

당신은 할 수 없습니다.

이런 종류의 추측은 수학적 증거에 적합하지 않으며, 수학적 증거는 건전한 유일한 종류의 증거입니다.

감동적인 단어 "잘못된"을 신 객체를 사용하는 효과를 정량화 할 수있는 측정 값으로 바꾸려고해도 다음과 같은 사실을 알 수 있습니다.

1. 이용 가능한 조치는 원유입니다.
2. 전문 프로그래머가 생성 한 코드에 대해 이러한 측정 값을 정량화 한 신뢰할만한 연구는 거의 없습니다.
3. 언어 구성이나 디자인 (반 패턴) 패턴이 이러한 측정과 관련이있는 믿을만한 연구가 거의 없다.

그리고 그것은 특정 물체가 언제 "신"물체인지 결정하는 문제를 무시하고 있습니다.

기껏해야 이러한 종류의 연구는 경험적 상관 관계만을 보여줄 수 있습니다. 진정한 증거는 아닙니다.

당신이 실제로하고있는 것은 다른 사람들의 의견 을 바꾸고 조직의 실천 을 변화시키기 위해 "신"사물의 장단점을 토론 하는 것 입니다.

"증거"와 같은 단어를 사용하지 마십시오. 또는 토론중인 사람들이 당신의 얼굴을 비웃을 수 있습니다.

당신은 주 # 84의 전문가 를보고 싶을 수도 있습니다 . 그것은 신의 대상 (단일체)과 그것이 어떻게 나쁜지에 관한 것입니다.

추출물:

(주요) 그것은 잠재적으로 독립적 인 기능을 클래스 내에서 분리합니다 ...]

당신의 팀이 "하나님의 사물이 잘못되었다"는 학문적 증거에 정말로 관심이 있다면 나는 확실하지 않습니다.

심리학 적 관점에서, 리팩토링 어프로치는 프로그램이 예상대로 작동하지만 "팀이 나쁜 일을했다"는 팀의 역량을 공격하는 것으로 오해 될 수있다.

실제로하고 싶은 것은 "spagetti code"와 "God objects"의 부정적인 부작용에 대처하는 것입니다. 부작용으로 인한 버그 증가로 인해 새로운 기능을 추가하기위한 비용이 폭발적으로 증가하고 있습니다.

답변을 제공하는 대신 매우 구체적이고 질문을하는 것이 더 도움이 될 수 있습니다.

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