현재 작업에없는 작업 흐름, 편집

일반적으로 프로그램을 작성할 때는 명확한 작업이 있지만 계속 진행할 때 정리하고 싶은 성가신 것을 찾으십시오.

여기에 세 가지 옵션이 있습니다.

• 나중에 수행하십시오 (티켓을 추가하는 데 시간을 소비하거나 잊었을 수 있음)
• 지금하고 내 현재 작업과 함께 커밋하십시오 (불분명)
• 지금하고 별도로 커밋하십시오 (찾아야 실수하고 실수로 옵션 # 2로 이동)

이것은 아마도 기본적이지만 svn / git / other를 사용하여 이것을 피하는 방법은 무엇입니까?

개인적으로, 나는 그것이 :-)에 달려 있다고 생각합니다.

• 들어 작은 수정 나중에 그 일의 오버 헤드 가치가 없기 때문에, 옵션 3 (현재, 별도의 커밋), 최고입니다. 이 경우 별도의 커밋을 만듭니다. 이를 수행하는 방법은 사용하는 VCS에 따라 다르며 별도의 질문입니다 :-).

• 그것은 경우 큰 수정 , 당신은 티켓을 만들 수 있습니다. 그렇지 않으면, 당신은 당신의 주된 과제에서 끊임없이 탈선 할 위험이 있습니다 ( "아, 봐봐, 리팩토링을위한 또 다른 기회, 오, 또 다른 곳이 있고 거기에있다 ...").

이걸 고려하세요. "불쾌한 일을 찾아서 정리할 때 (...)"결정을 내릴 때 경영진이 결정하면 우선 순위 토론 및 결정에서 팀의 나머지 부분을 잘라냅니다. 당신은시키는거야 당신 때문에 코드와 특권 관계의 다른 의제 트럼프 모두를. 나는 그것이 좋은 생각하지 않습니다. 경험을 바탕으로 팀 / 주주 분개도 유도합니다.

대신 정리 / 리팩토링을위한 이슈 / 태스크를 생성하십시오. 마음이 신선하지만 중요한 이유, 안정성 증가, 유지 보수 용이성, 그런 종류의 추정치 등을 나열하십시오. 팀의 운영 방식에 따라 노력을 추정 할 수 있습니다. 그런 다음 다음 작업 선택 / 할당 / 우선 회의에서 리팩토링 작업을 제시하고 다른 작업과 비교하십시오. 팀으로서, 언제 완료해야하는지 결정하십시오.

내가 당신에게 원칙의 이름으로 좋은 의미를 버리라고 말하고 있다고 생각하지 마십시오. 머리를 사용하십시오. 편집중인 기능에 못생긴 것이 있으면 새로운 리팩토링 작업이 아닙니다. 문제를 해결하고 모든 내용을 확인하십시오. 작업중인 속성의 이름을보다 합리적인 것으로 바꾸면 몇 가지 추가 소스 파일에 영향을 미치는 경우 새로운 리팩토링 작업이 아닙니다. 당신이 (미치, 나는 그 사람 싫어)을 편집하지 않는 기능에 뭔가를했던 방식처럼 다른 개발자를하지, 그것을 수정하고 다른 한편으로는,. 만약에 모든 것을 확인 하고 , 기능이 잘 작동 것으로 보인다 말했다 지금은 그대로 두십시오 . 리팩토링 작업을 만들고 팀에 사례를 제시하십시오.

새로운 기능을 선호하여 팀에서 리팩토링을 항상 거부하는 경우 다른 일자리를 찾아보십시오. 직업이 있으면 구직하기가 더 쉽습니다.