개발자의 속도를 늦출 수있는 것은 무엇입니까? [닫은]

개발자의 속도를 늦추는 요인은 무엇입니까?

다음과 같은 답변을 게시하지 마십시오.

• 지금은 느리지 만 기능에 유용합니다. (TDD, 리팩토링, ...)
• 방해 요소를 나열하십시오 .

아 이거 쉬운데 :

1. 회의
2. 더 많은 회의
3. 마지막 회의에 관한 회의
4. 다가오는 회의를 준비하기위한 회의
5. 회의를위한 파워 포인트 프레젠테이션 개발
6. 구현되지 않았거나 구현해서는 안되는 기능 및 판매 담당자가 모든 이유로 뛰어 드는 이유를 논의하는 회의를위한 파워 포인트 프레젠테이션 개발. 인터넷에 연결되어 있지 않거나 하드 드라이브에 액세스하지 않으면 현재 위치에 따라 앱에 표시 할 문서를 예측할 수 없습니다. 아니, 그냥 물어봐도 돼.

느린 컴퓨터

컨텍스트 전환 을 유발하는 모든 것 .

StackOverflow, programmers.stackexchange.com 등 :)

나는 소진을 말할 것입니다.

현재 작업에 적합하지 않은 프로세스를 따르려고 시도합니다.

이것은 모든 종류의 일이 될 수 있지만 내가 볼 수있는 일반적인 것은 다음과 같습니다.

• 테스트중인 코드에 맞지 않는 테스트 방법론
• 산출물 보증서보다 훨씬 더 민첩하거나 전통적인 프로세스
• 선택한 툴셋과 다른 툴셋을위한 지침
• 프로젝트 요구에 맞지 않는 설계 원칙
• 작업에 적합하지 않은 툴셋 사용

이러한 모든 것들은 일부 프로젝트 나 상황에 따라 매우 가치가있을 수 있지만, 일부 조직은 모든 ​​방법을 한 가지 방법으로 시도하고 종종 생산성이 떨어지는 다른 프로젝트에 적합하지 않습니다.

정치

예 : 둘 이상의 사람이 요구 사항을 소유 한 경우 (또는 더 나쁜 경우, 서로 다른 두 가지 투자 이익), 개발이 진행되는 동안 요구 사항을 경쟁하고 상충하는 변경 사항을 만듭니다.

다른 사람의 대화

그리고 일반적으로 소음

많은 답변이 상황 전환 및 영역 밖으로 나가는 것에 대해 이야기하며 소음, 특히 대화는 저에게 도움이되는 것 중 하나입니다.

내 큐브 월드에서 나는 사방의 소음과 대화에 둘러싸여있다. 한 줄로 메인 프레임 팀은 큐브 행에서 지속적인 계획 회의를 개최합니다. 때때로, 그들은 벽을 따라 사무실에서 컨설턴트들을 만나게 될 것입니다.

다른 한편으로, 웹 팀 회의 테이블은 서쪽 큐브 벽의 다른쪽에 있으므로 모든 회의의 일부입니다. 남쪽 입방체 벽의 반대편에는 프린터가 있으며, 항상 출력물을 기다리는 사람들의 잡담에 좋습니다.

" 소음 제거 헤드폰을 얻을 수 없습니다 "라는 즉각적이고 확실한 대답은 원하는 것이 침묵 일 때 도움이되지 않습니다.

때로는 코드 검토를 위해 점심을 먹지 않는 점심 시간에 종이 더미를 가져 가지만 일반적으로 눈에 띄는 TV가 있습니다. 아무도보고 있지 않으면 끄겠습니다. 그렇지 않으면 건물의 다른 부분에있는 다른 부서에서 빈 큐브를 찾을 것입니다.

프로그래머가 생각하고 숙고하고 고려하는 작업을 수행하려면 프로그래머가 할 수있는 환경이 필요합니다.

적절한 테스트없이 너무 많은 코드를 작성합니다.

고품질 커피 부족.

일단 개발이 시작되면 절대로 평가해서는 안되는 완벽한 추정을해야한다고 생각합니다. 제 생각에는 닭 계란 시나리오입니다.

다른 사람의 고장난 빌드 수정

의제가없는 회의.

기계가 느립니다.

두 번째 모니터가 없습니다.

멋진 새 마우스 대신 공이있는 오래된 마우스.

