빠른 코딩 방법 (품질 저하없이) [닫기]

나는 몇 년 동안 전문 코더였습니다. 내 코드에 대한 의견은 일반적으로 동일합니다. 테스트를 거친 훌륭한 코드를 작성하지만 더 빠를 수 있습니다 .

그래서 내가 어떻게, 더 빠른 코더 될 수 있나요 품질을 희생하지 않고? 이 질문을 위해 범위를 C #으로 제한하겠습니다. 주로 내가 코딩 (재미를 위해) 또는 Java는 중요한 여러 가지면에서 충분히 유사하기 때문에 범위를 C #으로 제한합니다.

내가 이미하고있는 것 :

• 작업을 수행 할 수있는 최소한의 솔루션 작성
• 많은 자동화 된 테스트 작성 (회귀 방지)
• 모든 종류의 것들에 대해 재사용 가능한 라이브러리 작성 및 사용
• 잘 작동하는 잘 알려진 기술을 사용하십시오 (예 : 최대 절전 모드).
• 적절한 곳에 디자인 패턴을 사용하십시오 (예 : 싱글 톤)

이것들은 모두 훌륭하지만 시간이 지남에 따라 속도가 증가하는 것처럼 느끼지 않습니다. 나는 어떻게 내가 (심지어 10 %) 내 생산성을 높이기 위해 뭔가를 할 수 있다면, 그건 내 경쟁사보다 10 % 더 빠른 있기 때문에주의를. (아무것도 없습니다.)

게다가 소규모 Flash 개발이든 엔터프라이즈 Java / C ++ 개발이든 상관없이 관리자로부터 지속적으로이 수수료를 받았습니다.

편집 : 금식의 의미와 속도가 느린 지에 대한 질문이 많이 있습니다. 좀 더 자세히 설명하겠습니다.

다양한 프로젝트와 다양한 기술 (Flash, ASP.NET, Java, C ++)을 통해 여러 회사의 중소 규모 팀 (5-50 명)에서 근무했습니다. 내 관리자 (직접 나에게 말한)의 관찰은 내가 "느리다"는 것입니다.

이것의 일부는 상당수의 동료들이 속도를 위해 품질을 희생했기 때문입니다. 그들은 버그가 많고, 읽기 어렵고, 유지하기가 어렵고, 자동화 된 테스트를 작성하기 어려운 코드를 작성했습니다. 내 코드는 일반적으로 잘 문서화되고 읽기 쉽고 테스트 가능합니다.

Oracle에서는 다른 팀 구성원보다 느리게 버그를 해결하려고합니다. 나는 그 효과에 대한 의견을 얻을 것이기 때문에 이것을 알고 있습니다. 이는 다른 (예, 상급 및 경험이 많은) 개발자가 거의 동일한 품질 (가독성, 유지 관리 성 및 테스트 가능성)로 저보다 짧은 시간 내에 작업을 수행 할 수 있음을 의미합니다.

왜? 내가 무엇을 놓치고 있습니까? 어떻게하면 더 나아질 수 있습니까?

최종 목표는 간단합니다. 오늘 40 시간 안에 제품 X를 만들 수 있고 내일 20, 30 또는 38 시간에 같은 제품을 만들 수 있도록 어떻게 든 개선 할 수 있다면 이것이 제가 알고 싶은 것입니다. 내가 거기 어떻게? 지속적으로 개선하기 위해 어떤 프로세스를 사용할 수 있습니까? 코드 재사용에 관한 것이라고 생각했지만 충분하지 않습니다.

나는 http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html 에서 찾을 수있는 Jeff Atwood의 접근 방식을 좋아 합니다.

기본적으로이 기사에서 그는 David Bayles와 Ted Orland의 Art & Fear 책의 구절을 참조합니다. 구절은 다음과 같습니다.

도예 교사는 개막 일에 수업을 두 그룹으로 나누겠다고 발표했습니다. 그는 스튜디오의 왼쪽에있는 모든 사람들은 자신들이 생산 한 작업의 양, 오른쪽에있는 모든 것들은 그 품질에 따라 등급이 매겨 질 것이라고 말했다. 그의 절차는 간단했습니다. 수업 마지막 날에 그는 욕실 저울을 가져 와서 "수량"그룹의 작업을 측정했습니다. 50 파운드의 냄비는 "A", 40 파운드는 "B"등입니다. 그러나 "품질"로 등급이 매겨진 사람들은 "A"를 얻기 위해 단지 하나의 냄비 만 생산해야했습니다. 글쎄, 등급이 매겨졌고 호기심이 생겼습니다. 최고 품질의 작품은 모두 양을 위해 등급이 매겨진 그룹에 의해 생산되었습니다. "수량"동안

