대규모 프로젝트가 일정 수준의 복잡성에 도달하면 계속해서 큰 프로젝트에 압도되고 있습니다. 프로젝트의 특정 지점에 도달하면 진행률이 크롤링되는 속도가 느려지고 계속 단계를 다시 추적하고 모든 종류의 혼란을 정리합니다.

나는이 약점 때문에 리팩토링에 정말 능숙했습니다. 그리고 항상 개체를 작고 관리하기 쉬운 개체로 분해하려고합니다. 이 약점은 아마도 물건을 올바르게 디자인하는 데 너무 많은주의를 기울 였을 것입니다.

문제를 더 작은 문제로 나눌 수 있는지 잘 알고 있으면 원활하게 달성 할 수 있습니다. 마음에 드는 전략 중 하나는 테스트 중심 개발입니다. 다른 무엇을 할 수 있습니까?

코드에 대한 생각을 멈추십시오

계층, 기능, 모듈, 서비스 및 기타 고급 추상화에 대해 생각해보기

당신은 너무 낮은 수준에서 생각하기 때문에 압도 당하고 있습니다

복잡한 것을 간단하게 만드는 것은 쉽다 ; 다른 방향으로 생각하십시오.

모두 가이 문제로 어려움을 겪고 있으며, 매우 효과적인 솔루션은 없습니다.

귀하의 질문에 이것을 나열하지 않았으므로 제 제안은 다음과 같습니다.

다음을 통해 기능적 응집력 에 중점을 둡니다 .

단일 책임 원칙 은 모든 대상이 단일 책임을 가져야하며 책임은 전적으로 클래스에 의해 캡슐화되어야한다고 명시하고 있습니다. 모든 서비스는 그 책임과 좁게 조정되어야합니다.

Google 이 첫 페이지의 결과 중 하나 를 검색 하면 다음 두 가지 훌륭한 자료를 찾을 수 있습니다.

• Robert C. Martin의 " 단일 책임 원칙 "(2002 년 2 월) :이 원칙은 다른 클래스에서 다른 이유로 변경되는 사항을 배치해야 할 필요성에 대해 설명합니다.
• Jeff Atwood (2007 년 3 월) 의 " Curly 's Law : Do One Thing "(단일 책임 원칙)에 따르면, 수업에는 변화해야 할 단 하나의 이유가 있어야합니다.

컴퓨터 과학의 응집력이란 무엇입니까?

응집력 은 단일 모듈의 책임이 얼마나 강력하게 관련되어 있는지 또는 집중되어 있는지에 대한 척도입니다. 객체 지향 프로그래밍에 적용 할 때, 주어진 클래스를 제공하는 메소드가 여러 측면에서 유사한 경향이 있다면, 클래스는 높은 응집력을 갖는다 고합니다. 응집력이 높은 시스템에서는 코드 가독성과 재사용 가능성이 증가하는 반면 복잡성을 관리 할 수 ​​있습니다.

다음과 같은 경우 응집력이 감소합니다 .-클래스에 포함 된 기능은 해당 메소드를 통해 액세스되며 공통점이 거의 없습니다. -방법은 종종 거칠거나 관련이없는 데이터 세트를 사용하여 다양한 활동을 수행합니다.

낮은 응집력 (또는 "약한 응집력")의 단점은 다음과 같습니다 .-모듈 이해의 어려움 증가. -도메인의 논리적 변경이 여러 모듈에 영향을 미치며 한 모듈을 변경하면 관련 모듈을 변경해야하기 때문에 시스템 유지 관리의 어려움이 증가했습니다. -대부분의 응용 프로그램은 모듈에서 제공하는 임의의 작업 집합을 필요로하지 않기 때문에 모듈 재사용의 어려움이 증가했습니다.

궁금한 점이 있으면 알려주세요.

기능을 가능한 가장 작은 항목으로 분해하십시오. 예를 들어, 양식의 단일 필드입니다. 가장 위험하거나 우선 순위가 높은 것을 골라 큰 프로젝트가 아닌 단순한 버그 수정처럼 진행하십시오. 나중에 일부 리팩토링으로 끝날 것이지만 최소한 앞으로 나아갈 것입니다.

내 경험상 TDD에 대한 의견으로 자신의 질문에 대답했습니다. 나에게 종종 당신과 같은 느낌이 들었다. 일단 시스템이 특정 크기에 도달하면 빠른 빠른 성공이 사소한 세부 사항으로 빠르게 혼란에 빠졌다. TDD를 사용하면 시스템의 각 부분을 작은 덩어리로 처리 할 수 ​​있으므로 나머지 시스템은 떠날 때 계속 작동하거나 작동해야한다는 것을 알았습니다. 또한 TDD를 사용하면 시스템을 독립적으로 테스트 할 수있는 작은 덩어리로 명확하게 나눌 수 있습니다.