컴퓨터에 인터넷 액세스가 부족하여 MSDN / stackoverflow 등을 쿼리하는 데 약간의 어려움이 있습니다.

너무 많은 시간을 프로그래밍

프로그래밍을 정말로 좋아하더라도 너무 많은 시간을 소비하면 결국 화상을 입을 수 있습니다 ...

"영역"밖으로 나가는 모든 것을 피하십시오. 즉, 이메일받은 편지함, 트위터 팝업 응용 프로그램, 회사 채팅 등을 의미합니다.

갖는 조용한 작업 조건 이 바탕 화면을 피하는 수단 소음이 너무합니다.

사전에 알고 있다면 쉽게 구현할 수있는 변경 요청.

코드가 잘못되었습니다.

처음부터 바로 작업을 수행 할 수 있었던 다른 사람의 일부를 다시 작성해야한다는 것은 제가 상상할 수있는 가장 큰 시간입니다.

당신을 늦추는 많은 것은 이것에 대한 좋은 블로그 게시물입니다.

...

많은 프로젝트가 핵심 인프라 수준의 기능을 반복해서 반복하여 비즈니스를 경쟁 업체와 차별화하는 기능을 제공하는 속도를 늦 춥니 다.

...

제품과 혁신이 개발자가 차별화되지 않은 작업에 소비하는 시간을 줄이는 데 도움이되는 것은 불가피합니다. 문제는 그러한 서비스와 도구가 어떤 형태를 취해야 하는가입니다.

...

요즘 가장 큰 둔화는 특정 순서로 수행되어야 할 여러 가지를 동시에 개발하기 때문입니다. 그래서 John은 (무고한 사람들을 보호하기 위해 이름이 변경되었습니다.) John이 SSIS 패키지에 필요한 구성 요소를 완성 할 때까지 기다립니다. Harry는 내보내기 테스트를 위해 볼 데이터가 필요하기 때문에 레코드 가져 오기를 기다리는 속도가 느려집니다. 테이블에 데이터가 없을 때 복잡한 내보내기 보고서를 작성해야합니까?) 디자인이 완료되지 않고 작업을 수행하는 데 필요한 데이터베이스 테이블이 아직 생성되지 않아 종료되지 않을 수도 있기 때문에 모두 속도가 느려집니다. 그들이 할 것이라고 말한 것 등

이와 같은 stackexchange.com에 대한 질문에 답변하십시오.

주의를 산만하게하지 말라고 요청했지만 큰 요소가 될 수 있습니다. 작업 환경을보고, 자주 중단되거나 프로젝트와 관련이없는 다른 작업을 수행하도록 요청되었는지 확인하십시오.

때로는 개발자가 이전에 해본 적이없는 일을하고 있기 때문에 문제가 발생하여 도움을 구할 위치를 모르는 경우가 있습니다. 소규모 팀이나 개인이라면 더욱 어려울 수 있습니다. 우리는 다소 교만하고 일을하는 방법을 모른다면 인정하기를 좋아하지 않는 경향이 있습니다. 또한 우리는 다른 사람들에게 도움을 요청하는 것을 좋아하지 않습니다. 개발자가 마감일을 충족시킬 수 있는지 또는 마감일을 충족해야 하는지를 묻고 정직하기를 바라는 것을 제외하고는 개발자가이를 인정하도록하는 쉬운 방법은 없습니다. 다른 도움을 받거나 도움을 줄 수있는 사람을 찾으라고 제안해야 할 수도 있습니다.

명확하게 정의 된 요구 사항이 없기 때문에 요구 사항을 파악하거나 결정해야합니다.

• PC가 사용 가능한 상태로 부팅 될 때까지 약 15 분 동안 기다려야 함
• PC가 응용 프로그램을 전환하기를 기다리는 중
• 사무실에서 자신의 차 / 커피를 만들어야하는 유일한 사람입니다.
• 깨진 키보드 (고정!)
• 전무 이사 (미국 최고 경영자) 사무실 밖 (사무실이 아닌 곳)과의 사이에 파티션이있는 경우 (특히 회의가있을 때)
• 보스는 이메일로만 연락 할 수 있지만 다른 사람은 모두 건물에 있습니다.
• VCS를 사용할 수 없음-분명히 내 뇌에 있어야 함
• 작은 화면
• 점심 이외의 휴식 시간을 허용하지 않음
• 건물에 sysadmin이 있음에도 불구하고 원격 서버 백업을 수행해야 함
• 백업을 수동으로 수행하라는 지시를 받았습니다.
• 불필요하게 복잡한 바보 같은 시간 관리 시스템을 사용하도록 강요
• 2 개월 동안 요구 사항에 대한 모호한 아이디어 만 얻음

