코드를 작성하지 않고 며칠 동안 디자인 문제를 생각하는 것이 정상입니까? [닫은]

때때로 나는 공허하게 공간을 응시하거나 아이디어를 스케치하고 종이에 의사 코드를 씁니다. 그런 다음 문제를 해결하고 다시 시작한 다음 문제에 대한 올바른 해결책이 있다고 생각되면 코드 작성을 시작합니다.

코드를 작성하지 않고 며칠 동안 생각하는 것이 정상입니까? 이것이 내가 문제에 완전히 접근하고 있다는 신호입니까? IDE에서 작성된 코드를 얻지 못하는 것이 긴장됩니다.

해결하려는 문제에 따라 설계 단계는 며칠이 아니라 몇 주가 아니라 몇 주 (몇 년이 아닌 경우) 가 걸릴 수 있습니다 .

코드를 즉시 bash 아웃하지 않는 경험이 필요합니다. 아키텍처와 높은 수준의 디자인에 대한 생각은 오래 걸리지 않으면 며칠 이 걸릴 것입니다. 코드 작성을 시작하기 전에 반드시 일어날 일입니다.

이를 일반적으로 "분석 마비"라고합니다.

일반적이지만 잘못되었습니다. 어떤 시점에서 다양한 아이디어를 테스트하여 자신에게 가장 적합한 것이 무엇인지 확인한 다음 점진적으로 개선해야합니다.

실용 프로그래머에게 특히 권장 되는 내용은 2 장 "Tracer Bullets"섹션

이것은 완전히 일반적입니다. 그러나 "먼저 테스트"또는 TDD 방식을 사용하는 경우 일반적이지 않으며 아이디어를 더 잘 공식화하는 데 도움이 될 수 있습니다.

습관은 일반적으로 사물에 대한 시행 착오 접근법의 결과이며 우리에게 원하는 결과를 제공하고 그렇지 않은 것을 피하는 것입니다. 우리가 좋아하는 것을 좋아하고 싫어하는 것을 피하는 것도 잘 작동합니다. 결국 임대료를 지불하기 위해 원하지 않는 일을 할 것이기 때문에 어느 정도까지는 효과가 있습니다.

무엇이 당신을 이끄는가와 당신의 이유에 달려 있습니다. 몇 가지가 있습니다 :

• 너무 자주 디자인 변경으로 인해 코드를 변경해야했습니다.
• 적은 솔루션이 이미 코딩되었으므로 열악한 디자인을 변경하지 않습니다
• 코드 지연을 작성하는 것보다 그리기 및 디자인을 선호합니다.
• 코딩의 구문과 세부 사항에 대해 걱정해야하므로 더 나은 디자인에 대한 생각이 산만 해집니다.

더 오래 디자인하면 코드가 더 좋다는 것을 알게 되셨기를 바랍니다. 되돌아 보면 디자인에 시간이 얼마나 걸리든 상관 없다면 변경을 원할 수 있습니다. 또 다른 고려 사항은 디자인 작업과 비교하여 코드를 작성한 후 문제를 발견하는 빈도입니다. 코드를 작성하기 전까지 문제를 찾지 못하면 균형을 고려하여 나중에가 아니라 더 빨리 코딩해야합니다. 이 접근법은 최신 기술이나 매우 복잡한 기능의 사용에 적용될 수 있습니다.

하나의 접근 방식이나 다른 접근 방식을 고수 할 때에도 하나의 접근 방식 또는 다른 접근 방식을 고수 해야하는 분야가 있는지 모르겠습니다. 때때로 나는 화이트 보드에 갈 필요가 있다고 느낀다. 다른 키보드.

매우 일반적이며 사물을 처리하고 이해하는 더 좋은 방법이라고 생각합니다. 프로젝트를 진행하는 동안 여러 번 문제가 발생하여 어떻게 더 잘 접근 할 수 있는지 이해하는 데 하루나 이틀이 걸립니다. 문제가 해결 된 후에도 하루가 지나기를 기다립니다. 이것은 나를 더 상쾌하게 만들고 나아갑니다.