본질적으로 손을 더 빠르고 더럽게하는 것은 "완벽한"방법에 대해 공부하고 이론을 세우는 것보다 기술을 향상시키는 것입니다. 저의 조언, 계속 연습하고, 기술을 유지하고, 디자인을 연구하십시오.

다른 사람이 언급하지 않은 한 가지 가능성은 당신이 잘하고 있고 관리자가 매우 좋지 않다는 것입니다. 생산성을 어떻게 측정합니까? 그들은 당신에게 구체적인 예를 줄 수 있습니까, 아니면 일반적인 인식입니까? 그들은 당신과 비교하여 다른 사람들의 일을 고치는 데 소비 한 시간을 고려 했습니까?

나는 많은 사람들이 일을 끝내는 것에 대한 신용을 얻는 것을 보았고, 나머지 팀원들은 남은 혼란을 해결했습니다.

사람들 이 중요 하다고 생각 하는 것의 대부분 은 중요하지 않습니다. 타이핑 속도는 중요하지 않습니다. 더 빠른 기계 나 도구는 중요하지 않습니다. 우리는 타이피스트 나 기계 운영자가 아닙니다. 우리는 생각하는 노동자입니다. 우리는 의사 결정자 입니다.

무엇 입니다 중요한 것은 지속적으로 의사 결정 과정을 개선하기 위해 피드백을 사용하고 있습니다. 다른 기술을 습득하는 것처럼이를 수행 할 수있는 유일한 방법은 경험, 의도적 인 연습 및 지속적인 피드백을 통한 것입니다.

• 부업 프로젝트에 참여하십시오.
• 오픈 소스 프로젝트를 수행하십시오.
• 나보다 나은 개발자와 협력하십시오. 페어 프로그램!
• 새로운 도구와 기술을 익히십시오. 작동하는 것을 유지하십시오.
• 의사 결정 장치를 훈련 시키도록 설계된 프로그래밍 연습을하십시오 *.
• 결함률 및 속도와 같은 객관적인 메트릭과 코드 품질 및 적합성과 같은 주관적인 메트릭을 기반으로 개선 사항을 모니터링합니다.

마지막으로, 품질이없는 속도는 쓸모없고 그 반대도 마찬가지입니다. 유용성을 극대화하려면 이러한 장력 사이의 균형을 찾으십시오.

* http://codekata.pragprog.com/

실제로, 당신이 희생하도록 요구되고 있다는 것을 확실히 가능성이 약간 더 속도, 품질.

일부 개발 환경 ¹ 에서는 "충분히 좋은 것"이 될 때 세련된 무언가를 생산하는 데 여분의 시간이 필요하지 않습니다.

^{1-나는 특히 "내부 툴 스미스"를 생각하고 있지만 아마도 다른 사람들도있을 것입니다.}

당신이 모든 좋은 일을하고있는 것처럼 들린다-중기 적으로는 당신을 더 빨리 만들 것이므로 실제로 느리다는 것은 분명하지 않다. 오직 당신 만이 그것을 알고 있습니다. (하지만 매우 현실적인 가능성입니다. PeopleWare는 동일한 작업에 대해 개발자간에 최대 10 배의 생산성 차이를 주장합니다).

그래서 나는 당신에게 몇 가지 제안을합니다 :

1. 시간은 상대적인 것이므로 문제는 실제 속도가 아니라 시간에 대한 인식입니다. 일주일이 걸린다는 것을 암시 할 수도 있지만, 다른 사람이 3 주를 소비 할 수있는 2 주를 소비하게됩니다.

2. 이 피드백을 자주 받고 있으므로 관리자와 동료들과 대화를 나눌 때 이야기를들을 시간이 많을 것입니다.

3. 차이점을 발견 할 수 있는지 확인하려면 "빠른 품질"개발자와 쌍 프로그래밍을 수행하십시오.

효과적으로, 그것은 경험으로 요약됩니다 . 당신이하는 일을 더 빨리하는 것은 자동차를 운전하는 것과 같습니다. 처음에는 다른 사람들이 빠른 (또는 음주) 드라이버 (또는 둘 다)이고 안전하게 집에 닿기를 원하기 때문에 (소프트웨어 용어로, 코드를 확인하고 싶습니다) 개발대로 작동하고 잘 작동합니다).

