지금 간단하게 유지하거나 미래를 염두에두고 프로그램합니까?

현재 회사와 관련된 새로운 응용 프로그램을 코딩하고 있습니다. 마감 시한을 맞추기 위해 기능이 상당히 축소되어 출시 준비가 완료되었습니다.

월말까지 버전 1을 설치하고 실행하는 작업을 받았습니다. 나는 개발의 중간 쯤에 있고 지금은 끝이났다.

어제, 나는 요구 사항 중 하나에 대한 아주 좋은 쉬운 솔루션을 만드는 데 시간을 보냈으며 그것이 어떻게 나타 났는지 자랑스럽게 생각합니다. 오늘 아침에 버전 2 문서가 발송되었으며, 어제 작성한 코드를 뜯어 내거나 심각하게 변경해야하는 요구 사항이 있습니다. 내가 그것을 그대로두면 앞으로 많은 일이 필요할 것입니다. v2 기능을 훨씬 적은 노력으로 추가 할 수 있도록 현재 솔루션을 더욱 강력하게 만드는 데 하루가 더 걸릴 수 있지만, 필요한 추가 코딩을 위해 약간 뒤쳐 질 것입니다.

v2를 할 것인지 모르겠습니다. 나일 수도 있고 동료 일 수도 있고 인턴 일 수도 있습니다.

당신이 내 신발에 있다면, 미래에 더 쉬워 지도록 지금 시간을 보내시겠습니까, 아니면 시간이 오면 솔루션을 떠나서 처리 하시겠습니까?

마감 기한이 스톤으로 조각 된 경우 마감 처리를 완료하십시오. 새 요구 사항에 대한 코드 변경 사항을 수용 할 수 있도록 v2에 대한 추정치를 부풀려 야합니다. 또한 새로운 v2 기능에 대해 변경해야 할 사항을 간단히 문서화하여 동료가 다른 것에 재 할당 할 때 동료가 선택할 수 있도록해야합니다.

마감일에 충분한 유연성이 있다면 (1 일, 그 소리에 따라 2.5 일 연장을 목표로), 계속해서 알려진 미래를 위해 코딩하십시오!

두 번째 시스템 효과에 빠지지 않도록하십시오 . 적용 할 몇 가지 좋은 기술은 다음과 같습니다.

1. 버전 2에서 나온 것 때문에 버전 1의 탈선을 피하십시오. 미리 계획하는 것은 좋지만 v2 사양의 작성자는 v1이 아닌 v2의 실패에 대한 책임을 져야합니다.
2. (가능한 경우) 제작자가 더 큰 변경이 필요하지 않은 버전 2의 요구 사항을 재 작업 할 수 있는지 확인한 다음 나중에 v3에 대한 계획을 세울 수 있습니다.
3. 계속 YAGNI을 염두에두고 있지만, 마음에 확장 성 코드에 시도 - 등을 피하기 마법의 숫자, 하드 코딩 된 값, 쓰기 좋은 단위 테스트 또는 코드 계약을, 리팩토링과 코드가 길을 따라 덜 고통스러운 변화를 만들 것입니다 초기에 좋은 기술을 적용.

도시처럼 성장 하는 대부분의 소프트웨어 프로젝트 는 장기적으로 성공합니다. 제한된 미래에 대한 혁신적인 계획을 통해 소프트웨어를 정시에 출시 할 때 릴리스에 필요한 기능을 제공 할 수 있습니다. Carl Sagan이 발췌 한 내용을 참조하십시오.

모든 도시 시스템이 병렬로 구축되고 주기적으로 교체되는 경우 [도시의 배치]가 더 효율적일 수 있습니다 (이 때문에 런던과 시카고의 대대적 인 폭발과 같은 비참한 화재가 때때로 도시 계획에 도움이되는 이유 임). 그러나 새로운 기능이 느리게 진행됨에 따라 도시는 몇 세기 동안 계속해서 일할 수있게되었습니다.

• 코스모스 Carl Sagan : http://www.eridanus.info/genesis.html

다음 달 요구 사항에 맞게 오늘 코드를 추가하지 마십시오. 오늘날 요구 사항에 맞는 가장 깨끗한 코드를 작성해야합니다. 나는 하루의 일이 이제 며칠 후에 절약 될 것이라는 점에 회의적이다. 나는 그런 주장을 들었고 그것이 사실이었던 하나의 사례를 기억할 수 없습니다. 코드를 보여줌으로써 저를 설득 할 수는 있지만 제 경험에 의하면 그럴 가능성이 적습니다.

그대로 두십시오.

개발자는 실제로해야 할 일을 더 이상하지 않는 레거시 프로젝트를 이해합니다.

오늘날 "미래"요구 사항을 충족시키기 위해 코드베이스를 "스테이징"하는 것이 좋은 아이디어처럼 보일 수있는 것은 앞으로 코드를 이해하는 데 장애가 될 것입니다. 아무도 부분적으로 구현 된 기능과 잊혀진 팬텀 요구 사항을 다루는 것을 좋아하지 않습니다. 나는 그것이 사실이라고 말하지는 않지만 최선의 의도에도 불구하고 종종 그런 식으로 나타납니다.

좋은 답변입니다. 나는 단지 추가 할 것입니다-이와 같은 경우에 내가하는 일은 좋은 diff를 취하여 내가 한 일을 포착하고 안전한 장소에서 다람쥐를 멀리 할 수 ​​있습니다. 그러면 다음 버전에서 다시 기회가 생기면 쉬울 것입니다.

일반적으로, 훌륭한 개발자는 미래의 요구 사항을 예상하지만 마감일이 다가 오면 이미 "배를 흔들지"않은 버그에 대응해야합니다.

따라 다릅니다. 좋은 구식 규칙이 있습니다. 자신을 대하고 싶은 것처럼 다른 사람들을 대하십시오. 자신의 프로젝트 였고 모든 우선 순위를 알고 있다면 어떻게 하시겠습니까?

v2가 반드시 필요하고 마감일이 어려운 것이 아니라 희망일 경우에는 날씨가 좋을 때 기술 부채를 내지 않고 항해를 수정하지 마십시오. 다른 사람이 v2를 수행하더라도 그들은 예견에 감사 할 것입니다.

v2의 필요성에 대해 의문이 있으면 YAGNI를 고수하십시오. 또한 스펙트럼의 반대편에 있고 아이디어를 형성하기 전에 끊임없이 자신의 아이디어로 스팸을 보내는 고객 중 한 명에게 이메일을 매일 2 ~ 3 회만 확인하고 조치를 서두르지 않으면 놀라게 될 것입니다 "문제"및 요청 수는 읽기 전에도 관련이 없습니다.