계속할 수 있지만 금요일인데 일을 잊고 싶습니다.

• 문서 부족 (시스템, 회사 등)
• 주석 처리 된 코드 부족
• 시스템에 대한 불완전한 이해
• 정치 (예 : 불필요한 회의, 서류 작업, 경영진의 장애물 ...)
• 불완전한 요구 사항 문서
• 페이스 북!
• 잠이 너무 많이?

프로젝트에 너무 많은 사람들이 있습니다.

경영진이 프로젝트에 더 많은 사람을 추가해야하는 실제 데이터를 기반으로 결정하지 않는 경우가 여러 번 나타났습니다. 그것은 무슨 일이 일어나고 있는지 거의 알지 못하는 사람들의 손을 잡기 위해 모든 것을 막아야하는 일을 알고있는 ppl에서 끝납니다. 나는 하나 이상의 프로젝트 버섯을 보았고 화장실에서 빨리 들어가는 동안 조금 느리지 만 괜찮아지기 전에 화장실에 들어갔다.

그래서 당신은 모든 여분의 사람들에 대한 예산을 완전히 날려 버렸기 때문에 속도가 너무 빠르거나 전혀 배달하지 못하기 때문에 한 달 늦게 지났습니다.

다른 사람들이 언급 한 것 외에도 코드를 컴파일 및 실행하기로 결정하고 긍정적 / 부정적 결과를 얻는 것 사이 의 먼 길 . 이상적으로이 RTT 는 1 초에 불과하지만 시간의 예를 보았습니다. BTW, 단위 테스트는이 문제를 해결하려고합니다.

또 다른 관련 작업 환경 의 일반적인 대기 시간 입니다. 다른 쪽의 컴퓨터에 대한 원격 데스크톱 연결을 통해 소름 끼치는 연결을 통해 작업해야한다고 상상해보십시오. 나 거기 가봤 어. 나는 이것을 싫어했다.

• 과도한 서류

• 주변에없는 사람에 대한 의존성 (예 : 상사-질문을해야하지만 항상 회의중인 경우)

• 부적절한 도구 및 장비.

• 사람들은 아무 이유없이 노를 젓거나 (UI로 눈에 띄는 변화는 이것에 영향을 받음) 사소한 것들에 대한 논쟁을 주장합니다.

• 깨진 커피 머신

• 잘못된 작업이 할당 됨

에어컨이 작동하지 않습니다.

따라서 사무실의 온도는 겨울 -5의 여름에 최대 40도까지 올라갑니다.

-5는 장갑과 유형을 착용 할 수 없으므로 입력하기에 좋지 않습니다. 40은 내 생각을 느리게합니다.

이것은 매우 개인적이고 논란의 여지가 있지만, 초기 설계 또는 "품질"코드 작성에 대해 너무 많이 계획하고 생각합니다. "주간 코딩으로 계획 시간을 절약 할 수있다"는 말이 있습니다.

그러나 종종 프로그래머가 코딩을 시작하기 전에 좋은 디자인을 스케치하려고합니다. 프로그램을 진행하면서 문제와 솔루션에 대해 더 많이 배우고 솔루션을 좋은 디자인으로 신속하게 리팩토링 할 수있는 "가는"것이 더 쉽다는 것을 알고 있습니다. 발생하는 대부분의 문제는 코딩이 시작될 때 거의 알 수 없기 때문에 (나의 미약 한 마음에 가장 가깝습니다) 미리 디자인하는 데 많은 시간을 낭비하는 것은 시간 낭비입니다.

이것이 제가 TDD를 좋아하지 않는 이유이기도합니다. 테스트를 작성하는 데 시간이 많이 걸리므로 리팩토링을 덜하거나 테스트를 다시 작성하는 데 많은 시간이 걸립니다. 단위 테스트는 프로젝트의 일부 단계와 일부 단계에 적합하지만 하나의 시작은 그들 중 하나가 아닙니다. :)

빠르게 작업하고 개선하십시오.

Programmer 's Block : 다른 속도 저하와 달리이 문제를 해결하기가 더 어렵습니다.