우리가 대부분의 전문가들이 바라는 상식을 벗어나지 않는 한 나에게만 중요합니다.

버전 관리에 관해 이야기 할 때 any version control beats not having anything at all개발 방법에는 그렇지 않다는 주장 이 있습니다. 방법은 규칙을 의미하며 규칙이 깨지는 경우가 있습니다. 나는 누군가가 기억할 수있는 한 정말 바보 같은 일을 해 온 회사에서 일했었다. 아무리 구피 절차가 치료되던 문제는 오래 전에 사라졌다.

회사에서 다음을 원합니다.

• 몇 페이지에 맞는 명확하게 문서화 된 절차. 속도를 맞추기 위해 논문을 읽거나 소설을 열람해야한다면 오랫동안 길을 잃을 것이다.

• 회사가 더 나은 절차를 변경할 수 있다는 증거. 다른 사람에게 가서 “[xyz]를하고있는 이유를 알고 있지만, 현재 대부분의 도구를 사용할 수 있습니다. 사용할 수 있습니까?” 라고 말해야 합니다.

• 작은 경쟁은 좋을 수 있으며 종종 피할 수없는 일입니다. 그러나 경쟁이 사람들에게 동기를 부여하는 주요 수단으로 사용되는 상점은 피할 것입니다. 오후 5시에 개발자가 하루에 커밋 한 라인 수를 레이저 프린터로 보내는 것을 체계화했다면, 나는 당신을 위해 일하고 싶지 않습니다.

• 축복받은 저장소의 빌드가 해당 빌드를 손상시키는 변경 사항을 수신하지 못하게하지 않은 경우 나는 지옥처럼 달려갑니다. 5시에 마지막으로하고 싶은 것은 마스터 리포지토리에서 변경 사항을 가져와 로컬 빌드를 테스트하고 다른 사람의 세미콜론을 수정하는 것입니다.

• 나는 민첩한 나무에서 떨어진 기존의 방법과 유사한 방법으로 뛰어 드는 것을 선호합니다. 필수는 아니지만 친숙 함은 절차상의 실수를하지 않으면 서 생산적이 되려는 초기 혹을 극복하는 데 도움이됩니다.

절차에 대해 감사하는 것보다 절차를 다시 보내는 데 더 많은 시간을 할애한다는 것을 알면 아마도 그 일을 계속할 것입니다.

다른 사람은 “오, 다시는 안돼!” 되어 “우리는 또한 우리를 위해 모범 사례를 설정합니다. 우리는 코드의 육백만 라인 (21 개) 재택 근무자가, 우리가 SVN 또는 무언가를 사용해야 바라고있어?” .

누군가 그것을 재미있게 분류 할 수 있습니다. 나는 그 사람이 아니다 🙂

답변