자연 현상이며 개발자가 마음의 시간을 중간에 가로채는 것이 좋습니다.

프로젝트 관리 과정을 수강했을 때 강사가 계획과 관련하여 내 머리에 갇힌 것 중 하나는 군대에서 가르치는 경험의 규칙이 계획 시간의 1/3을 차지한다는 것입니다. . 따라서 지금부터 3 개월 동안 완료해야하는 작업이있는 경우 실행을 시작하기 전에 계획에 한 달을 소비하는 것을 고려하십시오.

제 생각에는 특정 코딩 상황에 적합한 세 가지 접근법이 있습니다.

1. 이전에도 비슷한 문제를 보았으므로 적용 할 패턴과 솔루션이 어떻게 반응하고 반응해야 하는지를 잘 알고 있습니다.

   => 원하는 솔루션에서 시작하여 코드에서 작업하는 BDD / TDD를 사용하십시오. (좋아, 때로는 약간의 코드를 속여서 작성한 다음 테스트-중첩 된 2.-> 1. 접근법의 종류).

2. 적용 할 패턴을 잘 알고 있지만 솔루션의 모양을 잘 모르겠습니다.

   => 어떤 흥미로운 것들이 튀어 나오는지 확인하기위한 프로토 타입. 어떤 흥미로운 것이 바람직한 지 알아낼 때 1.로 이동하십시오.

3. 어떤 패턴을 적용할지 잘 모르겠습니다.

   => 문제와 문제에 접근하는 다양한 방법이 코드에 어떤 영향을 미치는지 생각하십시오. 해당 운동의 결과에 따라 2) 또는 1)로 이동하십시오.

다시 말해, 엔지니어가 가장 선호하는 답변은 다음과 같습니다.

한 달 동안 생각하고 디자인하는 것이 하위 표준 디자인을 기반으로 한 빠른 프로토 타입을 만드는 것보다 모양이 좋습니다. 특히 당신이 팀에 있다면; 다른 사용자가 코드에 따라 시작하면 다른 API로 더 나은 디자인을 구현하기가 훨씬 어렵습니다.

원칙적으로 문제 / 해결책을 생각하는 데 시간을내는 것이 좋은 생각이라는 다른 답변에 동의합니다. 그러나 갇힌 것처럼 느껴지면 계획 프로세스를 좀 더 일관성있게 만드는 방법에 대한 몇 가지 권장 사항이 있습니다.

• 디자인 아티팩트를 작성하십시오. 코드를 작성하지 않으면 어떻게됩니까? 어쩌면 당신은 단지 당신의 생각의 일기를 쓰십시오. 또는 일반적인 솔루션의 스케치. 또는 시간이 지남에 따라 개선하는 문제에 대한 훌륭한 요약 만 제공합니다. 아이디어를 고려하고이를 수락 / 거부 할 때 주제에 대한 추론을 기록하십시오. 이렇게하면 하루가 끝날 때까지 실제 작업 결과물을 작업의 증거로 지정할 수 있습니다.

• 사람들과 대화하십시오! 아이디어를 논의 할 수있는 살아 숨쉬는 인간을 갖는 것만 큼 좋은 것은 없습니다. 갇혀 있다고 생각되면 누군가와 대화하십시오. 누군가-누군가를 잡아서 그들에게 문제를 설명하십시오. 문제 해결 방법에 대한 생각을 스케치하십시오. 그들이 당신이 babble 동안 10 분 동안 숨을들이 쉬고 내쉬고 깜빡이더라도 , 문제를 설명하는 과정에서 새로운 통찰을 발견 할 가능성이 있습니다 .

Satchel Paige가 말했듯이 "때로는 앉아서 생각하고 때로는 앉아 있습니다."

그가 겪고있는 것은 당신의 생각을 다른 방식으로 생각하게 할 수 있기 때문에 때때로 당신의 마음을 깨끗하게하는 것이 좋다는 것입니다. 따라서 코드를 사용하지 않으면 다른 방법으로 회피 할 수있는 해결책이나 아이디어가 나올 수 있습니다. 그렇습니다. 코딩에 뛰어 들지 않는 것이 좋습니다.

