코딩시 분석을 통해 마비를 어떻게 극복합니까?

새 프로젝트를 시작할 때 종종 구현 세부 사항에 대해 즉시 생각하기 시작합니다. "DataBaseHandler를 어디에 두어야합니까? 어떻게 사용해야합니까? 이것을 사용하려는 클래스가 일부 Abstract 슈퍼 클래스에서 확장되어야합니까? 인터페이스를 사용해야합니까? 클래스가 포함 된 추상화 수준은 무엇입니까? 요청을 보내고 데이터를 파싱하는 방법? "

확장 성과 재사용 성을 위해 코딩하기를 원하기 때문에 오랫동안 실속합니다. 그러나 완벽하게 구현하는 방법에 대한 과거의 생각을 얻는 것이 거의 불가능하다고 생각합니다.

그리고 나서, 그냥 "나사, 그냥 끝내세요!"라고 말하려고하면 코드가 구성되지 않았고 추상화 수준 등이 혼합되어 벽돌 벽에 아주 빨리 닿았습니다.

새 프로젝트를 시작하면서 확장 성이 뛰어난 논리 / 모듈 구조를 설정하는 데 필요한 기술 / 방법은 무엇입니까?

- - 편집 - -

글쎄, 이것은 이미 대답하기가 어려운 질문 유형이지만 더 많은 피드백을 얻고 싶었습니다. 합의가 있는지 확인하십시오. TDD는 정말 시원하고 솔직히 JUnit 등을 사용하는 데 더 익숙해졌습니다. TDD의 팬들은 TDD와 관련하여 합법적 인 한 가지 점이 내 문제를 해결한다는 사실에 대해 어떻게 생각합니까? 특별한 문제는 TDD가 실제로 디자인 문제를 해결하지 못하는 것입니다. 물론 TDD가 내가하고 싶은 일을 정의하는 데 도움이되고 그 방법을 점차적으로 연구 할 수 있다는 데 동의하지만, 단위 테스트를 모두 통과 할 수있는 여러 가지 전체 디자인 패턴 / 구조가 있습니다. 그저 그저 : 단일 UNITS를 테스트합니다. 좀 혼란 스러워요 ... 몰라요. 아마도 나'

감사!

내가 사용 recomment 테스트 주도-개발을 , 일부는 특히 일식과 같은 좋은 IDE를 사용하여 작업 할 때 익숙해 필요하지만 장점은 중대하다.

기본적으로 코드 자체를 작성하기 전에 코드에 테스트를 작성하십시오. 따라서 코드 사용 방법의 관점에서 코드를보아야하므로 인터페이스가 구현하는 시나리오가 많아 질수록 인터페이스가 발전합니다.

또 다른 특징은 매우 작은 청크로 구현하는 것입니다 (기술과 프로그래밍에 경험이 많을수록 커짐). 매번 매우 작고 잘 정의 된 문제에 집중해야합니다.

또한 테스트를 먼저 작성하고 구현 한 후에 만 ​​실패한 테스트를 수행 할 수 있습니다. 따라서 대부분의 프로그래머와 같은 경우 "이 테스트를 수행해야합니다"라고 생각하기 때문에 미친 분석을하지 않아도됩니다.

짧은 자바 예제 :
db에서 메시지를 읽고 쓰는 프로그램을 개발하고 싶다고 가정 해보십시오.

먼저 잘 정의 된 첫 번째 작업부터 시작하여 DB가 필요합니다.

@Test
public void testDB() {
  DB db = DbConnector.getDB(address);
  assertNotNull(db);
}

자, 여기서는 테스트가 실패 할 때까지 DB를 반환하도록 DbConnector.getDB 클래스를 구현해야한다는 것을 알았습니다. 나는 그것을하고 ...

내가하고 싶은 다음 작업을 추가하지 말고 DB에서 메시지를로드하십시오.

@Test
public void testDB() {
  DB db = DbConnector.getDB(address);
  assertNotNull(db);
  String message = db.fetchMessage(key);
  assertEquals("hello world", message);
}

이제 메시지를 가져 오는 DB에 또 다른 작은 기능을 추가했습니다.이를 구현하고 완료하면 다음과 같이 도달 할 때까지 한 번에 하나의 기능을 계속 사용합니다.

