"빠른"프로그래머가되는 방법?

마지막 직업 평가에는 적시성이라는 한 가지 약점이있었습니다. 나는 이미 이것을 개선하기 위해 할 수있는 일을 알고 있지만 내가 찾고있는 것은 더 있습니다.

품질을 희생하지 않고 출력 속도를 높이기 위해 무엇을해야하는지에 대한 조언이나 조언이 있습니까?

타임 라인을 어떻게 추정하고 고수합니까? 단기간에 더 많은 일을하려면 어떻게해야합니까?

모든 의견에 감사드립니다.

컴퓨터를 꺼라. 연필과 종이를 잡아라. 디자인을 스케치하십시오. 동료들과 함께 검토하십시오. 그런 다음 코드를 작성하십시오.

몇 가지 아이디어 ...

• 금도금을 피하십시오-요구 사항 만 요구하십시오 (요구 사항 측면에서)
• 비즈니스 요구 사항을 이해하고 처음부터 올바르게 수행
• 환경과 도구를 철저히 이해
• 환상적인 타이피스트가되어 마우스 대신 키보드 단축키를 사용하십시오.
• 반복적 인 접근 방식을 취하고 올바른 검사를 받기 위해 위생 검사를 작성하십시오.
• 바퀴를 재발 명하지 말고 과거 작업과 다른 사람들의 작업 재사용을 고려하십시오.
• 방해 요소를 제거하고, 이메일을 계속 확인하고, 외부를보고, 동료와 대화하는 등의 작업을하지 마십시오.
• 과로하지 말고 휴식을 취해야 할 때를 인식하십시오

"빠른"프로그래머가 되려는 당신의 소망은 칭찬 할 만합니다. 그러나 정시에 납품하지 않는다고해서 속도가 느리다는 것은 아닙니다. 프로젝트가 제대로 계획되지 않았 음을 의미합니다. "빠른"프로그래머가되는 것은 도움이되지 않습니다. 그것은 단지 마감일을 더 빨리 지나친다는 것을 의미합니다.

귀하 (및 귀하의 팀)는 다음 실수 중 하나 (또는 ​​모두)를 수행합니다.

• 수행해야 할 작업을 과소 평가 ;
• 계획하는 동안 큰 요구 사항 또는 아키텍처 부분이 누락되었습니다 .
• 업무 견적과 캘린더 견적을 혼동 하고 회의 / 전화 / 기타 오버 헤드와 같은 것을 설명하지 않습니다.

위의 세 가지 중 하나를 해결할 수있는 여러 가지 방법이 있습니다. 그러나 당신이 그들 중 하나를 개선하기 전에, 일이 왜 진행되고 있는지 알아야합니다. 마지막 2 ~ 3 개의 프로젝트 추정값에 대한 사후 분석 을 수행하고 실제 소요 시간을 계산하고 추가 시간이 어디로 갔는지 파악하십시오.

다시 작성하겠습니다. 코드 작성 속도가 느려도 해당 사실을 고려하여 올바르게 계획 한 경우 마감일이 누락되지 않습니다 .

실제로 편집자를 배우십시오. IDE를 사용하는 경우 IDE가 제공하는 모든 기능을 사용하고 있는지 확인하십시오. 선택한 편집자를위한 키보드 단축키를 배우려면 치트 시트를 받으십시오. 쉘을 사용하는 경우 일반적으로 사용되는 디렉토리에 대한 바로 가기 설정

"품질을 떨어 뜨리지 않고 출력 속도를 높이기 위해 무엇을해야하는지에 대한 조언이나 조언이 있습니까?"

많은 사람들이 (a) 단순하고 (b) 신뢰할 수 있고 (c) 정확한 것을 희생하여 "궁극적 인"품질을 추구합니다.

개발 속도를 높이는 가장 중요한 방법은 작업을 단순화 하여 가능한 한 간단하게하는 것입니다.

정시 배송에 문제가있는 대부분의 사람들은 길을 너무 많이 전달하고 있습니다. 그리고 주어진 이유는 종종 바보입니다. 종종 실제 요구 사항이 아니라 인식 된 요구 사항 일뿐입니다.

많은 사람들이 고객이 "무엇을 기대하는지"말해 준다고 들었습니다. 이것은 잘못된 정책입니다.

