본문 바로가기
프로그래밍 놀이터/Tips

[실용주의 프로그래머] 우연에 맡기는 프로그래밍

by 돼지왕 왕돼지 2018. 11. 3.
반응형

[실용주의 프로그래머] 우연에 맡기는 프로그래밍


accidents of context, programming by coincidence, programming deliverately, [실용주의 프로그래머] 우연에 맡기는 프로그래밍, 가정을 문서로 남겨라, 가정을 테스트하라, 가정하지 말라, 리펙토링, 문서 남기기, 문서화된 동작에만 의존하라, 우연적 맥락, 증명하라, 테스트하기 쉬운 코드를 만들어라, 확고한 사실 근거

-

일단 코딩에 들어가면 대부분 기계적으로 따라가야 하는 일, 곧 설계 내용을 컴퓨터가 실행할 수 있는 문장으로 바꾸는 일만 남는다는 생각이 일반적이다.

이런 태도가 우리 생각에는 보기 흉하고, 비효율적이고, 구조가 엉망이고, 유지보수하기 힘들고, 한마디로 완전히 잘못된 프로그램이 그렇게나 많게 된 가장 큰 원인이다.



-

적극적으로 자기 코드에 대해 생각하지 않는 프로그래머는 우연에 맡기는 프로그래밍(programming by coincidence)을 하는 것이다.



-

실용주의 프로그래머는 모든 코드를 비판적인 눈으로 바라보는데, 자기 자신의 코드도 예외가 아니다.

우리는 스스로 만든 프로그램과 설계에서 언제나 개선할 여지가 남아있음을 느낀다.



-

여러분이 코드를 작성할 때는 언젠가 그 코드를 테스트하게 될 것이라는 생각을 꼭 마음 한 구석에 두고 있어야 한다.

테스트하기 쉬운 코드를 만들어라.

그러면 실제로 그 코드를 여러분이 테스트하게 될 확률도 늘어난다.



-

우리는 우연에 맡기는 프로그래밍, 곧 행운과 어쩌다 오는 성공에 의존하는 프로그래밍을 하지 말아야 한다. 대신 의도적으로 프로그래밍(programming deliberately) 해야 한다.



-

우연적 구현(accidents of implementation)은 단순히 코드가 지금 작성된 방식이 그렇기 때문에 생기는 일들을 가리킨다.

결국에는 문서화되지 않은 에러나 입력값이 특정한 조건에서만 돌아가는 경우와 마주치게 된다.



-

지금 잘 동작하는 데 괜히 건드렸다 일을 만들 필요가 있을까? (우연히 잘 돌아가는 경우)

    정말로 제대로 돌아가는 것이 아닐지도 모른다. 우리에게만 그런 것처럼 보일 수도 있다.

    여러분이 의존하는 조건이 단지 우연인 경우도 있다. 다른 상황에서는 이상 작동할지 모른다.

    문서화되지 않은 동작은 라이브러리의 다음 릴리스에서 변경될 가능성이 있다.

    불필요한 추가 호출은 코드를 더 느리게 만든다.

    추가로 호출한 루틴 때문에 새로운 버그들이 코드에 들어올 가능성이 있다.



-

다른 사람의 루틴을 호출할 때도 문서화된 동작에만 의존하라.

무슨 이유인지 그럴 수 없는 경우가 생긴다면, 여러분의 추측을 문서로 상세히 남겨라.



-

우연적 맥락(accidents of context)

    유틸리티 모듈을 짜고 있다고 가정해보자.

    GUI 환경용 앱에서 쓰려고 모듈을 작성한다고 해도, 그 모듈을 반드시 GUI 가 있어야만 돌아가도록 만들 필요가 있을까?

    사용자의 언어가 언제나 영어일 것이라고 가정하고 있지 않은가?

    사용자가 글자를 읽을 수 있다고 생각하는가?

    확실한 것이 아닌데도 의존하고 있는 다른 것들은 어떤 것이 있을까?



-

암묵적인 가정

    Y의 원인은 X 라고 가정하기 쉽다.

    하지만 가정하지 말라. 증명하라.

    확고한 사실에 근거하지 않은 가정은 어떤 프로젝트에서든 재앙의 근원이 된다.



-

우연에 맡기는 프로그래밍을 하지 말라.



-

언제나 자기가 지금 무엇을 하고 있는지 알아야 한다.



-

맹목적으로 코딩하지 말라. 완전하게 이해하지 못한 앱을 빌드하려 하거나 익숙하지 않은 기술을 사용하려고 시도하는 행동을 피하라.



-

계획을 세우고 그것을 바탕으로 진행하라.



-

신뢰할 수 있는 것에만 기대라. 우연한 일이나 가정에 의존하지 말라. 어떤 상황에서 신뢰할 만한 것과 아닌 것을 판단하지 못하겠거든, 일단 가장 최악의 상황을 가정하라.



-

여러분의 가정을 문서로 남겨라. 다른 사람과 가정에 대해 소통하는 데 도움이 될 뿐더러, 자신의 마음속에서 가정을 명확하게 하는 데에도 도움이 된다.



-

코드만 테스트할 것이 아니라 여러분이 세운 가정도 테스트해 보아야 한다. 어떤 일이든 단지 추측만 하지 말고 실제로 시험해 보도록 하자. 가정을 시험할 수 있는 단정문을 작성한다. 가정이 맞았다면, 코드의 문서화를 개선한 셈이다. 가장이 틀렸다면, 일찍 발견했으니 운이 좋았다고 생각하라.



-

노력을 기울일 대상의 우선순위를 정하라. 중요한 것들에 먼저 시간을 투자하라. 중요한 부분이 가장 어려운 부분이기도 한 경우가 많다.



-

과거의 노예가 되지 말라. 기존 코드가 앞으로 짤 코드를 지배하도록 놓아두지 말라. 더 이상 적절한 코드가 아니라고 생각되면, 어떤 코드라도 교체할 수 있다. 한 프로그램 안에서도, 예전에 한 일이 앞으로 할 일을 제약하지 못하도록 하라. 언제나 리팩터링할 자세가 되어 있어야 한다.




반응형

댓글