“너무 많은 지식”으로 인해 막힘 [닫힘]

http://news.ycombinator.com/item?id=4037794 에서 자세한 내용을 확인 하십시오.

비교적 간단한 개발 작업이 있지만 공격을 시도 할 때마다 미래를 확장 할 수있는 방법, 2 세대 고객이 필요로하는 것, "비 기능적"에 어떤 영향을 미치는지에 대해 깊이 생각하게됩니다. 측면 (예 : 성능, 인증 ...), 변경을 허용하도록 설계하는 것이 가장 좋은 방법 ...

나는 한참 전에 더 젊고 어쩌면 더 열심을 기억합니다. "나"는 그때 그 모든 것에 대해 생각하지 않았을 것입니다. 그는 앞서 가서 뭔가를 썼다가 다시 썼다가 다시 썼을 것입니다. 오늘의 "나"는 더 주저하고 더 신중합니다.

저는 오늘날 다른 사람들이 실제로 진행하고 직접 수행하는 것보다 일을하는 방법에 대해 앉아서 계획하고 지시하는 것이 훨씬 쉽다는 것을 알고 있습니다. 하지만 키보드에 앉을 때마다 같은 성가신 장소에있게됩니다.

이것이 잘못 되었습니까? 이것이 자연스런 진화인가, 아니면 내가 틀에 박힌 행동으로 이끌 었는가?

공정한 공개 – 과거에 나는 개발자 였지만, 오늘 제 직책은 "시스템 아키텍트"입니다. 그것이 의미하는 바를 알아내는 행운을 빕니다-그러나 그것이 제목입니다.

와. 나는 솔직히이 질문이 그렇게 많은 반응을 낳을 것으로 기대하지는 않았다. 요약하자.

원인:

1. 분석 마비 / 공학 / 금도금 / (다른 많은 "사전 생각은 당신을 해칠 수 있습니다").
2. 주어진 작업에 대한 경험이 너무 많습니다.
3. 중요한 것에 집중하지 않습니다.
4. 경험이 충분하지 않습니다.

솔루션 (이유와 일치하지 않음) :

1. 먼저 테스트하십시오.
2. 코딩 시작 (+ 재미)
3. 하나는 버릴 것입니다 (+ 하나는 버릴 것입니다).
4. 시간 제약 조건을 설정하십시오.
5. 보풀을 벗기고 물건과 함께있어.
6. 융통성있는 코드를 만드십시오 ( "일부 폐기"와 반대의 반대).

모두에게 감사합니다-여기에서 가장 큰 이점은 내가이 경험에서 혼자가 아님을 깨닫는 것이 었습니다. 나는 실제로 이미 코딩을 시작했으며 너무 큰 것들 중 일부는 자연스럽게 떨어졌습니다.

이 질문은 마감되었으므로 오늘 현재 대부분의 투표로 답변을 수락하겠습니다. 언제 / 변경되면-따라하려고합니다.

이러한 것들에 대해 생각하는 것은 확실히 좋지만 진행 상황을 막지 마십시오.

실제로 (특히 반복 개발에서) 효과적으로 작동하는 한 가지 방법은 간단한 솔루션을 구현 한 다음 나중에 필요에 따라 리팩터링하는 것입니다. 이를 통해 코드를 최대한 간단하게 유지하고 과도한 엔지니어링을 피할 수 있습니다. 고려중인 성능 또는 아키텍처 변경 사항은 대부분 필요하지 않을 것이므로 공식적으로 필요할 때까지 작성하지 않아도됩니다. 예를 들어, 프로파일 러가 성능을 향상시킬 시간이라고 말할 때까지 성능에 대해 걱정하지 마십시오.

조정하는 데 도움이되는 한 가지 방법은 코드를 작성하기 전에 무언가에 대해 생각하는 시간에 대해 어려운 시간 제한을 설정하는 것입니다. 대부분의 경우 코드를 약간 생각하고 작성하고 실수를 인식 한 다음 리팩토링을 통해 수정하면 코드가 더 잘 나타납니다.

여기에 맞아야 할 균형이 있습니다. 머리를 숙이고 결과에 대해 생각하지 말고 코드를 과도하게 엔지니어링하려고 시도해서는 안됩니다.

