기차니즘 초절정 고수 일탈을 꿈꾸며... - 스팟

개발이라는 말을 코딩이라는 말의 동의어 쯤이라고 생각해서는 안된다. 왜냐하면 개발은 코딩만을 잘한다고 성공할 수 없기 때문이다. 혼자서 북치고 장구치고 하는 정도의 프로젝트 규모라면 이 책이 와닿지도 않을 뿐더러 지루하기까지 하다.

이 책은 코드개발이 거의 끝나고 막 오픈하려는 시점부터 나올법한 문제점을 저자의 실전경험을 바탕으로 써놓았다. 아무리 잘 짠 코드라도 장애한번 나지 않은 역사가 짧은 코드라면 그 코드에 문제가 없다고 장담할 수 없다. 사람이란 실수하게 마련이고 그 실수가 코드에 반영되기 때문이다. 사람의 실수을 줄이더라도 기계적인 실수도 있다. 가령 이벤트가 갑자기 잘 되서 웹사이트에 찾아오는 손님이 많다고 했을경우, 코드는 완전무결하다고 해도 네트워크의 트래픽이나 하드웨어의 CPU, 메모리, 하드디스크가 완전무결하다고 할 수 없다. 심시어 전원이 꺼질수도 있지 않은가.

코드를 말할 때 설계를 중시한다. 디자인 패턴이나 리팩토링이 잘된 설계를 유지하도록 권하는 안내서이라면 이 책은 꼭 해야될 것과 하지 말하야 할것을 말한다.

내 경험에 비춰보면 로그는 꼭 잘 남기는게 좋다. 일단 아예 없다면 문제를 해결할 수 있는 실마리를 찾기 힘드니 지금이라도 로그를 남길 수 있도록 프로그램을 개조하자. 이제 로그를 잘 남기기 시작했다면 사람의 눈에 잘 들어오도록 조정하자. 로그는 사람이 보는 것이다. 한눈에 판단할 수 있도록 코드의 컨벤션을 지키듯이 로그도 그래야 한다. 수준을 정하자. 디버그를 위해 코드에 남겨뒀던 로그를 삭제하는 짓은 미련하다. 한 번 문제가 생겼던 부분은 자주 문제가 생기기 때문에 수준(level)에 따라 조정할 수 있게 하는게 현명한 일이다.

이책에 나오는 것중에 또 공감되는 내용은 '고장을 내라?'이다. 어느 웹 사이트에 접속했는데 화면레이아웃이 다 깨지고 정신없는 스크립트 에러가 나는 원인은 수많은 기능중에 단 한가지 때문인 경우가 많다. 연동된 시스템이 죽을 수도 있고, 개발자의 실수로 오타가 삽입될수 있다. 이런 경우 고장난 기능을 다시 부르지 않도록 빨리 고장을 전체 시스템에 알릴 수 있도록 방어하는 기술이 필요하다. 고장난 부분을 계속 부르게 되면 고장은 더 심각해지고 복구도 어렵다. 때문에 고장난 부분은 고장났으니 다시 부르지 않도록 고장났음을 표시하는게 오히려 서비스를 받는 입장에서 좋다.

경험은 무엇보다 소중은 자산이다. 이런 경험을 책을 통해서 얻을 수 있다면, 쉽게 말해 밤샘을 회필할 수 있는 가능성이 높아진다고 할 수 있겠다.



덧1)
이 책은 트랙백 이벤트에 당첨되서 위키북스에서 제공해주신 책입니다. 잘 읽었습니다.

좋은 책이다. 실천도서이기 때문에 실천하는게 중요할 것이다. 다만, '실용주의 프로그래머'라는 책을 읽은 사람은 패스~~

소프트웨어라는게 개발만하면 끝이 될 수 없다. 생명력은 사람이 계속불어넣어야 굴러간다. 기름칠도 해주고 고장나면 고쳐주고하는 품이 들어가게 마련이다. 이런 사실을 망각한 개발자들이 하는 말이 '이번 개발만 끝나면 해방이다.'이다. 하지만, 개발이 끝나도 계속되는 버그 수정과 기능 개선이 다가온다.

이런 품이 꼭 있기에 효율성이 개발과정이나 유지보수 기간에 필요하다. 그런 효율성을 높일 수 있는 학습의 기회가 찾아왔다.

http://www.talk-with-hani.com/archives/706 => 이벤트 참여하라.