가장 간단한 것을 만드십시오. 고객에게 더 많은 것이 필요하면 더 많이 구축하십시오. 그러나 가장 간단한 것을 먼저 빌드하십시오.

코드를 완벽하게 연마하지 말고 작동 시키십시오. 그것이 비즈니스가 기대하는 것입니다.

그러나 종종 속도를 높이면 품질이 저하됩니다.

재사용-나는 이전 프로젝트에서 영리한 비트를 제거하려고 노력하므로 향후 벤처에서 다시 사용할 수 있습니다. "언젠가 다시 사용할 수 있을까요?"

간단하게 유지하십시오.

TDD를 사용하는 경우 " 빨간색, 녹색, 리팩터링 "을 따라야합니다 .

1. 실패한 테스트를 작성하십시오 ( 빨간색 ). (기능에 따라 아직 코드에없는 기능이 있습니다.)
2. 끔찍한 코딩 범죄를 저지르면 테스트가 통과됩니다 ( 녹색 ). 필요한 경우 하드 코드.
3. Refactor , 아마도 테스트를 잠시 중단하지만 전반적인 디자인 개선.

모든 언어 / 라이브러리 설명서를 컴퓨터에 로컬로 다운로드 한 다음 네트워크 케이블을 분리하거나 Wi-Fi를 끄십시오 .

여기서 웃기려고하지 않습니다. 이것은 정말 나를 도와줍니다!

스택 오버플로를 너무 오랫동안 읽었을 때 주목하십시오. "컴파일"변명은 오래 동안 만 작동합니다. :)

작업을 너무 자주 전환하지 마십시오. Mylyn 과 같은 도구 를 사용하여 작업을 관리 하더라도 산만 함과 작업 전환으로 인해 하루가 걸릴 수 있습니다.

세분성 (예 : 30 분)을 파악하고 해당 작업과 관련된 작업 만 수행하십시오. 다른 것 (새로운 버그 보고서, 다른 문제에 관한 이메일, 관련없는 절차 문제)은 적어도 "다음 체크 포인트"까지 지연됩니다. 당신이 빨려 들어 가지 않도록 이메일 알림 팝업을 비활성화하십시오.

팀에 친구가있는 경우, 실제로 일이 녹아 내고 즉각적인주의가 필요한지 알려주는 친구에게 특히 효과적입니다.

가장 좋은 방법은 처음입니다. 그것이 시작하기 전에 잠시 멈추고 그것에 대해 생각해야한다는 것을 의미한다면, 그렇게하십시오. 시간의 90 %를 작동합니다.

가능한 빨리 터치 식으로 배우십시오 .

나는 내일한다 .

완료 하기도 매우 도움이됩니다.

어쨌든 짧은 관심을 가지고 있기 때문에이 책들은 내 초점을 유지하는 데 도움이됩니다.

연습과 노력.

시간과 노력을 들여야합니다. 사용하는 도구, 속도 및 창의력에 따라 더 편안하고 자신감을 가지게됩니다.

특정 기술을 향상 시키려면 연습을 디자인하는 데 도움이 될 수 있습니다. 속도가 디자인 단계에있는 경우 온라인에서 작동 할 디자인 문제를 찾으십시오. 같은 운동을 다시 실행하면 더 빨리 연습하고 연습 할 수 있습니다. 나는 개인적으로 순전히 프로그래밍 속도를 연습하는 TopCoder의 알고리즘 연습 을 좋아 합니다. 그들은 디자인 과제도 있지만 시도하지 않았습니다.

The Zone에 대해 배우고, 자신을 받아들이는 방법을 배우고, 없을 때 인식하는 방법을 배우십시오.

일단 "영역 내"에 있으면 매우 생산성이 높고 코드가 나옵니다. 종종 하루나 이틀 또는 3 일 동안 코딩을 수행 할 수 있습니다. 그러나 나는 종종 그 장소에 가기가 어렵다는 것을 알았습니다. 나는 다른 것들에 의해 정신이 산만 해져 있습니다 (예 : 스택 오버플로).

어떤 영역 에서 할 일 을 할 수 있는지를 인용 하십시오.

IDE와 프레임 워크를 잘 알고 있습니다. 모든 작은 일에 대해 Google을 사용하려면 시간이 걸립니다.

이맥스

개발을 시작하기 전에 :