Wikipedia 는 소프트웨어에서 "분석 마비"라고 명명합니다 . 레시피는 민첩한 방법론을 고수하는 것입니다. 모든 활동이나 개별 행동은 관행이나 정책을 수립하려는 시도보다 훨씬 가치가 있음을 의미합니다. 팀의 모든 기고자는 개인의 능력이 건축 적 이상에 얼마나 적합하거나 나쁜지에 관계없이 가치가 있습니다. 민첩하고 개인, 자아가 우선이며 정책은 마지막입니다.

가장 좋아하는 답변은 "Architecture is verb"입니다. 귀하와 팀이 아무리 불완전하고 비효율적이라고 생각하더라도 생각을 멈추고 행동을 시작하십시오. 아마도 첫 번째 조치는 부적절한 정책을 해체 할 수 있습니다.

40 년 전 프레드 브룩스는이 글에 대해 썼다. 아무것도 변하지 않았다........

이것이 잘못 되었습니까? 이것이 자연스런 진화인가, 아니면 내가 틀에 박힌 행동으로 이끌 었는가?

따라 다릅니다. 이것은 개발자의 길을 따라 일반적인 단계 인 경향이 있습니다.

1. 쓰레기를 같이 던지기 시작해 엉덩이에 물리지
2. 모든 것에서 살아있는 지옥을 과도하게 엔지니어링하고, 야 그니가
3. 쉬운 물건을 함께 때리고 실제 / 변경 될 수있는 물건에 충분한 공학이 주어지면서 작업 / 변경이 용이 한 실용적인 중간 지점에 정착하십시오.

당신이 2 번에 머물면 그것은 틀에 박힌 것입니다.

내가 항상 명심하고 싶은 것 중 하나는 "미래는 예전과 같지 않다"는 것입니다.

어느 정도의 경험이 있으면 미래를 예측할 수 있다고 믿기 힘들지만, 그럴 수는 없습니다. 미래의 클라이언트 / 사용자 / 원하는 것이 무엇이든 원하는 기능을 쉽게 구상 할 수 있지만 이것이 바로 고객이 원하는 것을 의미하지는 않습니다. 또한 다른 상충되는 기능을 원한다는 의미는 아닙니다. 따라서 미래를 계획하기 위해 오늘 보내는 시간을 제한해야합니다. 특히 미래에만 사용될 예정인 오늘날 물건을 만드는 데 소비하는 시간을 제한해야합니다.

내가 똑바로 좁히도록 요구하는 질문은 "지금이 기능에 대한 지원을 구축하는 것보다이 기능을 나중에 빌드하는 것이 얼마나 더 어려울 것입니까?" 일반적으로, 미래의 노력은 지금하는 것과 거의 같거나 아마도 두 배의 노력이라는 것입니다. 이 경우 미래를 예측할 수 없기 때문에 지금 구축하지 않는 데 아무런 문제가 없습니다. 답이 10 배 이상이되면, 내년이나 2 년 안에 사람들이 이것을 필요로 할 것이라고 생각하는 사람들에 대해 물어볼 것입니다. 그럼에도 불구하고, 광범위한 동의가 없다면, 나는 미래에 그 목표를 달성하기 위해 오늘날 우리가하고있는 일을 취소 할 필요가 없도록 스스로를 제한 할 것입니다.

예를 들어, 나중에 Hibernate를 데이터 액세스로 사용하고 있다는 사실을 추상화하는 데 많은 시간을 소비 한 몇 가지 프로젝트를 수행했습니다. (내가 Hibernate 기반으로 구축 된 프로젝트가 그것을 사용하는 것을 본 적이 없어서 시작하는 데 시간이 낭비되었지만 그것을 따로 설정해 보자.) 나중에 변경하고 싶을만한 합리적인 가능성이 있었음에도 불구하고 우리는 또한 데이터 액세스 객체 패턴을 사용하고 있었기 때문에, 처음부터 유연성을 구축하는 것보다 최대 절전 모드를 변경하고 필요할 때 동시에 변경하는 것이 어렵지 않았습니다. 지금과 같은 상황에 직면했을 때, 나는 우리가 실제로 필요할 때까지 유연성을 갖기를 원했습니다.

대기업을위한 전략적 계획을 세우지 않는 한, 기술이 빠르게 변화하고 있기 때문에 2 ~ 3 년 이상 건축 문제에 대해 생각할 가치가 없습니다. 오늘날 구축에 대해 생각하고있는 기능은 2-3 년 안에 오픈 소스로 자유롭게 제공 될 수 있습니다. 거의 확실하게 비용-이익 분석이 변경 될 것입니다.