@Test
public void testDB() {
  DB db = DbConnector.getDB(address);
  assertNotNull(db);
  String message = db.fetchMessage(key);
  assertEquals("hello world", message);
  message = "foo bar";
  db.storeMessage(message);
  message = db.fetchMessage();
  assertEquals("foo bar", message);
}

매우 간단한 예처럼 보이지만 더 복잡한 작업에도 적용됩니다. 처음에는 시간이 많이 걸리지 만 익숙해지면 실제로 훨씬 더 효율적이라는 것을 알 수 있습니다. 하나는 분석에 의한 마비를 피하고 다른 하나는 버그가 적고 반복 횟수가 적은 훨씬 강력한 코드를 얻습니다.

이것은 나에게 일어나므로 지속적인 리팩토링의 사고 방식을 받아들이고 포용하는 습관에 들어갔다. 가능한 한 가장 간단한 것을 만든 다음 정리하고 정리하고 분리하고 테스트하고 계속 진행합니다.

많은 계획이 없다고 말하는 것은 아니지만 스크랩이나 머리 속의 낙서처럼 매우 빠르고 자주 발생합니다. 결국, 나는이 작은 프로세스 마이크로 반복 (micro-iterations)을 5-20 분마다 걸리고 경험에서 내가 작업중 인 것을 끝내기 위해 2-3 시간이 걸리기 때문에 (때로는 내가 만들고있는 것에 따라) 분명히 불립니다.

부수적으로 : 나는 다양한 형태의 글쓰기 (일반적으로 보고서, 에세이 및 기술적 인 글쓰기)로 많은 사람들을지도했으며 이것은 작가의 블록을 극복하기 위해 글을 쓰는 것과 같은 방법입니다. "페이지에 떠오르는 주제에 대해 아무 것도 흐리게 처리합니다. 그런 다음 해당 주제를 이해하고 모든 단락으로 나누고 흐름을 확인합니다. 필요한 경우 다시 작성합니다."

작동 할 수있는 몇 가지 사항 :

• 해결하려는 핵심 문제를 식별하십시오. 수행하려는 작업의 핵심은 무엇입니까? 그것을 구현하기 위해 최소한의 지원 코드를 구현하십시오. 일단 만족스럽게 작동하면 각 단계마다 자비없이 리팩토링하여 반복적으로 구축하십시오.
• 다른 프로그래밍 패러다임이 효과가 있는지 확인하십시오. 모든 장점에도 불구하고 객체 지향 프로그래밍은 모든 문제에 대한 답이 아니며 모든 프로그래머의 두뇌가 그렇게 작동하는 것은 아닙니다. (순수한) 기능적 언어를 선택하십시오. 절차 코드를 작성하십시오. 하드웨어 수준까지 내려 가서 일부 C 또는 어셈블러를 수행하십시오. 등. 현재 C ++ / Java / C # / VB / ...와 같은 언어를 사용한다고 가정 할 때 마음이 흔들리는 몇 가지 언어 : Haskell, ML, Lisp (다양한 언어 선택), Erlang, Prolog, 스몰 토크 (Smalltalk), 자바 스크립트 (자바처럼 행동하고 폐쇄 특성을 받아들이려고하면), C, Pascal, awk, 그리고 아마도 12 개 이상. 주요 특징은 현재 사용하는 것과 매우 달라야한다는 것입니다. 이것은 큰 프로젝트에서 큰 일을하고 싶은 것이 아닙니다.
• 완전히 다른 설계 방법을 사용하십시오. 다른 각도에서 디자인을 선택할 수 있는지 확인하십시오. 나는 보통 당신이 수업을 배치하여 디자인을 시작한다고 가정합니다. 변경을 위해 데이터 구조로 시작하는 것은 어떻습니까? 또는 기능을 디자인하기 전에 문자 그대로 입력 양식을 그리는 UI를 먼저 디자인하는 것은 어떻습니까?

많은 설계 결정의 경우, 획기적인 프로토 타입으로 코딩하여 일부 아키텍처 또는 설계 옵션을 탐색 할 수있는 짧은 시간 제한 연구 노력 인 "스파이크"를 수행하는 데 도움이 될 수 있습니다. 예를 들어, 일부 오픈 소스 라이브러리의 사용 또는 클래스 및 인터페이스 구성 방법을 살펴볼 수 있습니다. 이 방법의 핵심은 첫 번째 방법이 만족스럽지 않을 경우 다른 접근 방법을 시도 할 수 있도록 짧게 유지하는 것입니다. 건축 결정을 더 잘 내리거나 개념을 입증하기 위해 연습에 대한 충분한 지식을 얻을 수 있기를 바랍니다. 연습 자체에는 즉각적인 코딩이 필요합니다. 즉, "git er done"을 너무 일찍 커밋하지 않고도 "writers block"에서 벗어날 수 있습니다.