몇 년 또는 몇 달에 걸쳐 운전과 고속도로가 끊어지면 운전을 즐겁게하는 몇 가지 트릭을 배우게됩니다. 그것이 우리가 경험이라고 부르는 것입니다. 그 "트릭"(내가 특성이라고 부름)이 도움이됩니다.

필자의 경우 코딩 (@ 가정)을 사용하고 일부 사용을 학습하여 디자인 패턴의 실제 사용을 배웠습니다. 따라서 디자인 패턴이 필요한 문제가 발생하면 과거 경험을 사용하여 어떤 것이 효과가 있었으며 왜 내 상황에 효과가 있는지 / 작동하지 않는지 알 수 있습니다.

요약하자면:

• 경험 은 자신감과 소프트웨어를 향상시키는 특성을 만듭니다.

추신 : 경험은 또한 다른 사람들로부터 배우는 데서 나옵니다. 예를 들어 SO, Pair Programming, Peer Review 등의 도움을받을 수 있습니다. 실수를 되돌아보고 배울 수 없거나 (누군가 노력에 결코 도전하지 않는 경우) 경험을 할 수 없습니다.

문제는 장기 총 비용을 볼 때 비용이 덜 든다는 것입니다.

즉, 테스트 케이스 및 문서를 포함하여 이러한 고품질 의 버그 수정이 더 빠른 동료가 수행 한 버그 수정을 유지해야하는 비용 보다 중요 합니까?

그렇다면, 상사에게이 사실을 알리도록해야합니다. 평가를 측정하지 않고 평가를 확인하는 데 필요한 데이터가 있으면 논쟁하기 어려울 수 있습니다.

그렇지 않다면 왜 그런지 고려해야 합니다.

• 너무 경험이 없습니까?
• 요청하지 않은 것들을해야 할 일에 많은 시간을 소비합니까?
• 수정이 완료되는시기를 결정하기가 어려우십니까?
• 생각보다 품질이 낮은 코드입니까?
• 코드 개발에 다른 방식으로 접근해야합니까? 지금하는 방식을 빠르게 달성하는 데 너무 오래 걸리기 때문입니까?
• 이 사이트와 같은 것들에 너무 많은 시간을 보냈습니까?

생각하고 찾은 내용으로 질문을 편집하십시오.

당신이 진정으로 느린 지 아닌지에 대해 사람들이 한 모든 의문은 바보입니다. 품질 저하없이 더 빠른 프로그래머가되는 것은 이미 얼마나 느리거나 빠른지에 상관없이 항상 좋은 목표입니다. 이것은 프로그래머로서의 제 1 목표이며 결코 끝나지 않을 것입니다. 나는 항상 품질을 희생하지 않고 더 빨리 얻으려고 노력하고 있습니다. 다음은 몇 가지 실험 아이디어와 함께 도움이되는 순서로 지금까지 나를 위해 일한 것입니다.

1) 학습을 중단하지 마십시오 : 일반적으로 컴퓨터 프로그래밍 및 사용에 관한 모든 것을 배우십시오. 약한 지역을 찾아서 배우십시오. 귀하의 작업 및 C #과 완전히 관련이없는 것처럼 보이지만, 귀하가 그것을 찾고 있다면, 귀하가하는 일에 적용하는 방법을 종종 찾을 것이라고 보장합니다. 학습은 또한 경험에 관한 것이므로 내용을 읽지 말고 시험 해보고 기술을 확장하십시오. Windows 사용에 익숙하다면 Unix를 사용해 보거나 그 반대로하십시오. 일반적으로 IDE의 명령 행 도구 및 텍스트 편집기를 사용하거나 그 반대로 사용하려는 경우. 이전에 들어 보지 못했거나 잘 모르는 도구 나 기술에 대해 들어 본다면, 계속해서 유혹하지 마십시오. 찾아 봐! 상자 밖에서 생각하고 다른 사람들이 실천할 수없는 실험적인 신기술을 배우는 것을 두려워하지 마십시오.