오늘날 필요한 것을 수행하고, 자랑스럽게 생각하며, 다음 번 변경으로 인해 몇 달 안에 작업 할 수있는 시스템을 구축하도록 제한하십시오. 정말 당신이 할 수있는 최선입니다.

다음은 (첫 번째 버전에서) 실용적이지 않고 비즈니스 관점에서 프로젝트를 손상시킬 수있는 굉장한 디자인에 대한 개인적인 제거 프로세스입니다.

1. 진원지 확인 : 프로젝트를 핫도그 스탠드로 생각하면 진원지는 핫도그가됩니다. 스탠드에서 다른 향신료 / 드레싱 / 식물을 꺼내서 핫도그를 판매 할 수 있습니다. 소프트웨어의 주요 목적은 무엇입니까? 다른 모든 추가 및 / 또는 추가 된 가치를 격리하고 진원지에 먼저 집중하십시오.
2. "나중에하는 것이 더 나은 것을 의미한다"라는 말을 계속 반복한다 : 그것이 의미가있는 곳을보고 그것에 대해 "나중에"메모를한다. 잘하고 실제 사용에 대해 생각하면 동일한 디자인으로 끝나지 만 로드맵에서 우선 순위가 결정됩니다.
3. Deminish-Decouple-Discard : 어떤 모듈 디자인을 사용하든 단순 / 필수 / 순수 / 범용으로 만들 수 있습니다 (때로는 기능을 제거하지 않고도 달성 할 수 있음). 더 단순화 할 수 없으면 스스로 살면서 목적을 가질 수있는 요소 분리를 시작하십시오. 결국 거기에 약간의 지방이 있으면 그냥 잘라낼 수 있습니다.
4. "프로덕션 코드"와 "라이브러리 코드"분리 : 재사용 할 수없는 코드가 항상 있지만 항상 디자인에 노이즈를 추가합니다. 이 코드는 비즈니스 규칙이 포함 된 코드입니다. 때로는 일부 비즈니스 규칙 이 견고한 디자인보다 쉽고 빠르게 변경 ( 매우 중요 ) 하다는 것을 알게 될 것입니다 . 신뢰할 수있는 코드와 향후 고객이 변경하거나 다시 구현해야하는 코드를 찾을 수 있습니다. 당신은 그것들이 가능한 한 분리되어 유지되기를 원할 것입니다.

BTW의 0 단계는 "디자인에 열중합니다"입니다. 이를 통해 시스템에서 시스템을 꺼내고 새로운 의미, 숨겨진 요구 사항 및 응급 기능을 찾을 수 있습니다.

나는 Rework 에서 1 & 2를 가져 갔다 .

테스트를 작성하십시오. 오버 엔지니어링의 서사시 단계 이전에, 그리고 확실히 오래지 않아 테스트가 모두 통과되면 완료됩니다. 작성하는 코드에 대해 일련의 테스트를 수행하면 중지 할 수있는시기를 알려주는 독립적이고 편견없는 관찰자가 제공됩니다.

어릴 때는 위험을 느끼지 못하지만 (중년 정치인들이 무서워하는 이유 일 수도 있지만) 나이가 들어감에 따라 나쁜 경험은 기회가있을 때마다 마비됩니다 (아마도 고위 정치인이 정체 한 이유 일 수 있습니다). Occam의 면도기 가이드 접근 방식을 채택하십시오 -가장 적은 요구 사항을 가진 솔루션을 찾은 다음 거기서 진화하십시오.

소프트웨어를 작성하고 설계 할 때 반드시 염두에 두어야 할 사항은 유지 관리 성 및 정확성입니다.

정확성은 단기적으로 가장 중요하며 테스트를 통해 쉽게 입증 할 수 있습니다.

유지 관리 성은 나중에 개발에 도움이되지만 찾기가 더 어렵습니다.

나의 현재 전략은 우선 모 놀리 식 개념 증명을 얻은 다음 UI를 모델에서 분리하는 것입니다 (모델이 UI에 대해 아무것도 알지 못하도록 보장). 이 단계를 너무 오래 기다리면 유지할 수없는 것을 얻게됩니다. 분리 된 레이어로 시작하면 UI가 모델에 대해 알아야 할 사항을 고수하면서 시작할 수없는 것 같습니다.

