제공 :
한빛 네트워크
저자 : chromatic
역자 : 임성진
원문 :
What are Your Force Multipliers in Software Development?
force multiplier의 개념은 군사 용어로부터 유래했으나, 그것은 속성, 수행 또는 장점 어느 것이든 집단이나 개인(의 속성, 수행 또는)의 효율성을 증가시키는 어떤 분야에도 넓게 적용시킬 수 있다.
프로그래밍과 프로그래밍 언어의 영역에서, 추상화를 위해 증가된 능력은 명백한 force multipliers이다.
컴퓨팅의 역사(이력)에서 몇몇의 굉장한 도약을 열거하기 쉽다: 폰 노이만 구조, 부호를 사용하는 컴퓨팅, 컴파일러, 구조적 프로그래밍, 인터프리터, 라이브러리, 이식이 가능한 프로그래밍 언어, higher-order 프로그래밍, 그리고 가비지 컬렉션이 그 예이다.
툴 또한 이 도약의 한 요소이다.
GDB (유닉스 기반의 시스템에서 동작하는 이식성 있는 디버거), Valgrind (리눅스용 디버깅 툴), Kcachegrind (프로파일 데이터를 비주얼하게 보여주는 툴)이 사용되지 않는 것을 분야가 없으며, 나는 몇몇의 GCC 플래그와 속성을 사용하지 않는 것을 상상할 수 없다.
Vim(vi 호환 텍스트 편집기), ctags(프로그래밍에서 인덱스나 테그 파일을 생성하는 프로그램), ack, grep(파일이나 표준 입력을 검색하여 주어진 정규 표현식과 맞는 줄을 찾아 프로그램의 표준 출력으로 출력하는 지시어) 에 대해 언급하는 것이 기쁘지만, 다른 사람들은 한 번에 IDEs(컴퓨터 마더보드의 데이터 버스와 컴퓨터의 디스크 저장 장치간에 사용되는 표준 전자 인터페이스) 를 생기게 하는 것이 더욱 효과적이라고 생각한다.
이러한 논쟁은 오래되고 잘 정립되었다.
생산성을 증가시키고 개인과 집단을 더욱 효율적으로 만드는 개발 절차에 대해 논의하는 것은 더욱 흥미롭다.
- 종합적인 테스트 : 테스트를 기록하고, 그것이 실패하는 가를 관찰하고, 코드를 생성하고, 그리고 테스트가 통과(에러가 없는가)하는 것을 관찰하는 전례적인 개발에 의하면, 코드는 테스트(에러가 있는지 없는지에 대한)를 할 수 있고, 테스트의 적용 범위는 오류와 복귀를 식별할 수 있을 만큼 충분히 넓다는 것을 확신한다. 이것은 소프트웨어가 버그에 자유롭다는 것을 보장하지는 못하지만, 그러나 그것은 잘 정의된 수행의 베이스라인을 확인한다.
- Diffs(차이점) : 나는 diff와 패치 없는 세계를 상상할 수 없다. 손으로 패치를 조작하는 것을 필요로 할 즈음, 단지 시스템간의 차이점을 식별 할 수 있는 것이 얼마나 편리한가를 인지한다.
- 차이점의 검토 : 유사하게, 이해 관계가 있는 분야에 대한 리스트를 가지는 것은 전체 시스템의 지식을 보급시키는 것을 도울 수 있고 개발을 위한 문제와 기회의 가능성을 식별하는 것을 파악할 수 있다.
- SCM/요구사항 추적의 통합 : 소스 코드의 저장과 오픈 버그, 주석, 그리고 특징적 요구사항간의 뒤섞인 링크는 시스템의 상태를 머릿속에 유지할 필요가 없다. 저장소에 코드와 그것의 이력사항을 저장하는 것처럼, 요구사항 추적은 프로젝트의 비전과 특징에 저장한다.
- 페어 프로그래밍(두 명의 프로그래머가 번갈아 프로그래밍을 할 수 있는 공간) : 버그를 정정하든 특징을 추가하든지 간에 프로그래밍의 능률을 가장 만족시키는 것으로, 나는 다른 사람들과 가깝게 함께 작업을 해왔다. 책상 위의 피카츄 인형이나 또는 나의 고양이 중 하나는 나와 같이 문제의 의도를 가진 다른 사람과 대화를 하기 위한 대용품이다.
- 손으로 직접 만든 툴 : Rakudo의 (개발) 속도는 Parrot Compiler Toolkit으로의 개발을 점차적으로 증가시켰다. 나의 작업 패턴을 인식하고, 그것을 자동화할 때 마다 나의 작업효율을 급격하게 증가시켰다. 나는 정확한 순서와 정확한 방법으로 특정 메모리 부족을 보고하기 위한Valgrind의 논쟁의 조합을 기억하지 못했다, 그래서 나는 최근의 가장 성공적인 새로운 방법을 쉘 별칭으로 검색하여 포착하고, 다름아닌 vgp로 모든 것을 삭제한다. 아마도 나는 이 아이템을 “당신 고유의 추상화를 만드는 능력” 이라고 라벨을 붙일 것이다.
- 분산화된 버전 제어 : 버전 제어를 사용하면서 프로젝트를 하나로 모으는 능력은, 이미 개발되었고, 그리고 패치 또는 일련의 패치 안에서의 작업은 상위 단계의 프로젝트에서 실행 할 수 있도록 기여하고, 순환적인 차이(diffs)와 여러 개의 링크를 통해 작업을 하는 것보다 훨씬 더 쉽게 연동한다.
내가 언급하지 않은 많은 force multipliers이 있다고 확신한다.
그들 고유의 것에서, 아마도 어떠한 것도 Brooks의 “하나의 묘책”으로 대표할 수는 없을 것이다 – 그러나, 그들은 생산성(효율성)에서 중요한 개발의 복합적인 순서를 만들 수 있을 것이다.
당신의 force multipliers은 무엇입니까?