2) 프로젝트 나누기 : 프로젝트를 미니 프로젝트로 나누십시오. 매일 또는 최대 며칠에 한 번씩 새 릴리스를 수행하십시오. "내가 릴리스 할 수있는 최소 기능은 얼마입니까? 여전히 사용자에게 유용한 것을 릴리스하십시오." 이것은 당신이 그것을 통해 배울 수있는 기술입니다. 관리자에게이를 허용하도록 설득해야 할 수도 있지만 일반적으로 결과에 매우 만족합니다. 이렇게하면 기능에 필수적이라고 생각한 것이 실제로는 나중에 개발 될 수있는 추가 기능이라는 것을 알 수 있습니다. 이를 통해 관리자와 관리자는 작업중인 기능과 관련된 모든 기능 대신 가장 중요한 기능 만 우선 순위로 지정할 수 있습니다. 이를 통해 마음을 명확하고 집중적으로 유지함으로써 더 빨리 생각할 수 있습니다. 당신은 합법적으로 더 빨리 프로그램 할 것입니다. 관리자 또는 최소한 관리자의 관리자도 릴리스가 더 많아지기 때문에 현재보다 훨씬 빠르게 프로그래밍하고 있다고 인식 할 수 있습니다. 이것의 또 다른 큰 이점은 릴리스가 완료되는 데 걸리는 시간을 추정하는 데 훨씬 더 좋으며 관리자가이를 좋아한다는 것입니다. 이미 많은 자동 테스트를 수행하고 있으므로 안정적인 릴리스를 자주 수행하는 데 아무런 문제가 없습니다. 자동화 된 빌드 시스템을 강화해야 할 수도 있습니다. Martin Fowler 시리즈의 Continuous Delivery 책을 읽는 것이 좋습니다. 읽기 어렵고 매우 반복적이지만 여전히 매우 유용하기 때문입니다. 또한 관리자는 릴리스가 더 많아지기 때문에 실제보다 훨씬 빠르게 프로그래밍하고 있다고 인식 할 수 있습니다. 이것의 또 다른 큰 이점은 릴리스가 완료되는 데 걸리는 시간을 추정하는 데 훨씬 더 좋으며 관리자가이를 좋아한다는 것입니다. 이미 많은 자동 테스트를 수행하고 있으므로 안정적인 릴리스를 자주 수행하는 데 아무런 문제가 없습니다. 자동화 된 빌드 시스템을 강화해야 할 수도 있습니다. Martin Fowler 시리즈의 Continuous Delivery 책을 읽는 것이 좋습니다. 읽기 어렵고 매우 반복적이지만 여전히 매우 유용하기 때문입니다. 또한 관리자는 릴리스가 더 많아지기 때문에 실제보다 훨씬 빠르게 프로그래밍하고 있다고 인식 할 수 있습니다. 이것의 또 다른 큰 이점은 릴리스가 완료되는 데 걸리는 시간을 추정하는 데 훨씬 더 좋으며 관리자가이를 좋아한다는 것입니다. 이미 많은 자동 테스트를 수행하고 있으므로 안정적인 릴리스를 자주 수행하는 데 아무런 문제가 없습니다. 자동화 된 빌드 시스템을 강화해야 할 수도 있습니다. Martin Fowler 시리즈의 Continuous Delivery 책을 읽는 것이 좋습니다. 읽기 어렵고 매우 반복적이지만 여전히 매우 유용하기 때문입니다. 그리고 당신의 매니저는 이것을 당신을 사랑할 것입니다. 이미 많은 자동 테스트를 수행하고 있으므로 안정적인 릴리스를 자주 수행하는 데 아무런 문제가 없습니다. 자동화 된 빌드 시스템을 강화해야 할 수도 있습니다. Martin Fowler 시리즈의 Continuous Delivery 책을 읽는 것이 좋습니다. 읽기 어렵고 매우 반복적이지만 여전히 매우 유용하기 때문입니다. 그리고 당신의 매니저는 이것을 당신을 사랑할 것입니다. 이미 많은 자동 테스트를 수행하고 있으므로 안정적인 릴리스를 자주 수행하는 데 아무런 문제가 없습니다. 자동화 된 빌드 시스템을 강화해야 할 수도 있습니다. Martin Fowler 시리즈의 Continuous Delivery 책을 읽는 것이 좋습니다. 읽기 어렵고 매우 반복적이지만 여전히 매우 유용하기 때문입니다.

3) 포모 도로 기술을 사용하고 자신에게 효과가없는 것을 수정 / 변경하십시오. 이 목록에서이 번호를 2와 결합하면 생산성이 크게 향상됩니다.