• 사서함에서 로그 아웃
• 모든 IM 클라이언트 끄기
• 정중하게 동료에게 집중할 시간을달라고 요청하십시오
• 물론 인터넷 서핑을 중단하십시오

당신이 중단 될 때마다, 당신의 생각으로 다시 돌아 오는 데 시간이 걸리므로 속도가 느려집니다. 나는 각 중단마다 인간의 마음이 중단 이전의 사고 과정으로 되돌아가는 데 5-10 분이 걸린다는 수치를 들었습니다. 중단 당 많은 시간이 걸리므로 하루 종일 낭비하는 데 많은 시간이 걸리지 않습니다.

우리 회사의 직원들은 실제로 일정에서 시간을 차단 한 다음 매일 두 시간 동안 빈 회의실로 옮겼습니다.

개발 IDE를 안팎으로 배우십시오. 단축키를 배우십시오. 마우스 사용을 줄이십시오. 나는 이것이 나를 위해 많은 시간을 절약한다는 것을 알았습니다.

동료보다 느리거나 추정치가 더 낙관적입니까?

소프트웨어를 더 빨리 생산하기 위해 최선의 방법은 런타임 API를 최대한 배우는 것입니다. LINQ 확장이 수행 할 때 목록 논리를 입력하지 마십시오. 바인딩이 작동 할 때 이벤트 리스너를 많이 만들지 마십시오.

추정에 이르기까지, 그것은 경험과 함께 제공됩니다. 더 나은 견적을 찾는 데 도움이되도록 견적 소프트웨어를 사용할 수 있습니다.

개인적으로 저는 주니어 레벨 개발자와 함께 초기 추정치에 관계없이 2를 곱한 다음 두 배로 늘 렸습니다. 이것은 모든 학습, 회의, 낭비 된 시간 등을 설명 할 것입니다. 상급 레벨의 개발자는 추정치보다 2 배 정도 일하는 경향이 있습니다.

종종, 당신의 추정이 틀렸다면 질문은 아닙니다. 당신의 견적이 모든 올바른 것들을 설명했습니까? 코딩 노력 또는 일정 시간 측면에서 예상치와 타임 라인을 제공합니까? 하루 중 항상, 그리고 실제, 생산적인 코딩 대 회의, 학습, 디버깅 등의 양을 생각하십시오.

암시 될 수있는 두 가지 사항이 있지만 여기에 나와있는 답변 중 아직 보지 못한 생산성 향상은 다음과 같습니다.

• 일종의 빌드 및 배포 스크립트를 사용하십시오. 응용 프로그램 서버를 컴파일, 배포, 다시 시작하면 시간이나 집중력이 떨어지지 않으며 한 번 클릭하면됩니다.

• 일종의 버전 관리가 필요합니다. 변경 사항을 롤백하지 않고 코드를 작성하는 것은 계란을 밟는 것과 같습니다

몇 가지 아이디어가 떠 오릅니다.

1. 추정치에 대한 다른 의견 얻기- "이 시간대에 이런 종류의 기능을 수행 할 수 있다고 생각하십니까?"와 같은 질문을 할 수있는 다른 개발자가 있습니까? 다른 사람의 의견은 누군가가 견적을 내릴 때 놓친 많은 것들을 주목할 수 있기 때문에 어떤 경우에는 정확성에 도움이 될 수 있습니다.

2. 견적 기술 연마-견적에서 벗어난 이유와 왜 벗어난 이유를 추적합니다. 다른 작업 항목으로 인해 마감일이 지났습니까? 무언가가 얼마나 복잡한 지 일관되게 과소 평가하고 있습니까? 실용적이지 않을 때 전체 타임 라인을 제공합니까? 예를 들어, 프로토 타입을 만드는 데 몇 주가 걸리고 다른 작업을 다시 평가해야하는 것은 모호합니다. 이 작업을 수행하면 해당 기술을 구축하는 데 가장 도움이 될 수 있으므로 x 시간이 걸릴 것이라고 말하면 반복해서 반복했기 때문에 자신감을 가질 수 있습니다. 이것을 나타내는 다른 방법은 단지 연습, 연습, 연습입니다.

아마도 당신이 이미 이것들을 고려 했음에도 불구하고, 나는이 아이디어를 고려하지 않았을지도 모르는 다른 사람들을 위해 이것을 언급하는 것이 가치 있다고 생각했습니다.

