베테랑 소프트웨어 개발자인 조엘 스폴스키의 블로그의 글을 정리한 '조엘 온 소프트웨어, 유쾌한 오프라인 블로그'를 읽고 내용 & 개인적으로 느낀점들을 정리해 본 포스트입니다.
1. 기본으로 돌아가기
책에서는 C언어 학습을 건물의 기초공사에 비유한다.
문자열 처리나 메모리 관리와 같은 복잡한 부분을 알아서 처리해주는 최근 언어(JAVA, C++, Python등)들과 달리, 개발자가 직접 관리해야 하는 C언어는 컴퓨터가 이러한 부분에서 어떻게 동작하는지를 이해해야 하기 때문이다.
옛날에는 개발을 공부한다고 하면 무조건 C언어부터 배우라는 조언을 많이 들었는데(유명한 '열혈 C프로그래밍'과 함께..) 요즘은 자바나 파이썬을 배우라고 하는 빈도도 늘어난 것 같다.
그런데 조엘이 지적하는 것은 이런 소위 '편한' 언어로만 개발을 하게 되면 기초가 닦이지 않아 잘못된 코드를 작성하고도 인식하지 못하게 된다는 점이다.
개인적으로도 비전공자에 파이썬으로 개발을 시작했는데 전공자들에 비해 세세한 부분(메모리 관리나 기초적인 전산지식)에서 생각지도 못한 에러에 대처하는 방법에서 부족하다는 점을 뼈저리게 느끼고 있다.
2. 유니코드와 문자 집합에 대한 고찰
예전의 웹사이트들을 보면 어떤 외국 사이트에서는 문자가 전부 깨져보이는 현상이 종종 있었다.
이는 문자 인코딩과 관련된 문제로, ASCII로 인코딩된 문자는 가능한 조합이 많은 아시아 문자와의 상성이 최악이어서 표기가 제대로 되지 않는 경우도 많았다.
다행히 유니코드가 거의 표준화되다시피 하면서 이런 문제는 줄었지만, 개발자 입장에서는 문자열이 있으면 이것이 어떤 식으로 인코딩되어 있는지 알아야 한다.
근무하고 있는 회사에서도 문자열 인코딩은 무조건 utf-8 방식으로만 하도록 해놨는데, 처음에는 이것이 무엇을 뜻하는지 잘 몰랐지만 이유가 있음을 알게 되었다.
3. 명세서 작성
명세서 작성은 반드시 필요한 일이지만 작성하기를 좋아하는 사람은 많지 않다.
명세서를 쓰느니 코드를 바로 작성하는게 시간 단축에 도움이 된다고 생각할 수도 있다.
하지만 이렇게 생각해 보면 어떨까?
명세서의 글의 무게는 코드의 무게보다 가볍다.
명세서의 내용을 수정하기는 쉽지만, 코드를 수정하게 되면 더 오랜 시간이 걸린다. (특히 개발자는 자기 코드를 지우는 것에 민감하다)
또한 명세서를 통해 의사소통에 필요한 시간을 줄일 수 있다.
명세서가 없으면 기능이 어떻게 동작해야 하는지, 무엇을 테스트해야 하는지 일일이 물어봐야 하지만, 명세서가 있으면 이를 읽기만 하면 개발자는 무엇을 해야 하는지 바로 알 수 있다.
마지막으로 명세서가 없으면 일정을 예측할 수 없다.
돈이 썩어나지 않는 이상 제품을 만들려면 투자를 받아야 하고, 언제 개발될지도 모르는 제품이 투자할 사람은 없을 것이다.
명세를 통해 비용과 기간을 예측할 수 있다.
비록 문과출신이지만 개발을 하다보면 문서 작성하는 일이 무거운 짐처럼 느껴질 때가 있다.
분명 필요한 일인 것은 아는데 어쩐지 손이 가지 않는다고 해야 할까.
그나마 양식이 있을 때는 다행인데, 백지에서 시작하려고 하면 두려움이 엄습해온다.
그러면 조엘이 제시한, 명세서를 작성할 때의 팁을 한 번 보자.
-
재미있게 쓰기
딱딱한 글보다는 노잼이라도 즐겁게 하려는 의도가 보이는 글이 눈에 더 들어온다.
한국의 회사 분위기(대기업이라면 더더욱..)에서는 어려울 수 있겠지만 시도는 해보고 싶다. -
이해하기 쉽게 쓰기
명세서를 작성하다보면 기술적으로'만' 올바르게 작성하게 되는 경향이 있는 것 같다.
그래서 이해하기 어렵고 해석이 필요한 명세서가 나오게 된다.
명세서를 작성할 때는 읽는 사람의 수준을 감안하여 그 사람이 이해할 수 있을지를 생각해야 한다. -
단순하게 쓰기
쉬운 문장으로 써야 더 잘 읽힌다. 괜히 어려운 단어, 긴 문장을 사용하면 사람들은 잘 읽으려 하지 않는다.
또, 글만 있는 것보다 이미지 등을 사용하는 것이 좋으므로 실제 화면을 캡처해서 보여주는 것을 추천한다. -
검토하기
명세를 검토하고 여러 번 읽어본다. 이해되지 않는 문장이 있다면 고친다. -
표준양식은 해롭다
표준양식이 있으면 좋아보이지만(위의 나처럼) 매번 기능마다 중요하다고 생각하는 사항을 보충하기 위해 표준양식에 절을 추가해야 하는 수고를 해야 한다.
4. 버그 수정
모든 버그는 수정해야 마땅할까?
버그 수정은, 수정한 버그의 가치가 수정 비용을 넘어설 때 유효하다.
그러면 수정할 가치가 있는 버그를 찾아내는 방법에 대해 알아보자.
우선 찾아낸 버그를 모두 확인해야 한다.
직접 실행해가며 버그를 찾아낼 수도 있고, 자동으로 버그를 수집하는 시스템을 통해 버그가 발생하면 이를 보고하도록 할 수도 있다.
그러면 버그 수정에 드는 비용을 계산해야 하는데, 정확하게 파악하기는 쉽지 않지만 기술지원에 드는 경비(인건비 등)를 통해 비용을 추산해볼 수 있다.
비용을 계산했다면 버그 수정을 통한 이익이 얼마인지를 통해 버그를 수정해야 할지를 파악할 수 있다.
5. 쏘면서 움직여라
운동을 할 때 가장 어려운 것은 헬스장에 가는 것이다.
그래서 사람들은 '뇌를 비우고 일단 가라'는 조언을 해 준다.
코드를 작성하는 것도 이와 비슷한 것 같다.
에디터를 켜고 키보드에 손을 대기까지 많은 시간이 걸릴 때가 있다.
이거는 어떻게 하고 저거는 어떻게 하지 고민하다 보면 한줄도 작성하지 못하는 경우도 있다.
엉망인 코드라도 매일매일 조금씩 쓰고, 버그를 지속적으로 잡아낸다면 결국은 좋은 코드가 된다.