이런 상황에 처했을 때, 나는 가상의 프로그램을 사용하여 합리적인 사소한 일을 끝내는 최종 사용자라는 것을 완고하게 상상하는 것이 도움이된다는 것을 알게되었습니다. 그런 다음 해당 작업을 지원하는 데 필요한 프로그래밍 방식의 진입 점이 무엇인지에 초점을 맞추고 가능한 한 시스템의 다른 측면을 무시하려고 노력합니다. 여기에서 완성 된 시스템의 기능에 대한 (작은!) '위시리스트'를 구성하고 이를 구현하기 시작 하는 비현실적인 코드를 작성하는 것이 종종 가능 합니다. 그 운동 후, 나는 보통 시작되고 나머지 시스템은 더 명확 해지기 시작합니다. 그것은 모든 진입 점에 관한 것이며 모든 소프트웨어의 대다수의 진입 점은 최종 사용자가 프로그램을 사용하는 초기 행동입니다.

나는 당신이하고있는 작업이 너무 쉬운 신드롬이라고 생각합니다.

몇 년 전에 당신을위한 도전은 주어진 작업을 수행 할 코드를 작성하는 것이 었습니다. 이것이 당신의 마음을 완전히 사로 잡았습니다. 이제, 당신의 마음 (경험 등)이 더 효과적으로 일하고 있으며 같은 일을하기 위해서는 이전에 필요한 에너지의 일부만 필요합니다. 이것이 당신이 그 깊은 생각의 나선형으로 끝나는 이유입니다. 당신의 마음은 일상으로부터 자신을 방어하고 도전을 위해 싸우고 있습니다.

작업 변경을 고려해야한다고 생각합니다. 아마도 새로운 프로그래밍 언어를 배워야 할 것입니다.

15 년 전 같은 문제가있었습니다. 솔루션을 필요 이상으로 훨씬 더 복잡하게 만드는 완벽하고 재사용 가능한 범용 코드를 작성하고 싶었습니다. 오늘 나는 이것을 금도금 으로 본다 . 많은 도움이 된 것은 동료의 조언이었습니다.

• 기능을 향상시킬 수있는 아이디어가 있다면보다 보편적으로 만들 수 있습니다. ...이 아이디어를 별도의 텍스트 파일 "ideas.txt"에 작성하되 지금 구현 하지는 마십시오 .
• 긴급한 작업을 계속 수행하십시오.
• 6 개월 후 "ideas.txt"를 검토하고 프로젝트에 실제로 도움이 된 변경 사항을 분석하십시오.

이것은 단순히 분석에 의한 마비입니다. 그것은 많은 분야의 많은 사람들에게 발생합니다. 당신은 그것을 뚫을 수 있습니다.

대답은-그냥 IT와 함께하십시오 ;-)

나는 피트니스 포럼에 글을 올리는 사람들이 여러 번 다른 루틴에 대해 글을 올리며 정확한 루틴을 찾으려고 노력합니다. 그래서 우리는 그들에게 훈련을 시작하고 당신이 따라갈 때 작동한다고 말합니다. 당신은 더 강해지기를 원하고, 약간의 운동을하고, 당신이 갈 때 일을 조정합니다.

큰 프로그램을 가지고 있고 두뇌가 초과 근무를 할 때 간단한 사례를 먼저 코딩하십시오. 처음에는 프로그램을 실행 한 다음 입력을 받아야합니다.
나중에 과제를 쉽게 업데이트하고 리팩토링하는 것이 쉽지만 코드는 작업을 수행하는 데 필요한 것보다 더 복잡하지 않아야합니다.

미래에는 새로운 우선 순위를 충족시키기 위해 코드를 리팩터링하는 것이 좋습니다. 당신은 그들 모두를 미리 예측할 수 없으므로 시도하지 마십시오.

다음 작업을위한 코드 – 오직. 코드는 간단하고 훌륭하므로 필요한 경우 리팩터링하기 쉽습니다. 프로그램이 작동하는지 확인하십시오. 반복.

최종 사용자 유스 케이스 시나리오에 대해 "고착"한 결과를 얻었으므로 API를 공개하고 모르는 사람들이 해당 API를 활용할 것으로 예상되는 경우 여기에서 고려해야 할 사항이 있습니다. 일단 API가 게시되면 나중에 첫 번째 릴리스가 얼마나 나쁜지 알게 되더라도 API를 계속 지원해야합니다. 미래의 모든 시간 동안.

표준 솔루션은 사용자가 필요로하는 것과 API 소비자가 무엇을하고 있는지 이해할 때까지 언제라도 API가 변경 될 수 있다는 규정을 게시하는 것입니다.