1. 내부와 외부의 기술을 알고 있습니다.
2. 중지! 생각한다! 가다!
3. 발생할 수있는 모든 것을 설계하지만 실제로 요청 된 사항 만 구현하십시오.
4. 키스-간단한 바보 유지
5. 너무 복잡해지면 아마도 잘 생각되지 않습니다. (2와 4로 돌아가십시오)
6. 5에 갇히지 마십시오. 처음부터 시작하여 지불하는 경우가 많습니다 (2 및 4로 돌아 가기).
7. 1로 돌아갑니다.

여기서 핵심 단어는 "적시"라고 생각합니다. 그들은 당신이 너무 느리다고 말하지 않았고, 당신이 적시에 아니었다 고 말하였습니다.

프로젝트 관리에서 관리자는 작업 항목이 언제 정확하게 완료 될지 추정 할 수 있어야합니다. 귀하의 노력이 적시에 이루어지지 않은 주된 이유는 일정에 따라 배송되지 않고 예정보다 훨씬 늦게 배송 된 품목이 많기 때문입니다.

적시성을 향상시키기 위해 기술, 경험 및 도메인에 따라 특정 작업 항목을 완료하는 데 걸리는 시간을 이해하는 데 더 많은 시간을 할애 할 수 있습니다. 이를 통해 프로젝트 관리자에게 더 나은 견적을 제공 할 수 있습니다. 여기서 핵심은 "더 나은"것입니다. 퍼지 팩터로 모든 것을 채우면 더 자주 제 시간에 제공 할 수 있지만 실제로 노력하고 싶은 것은보다 정확한 추정치입니다.

이것이 실제로 문제인지 확인하기 위해 관리자와 논의 할 것입니다. 그렇지 않으면, 예전보다 절반으로 유망한 것을 두 배나 빠르게 프로그래밍 할 수 있고, 추정치에는 여전히 같은 오류 요소가 있기 때문에 적시성에 대한 비판을받을 수 있습니다.

안정을 유지하십시오.

약간의 기능을 구현하고 엔드 투 엔드가 작동하는지 확인하십시오. 그런 다음 새로운 기능을 추가 할 때 작동 상태를 유지하십시오. 예, 이것은 부분적으로 TDD 연습이지만 TDD를하지 않더라도 의미가 있습니다.

근거는 내가 안정적 적이 코드의 이주와 함께 사람을 본 적이 때마다, 항상 다른 이주 소요입니다 얻을 이 안정적.

안정 을 유지 한다면 , 그 불확실성을 제거하고 필요에 따라 마감 기한을 좁힐 수있는 방법을 제공하십시오.

명백한 반박 론은 최종 작업이 아닌 코드를 안정화하는 추가 작업을 수행하므로이 작업을 한 번만 쓰는 것보다 시간이 더 걸린다는 것입니다. 나는 이것을 잠시 사지 않는다. 작동하는 코드가 있으면 5 줄을 변경하고 무언가가 끊어 지면 중단이 발생한 위치를 정확히 알 수 있습니다.

작동하지 않은 10,000 줄의 코드가 있고 중단을 찾아야하는 경우 검색 할 코드가 많이 있습니다.

지속적으로 안정적인 FTW 인 시스템의 작은 증분 변경. 빨리 가려면 천천히 가십시오.

저에게있어 생산성을 높이려면 달성하려는 목표와 목표 달성 방법에 대한 명확한 아이디어가 필요합니다.

여기저기서 많은 곳에서 거의 모든 대답이 죽었다고합니다. 또는 적어도 나는 그것을 들었다고 들었다. IDE를 배우고, 더 빨리 타이핑하고, 프레임 워크를 사용하고, 코드 생성 등을 배우십시오. 물론 이런 것들이 도움이 될 것입니다. 그러나 이러한 질문을하고 스택 오버플로와 같은 사이트를 자주 방문하는 프로그래머 유형은 이미 알고있었습니다 . 당신은 단지 여기에 반복하고 싶었습니까, 아니면 조금 환기시키고 싶습니까?

