“ 신 개체 ”가 잘못되었음을 어떻게 증명하거나 반증합니까?

실천 변경 사례는 문제점을 파악하여 이루어집니다. 기존 디자인으로 만들어졌습니다. 특히, 기존 설계로 인해 필요한 것보다 더 어려운 것이 무엇인지, 깨지기 쉬운 것, 현재 중단되는 것, 직접적인 (또는 다소 간접적 인) 결과로서 간단한 방식으로 구현할 수없는 행동을 식별해야합니다. 현재 구현, 또는 경우에 따라 성능 저하, 새 팀원이 속도를 높이는 데 걸리는 시간 등입니다.

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

잘못 설계된 시스템에서 공격 할 수있는 작은 표면적을 찾는 것은 종종 어려운 일입니다. 초기 값을 제공하는 것보다 시간이 오래 걸릴 수 있으며 초기 보상은 그다지 인상적이지 않을 수 있습니다. 하지만 최소한 약간 동정적인 팀원과 짝을 지어 새로운 접근 방식을 옹호하는 사람을 찾는 작업을 수행 할 수도 있습니다.

신 개체를 애도하는 것은 “설교 할 때만 효과가 있습니다. 합창단. “문제의 이름을 지정하는 도구이며 문제에 대해 뭔가를 할 수있는 충분한 동기를 가진 수용적인 청중이있을 때만 문제를 해결하는 데 효과적입니다. God 개체를 수정하는 것이 논쟁에서 승리합니다.

귀하의 즉각적인 우려가 경영진의 동의로 보이기 때문에이 코드를 교체하는 것이 전략적 목표가되어야하고이를 귀하가 담당하고있는 비즈니스 목표에 연결해야한다고 주장하는 것이 최선이라고 생각합니다. 이를 대체하기 위해 수행해야한다고 생각하는 기술적 스파이크를 먼저 작업하여 기술적 인 방향을 제시 할 수있는 사례를 만들 수 있습니다. 가급적 현재 설계에 대해 예약이있는 한두 명의 기술 인력의 리소스를 포함합니다.

나는 당신이 주장을 정당화하기에 충분한 자료를 찾았다 고 생각합니다. 그러한 회의에 참석 한 사람들은 귀하의 연구 요약에만주의를 기울이고 “두세 가지 확증 출처를 언급 한 후에는 청취를 중단 할 것입니다.처음에는 다른 사람이 잘못했거나 자신이 옳다는 것을 증명하는 것이 아니라 자신이 보는 문제를 해결하기 위해 인수를받는 데 초점을 맞춰야합니다. 이것은 논리적 문제가 아니라 사회적 문제입니다.

기술 리더십 역할에서는 모든 이니셔티브를 비즈니스 목표에 연결해야합니다. 따라서 경영진에게 사례를 제시하는 데 가장 중요한 것은 이러한 목표를 위해 노력할 것입니다. 당신은 또한 “새로운 사람”으로 간주되기 때문에 사람들이 자신의 일을 버리거나 빠르게 줄을 서기를 기대할 수는 없습니다. 제공 할 수 있음을 입증하여 신뢰를 쌓아야합니다. 장기적인 관심사로서 리더십 역할에서 결과에 집중하는 법을 배워야하지만 반드시 결과의 세부 사항에 집착 할 필요는 없습니다. 이제 전략적인 방향을 제시하고, 팀의 진행 과정에서 전술적 장애물을 제거하고, 팀원과의 신뢰를 얻기 위해 팀 멘토링을 제공해야합니다.

하향식 결정을 내리는 것이 좋습니다. 게임에 스킨이없는 한 믿을 수없는 경우가 거의 없습니다. 계속해서 비슷한 상황에 처해 있다면 상황을 통제 할 수 없다고 느끼면 확대하기보다는 조직 내에서 합의를 구축하는 데 더 집중해야합니다.

하지만 현재 위치를 고려할 때 가장 좋은 방법은 귀하의 접근 방식이 귀하의 경험을 바탕으로 측정 가능한 장기적인 이점을 가져올 것이며 다음과 같은 잘 알려진 실무자의 작업과 일치한다고 주장하는 것입니다. 삼촌 Bob and co., 그리고 당신은 좋은 디자인에 대한 당신의 견해를 보여주기 위해 몇 일 / 주 동안 최고의 가치를 지닌 측면의 좁은 리팩토링에 대한 예제를 이끌고 싶습니다. 그러나 개인적인 선호도를 넘어서 특정 비즈니스 목표에 맞게 케이스를 조정해야합니다.

댓글