그 솔루션에서 나는 당신의 자신의 솔루션이라고 생각합니다. 한두 가지 일을하는 작은 일을 쓰십시오. 아마도 괜찮을 것입니다. 미래에 변경 될 사항이 무엇인지 스스로 이해하십시오.

디자인이 실제로는 발견의 여정이기 때문에 시작할 때 모든 것을 얻을 수 없으며, 어떤 경우에는 그 어느 것도 괜찮습니다. 가장 먼저 나온 것이 아니라 마지막으로 나온 것입니다.

API를 바로 설계 할 수 없으며 소비자에게 API를 제공 할 필요가 없습니다. 그 이유를 알 수 있습니다. 같은 토큰으로 소프트웨어를 작성할 수 없으며 모든 것을 버리고 새로운 접근법으로 다시 시작할 필요가 없습니다.

나는 당신이 우연히 덜 창의적이고 생산적이거나 바람직한 것으로 진화했다는 의미에서 문제가 있다고 생각하지 않습니다. 나는 당신이 실수로 자신의 상황에 잘못 적용하는 높은 기준을 가지고 있다고 생각합니다. 모든 사람이 생각하는 일반적인 실수입니다.

냉소적 인 노하우가되고 모든 것이 다 이루어지지 않는 한 경험은 결코 당신에게 불리하지 않습니다.

커질 때 마음에 두는 이미지가 몇 개 있습니다. 하나는 레고와 함께 노는 것입니다. 정리해 마음대로 분해합니다. 내가 만들기 시작하는 것이 내가 만드는 것이 아닐 수도 있습니다. 나는 내가 따라갈 때 내 마음에 떠오르는 가능성에 대해 서핑하고 유리하게 생각하며, 종종 영감의 순간에 그 자리에서 내 목표를 완전히 재현합니다 ... 그것이 창의성입니다.

다른 이미지는 실제 과학을하는 것을 묘사 한 비유입니다. 어두운 방에서 검은 고양이를 보지 못하고있을 것입니다. 당신이 그 고양이를 찾지 못하는 데 실패했다고 생각하는 경우에만 문제가되지 않습니다. 검은 고양이를 찾는 다른 방법은 없습니다. 그것은 그것들을 찾는 유일한 활동입니다. 다른 것은 이미 당신이 찾고있는 것을 가지고있는 형태입니다.

당신은 너무 많이 모른다; 당신은 충분히 모른다! 그리고 당신은 최근에 그것을 깨달았습니다.

"올바른"항목이 없기 때문에 디자인 선택을 "올바른"항목으로 생각하지 마십시오. 많은 "잘못"이 있지만 트레이드 오프도 있습니다 (실행 속도, 코딩 완료 시간) 과제, 확장 성 등). 잘 고안된 코드는 여전히 다양한 장점과 단점이 있습니다.

목표는 현재와 미래의 사용 및 유지 관리와 관련하여 이러한 장단점을 이해하는 것이 처음에 코드를 작성하는 것보다 크게 어렵지 않는 지점에 도달하는 것입니다.

따라서 깊은 생각을 피하지 말고, 이런 종류의 디자인에서 마스터가 되려면 생각뿐만 아니라 경험이 필요하다는 것을 기억하십시오. 특정 선택에 대해 확신이없는 시점에 도달 할 때까지 생각한 다음 원하는 것을 가장 잘 구현하고 시험해보고 진행 방법을 배우십시오.

연습 코딩. 연습 문제를 찾거나 온라인에서 찾은 후 최대한 빨리 올바르게 마무리하십시오. 속도를 높이면 유지 보수성 및 성능과 같은 고려 사항을 추가하십시오. 프로덕션 환경에 들어 가지 않는 코드를 새로 작성하면 코딩에 대한 두려움에서 벗어날 수 있습니다.

여가 시간에 10 년 전에했던 방식으로 걱정없이 재미있게 코딩하십시오.

팀 매니저가되어 직접 젊은 개발자 - 당신이 10 년 전에 같은 정신 상태에있다.

아뇨, 아직 충분하지 않습니다.

다음과 같은 간단한 규칙으로 지식을 풍부하게하십시오.

• 키스 : 작고 단순하게 유지하십시오.
• YAGNI : 당신은 그것을 필요로하지 않을 것입니다.
• 더 나쁜 것이 더 낫다 : 일부 더 나쁜 해결책은 실제로 유지 보수성 측면에서 더 낫다.