이 과정을 직접 수행하는 두 가지 방법이 있습니다. 텍스트 파일과 프로젝트와 관련된 도면이있는 폴더를 만듭니다. 나는 내 아이디어를 적어두고 가능한 한 최선의 사고 과정을 시도하고 저장합니다. 또한 알고리즘에서 CSS 레이아웃에 이르기까지 간단한 아이디어를 빠르게 테스트 할 수있는 스크래치 패드 프로젝트를 작성합니다.

프로그램 = 알고리즘 + 데이터 구조

IMHO, 디자인 (문제 해결) 과정은 전적으로 규칙입니다. 구현 (기술 문제) 세부 사항은 자연스럽게 따르고 해결됩니다.

여기 내 생각이 있습니다.

1. 처음부터 시작 먼저 원하는 것을 대략적으로 생각해야합니다. 일부 요구 사항 목록을 얻거나 작성하십시오. 여기서 상황을 파악하는 데 약간의 시간이 걸립니다. 최소한 자신이 원하는 것으로 생각되는 부분이 있으면 해당 부분의 인터페이스를 대부분 알고 있으면 코딩을 시작하십시오.

2. 기존 코드로 문제 해결 우선 문제를 추적하십시오. 실제 코드를 작성하지 않는 데 다소 시간이 걸릴 수 있습니다 (일부 디버그 코드가 작성 될 수 있지만 일반적으로 유지되지는 않습니다). 복잡성에 따라 문제를 찾으면 코드 작성을 시작하여 문제를 해결하십시오. 일단 버그가 알려지면 약간의 생각이 필요합니다. 문제가 주요 디자인 결함으로 판명되면 다음 섹션을 참조하십시오.

3. 디자인 변경 / 주요 특징 이것은 아마도 가장 많은 생각을 필요로 할 것입니다. 구조 보존에 대한 생각, 이전 버전과의 호환성 등이 포함되어야합니다. 최상의 변화를 생각하면 상당한 시간을 절약 할 수 있지만 일반적으로 며칠을 넘지 않습니다.

4. 간단한 기능 추가 중대한 설계 변경이 필요하지 않으면 시행 착오를 통해 기능을 간단히 코딩하십시오. 일반적으로 많은 시간이 필요하지 않습니다.

나는 이것에 대한 합의에 동의하지 않을 것입니다. 시스템 작동 방식에 대한 애매 모호한 개념을 갖 자마자 무언가를 프로토 타이핑하기 시작합니다. 매우 정확하게 방법을 지정하지 않으면 문제를 일으킬 수있는 작은 세부 사항을 모두 생각하는 것이 거의 불가능합니다. 사람들과 디자인을 논의하고 있다면 좀 더 복잡한 문제를 직접 해결하기가 너무 쉽습니다. 이와 같은 것을 지정하면 정확하고 형식적이지만 컴파일 및 실행할 수없는 다른 표현 방법 대신 소스 코드에 직접있을 수 있습니다.

"normal"의 의미에 따라 다릅니다 . 나 자신에 대해 말하면, 코드는 훌륭한 학습 도구라고 생각합니다. 복잡한 문제에 직면 할 때 종이에 스케치를하지만 테스트 중심 코딩도합니다. 코드는 화이트 보드가 말을 할 수없고 그 반대도 가능하다고 생각하며 결과는 통찰력이 있거나 도메인 전문가에게 몇 가지 질문이 더 필요할 수도 있습니다.

따라서 실제 조언은 "문제 정의에 가까워지기 위해 필요한 모든 학습 도구를 사용하십시오" 뿐만 아니라 "이 도구는 학습 도구이므로 기억하지 마십시오"라는 코드와 스케치는 모두 버려야합니다. .

RAD 및 민첩한 프로그래밍 시대에 시스템의 주요 부분을 식별하자마자 개발을 시작해야합니다. 소프트웨어가 점점 커지고 있기 때문에 모든 세부 사항에 조기에 집중하면 아무데도 도움이되지 않습니다.