그러나 우리가 그 상태에 도달 할 수 있다면 어떨까요? 이 모든 제안을 마스터한다는 의미입니까? 그러면 어떻게 될까요? 잘. 타임 라인이 더 줄어드는 것 같습니다. 그리고 다시 품질에 대한 인식으로 돌아갑니다. 우리의 기술은 확실히 수십 년에 걸쳐 발전하고 점점 더 생산적이되었습니다. 그러나이시기에 품질이 향상 되었습니까 (물론 초기 단계는 제외)?

제 대답은 간단합니다. 고품질 소프트웨어는 시간이 걸립니다 ! 하나만 다른 것 (품질 / 속도)으로 교환 할 수 있습니다. 그러나 그렇습니다. 그러나 우리는 그 절충이 종종 규모의 속도로 끝나는 정도에 대해 정직하지 않다는 것을 알고 있습니다. 그리고 우리는 프로젝트 초기에 더 큰 거짓말 쟁이입니다!

나는 당신이 여기에 잘못이 없다고 말합니다 . 문제는 사람들이 품질 소프트웨어가 얼마나 오래 걸리는지에 대한 인식 입니다. 우리는 관리자 나 심지어 우리가 추측하는 타임 라인의 유형으로 양질의 소프트웨어를 만들 수 있다고 믿습니다. 우리는 양질의 소프트웨어를 만들지 않습니다 . 우리는 응용 프로그램의 특정 구석에서 작동하지만 때로는 품질이 떨어지는 소프트웨어를 작성합니다.

그래서 우리는 이것에 대해 무엇을 할 수 있습니까? 우리는 각 프로젝트에 대한 투자를 두 배 또는 세 배로 늘려야한다는 것을 상사에게 설득시킬 수는 없습니다. 나는 예를 들어 리드를 말한다. 부수적 인 프로젝트로 진정으로 훌륭한 소프트웨어를 만듭니다. 자신의 시간을 투자하고 타협하지 마십시오. 항상 당신이 진행하는 방법에주의를 기울이십시오. 예상치 못한 시간을 들여야했던 분명히 관련없는 작업을 기록하고 정당화 할 수 있는지 확인하십시오. 이 작업을 다른 모든 프로젝트와 대조하십시오. 수 잔인하게 정직자신과이 분석의 모든 측면에서 "실제"프로젝트에서 품질 소프트웨어로 수행 한 추가 작업을 무시할 수 있습니까? 그러나 아마도 당신의 시도는 실패했을 것입니다. 이유가 무엇입니까? 핵심 기능을 수행하기 위해 지루해하고 서두르셨습니까? 나는 아직 나 자신과 같은 일을하고 있기 때문에 의심의 여지 없이이 생각을 끝내야합니다. 그러나 나는 그것을 실제로 시도하려고합니다. 계속 게시하겠습니다 :).

마지막으로, 나는 (모두는 아니지만) 대부분의 성능 평가가 왜곡되고 특별하게 조작된다고 생각합니다. 품질과 속도를 100 %로 조절할 수 없습니다. 상사는 조직이 정한 표준에 따라 점수를 매겨 야합니다. 품질과 속도의 균형에 대한 조직의 표준. OrangeSoft Inc.는 33 %의 품질과 66 %의 속도를 기대한다고 상상해보십시오. 따라서 단위 테스트의 3 분의 1을 가진 코드를 작성하는 경우 속도가 빠르고 배달 시간이 단축되는 코드를 작성하면 리뷰에서 거의 100 %의 점수를 받아야합니다! (이것은 꽤 거친 비유이지만 요점을 얻습니다). 그러나 대신 밥은 코드를 매우 빠르게 작성하지만 악명 높은 버그입니다. 그의 성능 검토에서 그는 품질에 대해 3/5, 속도에 대해 5/5를 얻습니다. 반면에 Carol은 코드를 훨씬 느리게 작성하지만 훨씬 적은 버그를 생성합니다. 그녀는 품질은 5/5, 속도는 3/5입니다. 밥과 캐롤은 자신의 인상에 도킹됩니다. 모든 직원이 완벽한 점수를받을 수 있습니까? 이건 공정한가요?

내가 사용하는 기술은 진화 적 프로토 타입입니다

더 많은 정보를 얻으려면 Google을 사용할 수 있지만 무언가를 빨리 생산해야하는 경우 갈 수있는 유일한 방법입니다. 또한 사용자가 자신이 좋아한다고 말하면 완료됩니다 (... 및 문서 작성을 시작할 수 있음).