과도하게 엔지니어링하지 마십시오. 리팩토링 기술을 사용하여 변경을 준비하십시오. 그러나 코드에서 가능한 모든 변경 사항을 인코딩하지는 마십시오. 시간이 지남에 따라 클래스 또는 함수가 너무 커지면 변경하십시오. 나누고 정복하십시오. 인터페이스를 사용하고 더 많은 기능을 사용하십시오. 너무 많이 나누었다 고 생각되면 (즉, 어쨌든 더 좋아졌지만 읽기 어려워 짐) 마지막 변경 사항을 취소하십시오.

요약하자면, 코드는 유연하지만 충분하지는 않다. 대신, 자신을 융통성있게 만들고 리팩토링에 관한 책을 구입하십시오.

두가지:

1. 많이 아는 것만으로는 충분하지 않습니다. 구현할 가치가있는 것에 대한 의견이 있어야합니다. 나는 개인적으로 TDD를 나쁜 아키텍처를 가능하게하는 목발로 본다. 이 문제에 대해 나에게 반대되는 대중적인 의견이 많았을 때, 아마도 틀렸을 것입니다.하지만 JavaScript에서 TDD를 구현할지 여부는 디버그에 큰 문제가되지 않았습니다. 개발 커뮤니티에서 대중적인 의견이 나중에 몇 년 후에 결함으로 간주 된 것은 이번이 처음이 아닙니다. 오만한 찌르는 법을 배우십시오. 적어도 내부에. 당신은 틀렸을 수도 있지만, 그렇지 않을 수도있는 것들을 지나치게 생각하기보다는 당신을 위해 일하는 것에 최선을 다하고 있습니다.

2. 마이크로로 시작하는 것처럼 들립니다. 매크로로 시작하십시오. 먼저 앱이 수행해야하는 작업을 수행하는 데 필요한 도구입니다. 그 부분은 충분히 쉽게 와야합니다. 그런 다음 아키텍처 / 인터페이스 문제로 시작하십시오. 배관 연결 방법과 연결 방법은 실제로 옆으로 스 와이프하여 변덕스럽게 교체 할 수있는 모든 것의 칙칙한 부분이어야합니다. 작업 방법에 대한 세부 사항과 마찬가지로. 올바르게 포장하면 쉽게 교체 / 편집 할 수 있습니다.

하지만 공격하려고 할 때마다 깊은 생각을하게됩니다

아무 문제가 없다. 당신은 프로세스, 즉이 경우에는 사고 프로세스를 개선 할 때가되었다는 것을 알게되었습니다.

많은 사람들이 분석에서 길을 잃거나 다른 방식으로 길을 잃지 않으며 결코 눈치 채지 못합니다. 당신은 당신이 생각 과정을 추적 할 수 있도록 변경되었습니다.

이것에 대한 많은 해결책이 있으며, 위에서 본 가장 좋은 방법은 시간 제약을 설정하는 것입니다. 시작하기 전에 분석하고 생각하는 데 얼마나 시간을 할애할지 결정하십시오 (1 시간?). 타이머를 설정하십시오.

그런 다음 타이머가 꺼지면 코딩을 시작하십시오. 너무 오래 생각하는 것을 발견하면 즉시 결정하십시오. 그 시점에서 무엇을 결정하든 올바른 결정이 필요합니다. 나중에 언제든지 변경하고 개선 할 수 있습니다.

게다가, 우리의 환경은 항상 변화하고 있습니다. 새로운 요구 사항, 새로운 기술, 새로운 하드웨어, 언어 및 시스템 업데이트 등을 처리하기 위해 종종 코드를 업데이트해야합니다.

예,이 코딩 공포는 나에게도 발생합니다. 스택 오버플로에 치다. 작은 응용 분야를 위해 자세히 코딩하십시오. 그러나 아웃소싱 프로젝트 인 경우 시간 제약 때문에 많은 시간을 소비하지 않습니다. 그리고 새로운 무리의 사람들과 함께 일하면 이것을 극복 할 수 있다고 생각합니다.

당신은 무자비하지 않습니다

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

편집 : 이 기사의 요점은 개발 할 때 작은 세부 사항에주의를 기울이고 있지만 가능한 가장 효율적인 솔루션을 찾고 작업을 완료하기 위해 무자비한 태도로 단순하거나 복잡한 작업에 접근하는 것이 도움이된다는 것을 알았습니다.