일부 사람들은 이해하기 쉬운 모듈 식 프로그램을 설계하는 데 능숙하지만 대부분의 프로그래머에게는이 기능이 부족합니다. 나는 많은 경험을 제외하고 첫 번째 유형의 프로그래머 중 하나를 두 번째 유형으로 바꿀 수있는 책, 절차 또는 연습이 없다는 것을 알고 있습니다. 그러나 나는 그것에 대해 확신조차하지 못합니다.

결론은 대부분의 프로그래머가 평범한 수준 이상으로 상승하는 데 어려움을 겪고 일부는 괜찮을 것입니다. 소수는 우수 할 것입니다. 나는 오랜 경력에서 결코이 훌륭한 것들 중 하나를 만난 적이 없다고 말해야합니다 :-)

많은 사람들이 솔루션을 과도하게 엔지니어링하려고합니다. 그들은 조금 더 실용적인 방법으로 많은 것들을 단순화 할 때 "Adam & Eve"접근법을 취합니다.

전문화 된 수업은 사악한 것이 아니라 건전한 소프트웨어 디자인의 자연스러운 결과입니다.

제 생각에는 많은 프로그래머들이 이것을 이해하지 못하며 이것을 아는 책이 없습니다.

확실히 도움이되는 또 다른 것은 TDD입니다. 이것은 수업을 실제로 사용하는 "어떻게"이해하고 많은 경우에 하루를 일찍 저축 할 수 있기 때문에 하루를 절약 할 수 있습니다.

마지막으로, 내가 당신이라면 내가 찾게 될 또 다른 매우 중요한 것은 디자인 패턴입니다. 디자인 패턴은 사람들이 당신이나 나보다 똑똑하게 프로그래밍 문제를 해결하는 방법입니다. 패턴 뒤에 숨겨져있는 아이디어는 무엇을 추측 하는가? 요리 책으로 사용하지 말고 방금 슬래시하는 요리법이 아니라 신중하게 응용 프로그램 도메인을 가장 먼저 이해해야한다는 것입니다.

패턴을 현명하게 사용하면 관리해야 할 세부 사항의 양이 크게 줄어 듭니다.

귀하의 요구에 맞게 설계된 훌륭한 디자인 패턴 라이브러리는 매우 귀중합니다. 상황에 맞는 간단한 예제를 보자.

버튼을 누를 때 다른 양식이 스스로 업데이트되어야하는 양식이 있다고 가정하십시오. 일반적인 "관찰자"패턴입니다. 당신은 주제와 몇몇 관찰자들을 가지고 있으며, 그것들은 그 주제에 그들 자신을 등록합니다. 왜 인터페이스를 구현해야합니까? 메소드를 추가하거나 관찰자에 대한 인터페이스와 주제에 대한 일반 목록을 사용하는 것이 더 좋습니다. 이제 당신은 두 세계의 장점을 모두 얻었습니다 : 관찰자들을위한 독립성과 주제에 대한 흔들리지 않는 것들.

그것이 당신에게 의미가 있기를 바랍니다!

안드레아

추상화 속도의 필요성을 간과하면 개발 속도와 가독성 문제가 발생할 수 있습니다. 내가 일한 일부 큰 코드 기반에서 가장 일반적인 적 중 하나는 코드가 부풀어 오르는 매우 유사한 기능을 가진 가장 많은 특화된 클래스였습니다. 한 걸음 물러서서 응용 프로그램의 일부가 아닌 요구 사항 전체를 이해하면 많은 추상화가 떠오를 것입니다.

나에게 도움이 된 몇 가지 간단한 단계

• Simian과 같은 유사성 분석기를 사용하여 코드 기반에서 중복 코드 블록을 찾으십시오. 중복 코드가 많으면 추상화가 적습니다.
• 클래스와 메서드의 크기를 모니터링하면 큰 클래스와 메서드는 서비스 나 컨트롤러가 신이되는 것을 거의 의미하지 않습니다.
• 단위 / 통합 테스트를 필수로 설정하고 리팩토링에 대한 확신을 제공하며 사양으로도 작동합니다.
• 그들이 사용하는 기술 / 비즈니스 / 도메인 용어가 클래스 이름에 반영되는지 이해하기 위해 비즈니스와 함께 회고합니다. 이를 통해 간단한 집합 및 목록으로 표시하는 대신 일등석 컬렉션의 이름을 이해하고 얻는 데 도움이됩니다. 우리가 생각하지 않은 일부 추상화는 비즈니스 사람들과 함께 앉아있을 때도 드러날 것입니다.