4) Vim을 배우십시오. ViEmu를 통해 Visual Studio 내에서 또는 플러그인을 통해 Eclipse 내에서 또는 Emacs 내에서 이러한 명령을 사용하더라도 생산성을 얻을 수 있습니다. Vim을 배우는 가장 좋은 방법은 Vim을 사용하기 시작하고 마스터 할 때까지 사용하지 않도록 설정하는 것입니다. 처음에는 고통 스럽지만, 결코 뒤로 물러서기를 원치 않으며, 그것없이 일해야 할 때 울 수도 있습니다. 어떤 사람들은 이것이 속도를 크게 증가시키지 않을 것이라고 말합니다. 그러나 코드를 읽고 수정하는 것이 우리가하는 일 일 때 특히 빠릅니다. 때때로이 작업으로 많은 시간을 절약 할 수 있습니다.

5) 마지막 아이디어는 그것이 좋은 아이디어인지 확실하지 않기 때문에 반드시 권장되는 것은 아니며 실제로 생산성을 떨어 뜨릴 수 있지만 어쨌든 그것을 통해 진행할 것입니다. 더 많은 승인 테스트와 더 적은 단위 테스트를 시도하거나 최소한 승인 테스트를 수행해야합니다. SpecFlow로 성공했지만 더 좋은 것이 있다고 생각합니다. 사양을 작성하는 것조차 매우 기술적 인 것이 될 수 있으므로 관리자 / 고객이 먼저 초안 버전을 작성하여 크게 변경하거나 전체 내용을 직접 작성하여 읽고 확인하도록 할 수 있습니다. 이것은이 목록에서 2 번으로 도움이 될 것입니다. 또한 승인 테스트는 단위 테스트보다 더 실용적이며 적은 코드가 필요합니다. 이것은 그들이 다른 것을 대체하는 다른 도구를 대체한다고 말하는 것이 아닙니다.

6) 이것은 훨씬 실험적이고 논란의 여지가 있습니다. 나는 실제로 이것을 직접하지 않았으므로 정확하게 추천 할 수 없습니다. JetBrains에서 메타 프로그래밍 시스템을 배우고 사용하십시오. 관리자 / 고객이 원하는 소프트웨어를 직접 만드는 데 사용하는 도구를 만드는 데 사용하십시오. 이를 사용하여 관리자 / 고객이 매우 간단하고 복잡한 방식으로 동작을 지정하는 데 사용하는 도구를 만들 수있는 경우 단위 및 승인 테스트 수행을 중지 할 수도 있습니다. 아이디어는 프로그래머를 제거하는 것이 아닙니다. 프로그래머는 고객 (관리자가 아닌 사람)이 원하는 기능을 쉽게 만들 수 없을 때마다 고객 / 관리자가 사용하는 이러한 도구에 새로운 기능을 추가해야합니다. MPS 또는 이와 유사한 다른 도구가 미래의 방법이라고 생각합니다.

뇌를 더 많이 사용하고 테스트를 줄이십시오. 솔직히 말해서 테스트는 그 자리에 있지만 비용이 많이 듭니다.

또한 유닉스 프로그래밍의 기술을 읽으십시오 (무료 온라인, 가격 가치가있는 책)

마지막으로, 당신은 올바른 장소에 없을 수 있습니다. 사각 작업 등의 둥근 못

궁극적으로 그것은 학교와 같습니다 : "선생님이 원하는 것을 산출하십시오"는 "경영진이 요구하고 지불 한 것을 산출합니다".

게으르고 완성 된 프로젝트를 수행하고 시간당 "최종"코드 라인 수를 얻는다면 프로그래머가 상상했던 것보다 훨씬 느리게 코딩하는 것을 알 수 있습니다.

우리는 하루에 몇 줄의 코드 만 이야기하고 있습니다. 남은 시간은 디버깅, 재 작성 및 일반적인 프로그래머 작업에 사용됩니다.

당신이 입력하는 동안 오류가 발생하면 빌드 시간에 오류를 잡았을 때 시간을 10 배 절약 할 수 있습니다 .QA 중에 잡는 것보다 10 배 빠릅니다 .10 배 더 좋습니다. 석방 후 잡는 것보다

어떻게 속도를 높이나요? 오류를 줄이고 코드와의 "미래 상호 작용"을 개선하는 것이 어떤 형식의 타이핑 속도에도 집중하지 않기 때문에 시간을 훨씬 더 투자해야합니다.