• 사회적인 문제입니다. 잘못된 작성 코드와 잘못 설계된 애플리케이션이 많은 이유 일 것입니다.
• ‘ 비즈니스 연설 ‘ 그 자체로; 가능한 한 잠재 고객과 관련이 있도록 만드는 것을 목표로합니다. ‘ 경영진과 이야기하는 경우 실행 / b> 코드 표준이 유지 관리 및 성능과 직접 연결되는 방법에 대해 이야기하고 이것이 전체 프로젝트 재정, 장기 안정성 등과 어떻게 연관되는지 논의합니다. 당신처럼 들립니다 ‘ 당신의 지식으로 고용되었습니다. 이것을 기억하십시오. (그냥 생각하는 멍청한 관리자가되지 마십시오. ‘ 그는 항상 가장 잘 알고 있습니다 -하지만이 경우에는 ‘ 100 % 맞습니다.)
• +1 for ” 작업 코드는 이론이나 좋은 디자인에 대한 모든 주장보다 우선합니다. ” 우리가 탐구에서 종종 잊는 것 완벽한 코드를위한 것입니다.
• 좋은 대답, 야심 찬 팀 리더를위한 많은 지혜.

먼저, 측정 가능한 조직이 업계 모범 사례를 채택해야한다는 것을 제시해야합니다. “우리에게만 효과가 있습니다!” 그것은 단순히 예측할 수 없기 때문에 시간이나 자원에서 측정 할 수 없습니다. 소프트웨어 엔지니어링은 다른 과학 분야와 마찬가지로 과학이며 이러한 개념은 연구, 연구, 테스트 및 문서화되었습니다.

1. God Object 는

   를 나타내는 반 패턴 입니다.

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

2. 2009 년 Google IO 컨퍼런스 에서이 주제는 MVP가 패턴이 설명되었습니다. God Object와는 관련이 없을 수 있지만 약간의 탄약을 줄 수 있습니다.

3. 또한이 안티 패턴을 사용하면 단일 책임 원칙 :

   모든 클래스는 단일 책임을 가져야하며 그 책임은 다음과 같아야합니다. 클래스에 의해 완전히 캡슐화됩니다. 모든 서비스는 해당 책임과 좁게 일치해야합니다.

4. Decaying Code 블로그에서도 이것과 그에 대한 해결책에 대해 이야기합니다.

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) 더 잘 확장 될 더 복잡한 (최적화 된) 정렬 알고리즘 (빠른 정렬 등) 작성

코멘트

• 객체 지향 프로그래밍 언어에서는 두 개의 독립적 인 소스 어셈블리가 개체 동작의 여러 측면에서 ‘ 이러한 동작을 캡슐화하기 위해 독립적 인 개체 인스턴스를 만들어야합니다. 불행히도 대부분의 경우 코드 어셈블리 간 기능의 가장 논리적 세분화가 개체 인스턴스 간 기능의 가장 논리적 세분화와 일치하지는 않지만 ‘ 두 종류의 세분화를 구분하는 것에 대해 많은 논의를 보지 못했습니다.
• 이 질문에 대해 약간의 주제를 벗어난 것 같습니다. 우리는 ‘ 여기서는 God Object 안티 패턴에 대해 이야기하는 것이 아니라 훨씬 광범위한 주제이며 매우 주관적인 코드 결합과 응집력에 대해 이야기합니다.

오, 여기에 또 다른 오래된 질문을 묵살하고 있습니다.하지만 당신이이 논쟁에서 이기지 못했다고 생각합니다. 이유.

문화 문제인 것 같습니다.

당신은 그들의 매니저는 그들을 대체 할 수없고, 그들이해야한다고 믿는 일을하도록하기 위해 매니저에게 가야합니다.이 경우에는 적어도 앞으로 나아가는 신의 물건을 두드리는 것이라고 생각합니다. 제게는 그것이 태어난 문화를 반영한 코드의 전형적인 사례처럼 들립니다. 다시 말해서 신의 목적은이 회사가 작동하는 방식입니다. 어떤 종류의 의미있는 변화를 만들고 싶습니까? 당신은 항상 같은 곳으로 가고 있습니다. 궁극적으로 모든 결정은 최상위에서 삭제되어야하기 때문입니다.

레거시 코드 정리 및 코드 정책 변경에 대한 여러 번의 실패 시도에 대한 경쟁 나는 이제 그 문화가 여전히 확고하게 자리 잡고 있거나 적어도 싸우는 문화가 처음부터 코드를 가능하게 한 문화와 싸울 수 없다고 생각합니다. “누구도 나에게 충분한 돈을 지불하거나 다시 성공할만한 가치있는 노력이라고 느끼기에 충분한 힘을 줄 수 없을 것 같은 매우 힘든 오르막 슬로 그.

