실용주의 프로그래머 15 - 21

15. 조개 놀이

명령어 셸(Shell)의 힘을 사용하라

15장인 조개 놀이는 명령어 셸 에 대한 내용을 다루고 있다.

GUI 인터페이스는 사용하기 훨씬 편리하지만, 책에서 나오는 것처럼 설계자의 의도에 다른 제약이 있다.

명령어 프롬프트에서 작업한다면 자신이 원하는 기능을 결합하여 만들어 사용할 수 있으니, 셸을 잘 다루도록 하자.

+) 아무리 셸(Shell)이라지만, 장 이름이 조개 놀이라니 번역이 문제인지, 저자의 유머감각인지, 원래 그렇게 부르는데 나만 모르는 건지 잠깐 고민했다.

 

16. 파워 에디팅

하나의 에디터를 잘 사용하라

에디터 하나를 골라서 완전히 마스터하여 사용해야 한다고 조언한다.

난 안드로이드 개발로 IDE는 안드로이드 스튜디오를 사용하기 때문에

다른 IDE를 사용하더라도 확실히 JetBrains 라인의 에디터를 사용하는 것이 훨씬 익숙하다.

특히 커서 이동, 편집, 정렬 등 단축키를 잘 다룬다면 훨씬 개발 속도도 빨라진다.

 

안드로이드 처럼 개발하는 플랫폼이나 언어에 따라 주된 에디터가 있는 것도 있지만,

여러 에디터 중 고민이 된다면 책에서 자신의 상황에 맞게 에디터를 선택하는 팁을 안내하고 있으니 참고하면 좋을 것 겉다.

(특히 파이썬 에디터 고르기가 좀 힘든 것 같은...)

 

17. 소스코드 관리

언제나 소스코드 관리 시스템을 사용하라

소스코드 관리 시스템 혹은 더 넓은 의미의 형상 관리 시스템은 소스 코드나 문서 관련의 모든 변화를 기억한다.

그래서 실수가 생겨도 되돌릴 수 있고, 변경 사항에 대한 정보를 얻을 수 있기때문에 버그 추적, 퍼포먼스, 품질 관리 목적으로 유용하다.

그러니까 SCCS를 잘 사용하도록 하자.

 

+) 사실 개발을 시작할 때 git부터 배우고 시작하기 때문에 다들 잘 쓰고 있는 듯하다.

+) 팀에서 SCCS을 쓰지 않는다면 복음 전도를 할 기회라고 하는데...여기서 저자가 책을 재밌게 쓰고자 굉장히 노력하고 있다는 것을 깨달았다.

 

18. 디버깅

비난 대신 문제를 해결하라.

"버그가 여러분의 잘못인지 다른 사람의 잘못인지는 그리 중요한 게 아니다. "

정말 와닿았던 문구.

요새 개발 자체를 떠나 개발 문화에도 관심을 갖게 됐는데, 장애 블레임 하는거 정말 별로다.

담당자를 확인하는 이유는 원인 파악이 중요하고 다시 발생하지 않도록 하기 위함이지,

잘못을 탓하는 것은 팀에 별로 도움이 안되는 것 같다.

(특히 나같은 개복치 신입은 한번 당하면 트라우마가 생길거다 분명...)

디버깅을 할 때 당황하지 마라.

버그가 발생하면 "이게 왜...?"라는 생각이 드는데

결국 책에서 나온 것처럼 그런 일은 일어날 수 있으며, 실제로도 일어난 일이다.

 

그리고 디버깅을 할 때는 근시를 조심하라.

근본적인 원인을 파악하고, 그 문제의 증상만 고치려고 하지 말자.

'select'는 망가지지 않았다.

나는 OS 탓을 좀 많이 해서 'select'가 잘못 됐다는 엔지니어가 좀 공감 간다.

하지만 OS문제가 아니고 OS 버전 업데이트에 따라 기능이 달라져서 버그가 생기는 경우다. (Android 12 많이 힘들었다...)

갸정하지마라. 증명하라.

테스트가 정말 중요한데, 잘 작동한다고 그냥 넘어가지말고 테스트 조건을 철저하게 확인해야한다.

안드로이드로 치면 테스트 기기, OS 버전, 현재 설정, USIM 유무, 네트워크 유무 등 다양한 환경에 따라 결과가 달라질 수 있다. (경험담)

 

+) 최초의 버그는 진짜 나방.
기술자 한 사람은 보고 후, 날개를 비롯해 전체를 업무일지에 테이프에 붙였다고 한다는 내용이 자꾸 아른거린다.

 

19. 텍스트 처리

텍스트 처리 언어를 하나 익혀라

음 익히도록 합시다. 끝!

 

20. 코드 생성기

코드를 작성하는 코드를 작성하라

같은 코드를 여러 곳에서 반복해야할 때 코드를 생성하는 코드를 작성할 수 있다.

코드 생성기는 한번만 실행하고 결과물이 독립적인 수동적 코드 생성기와 코드 생성이 필요할 때마다 작동하는 능동적 코드 생성기가 있다.

코드 생성기는 꼭 복잡할 필요는 없으며, 가능하다면 잘 작성된 라이브러리를 사용하는 것도 좋을 것 같다.

 

21. 계약에 의한 설계

계약에 따른 설계를 하라

계약에 의한 설계(Design By Contract, DBC)란 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈들의 권리와 책임을 문서화하는 데에 초점을 맞춘다. DBC에는 다음 내용이 들어간다.

• 선행조건: 루틴이 호출되기 위해 참이어야 하는 것.
• 후행조건: 루틴이 자기가 할 것이라고 보장하는 것.
• 클래스 불변식: 호출자의 입장에서 볼 때는 이 조건이 언제나 참이라는 것을 클래스가 보장한다.

DBC를 사용하는 장점은 요구사항과 보증의 문제를 전면으로 내세운다는 것이다. 입력 도메인 범위, 경계 조건, 루틴의 동작 등을 설계 시기에 나열하는 것만으로도 더 나은 소프트웨어 작성에 도움이 된다.

DBC에 대한 내용은 이해가 잘 되지 않고, 내용이 크게 와닿지 않았다. (일단 길고 재미가 없다.) 일단 DBC의 세가지 요소에 집중해서 기억하고, 나중에 다시 한번 읽어봐야할 것 같다.