읽기 쉽고 명확한 코드가 중요합니다. 코드를 한 번 작성하지만 수십 번 읽습니다. 가독성을 위해 글을 쓰면 많은 시간을 절약 할 수 있습니다. 다시 돌아가서 코드를 읽고 잠깐 동안 생각해야한다면 잘못하고 있습니다.

페어 프로그래밍은 QA 시간을 단축시킬 수 있으며, 한 프로그래머가 하루에 몇 줄만 생산한다고 생각한다면, 두 개가 하나와 동일한 속도로 코딩 할 수 있지만 오류는 줄어든다면 앞으로 나아갈 수 있습니다.

방어 적 코딩 (예 : 매개 변수 확인)으로 문제를 줄일 수 있습니다 ... 팀에 대한 분석가 / 건축가가 정말 좋으면 좋은 시작 설계로 시간을 절약 할 수 있습니다.

그렇지 않으면 디자인 기술을 계속 향상시킵니다. 경험이 많을수록 작동하지 않는 패턴을 더 잘 인식하고 피할 수 있으며 시간을 미리 파악할 수 있습니다.

작업하면서 자신에 대한 자세한 감사를 고려한 적이 있습니까? 시간을 어떻게 보내는 지 펜이나 종이로 추적하거나 Rescue Time 과 같은 것을 사용 하여 자신을 추적하십시오.

정확히 어떻게 당신이 당신의 시간을 보내는 지 더 잘 알고 있다면, 당신은 거기에 당신의 노력을 개선하고 집중해야하는 것에 대한 더 나은 아이디어를 얻을 수 있습니다.

이상적으로는 일부 동료에게도이 작업을 수행하고 결과를 비교하며 서로 아이디어를 얻도록 요구할 수 있습니다. 당신은 아마 그들도 혜택을 누릴 수있는 강점을 가지고 있습니다.

자동화 된 프로세스의 일부에 너무 많은 시간을 소비하고 있거나 하루 중 특정 시간 동안 많은 산만 함을 느끼고 하루 중 다른 시간이 조용하다는 것을 알게되면 작업을 계획 할 수 있습니다 그 등

또는 테스트 시간이 생각보다 시간이 오래 걸리고 더 빠르다는 인식을 다시 생각해야 할 수도 있습니다.

다른 것이 없다면 벤치 마크를 제공 할 수 있습니다.

당신의 목록에서 당신은 잘하고 있습니다.

동료가 CRAP 번호가 더 높은 코드를 작성하는 경우 더 빨리 진행됩니다. CRAP는 사이 클릭 복잡성과 테스트 범위를 결합한 만화 이름의 메트릭입니다.

더 많은 CRAP 코드를 작성하지 마십시오. ;)

당신에게 제안하는 유일한 변경 사항은 다음과 같은 경우가 아니라면 라이브러리를 사용하는 것입니다.

1. 회사에서 도서관을 판매합니다
2. 반복 코드를 라이브러리로 리팩토링했습니다.

당신은 읽고 일하고 있으며 훌륭합니다. 그러나 당신은 procuedural 또는 OO 코드에 대해 생각할 수 있습니다. 당신은 함수형 프로그래밍 (Hassell?)과 Prolog에 노출되어 있습니까?

OO 프로그래밍 기술을 향상시키기 위해 Smalltalk / Squeak?

그리고 마지막으로 이론. 최소한 그래프 이론에 대한 기초 지식이 있습니까? (일부 프로그램은 트리, DAG 또는 일반 그래프와 함께 작동합니다. 네트워크는 그래프입니다)

밥 삼촌 을 인용하겠습니다 .

빨리가는 유일한 길은 잘가는 것입니다.

속도를 위해 품질을 교환하려는 유혹에 빠질 때마다 속도가 느려집니다. 매번

- "Vehement Mediocrity", Robert C. Martin

내가 아는 한 :

1. 좋은
2. 빠른
3. 싼

관리자는 2를 선택할 수 있습니다.

속도에 대한 의견은 걱정하지 마십시오. 동료 코더로서 나는 잘 짜여진 코드보다 잘 짜여진 코드를 유지하려고합니다.

내가 생각할 수있는 주요 사항은 다음과 같습니다.

