최고의 디자인 결정을 선택할 때 종종 멈춰 있습니다. 함수 정의, 제어 흐름 및 변수 이름과 같은 작은 세부 사항조차도 선택의 이점과 장단점에 대해 비정상적으로 오랜 시간을 소비합니다.
나는 이것과 같은 중요하지 않은 세부 사항에 시간을 소비함으로써 많은 효율성을 잃고있는 것처럼 느낍니다. 그럼에도 불구하고 현재 디자인이 제대로 작동하지 않으면 이러한 것들을 바꿀 수 있다는 것을 알고 있습니다. 한 가지 선택만으로 결정하는 데 어려움이 있습니다.
이 문제를 해결하려면 어떻게해야합니까?
답변:
두 가지 간단한 규칙 :
이러한 각 작업을 시작하면 나중에 변경에 대응할 수있는 능력을 손상시키지 않으면 서 간단한 결정을 내릴 수 있다는 확신을 갖게됩니다.
향후 교정은 코드를 변경해야 할 수있는 모든 가능한 방법을 예상하지 않고 코드를 쉽게 변경할 수 있음을 의미합니다.
일반적으로 그런 느낌이들 때 시도해야한다는 것을 의미합니다.
문제에 구문과 작은 조각이 관련된 경우 :
자신을 무 활동으로 생각하는 것은 매우 쉽습니다. 당신이 관리하더라도, 어떻게 든 최선의 해결책을 마련하기 위해 지금 다음 무엇을 그 쉽게 전에 변경할 수있는 프로젝트를 완료하고?
최상의 솔루션이 무엇인지 앉아서 생각하는 것보다 알맞은 솔루션을 선택하고 실행하는 것이 좋습니다 . 최선의 해결책은 애매하고 더 나쁘고 주관적입니다. 요구 사항이 조금이라도 바뀌면 솔루션은 당시 최고가 아니기 때문에 버린 솔루션보다 나빠질 수 있습니다.
나는 분석 마비도 피하는 법을 배우고 있습니다. 그래서 우리에게도 =) 이것은 "최상의 디자인"을하고 싶기 때문에 종종 발생합니다. 실제로 "최고"는 보는 사람의 눈에 있습니다. 분석 마비를 피하기위한 나의 공식은 충분한 디자인 원칙 을 적용하는 것 입니다. 어떻게합니까? 나는 시간 제약과 같은 변수를 가져 와서 일정을 잡고 품질을 손상시키지 않고 작업을 수행 할 수있는 가장 간단한 디자인이 무엇인지 스스로에게 묻습니다. 그러나 동시에 테스트 할 수 있는지 확인 하고 확장을 위한 공개 (OCP)디자인도. 테스트 가능 및 OCP 란 무엇을 의미합니까? 글쎄, 내가 가장 잘 고려한 것을 찾는 대신, 상황이 나빠질 때를 알려주고 나중에 리팩토링하고 개선 할 수있는 충분한 코드를 시도하는 디자인을 고려했습니다. 또한 동일하게 유지되는 코드로 변경 될 코드를 분리하십시오. 리팩토링이 더 쉬워집니다. 변경되지 않아야하는 코드는 미래에 당신이나 다른 사람으로부터 더 안전하기 때문입니다.
당신의 직감이 옵션 중 하나를 결정하게하는 것은 어떻습니까? 그것은 꽤 빠르며, ammoQ도 제안한 타임 박스 와 잘 어울려야한다 . 옵션이 이미 설정된 경우 1 분, 또는 먼저 정의해야하는 경우 2 분으로 제한 할 수 있습니다. 또는 적절한 것 (사전 정의). 직감에 귀를 기울이는 것을 배우면 실습을 통해 직관적 인 선택이 더 빨라지고 향상됩니다 .
완벽하지 않은 것을 선택할 가능성에 대한 걱정에 시달리는 경우 다음을 해결하기위한 몇 가지 생각이 있습니다.
행운을 빕니다! :)
결정하기를 꺼려하기 위해 타임 박스를 적용하십시오 . 몇 분 안에 알람 시계가 울리도록 설정하십시오. 그때까지 당신의 마음을 괴롭히지 만 경보가 울릴 때까지 그때까지 찾은 최고의 옵션을 선택하십시오.
프로토 타입을 만듭니다. 프로토 타입은 버려 지므로 사용하는 함수, 변수 이름 또는 그랜드 아키텍처는 중요하지 않습니다. 당신은 그것이 작동한다는 것을 증명하기 위해 그것을 구축했습니다.
일단 당신이 그것을 만들고 그것을 버렸다면, 나는 당신이 그 결정을 내리는 데 더 쉬운 시간을 가질 것이라고 기꺼이 생각합니다.
나는이 문제로 고통받습니다. 내가 말하고자하는 것은 충분한 인센티브가 충분하지 않다는 것입니다.
예를 들어, 렌더링 코드를 작성할 때 시스템을 실제로 사용하면 시스템을보고 쿼드를 텍스처링하는 것이 얼마나 멋진 지 알았 기 때문에 완료 인센티브가 컸습니다. 또는 vert 변환. 그러나 이제는 리팩토링 (알고 싶은 경우 4 번 시도) 한 다음 많은 작업이 있기 때문에 고통 받고 있습니다. 마무리해도 이전의 동일한 쿼드가 표시됩니다. 그리고 나는 다시 리팩토링하고 싶지 않으며 같은 오래된 쿼드를 반복해서 보는 것에 질려서 더 이상 나에게 보상이 아닙니다.
콘솔 I / O가 작동하고 있음을 보여 주더라도 구성 요소로 분류하고 완성한 것에 대해 스스로 보상해야합니다.
나는 다른 포스터들과 함께 당신의 질문을 읽고 생각하고있었습니다 : 당신은이 직업에 적합하지 않습니다. 자신에게 시간 제한을 제공하십시오. 잠시 다른 일을하십시오. 약간의 반성 후, 나는 어떤 대답이 실제로 그렇게 도움이 될지 확신하지 못한다
이와 같은 정신 문제의 문제는 해결하기가 쉽지 않고, 당신의 일부이며, 당신이 직업에 대해 (너무 많이) 관심을 가지고 있고, 자신에 동의 할 자신감이 없으며, 첫 번째 선택을 고려한 경험이 전혀 없었거나 완벽하게 올바른 것보다 너무 많은 스트레스를 받았습니다. 왜 그런 사소한 일에 대해 걱정하겠습니까?!
이제 비슷한 문제가 있지만 코드가 너무 많지 않습니다. 일반적으로 저녁 식사를 위해 무엇을해야합니까 .. 피자 나 카레. 흠 ... 피자하지만 카레는 좋지만 카레처럼 느껴지지만 피자는 저렴합니다. 그러나 더 많은 카레를 얻지 만 ... 등등. :)
그래서 나는 코딩에 비슷한 문제가없는 이유를 생각했습니다. 그리고 정기적으로 사용하는 패턴 세트가 있기 때문에 간단하게 생각합니다. 함수 정의가 필요하다면, 쉬운 일이다. 내가 코딩했던 다른 모든 함수 정의와 같은 맥락에있을 것이다. 제어 흐름이 필요한 경우 먼저 for 루프 또는 while 루프가 필요한지 여부를 결정한 다음 마지막에 사용한 것과 동일한 이전 코드를 작성하여이 중 하나가 필요합니다. 모든 것이 동일합니다. 대기열을 원합니까? 물론-내 '표준'대기열 코드를 잘라 붙여 넣을 수 있습니다 (마지막으로 작업 한 프로젝트 또는이 중 하나를 사용하여 기억할 수있는 코드). 최종 결과 ... 나는 단지 새로운 것들에 대해 걱정하고 있으며, 솔직히 말하면, 그것은 기쁨입니다.
그래서 제 충고는 코드 스 니펫 라이브러리를 작성하는 것입니다. 이메일로 이메일을 보내고 폴더에 넣었지만 사용하는 것이 가장 좋습니다. 매번 할 일을 알기 시작합니다. 항상 이전에 작성한 코드로 이동하여 문제를 해결하고 다음 문제에 대비하십시오. 당신은 훨씬 더 빠른 개발자가 되리라는 것을 알게 될 것입니다. 위에.
물론, 후자의 모든 부분도 중요합니다. 작업이 많을수록 생각하는 데 덜 고급스러워집니다.
Rein Henrichs ( 단순, 리 팩터 시작 )와 ammoQ ( 타임 박스 ) 의 제안 을 결합한 전략은 다음과 같습니다 .
x을 다할 때까지 수정하십시오 .stringnameuserHandle이 방법의 가능한 이점 :
일반적으로 결정할 수없는 이유는 그 차이가 중요하지 않거나 충분한 정보가 없기 때문입니다.
a) 고려해야 할 합리적인 옵션을 제시하기 위해 시간 제한을 설정하십시오. 아직 어느 것을 결정하지 마십시오. 시간이 끝나면 식별 된 옵션 중 하나 (임의의 선호가없는 경우 무작위로)와 다른 시간 제한을 선택하십시오. 시간이 끝날 때 분명한 결정이 없으면 이미 선택한 결정입니다. 코딩을 시작하고 명확하게 틀린 경우 리팩터링하십시오. 사장님이 왜 "내가 동전을 뒤집었을 때 더 좋은 방법이 있습니까?"라고 물으면
경우 b)-당신은 더 많은 정보가 필요하며, 당신의 큰 뚱뚱한 A.에 앉아 하루 종일 그것을 제공하지 않을 것입니다. 디자인 모드에서 벗어나 정보 수집 모드로 들어갑니다. 프로토 타입, 질문, 기술 잡지를 읽으십시오. 당신이하는 동안, 너무 오래 자지 마십시오.
종종 최선의 해결책은 결정을 동료에게 설명하는 것입니다. 그러나이 작업을 자주하지 않으려면 다음으로 가장 좋은 방법은 종이 / 펜 또는 빈 메모장 창을 사용하여 종이에 대해 생각하는 것입니다.
글의 리듬에 들어가기 위해 절대적으로 무엇이든 쓰면서 시작하십시오. 메모장 창에서 "종이에 대해 생각하고 있습니다"라고 입력 한 다음 일련의 의식을 계속 수행 할 수 있습니다. 몇 초 후에 작문의 리듬에 빠질 수 있으므로 enter 키를 몇 번 누르고 딜레마를 설명하십시오.
문제를 진술 한 다음 가능한 해결책, 각각에 대해 좋은 점 등을 진술하십시오.
항상 작동하는 것은 아니지만 헤드 (RAM)와 외부 미디어 (메모장 문서)에 대한 생각을 얻는 과정을 통해 새로운 연결을 만들고보다 다양한 관점에서 의사 결정을 볼 수 있습니다.
나는 같은 문제로 고통받습니다. 작은 문제의 경우, 처리하려고하는 방식은 내가 생각한 첫 번째 디자인을 다루는 것입니다. 최적의 디자인을 찾으려고 노력할 필요는 없습니다. 글씨를 쓰지 않고 생각할 수있는 모든 디자인의 뉘앙스에 대해 추론하는 것이 불가능하지는 않더라도 어렵습니다. 코딩 할 때 약간의 개선이 가능하다는 것을 알게 될 것입니다. 맞습니다.이 방법으로 합리적으로 좋은 솔루션에 수렴하는 것이 상당히 쉽다는 것을 알았습니다.
더 큰 문제의 경우 먼저 옵션을 통해 생각하는 것이 장점이라고 생각하지만 타임 박스입니다. 큰 문제에는 큰 솔루션 공간이 있으므로 모든 가능성을 평가할 수 없으며 시도하지 않아야합니다.
TLDR; 합리적인 솔루션을 선택하고 갈수록 개선하십시오.
이것은 또한 관련이 있습니다 :
도예 교사는 개막 일에 수업을 두 그룹으로 나누겠다고 발표했습니다. 그는 스튜디오의 왼쪽에있는 모든 사람들은 자신들이 생산 한 작업의 양, 오른쪽에있는 모든 것들은 그 품질에 따라 등급이 매겨 질 것이라고 말했다. 그의 절차는 간단했습니다. 수업 마지막 날에 그는 욕실 저울을 가져 와서 "수량"그룹의 작업을 측정했습니다. 50 파운드의 냄비는 "A", 40 파운드는 "B"등입니다. 그러나 "품질"로 등급이 매겨진 사람들은 "A"를 얻기 위해 단지 하나의 냄비 만 생산해야했습니다.
글쎄, 등급이 매겨졌고 호기심이 생겼습니다. 최고 품질의 작품은 모두 양을 위해 등급이 매겨진 그룹에 의해 생산되었습니다. "수량"그룹이 바쁘게 일을 쌓고 실수로부터 배우는 동안 "품질"그룹은 완벽에 대해 이론을 세우고 결국 큰 이론보다 그들의 노력에 대해 보여줄 것이 거의 없었던 것 같습니다. 죽은 점토 더미.
에서 http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .
나는 이것을 이해하지 못했습니다. 내가 강사 였을 때 나는 다음과 같이 말할 것이다.
"OK, create an integer variable and assign the return value of strlen() to it."
너무 복잡하지 않다고 생각하면 사람들의 95 %가 다음과 같이 썼습니다.
int x; // or y, or len, or whatever
x = strlen( s );
그러나 때때로 헤드 라이트에 마비 된 토끼처럼 앉아있는 사람이있을 것입니다. 나는 문제가 무엇인지에 대해 공감 적으로 묻고 "무엇을 부를지 모르겠다!"라고 말할 것입니다.
이들은 다른 직업을 찾아야하는 사람들입니다. 어쩌면 당신은해야합니다.