언제 일을 멈추고 도구를 만들어야합니까?

소프트웨어 엔지니어로서 우리는 항상 생산성 향상을위한 효과적인 도구를 원합니다. 또한 일상적인 작업에서 기존 도구에 만족하지 못하는 경우가 많으며 GDB 스크립트 설정, Vim 스크립트 및 일부 Python 스크립트와 같은 더 나은 방법을 사용하여 지루한 작업을 자동으로 수행하려고합니다.

그러나 도구를 만드는 데에도 시간과 에너지가 필요하기 때문에 실제로 절충점입니다. 생산성 향상을 즉시 제공하지는 않습니다. 그러므로 일을 멈추고 미래의 고통을 덜어 줄 도구를 만들어야 할 시점을 어떻게 판단합니까?

다음 중 하나에 해당하면 "도구를 만듭니다".

1. 작업은 나를 귀찮게합니다
2. 작업에서 인적 오류의 위험이 너무 큽니다

두 번째 옵션의 "위험"은 크지 않아도됩니다. 하나의 작은 도구를 만드는 데 드는 비용은 일반적으로 적기 때문에 일주일에 한 번 10 분 동안 다시 빌드 할 위험이 있습니다. 매우 빨리 상환하십시오.

도구를 최대한 작게 만들려고합니다. 이제 작업을 조금 더 쉽게하고 다음에 다시 개선 할 수 있습니다.

즉, 매번 가장 큰 고통을 해결하고 실제로 당신을 해치지 않는 문제에 대한 해결책을 만들지 않습니다.

경험을 통해 나는 거친 작업을 열심히하는 것이 일반적으로 가장 시간 효율적이라는 것을 알았습니다. 도구를 만드는 것은 종종 유혹적입니다. 다음과 같은 경우에 저항을 포기합니다.

• 이 도구에는 여러 가지 목적이 있습니다. 훌륭한 체스 플레이어는 각각의 움직임으로 두 가지 일을 완수했습니다 : 상대방 조각을 차단하고 감독을 해방하십시오. 초보자는 아마도 두 번의 턴이 필요할 것입니다. 마찬가지로 도구가 한 가지 작업 만 수행하거나 약간의 추가 노력으로 두 가지 작업 (예 : 일부 원시 데이터 파일 수정 및 인공 테스트 데이터 작성)을 고려합니다.
• 미래의 유용성. 이번 주 작업 시간을 절약 할 수 있지만 다음 주에 새 프로젝트를 진행할 때 저나 다른 사람의 시간을 절약 할 수 있습니까?
• 새로운 언어, 도서관, 디자인 기술 등을 배우기에 좋은 시간입니다. 이 도구는 이미 교육에 부여 된 시간을 사용하여 무언가 교육을하는 데 유리한 부작용입니다.
• 일을 처리하는 데 심각한 문제가있을 때 낙하산이없는 스카이 다이빙과 마찬가지로 낙하산을 만들거나 구입하려면 시간이 걸립니다. 의미있는 실험 결과를 얻지 못하거나 새로운 웹 앱이 전혀 작동하지 않으면 볼 수 없거나 구성 요소를 구동하거나 체계. 도구가 필요한 작업이 완전히 중단되면 향후 사용 또는 다중 사용에 신경 쓰지 않습니다. 필요 무게가 충분합니다.

경험상 세 번째로 무언가를해야 할 때 작은 스크립트를 작성하여 자동화하거나 접근 방식을 다시 생각해야 할 때입니다.

나는이 시점에서 본격적인 "도구"를 만들지 않고 수동으로 한 일을 자동화하는 작은 스크립트 (일반적으로 bash 또는 python; perl도 작동하거나 심지어 PHP도 가능)를 만듭니다. 기본적으로 DRY 원칙 (또는 본질적으로 동일한 단일 소스 원칙)을 적용한 것입니다. 두 소스 파일을 동시에 변경해야하는 경우 공통의 사실이 있어야합니다. 진실은 하나의 중심 장소에 고려하여 저장해야합니다. 리팩토링을 통해 내부적으로이 문제를 해결할 수 있다면 좋지만 때로는 이것이 가능하지 않으며 사용자 지정 스크립트가있는 경우가 있습니다.

