실용주의 프로그래머를 읽고 느낀점을 써보려고 합니다. 제가 느낀바로는 이러한 내용이다 하는 방향으로 기술할 것 같습니다.
craftsman 이라면 연장 정도는 손에 익혀둬야하는게 맞다. 프로그래머도 자신의 툴을 손에 익혀야하는 것이 당연하다.
도구는 재능을 증폭시켜준다. 도구가 좋다는 가정하에 쓰는법만 알면 반드시 최고의 결과를 보장해준다. 생산성을 높히려면 경험을 통해 툴쓰는 법을 자꾸만 많이 익혀둬야 한다. 내 툴박스에는 자꾸만 뭔가 추가될거고 언젠간 빼게될 것들이 막 생길 것이다. 필요에 따라 어떤툴을 써야할지도 알게 될 것이다.
모양을 만들 재료는 어떤 것인가? (일반 텍스트의 힘)
IDE에만 익숙해지지 말고 간단한 쉘 프로그라밍 정도는 할 줄 알아야한다! (shell games)
(파워 에디팅) 장에서는 툴 어케쓰면 좋은지 알려준다.
(소스코드 관리) git 써라
(디버깅) 디버깅은 완벽한 프로그램을 만들기 위한 필수다. 디버깅을 못한다 = 좋은 프로그래머가 되긴 힘들지 않을까
(텍스트 처리) awk, perl, python을 소개
(코드 생성기)는 봐야 알듯.
일반 텍스트(plain text)를 의미.
사람이 이해할 수 있는 텍스트를 쓰는게 좋다. 그냥 플레인텍스트 뿐 아니라 XML이나 HTML처럼 잘 정의된 구조를 가진거면 일반 텍스트 정도로 이해된다.
일반 텍스트를 쓰면 데이터가 어떻게 흘러가는지 보다 빠르게 이해할 수 있다.
단점)
그런데도 불구하고 쓸 필요가 있는 이유는?
알아보기: yaml은 뭐임?
텍스트를 다루는 프로그래머라면 쉘에서 주로 놀게될 것이다. 파이프, 매크로 등…
GUI도 존나 좋은거다. 대놓고 직관적이니까. 근데 텍스트에서의 장점은 따로 있다. 그것은 ‘자동화’, ‘매크로’가 그것이다. 이건 미쳤다. 파일 이름 일일이 변경이나 필요한 작업들은 쉘이 더 빠를 때가 있다.
e.g. Makefile보다 더 최근에 바뀐 모든 c 파일을 찾아라
$ find . -name '*.c' -newer Makefile -print소스의 zip/tar 아카이브를 떠라
$ zip archive.zip *.h *.c
$ tar cvf archive.tar *.h *.c지난주에 바뀌지 않은 자바파일은 무엇인가?
$ find . -name '*.java' -mtime +7 -print그 중에 어느 파일이 awt 라이브러리를 쓰고있나?
$ find . -name '*.java' -mtime +7 -print | xargs grep 'java.awt'(args는 -exec같은 식으로 쓰이는데 더 효과적인듯 보인다. xargs란?)
쉘은 잘 드는 칼 같은거라서 겉보기엔 무서워보이는데 매우 좋다.
Tip 21. 명령어 쉘의 힘을 사용하라.
자바에서 명시적으로 import하는 패키지 이름의 합집합 목록을 만들어서 list란 파일에 저장하기
$ grep '^import ' *.java |
sed -e 's/.*import *//' -e 's/;.*$//' |
sort -u > list이런식으로 매우 좋다!
세상에 에디터는 널렸다. 근데 내가 쓰는거에 대해선 좀 능숙해질 필요가 있다. 정말 남이봐도 잘쓴다 싶을정도로… 하나를 쓴다해도 무슨 기능이 있는지 통달할 필요가 있다!
Tip 22. 하나의 에디터를 잘 사용하라.
에디터 하나를 잘 골라서 잘 쓸 수 있도록 만들고 모든 편집작업에 그걸 사용하도록 하라! 무엇을 쓰든간에 정말 효율적으로 바로바로 필요한 기능이 나오도록 하게 하는 것이 베스트다. 또한 그 에디터가 어지간한 플랫폼에서 다 쓸 수 있는지도 파악하면 도움이 된다. (무슨 작업환경에서든 다 쓸 수 있도록 해두라는 말)
책에서 추천하는 에디터의 기능: 그럴싸한 에디터라면 갖추고있는 몇가지 기능은 다음과 같다.
설정변경 가능
확장 가능:
프로그램 가능:
많은 에디터들은 다음과 같은 특정 고유기능들이 있다:
• 구문 강조(syntax highlighting)
• 자동 완성
• 자동 들여쓰기
• 코드나 문서 상용어구 지원
• 관련 도움말 시스템
• IDE 기능(컴파일, 디버그 등)메모장으로 잘라붙이기 할 수도 있다. 그런데 예를들어 소스코드를 내가 원하는 내용으로 정렬할 필요가 있을 때는 어떻게 하면 좋을까?
vi기준 :.,+3!sort 하면 알파벳 순으로 라인 정렬이 된다.
또는 프로그래밍할 때 처음 내가 입력할 필요가 없는 것들을 파일 생성과 동시에 대신 입력해주기도 한다. 예를 들어 이런것들…
• 클래스와 모듈 이름(파일 이름에서 도출된것)을 자동입력
• 소스코드 작성자 이름, 저작권 선언
• 특정 언어의 스켈레톤 코드(생성자, 소멸자 같은것들 자동작성)책에서는 내가 쓰는 에디터가 무엇인지, 어느정도 쓸 수 있는지에 따라 다음 행동을 제시한다.
| 나의 실력 | 앞으로 어떻게 하면 좋을까요? |
|---|---|
| 나는 여러 에디터 중 기본 기능만 쓴다 | 강력한 에디터 하나를 골라잡아서 제대로 익혀보세요 |
| 선호하는 에디터가 있긴 한데, 기능을 다 쓰지는 않는다 | 그걸 제대로 배워서 입력하는 키 갯수를 최대한으로 줄여보세요 |
| 선호하는 에디터가 있고 가능하면 그걸 쓴다 | 지금 하는 작업 이외에 다 많은 작업에 쓰도록 확장해보세요 |
Git 씁시다! 형상관리를 SE시간에 배웠고 그 예시로 Git이 당당히 나왔다. 필요하다면 SVN도 알아둬야할 것 같다.
소스코드 관리 시스템(SCCS: Source Code Control System) 은 누가 소스를 바꿨고 주간 소스코드 버전차이, 어느 릴리즈에 몇줄 바뀌었는지? 어느 파일이 자주 바뀌었는지? 등을 다 파악할 수 있다. 이는 추후에 버그트래킹, 퍼포먼스/품질 관리 등에 쓰이기 좋은 정보들이다.
브랜치를 나누어서 특점 시점에서 개발 로그를 다르게 남길 수도 있다.
여러사람이 동시에 작업할 수도 있다.
이는 작은 프로젝트든 큰 프로젝트든 어디든 다 쓰일 수 있다.
Tip 23. 언제나 소스코드 관리 시스템을 사용하라!
전체 프로젝트를 제품 빌드를 자동화하고 반복작업을 가능하게 한다.
갓-깃 씁시다.
프로그램은 완벽하게 짤 수 없다. 그렇다면 디버깅에 관련한 문제를 알아보고 찾기 힘든 버그를 찾아내는 일반적인 전략 몇가지를 알아보자. 피할 수 없으면 효율적으로 격파해야지!
안되는 코드는 풀어내면 된다. 그 방법중에 하나가 디버깅이다. 못짠 코드는 누구나 만들어낼 수 있다. 절대로 다른 팀원을 비난하면 안 된다!
Tip 24. 비난 대신 문제를 해결하라.
디버깅하면 내 코드가 틀릴 수 있다는 걸 염두에 두고 해야한다. 디버깅 때는 프로젝트의 압박이 있다하더라도 다음 철칙을 항상 염두에 두자!
Tip 25. 디버깅을 할 때 당황하지 마라.
뭐 때문에 버그가 생겼는지, 인과관계가 어떻게 되어있는지 생각해보는게 정말 중요하다. 버그가 터져도 ‘와 말도 안돼’, ‘버그 터질리가 없는데’ 같은 소리는 의미가 없다. 왜냐고? 진짜 터졌으니까.
디버깅할 때는 ‘근시’를 조심해야 한다. 바로 눈에 터지는 것만 없애려 하지말고 문제의 근본적인 원인을 분석해서 어떻게 터지는지 분석해야 한다. 특정 증상만 고치지 마라!
사실 버그 리포트는 정확한 과학이 못 된다… 우연히 어떻게 터졌는지 모르는 것들이기 때문이다. 자세한 사항을 보기 위해 실제 버그가 어떤 상황에 정확히 어떻게하면 터지는지를 알아야한다.
데이터를 가시화하라!
트레이싱(tracing)
고무오리
제거 과정: 내 코드가 문제냐, OS가 문제냐?
select 관련 코드였던 것이다.Tip 26. ‘select’는 망가지지 않았다.
Tip 27. 가정하지 마라. 증명하라.
버그를 고쳤다면, 이 버그가 왜 일찍 보이지 않았을까? 생각할 필요가 있다. 이 버그를 일찍 잡을 수 있도록 단위 테스트나 다른 테스트를 수정할 필요가 있는지도 고려하는 것이 좋다. 이거 비슷한 오류가 터질 코드가 있을 것 같으면 지금 같이 수정하면 된다.
위 글을 통해 디버깅 체크리스트를 책에서는 제시한다.
텍스트 처리를 위해 awk, sed같은툴이나 쉘 뿐 아니라 파이썬이나 펄도 배울 필요가 있다!
어떤걸 처리하는데는 다른 특정 언어가 더 나을 수도 있다. 다른언어들로 구현해봤을 때 얼마나 짧고 빠르게 구현할 수 있는가를 논했을 때 C가 150줄일 때 펄은 17줄이면 끝일 정도니까(책피셜)
Tip 28. 텍스트 처리 언어를 하나 익혀라.
텍스트 처리 언어의 적용범위는 상당히 넓다:
property를 파악하고 getter/setter를 만들어낼 수 있다.똑같은걸 만들 때는 템플릿을 써먹으면 된다. 잘만든 템플릿은 두고두고 써먹는다. 반복되는 작업을 통한 실수를 대폭 줄여주고 실제로 해야할 구현에만 집중할 수 있게 해준다.
코드 생성기는 그래서 중요하다. 잘 만든 코드 생성기는 프로젝트 전 기간에 그냥 거저로 써먹을 수 있다!
Tip 29. 코드를 작성하는 코드를 작성하라.
코드 생성기는 다음 두가지로 분류된다.
수동적 코드 생성기
능동적 코드 생성기: