그의 질문 "을 어떻게"에서 "어떻게 최고/안전한"으로 변경 되었습니다.

ZILK1988는 여러 경력 후, 14의 나이에 프로그래밍을 시작 했다 그리고 마지막으로 지금 39 세, 선택 (일컬어 코드 농업), 1997 년에 전문 프로그래머가 될 하기로 아직도 후회.

하지만 그때 그는 문제가 발견, 풍부한 그의 경험, 프로젝트 또는 작업을 완료 하는 것이 더 이상. 때문에 그가 잘못 갔을 선택에 주저 수 있습니다 너무 많은 상황을 봤다. 예를 들어, 그는 그냥 파일에 작성 하는 코드 작성에 대해 생각 했다 그리고 그는 다음과 같은 일련의 질문에 대해 걱정 하기 시작 했다: 권한, 잠금, 동시성, 원자 조작, 바퀴/프레임 워크, 다른 파일 시스템, 디렉토리, 예측 가능한 임시 파일 이름에 파일의 수 PRNG (의사 난수 생성기) 임의성 품질 작업을 수행 하는 방법을 충분히 이해 하 고, 문서를 등등 작성 해야 어떻게 API를 작성 하는 방법.

즉, 그의 질문은 "어떻게 최고/안전"을 "어떻게 할" 변경 되었습니다.

결과 그 버전 바위 고체 했다 하지만 또한 그 신인 보다 더 긴 프로젝트 완료를 발생.

Zilk 그는 알고리즘에 능숙, 수학 사랑, 복잡 한 프로젝트를 즐긴다 고 농도와 아무 문제가 있다. 아마도 경험 실수 하 고 시간이 걸리는 프로젝트를 만드는 문제 (비록 이미 39 세), 일으키는 두려움입니다. 그래서 그는 그의 동료 그는 Stackexchange에 문제를 해결할 수 있도록 초대 합니다.

여기에 솔루션의 선택은:

Telastyn:

당신은 프로젝트를 완료 하는 속도가 느린 되지 않습니다. 당신은 신인 프로젝트를 완료 했다, 하지만 그것은 정말 이상 생각 했었다. 고객에 게 품질을 판매 한다. "회사 빠르고 저렴, 그것을 할 수 있지만 프로젝트 정말 다"? 또는 버그를 찾고 년을 기꺼이 당신은? 또한, 알고 해야 하며 오래 된 말에 동의: "완벽은 좋은 적 이다." "

Sevenseacat:

"좋은, 빠르고, 3 선거 2 저장". 전에 당신이 "좋은" 얼마나 작은 너무 희생을 알고, 지금 알다시피 점점 희생 "빨리."

Mouviciel:

그것은 당신의 경험 참으로 부족 한 것입니다 보인다. 단원: 수요에 따르십시오, 다른 생각 하지 마십시오. 이 원치 않는 기능을 구현 하지 않습니다.

사 티:

민첩 한 방법론은 폭포 스트림 대신 고려해 야 합니다. 먼저 전달 하 고 반복. 이 위험 및 비용을 줄일 수 있습니다.

DXM:

그것은 어두운 면을 합류 하는 것 같다: 그것은 시간 관리.

난 당신 관리자 되 프로그래밍 포기 제안 하지 해요. 하지만 귀하의 경험의 관점에서 기술 수준으로 제한 됩니다. 그래서 간단한 것 들 문제 10 측면의 생각할 수 있는 파일을 쓰기, 약간 개발자의 절대 안 나올 것 이다. 나쁜 것은 아닙니다만...

어두운 면에 있는 모든 현재 가치와 관련이 있습니다. 그것은 최대 출력 (비용-편 익 분석)를 달성 하는 방법에 대 한 최소한의 입력 함께입니다. 모든 비즈니스에서 비용, 성공, 실패 확률, 잠재적인 보상, 및 등의 확률을 온다. 수학을 하 고 조치를 취할.

개발자 인 경우에 그건 무시 권한 및 이름 충돌 없이 5 분 동안 임시 파일을 작성 하는 확인. 당기 순이익: 다른 팀 멤버가이 파일에 대 한 작성 하는 코드에 의존을 시작할 수 있습니다. 이것은 완벽 한 솔루션? 물론 아니에요. 무엇에 대해 99%? 95%? 90%? 이러한 가능성은 존재 한다.

그리고 당신에 게 질문: 어떻게 기술 부채에 대 한 생각 (참고: 후속 유지 보수의 비용을 증가 하는 방법 하지만 빠른 수정)? 어떤 사람들 생각 기술 부채 이어야 한다. 난 동의 하지 않는다. 사업, 기술 부채 사용 하면 "돈"과 "시간" 나중에 뭔가 전달 하기 위해 빌려 수 있습니다. 완벽 한 솔루션, 또는 고객을 쾌도 매듭을 해결 하기 위해 4 개월 2 년 사용 하 고 더 나은 뭔가 살 수 있습니다.? 심판 확실히 상황, 하지만 대부분의 시간에 2 년을 기다리는 고객을 유지 해야 하는 경우, 고객 수 있습니다 이미 등록 경쟁 업체와 함께.

열쇠 기술 부채를 관리 하 고 비즈니스 채무 관리 이다. 만약 당신이 충분 한 돈을 빌려 하지 않습니다, 당신은 당신의 투자에 최고의 수익을 받지 못합니다. 하지만 부채 너무 높 때, 관심 호감 것 이다.

내 조언은 토마토 작업 메서드를 사용 하는 것입니다. 작은 시간 간격 (토마토)에 초점 다음 미래의 작품/연구를 위한이 기간을 할당 하 고 지속적으로 실행 하는 과정에서 이벤트의 우선 순위를 조정.

사울:

프로그래밍 키 중 하나 관리 하 고 제어 복잡성, 내 최고의 우선 순위 중 하나입니다. 복잡성 관리는 무시, 중 결함, 또는 소프트웨어의 ETA (도착 예상된 시간) 극적으로 증가.

많은 다른 관리 수준 및 접근 소프트웨어 복잡성이 있다: "모든 소프트웨어 프로젝트에 대 한 우선 순위가 가장 높은 고객 만족은 고객이 기대 하는 기능입니다." "

즉, 복잡 한 소프트웨어는 고객의 기대 수준을 제어 하는 방법에 따라 달라 집니다.

이 보기에 동의 하는 경우 다음 두 가지 사항을 분명도 있습니다.

고객의 기대를 항상 변경 하 고 수 협상 고객의 기대를 표현 해야 합니다.

당신은 인용 "직접 작성" 또는 "수많은 다른 고려 사항"의 좋은 예. 고려, 누군가가, 모두의 요구 사항을 아래 면은 두 측면의 기능 설명 동일?

같은 비행기를 구축 하는 것입니다, 그리고 F16 비행 수 있습니다., 모형 항공기 날 수 있습니다., 하지만 그 같은 수?

원래 모든 제안, 추출 하려고 하지만 zilk 퍼즐을 해결 하 고 이러한 제안을 하려면 위의 통찰력을 감안할 때,이 문서를 중지, 당사자는 전체 토론을 볼 수 있습니다.

마지막으로, 나만 한 문장 추가:

맥도날드의 이론에서 볼 수 있습니다.