그런 다음 나중에 스크립트가 완전한 도구로 발전 할 수도 있고 발전하지 않을 수도 있지만 일반적으로 하드 코딩 된 많은 항목이 포함 된 매우 구체적인 스크립트로 시작합니다.

나는 열정을 가지고 거친 일을 싫어하지만, 그것이 잘못되었거나 잘못된 디자인의 표시라고 강력하게 믿는다. 게으르다는 것은 프로그래머에게 중요한 특성이며 반복적 인 작업을 피하기 위해 많은 시간을 투자하는 것이 좋습니다.

물론, 때로는 균형이 부정적입니다. 코드를 리팩토링하거나 스크립트를 작성하여 1 시간의 반복 작업을 절약하기 위해 3 시간을 소비합니다. 그러나 일반적으로, 균형은 긍정적입니다. 직접적으로 명확하지 않은 비용을 고려할 경우 : 인적 실패 (인간은 반복적 인 작업에서 실제로 나쁩니다), 더 작은 코드베이스, 중복 감소로 인한 유지 보수성 향상, 자체 문서화, 빠른 미래 깨끗한 코드 개발. 따라서 현재 잔액이 마이너스로 표시 되더라도코드베이스가 더 커지고 3 개의 데이터 개체에 대한 웹 양식을 생성하기 위해 작성한 도구는 30 개의 데이터 개체가있을 때에도 여전히 작동합니다. 필자의 경험에 따르면, 균형 잡힌 작업을 선호하여 균형을 잡는 것으로 추정됩니다. 아마도 반복 작업이 예측하기 쉽고 추정치가 낮기 때문에 리팩토링, 자동화 및 추상화가 예측하기 어렵고 위험하며 과대 평가 된 것으로 인식되기 때문입니다. 일반적으로 자동화는 그렇게 어렵지 않습니다.

그런 다음 너무 늦게 할 위험이 있습니다. 3 개의 새로운 데이터 객체 클래스를 형태로 리팩토링하고 웹 양식을 생성하는 스크립트를 작성하는 것이 쉽고, 일단 완료하면 27 개의 클래스를 추가하기가 쉽습니다. 스크립트로 작업하십시오. 그러나 30 개의 데이터 객체 클래스가 있고 각각 손으로 작성한 웹 양식이 있고 그 사이에 일관성이없는 지점 (일명 "유기적 성장")에 도달하면 해당 스크립트를 작성하는 것이 거의 불가능합니다. 30 개의 클래스를 자신의 형태로 유지하는 것은 반복적 인 코딩과 반 수동 검색 대체의 악몽입니다. ​​일반적인 측면을 변경하는 데 30 배가 걸리지 만 문제를 해결하기 위해 스크립트를 작성하는 것은 프로젝트가 시작되었을 때 점심 시간이 없었던 것은 이제 버그를 수정하고 사용자를 교육하며 심지어 포기하고 되돌릴 수있는 한 달 동안의 여파가 무서울 정도로 무서운 2 주간의 프로젝트였습니다. 오래된 코드베이스. 아이러니하게도, 30 클래스 엉망을 작성하는 것은 언제나 편리한 스크립트를 이용할 수 있었기 때문에 깨끗한 솔루션보다 오래 걸렸습니다. 내 경험상 반복적 인 작업을 너무 늦게 자동화하는 것은 장기적으로 실행되는 대규모 소프트웨어 프로젝트의 주요 문제 중 하나입니다. 당신은 항상 편리한 스크립트를 타고 있었기 때문에. 내 경험상 반복적 인 작업을 너무 늦게 자동화하는 것은 장기적으로 실행되는 대규모 소프트웨어 프로젝트의 주요 문제 중 하나입니다. 당신은 항상 편리한 스크립트를 타고 있었기 때문에. 내 경험상 반복적 인 작업을 너무 늦게 자동화하는 것은 장기적으로 실행되는 대규모 소프트웨어 프로젝트의 주요 문제 중 하나입니다.