변화가 있기 전에, 그들은 변화에 동기를 부여해야하며, 불행히도 가끔 스택을 읽을 수있는 충분한 시간을주는 프로그래머로서 모든 사람이 같은 것에 동기를 부여하지는 않는다는 것을 이해하기가 어렵습니다. 나는 내 경험에서 많은 합리적 주장을 이겼지 만 결국 회사는 이유 때문에 지적으로 게으른 개발자로 고통받습니다.

비즈니스 문제는 아마도 내일에 대해서만 생각하도록 동기를 부여했을 것입니다. 다음 주 또는 5 년 후에 (당신이 묵시의 경우에 북극에 종자 금고를 지은 나라에서 온 이민자의 자녀 일 때 특히 실망스러운 시나리오). 아마도 그들은 변화를 두려워 할 것입니다.어쩌면 그들은 자신의 모든 팀원이 자신의 시간에 충분히 성장한 사람이 없다는 것을 인식하기 때문에 외부에서 개발 팀 리더 또는 관리자를 고용해야하는 경우에도 지휘 체계가 무의미 할 정도로 고위직을 지나치게 중요하게 생각합니다. (또는 말한 생명이 “책임과 관련된 위험을 원하지 않기 때문입니다.)”또는 “나는 이것을 본 적이 있습니다. 아마도 평범함이 자신을 옹호하는 매우 현실적이고 우울한 현상 일 수 있습니다. t 품질과 경쟁 할 수 있고 “문제를 해결할 수있을만큼의 욕설이있을 때”모든 것이 정기적으로 산산조각이 났을 때 누구를 비난 할 것인지 파악할 수 없습니다.

궁극적으로 공포에 뿌리를 둔 문제에 어떻게 대처합니까? 성공에 대한 잘못된 지표? 제가 말씀 드리죠. 헌신적 인 품질 개발팀보다 훨씬 많은 시간이 소요되며이 Q가 게시되었을 때의 사운드보다 훨씬 적습니다.

불가능하지 않은 사건에서 그것은 다루기 힘든 문화 문제가 아닙니다 …

이제 사람들이 정상에 있다고 가정합니다. 변화를 매우 잘 받아들이고 그들은 “실제로 당신이 그것을 만들겠다고 믿고 있습니다. 당신은 돈과 기회를 잃어버린 당신의 주장을 강조하기 만하면됩니다.

누군가를 훈련시키는 데 시간이 더 오래 걸릴 때마다 이 어리석은 코드베이스에 새로운 기능을 추가하면 새로운 기능을 수정하거나 추가하는 데 시간이 더 오래 걸릴 때마다 파트너가 되고자하는 회사의 다른 시스템에 엔드 포인트를 노출하는 것이 엄청나게 어려워 질 때마다 비용이 많이 듭니다. 가장 중요한 점은 더 민첩한 경쟁자가 급습 할 수있는 창을 열어 두는 것입니다. 당신이 할 수있는 일은 그들에게 너무 느리게 반응하는 것뿐입니다. 그리고 궁극적으로 모든 것을 당신에게서 빼앗 으십시오.

특히 고집스럽고 어리석은 문화는 회사의 실제 물리적 지붕이 실제로 불타 오르더라도 어떤 대가를 치르더라도 현상 유지를 유지할 것입니다.

댓글

• 곧 퇴사했습니다. 그들은 저를 풀 타임으로 고용하고 제의를 수락하기 위해 시애틀에서 뉴욕으로 이사하도록했습니다. 저는 기본적으로 그들에게 ” 아니요. ‘ 제가 관리 할 팀이 Bellevue에있을 때 NY로 이사하지 않겠다고 말했습니다. WA ” 그 시점에서 저는 기본적으로 길을 건너서 더 나은 것을 찾을 때까지 MSFT에서 일자리를 얻었습니다.
• @honestduane 예, 그 기대치입니다. 혼자서 볼륨을 말합니다. GTFO에 대해 잘 알고 있습니다.

다음과 같은 가장 기본적인 OOP 원칙을 인용 할 수 있습니다. 느슨한 결합과 높은 응집력. “신 객체”는 관련없는 클래스를 결합하고 응집력이 낮은 것처럼 들립니다.

언제든지 밥 삼촌에게 물어볼 수 있습니다. .

문제는 모든 감각을 가진 사람들에게 너무나 명백해서 일단 철자를 입력하면 여러 저자가 다시 참조 할 필요가 없다는 것입니다. 하나의 출처입니다.

출처를 찾을 때 사용할 수있는 다른 용어는 다음과 같습니다.