• 타이핑 속도를 높이십시오.
• 생산성 향상을 제공하는 도구를 사용하십시오. 예를 들어 ReSharper입니다.
• 더 빠른 기계 또는 도구. 더 많은 RAM 또는 솔리드 스테이트 드라이브처럼.

코딩 기술 영역에서도 할 수있는 일이 있다고 확신하지만, 그런 일이 끝났다고 들립니다. 위에 나열된 사항은 일반적으로 개발자가 간과합니다.

스피드 타이핑 코스를 수강 할 수 있습니다. 더 빠른 타이핑이 문제인지는 모르겠지만 타이핑 속도가 느리면 "코딩이 너무 느리게"발생할 수 있습니다.

코드 생성기는 어떻습니까? 때로는 코드가 반복적으로 나타납니다. 리팩토링은 일부를 제거 할 수 있지만 동일한 리팩토링 된 함수를 반복적으로 호출 할 수도 있습니다. 작업하는 데이터와 코드에 따라 코드 생성기 (Excel, Perl, Java 등으로 작성 됨) 는 많은 시간을 절약 할 수 있습니다 . UI 개발을 위해 코드 생성 도구를 사용하는 것은 보통 쉬운 일이 아닙니다.

마지막으로 측정 항목이 잘못되었을 수 있습니다. 다른 모든 것을 고려할 때 가능한 빠른 속도로 코딩하고 타임 라인 이 너무 짧아서 느린 코더로 보이는 것을 고려 했습니까?

귀하의 질문에 대한 편집 내용을 바탕으로 일부 동료의 경로를 잡고 가장 빠른 솔루션을 함께 해킹 할 수있는 것처럼 보입니다. 문서와 QA는 저주를 받았습니다!

또는 ... 특정 영역에서 더 많은 경험과 실습을 통해 코드베이스와 API를 알면 수면 중에 솔루션을 코딩 할 수 있습니다. 이 작업을 수행 할 수 있지만 시간이 더 필요합니다. 당신이 더 많은 선배와 경험이 많은 것으로 알려져있다보다 빠르게있는 다른 개발자가 다음 할 수있는 단 한 가지가 있다면 - 당신이 해야 될 고위과 경험을!

OP의 "속도에 대한 품질 저하"관점에 반대합니다.

전문 코더 (프로그래머)는 다음 세 가지 목표를 충족해야합니다.
1) 코드가 의도 한대로 실행되어야합니다.
2) 배송이 제 시간에 이루어져야합니다.
3) 품질, 문서 등이 양호 해야합니다 .
4) 기타 등

OP가 제 시간에 끝나지 않았기 때문에 OP가 느리다고 비난했습니다.

이것은 돌아 다니기 어려운 캐치 22입니다. 여전히 경험이 부족하고 많은 측면에서 이미 많은 양의 지식 이 대부분의 것보다 빠르지 만, 측정 하는 것이 더 어렵다는 것이 캐치입니다 .

이 시점에서 개인적으로 최선을 다하는 것은 자신을 측정하는 것입니다. 업무 방식에 대한 피드백을 제공하십시오. 업무 습관을 조금만 변경하면 생산성을 높일 수 있습니다.

메일이 중단 때문에 생각했던 것보다 훨씬 더 많이 먹는 것을 발견했습니다. 이제 하루에 두 번만 메일에 응답하고 며칠 동안 거의 1 시간의 생산성을 얻었습니다. pomodoro 와 같은 방법을 사용해보십시오 . 측정 수단으로 사용했습니다. 정기적으로 (15 분) 그 당시 내가하고 있던 일을 기록해 두었습니다. 이를 통해 하루의 구조와 효율성을 극대화 할 수있는 방법을 알 수있었습니다.

빠른 코딩에 대한 Squeak의 장점은 "OOP 기술을 호소하는 것"을 넘어선 것입니다. JUNIT가 Java에 대한 SUNIT의 포트, "OOP"라는 용어가 스몰 토크 등을 설명하기 위해 고안된 것은 말할 것도없고, 최신 GUI와 IDE가 스몰 토크에서 발명 된 이유가 있습니다.

달성하고자하는 모든 것에 가장 적합한 언어와 환경을 항상 사용해야하지만, 일반적인 프로토 타이핑을 위해서는 최소한 하이퍼 카드를 제외하고는 무엇이든 찍어 내야합니다. Squeak에 내장 된 하이퍼 카드와 유사한 기능이 있다는 점을 감안하면 실제로 더 빠릅니다.