방금 이것을 기억했습니다.

물론 이것의 문제는 실제 상황에서는 이러한 데이터를 쉽게 측정하여 테이블에서 올바른 셀을 선택할 수 없다는 것입니다. 다른 답변에서 언급했듯이 방정식에 추가 해야하는 다른 변수 (오류 위험, 작업이 너무 지루합니다 ...)가 있습니다.

따라서 제 대답은 그것이 상황에 따라 다르며 모든 상황에 대해 "올바른"대답을 얻을 수는 없다는 것입니다. 우리가 모든 것에 대한 요리 책을 가지고 있다면 모든 삶은 지루할 것입니다.

이것은 내 경험에서 큰 문제입니다. 도구 제작은 대개 도구 제작 작업을 중단하는 동기 부여 된 개발자에게 맡겨집니다. 이것은 종종 가치를 제공하더라도 개발을 방해합니다. 툴 빌딩은 개발 "프로세스"의 통합 된 부분으로 간주되어야합니다.

헤더 오류로 인해 다른 검토 일정이 잡히는 코드 검토에 참석 한 것을 기억합니다. 이 중 많은 것이 도구에 의해 감지되었을 수 있습니다. 예를 들어, 잘못된 슬로 카운트, 요구 사항 누락, 포맷 오류. perl로 작성된 내 도구는 제공된 코드에서 헤더를 생성하고 Oracle 데이터베이스의 검증 된 요구 사항을 생성했습니다. "프로세스"의 일부가 아니었기 때문에 단기 구축시 도구가 배송 지연으로 간주되었습니다.

전체 팀은 주기적으로 중지하고 도구 작성으로 자동화 할 수있는 것보다 수동 작업이 필요한 위치를 확인해야합니다.

다른 모든 대답은 훌륭하지만 작은 도구를 작성하는 데 시간을 소비하고 .vimrc, .emacs 등을 사용자 정의하는 것이 더 가치있는 이유를 하나 더 추가합니다.

때때로 당신은 창의적으로 또는 동기 부여로 "충돌에 빠졌다"고 무엇인가를하면 "주스가 흘러 나옵니다"(유를 섞어). 이상적으로는 생산적으로 프로젝트를 진행시키는 것이지만, 약간의 접선이며 영감을 주면 좋을 것입니다.

빈 화면을 쳐다 보지 않고 큰 작업에서 진행 상황을 보는 데 어려움을 겪을 수 있습니다. 그러한 상황에서, 어떤 유형의 무언가를 똑딱 거리는 것은 당신이 어디에도 가지 않는 것처럼 느끼는 것을 막을 수 있습니다.

이에 대한 변형은 "백 버너"에 있어야 할 것에 대해 계속 생각할 때입니다. 잠시 시간을내어 행동하면 마음을 빼앗아 전체 에너지를 다시 주 업무에 투입 할 수 있습니다.

도구를 만드는 것으로 간주하는 대상에 따라 다릅니다. 틀림없이 나는 다른 개발자들이 경솔하게 생각하는 방식으로 그것들을로드합니다 ... 가장 기본적인 파일 시스템 명령을 제외하고 거의 모든 것을 위해 만들어지기 때문 입니다.

나는 그것을 뒷받침하기 위해 두 가지 근거를 사용합니다.

• DRY 원칙의 확장입니다. 우리가 무언가를 반복하고 싶다면 수동 노력이 인적 자원을 가장 효과적으로 사용하는 것입니다.
• 내가 한 일을 기록하는 효과적인 방법이므로, 무언가를 만들면 몇 주 또는 몇 달 후에 내가 한 일을 다시 참조하고 프로젝트 작업 로그를 유지하려고 할 수 있습니다.

때때로 그들은 더 큰 도구로 성장하고 대화 형 기능을 얻지 만, 그렇지 않으면 여전히 레코드로서 가치가 있습니다.