그런 다음 Asaf가 프로젝트 구현을 진행하기 위해 언급 한 TDD 또는 BDD 접근법을 사용하는 것이 좋습니다.

당신은 그것을 필요로 하지 않을 것이므로 처음에 너무 많이 생각하지 마십시오.

목표와 문제를 이해하기 위해 더 많은 시간을 투자하십시오.

"확장 성 및 재사용 성"은 잘 작성된 소프트웨어 프로그램의 수명주기의 자연스러운 결과입니다.

우리가 중형 프로젝트를보고 있다고 가정하겠습니다.
나는 드로잉 보드에서 시작합니다. 이 작업을 수행하기 전에 기능적 및 비 기능적 요구 사항을 준비해야합니다. 먼저 소프트웨어 아키텍처를 생각해 봅니다. 즉, 요구 사항에 맞는 건축 패턴을 살펴보십시오. 아키텍처
가 어떻게 보이는지 결정한 후에는 저수준 디자인으로 이동해야합니다. 즉, 모든 엔티티, 클래스 및 기능을 살펴보십시오. . 여기서는 다시 맞는 디자인 패턴을 확인하고 시도합니다.이 과정에서 기본 클래스가 무엇인지, 필요한 인터페이스를 알
수 있습니다. 그런 다음 프레임 워크를 빌드하고 몇 가지 빠른 테스트를 실행하여 이것이 맞는지 확인할 수 있습니다. 모든 비 기능 요구 사항을 충족시킵니다
그런 다음 @Asaf가 제안한대로 Test Driven Development를 사용합니다.

디자인과 아키텍처에 좋은 시간을 보내더라도 필요한 경우 항상 아키텍처를 다시 방문하십시오.

나는 이것이 큰 질문이라고 생각하며 모든 사람에게 아무것도 효과가 없을 것입니다. 그런 마비는 당신의 분야에서 점점 더 유능 해져서 생기는 부산물이라고 생각합니다. 즉, 여기 내가 도움이되는 몇 가지 사항이 있지만 문제를 해결하지는 못합니다.

• 원시 프로젝트를 제쳐두고 난독 한 버전으로 작업하십시오. 이것은 당신이 말한 버전입니다 : a. 코드는 예쁘지 않아야합니다. 사실, 주요 리팩토링 및 재 포맷은 허용되지 않습니다. 그것은 절대적으로 조직화되지 않고 좋은 코딩의 유대로부터 자유 로워지게하십시오. 비. 그냥 작동해야합니다. 씨. 다른 모든 문제를 버릴 때 문제 공간에 대해 배우는 것이 항상 놀랍습니다. 또한 좀 더 깔끔한 방법으로 올바른 디자인을하는 데 도움이되는 약간의 정리를하게됩니다.

• 컴퓨터 없이도 프로젝트를 진행할 적절한 크기의 블록을 따로 보관하십시오. 실제로 달성하려는 것을 개념화하고 OO / Design Pattern 광기를 초월하는 마법의 선을 찾으십시오.

생각을 구체적으로 표현하십시오 : 글을 쓰거나 타이핑하거나, 그립니다. 이것은 필요할 때 생각을 다시 찾도록 도와 줄 것입니다. 그것은 당신이 서클에 들어가는 것을 막을 것입니다; 더 명확하게 생각하도록 도와줍니다.

내가 어디로 가고 어디에서 무언가에 대해 생각하는 것을 볼 때마다, 나는 그것들을 타이핑하고 명확하게 생각하는 데 도움이됩니다.

나는 보통 처음부터 시작하여 가능한 가장 간단한 프로토 타입을 만들고 무언가를 실행시킵니다. 프로토 타입을 사용하여 행복한 경로 테스트 사례를 리버스 엔지니어링하고, 테스트 사례를 통해 인터페이스를 구동 한 다음 사전 / 사후 계약을 고려하여 테스트 범위를 구축하십시오.

문제가 완전히 이해 될 때까지 추상화, 최적화 또는 검증에 대해 걱정하지 마십시오.