• SOLID
• 데메테르 법칙
• Big Ball of Mud

실제로 이름을 지정하지는 않지만 실행 가능한 참조 소스를 산출 할 수있는 관련 개념을 모두 표현합니다.

궁극적으로 하지만, 당신은 “상사입니다. 그렇게하는 이유는 당신이 그렇게 말했기 때문입니다. 훌륭한 관리자로 간주 되더라도 당신은 당신의 결정을 정당화 할 준비가되어 있어야합니다. 당신은 그렇게했습니다. 그리고 여전히 저항이 있다면, 올바른 행동 방침은 팀이 “말한대로 수행하는 것입니다.

댓글

• ” 아직 저항이있는 경우 올바른 행동 방침은 팀이 ‘ 말한대로 수행하는 것입니다. ” 올바른 조치는 팀을 비참하게 만드는 것보다 그만두는 것입니다 ..?
• 관리자 ‘ s 결정이 적절하게 정당화되었으며 팀이 ‘ 동의하지 않으면 문제는 팀에있는 것입니다. OP는 그의 전문 지식을 위해 고용되었으며 동료들이 이기고 ‘ 합리적으로 행동하지 않았기 때문에 ‘ 비즈니스에 도움이 되었기 때문에이를 사용하지 못했습니다. 허용됩니다. ‘ 당신의 주장을 뒤집어 보자. ‘ 일에 대한 그들의 견해가 맞지 않을 경우 저항하는 팀원들이 그만두면 안되는 이유 그게 사업인가요?
• 적당합니다. 팀 운영 방식에 따라 다릅니다. 그러나 내 경험상 사람들이 자신의 의지에 반하는 일을하도록 강요하는 것은 단지 비참함으로 이어집니다. 나는 비참한 개발 팀보다 코드베이스 전체에서 God Objects를보고 싶습니다. 아마도 답은 그들을 훈련 과정에 보내는 것입니다. 모두가 교육 과정을 좋아합니다. 윈윈.
• 주임 개발자 / 관리자 / 팀이 서로 좋은 업무 관계를 유지할 수 있도록 모든 합리적인 조치를 절대적으로 취해야합니다. 추가 교육이 도움이된다면 반드시 선택 사항으로 고려하십시오. 그러나 이것은 고의적 인 무지의 경우와 같으며, 누군가가 생각하는 바를 이해하도록 교육을 받아야한다고 말하는 것 같습니다. ‘ 이해하지 않고 동의하지 않으면 역효과를 낼 수 있습니다. 배우고 싶지 않은 ‘ 사람들을 상대하는 방법을 상상하기가 어렵습니다.

“신”개체가 잘못되었음을 어떻게 증명하거나 반증합니까?

당신은 할 수 없습니다.

이러한 종류의 추측은 수학적 증명에 적합하지 않으며 수학적 증명 만이 건전한 증명의 유일한 종류입니다.

감정적 인 단어 “잘못된”을 대체하려고해도 신 개체 사용의 효과를 정량화 할 수있는 측정을 통해 다음을 발견 할 수 있습니다.

1. 사용 가능한 측정이 조잡하고
2. 이러한 측정이 정량화 된 신뢰할 수있는 연구는 거의 없습니다. 전문 프로그래머에 의해 생성 된 코드의 경우
3. 언어 구조 또는 디자인 (안티) 패턴이 이러한 측정에 연결되어있는 신뢰할 수있는 연구는 거의 없습니다.

그리고 특정 물체가 “신”물체인지 결정하는 문제를 무시하는 것입니다.

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

실제로하고있는 것은 다른 사람들을 변화시키기 위해 “신”물체의 장단점을 토론 하는 것입니다. “ 의견 … 그리고 조직의 관행입니다.

“증거”와 같은 단어를 사용하지 마십시오. 토론중인 사람들이 당신의 얼굴에 웃기 쉽습니다.

이주의 전문가 # 84 를 참조하세요. . 그것은 모두 신 개체 (모놀리스)와 그것이 얼마나 나쁜지에 관한 것입니다.

추출 :

(Major) 클래스 내에서 잠재적으로 독립적 인 기능 […] (사소) 새로운 기능으로 클래스를 확장하는 것을 권장하지 않을 수 있습니다. […]

당신의 팀이 “신의 대상이 틀렸다”고 증명하는 학문적 연구에 정말로 관심이 있다면 확신 할 수 없습니다.

심리적 관점에서 리팩토링 계획은 팀의 능력을 공격하는 것으로 오해 될 수 있습니다. 프로그램이 예상대로 작동하지만 “팀이 나쁜 일을했습니다”.

당신이 정말로하고 싶은 것은 “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