심플소프트웨어를 읽고

사실 이 책을 읽은지는 좀 되었다. 다른 블로그를 할때 리뷰를 작성하긴했었는데 그걸 그대로 가져올까 하다가 오늘 이 책을 다시 읽어봐야겠다 라는 생각을 갖게한 계기가 생겨서 다시 작성하게되었다.

현재 회사에서 같은팀 소속 프론트개발자는 나를포함 총 2명이다. 나는 오늘로 입사 1년차가 되었고 동료개발자는 입사한지 2달정도된 신입사원이었다. 같은 프로젝트를 (이 사원은 중간부터 투입되었다) 진행하다가 나는 새로운 프로젝트를 맡아 진행하게되었고 동료 개발자는 하던 프로젝트를 이어가며 추가적인 요청사항에 대해서 기능추가에 대한 개발을 진행했다.

중간중간 남는시간이 있을떈 동료개발자가 내가하던 프로젝트 일부를 함께 하기도 하였다. 내가하던프로젝트는 vue + electron으로 키오스에 사용될 어플리케이션을 개발하는 일이었고 이중 하나의 페이지를 맡긴적이 있었다.

내가 만든 컴포넌트들에 대해서 설명을 해주고 간단하게 프로젝트 구조에 대해서도 브리핑을 해주고 진행을 하고 결과물을 받았다.

결론부터 말하자면 나는 그 모든 코드를 다 뜯어고치고 새로 구조화를 해야만했다. 공통으로 쓰기위해 만들어놓은 컴포넌트는 하나도 활용하지않았고 가독성은 끔찍했으며 전혀 고민하고 생각한 흔적이 보이지 않았다. 요구했던 최종 결과값만 리턴하게 해달라것도 구현되어있지않았다.

이게 불과 일주일 전이었고 코드의 수정을하면서 개선방향을 보여주었다. 그리고 일주일이 지난 오늘 신규 프로젝트를 하느라 신경쓰지못했던 이전 프로젝트에 이 사원이 작성한 코드를 보는순간 다시한번 충격을 받았다.

기존프로젝트는 React 기반으로 작성되어있는데 여기서또한 기존에 컴포넌트를 하나도 재사용하지않았고 마치 html / css / js 를 하드코딩한 비슷한 모습을한 코드를 마주할 수 있었다.

변수의 이름이나 클래스명또한 눈살을 찌푸리게했고 (검색기능의 목록을 뿌려주는 갯수를 품고있는 변수명이 perpage였다. 심지어 CamelCase도 되어있지않았다.) 따로 데이터를 객체화해 놓은 코드는 전혀 연광성이 없는 데이터들끼리 묶어놓고 사용하고있었다. 심지어 그냥봐선 알수없는 default 라는 props는 무엇인가

만약 이 사원이 퇴사하고 이 코드를 내가 수정해야하는 상황이었다면 난 여전히 전체를 다 뒤집어엎고 새롭게 짜야만 했을것이다.

서론이 길었는데 어쩃든 한숨을 푹쉬며 퇴근을 하면서 나또한 이전엔 어떻게 했을까 문득 생각이 들었고 같은팀원으로 앞으로도 쭉 (둘중에 누가 퇴사하지 않는한) 같이 일해야할 동료인데 이걸 어디서부터 어떻게 잡아가야할지 생각해보기위해 이 책을 리마인드하기위해 펼쳐보는데 가장 첫 인상깊게 봤던 문구가 있다.

뛰어난 프로그래머가 되고자 하는 마음이 있어야만 뛰어난 프로그래머가 될 수 있다. 이런 마음이 없는 사람은 아무리 훈련을 받아도 뛰어난 프로그래머가 될 수 없다.

이런 사람은 아무리 가르치고 아무리 세미나에보내도 아무 의미가 없고 나아지지 않다고 한다. 나는 나 스스로가 끊임없이 생각하고 더 나은 코드 내가 더 나은 프로그래머가 되기위해 노력한다고 생각한다.

내가 그렇듯 이 동료또한 그런마음을 꼭 안에 품고있었으면 좋겠다. 정말이지 그냥 잘 돌아가기만 하면된다는 식의 코드였고 협업이나 다른 개발자가 유지보수하게될 경우에 대한건 안중에도 없어보이는 코드였다.

두 문장으로 요약한 소프트웨어 설계

1. 구현에드는 수고보다 유지보수에 드는 수고를 줄이는게 더 중요하다.
2. 유지 보수에 드는 수고는 시스템의 복잡성에 비례한다.

물론 나 또한 완벽하지 못한 인간으로 내가 무조건 맞다 라고 생각하지는 않는다 그 코드를 짜면서도 분명 생각을 했을거고 고민을했을거고 시행착오를 통해 만들어졌을리라 생각한다.

그래서 더욱 더 두 문장이 와닿는다. 그 사원이 구현한 기능들도 몇가지 버그를 제외하고는 동작에 전혀 문제가 없다. 심지어 동작 테스트를 거친 후 실제운영서버에 올라가기까지 했다.

하지만 나중에 유지보수에도 문제가없을까? 다른 개발자가 보기에도 유지보수하기 쉬워보일까 아니면 관련 소스코드를 다 뒤져야지만 이해하고 작업을 진행 할 수 있을까?

친절과 코드

이 부분은 나 스스로가 좀 찔리는 부분이기도 하다. 다행히 여기서 말하는 상대를 공격하면서 말하지는 않았고 코드에 대해서만 얘기를 했다는점이고 불행인점은 공격성을 띄는 말투로 얘기를 한것이다.

함께 일하는 사람에게 무례하게 굴어서 좋을게 없다. 다른이에게 틀렸다고 일을 그렇게 하면 안된다고 화를 내도 좋을 게 없다. 소프트웨어 설계 법칙이 적용되었는지 확인하고 가독성과 유지 보수를 고려해서 이해하기 쉬운 시스템을 만들 수 있도록 좋은 길로 가자고 권고하는 건 도움이 된다.

개발자말고 코드에 대해 이야기하는게 중요하다.

맞다 나는 오늘 감정 조절을 제대로 하지못했고 무례했다. 이점은 앞으로 내가 바꿔나가야할 방향이다. 나 또한 완벽하지않고 실수 할 수 있으며 지적 받을 수 있고 내 코드를 보고 다른 개발자 또한 화가나거나 답답한 상황이 충분히 올 수 있다는걸 항상 고려하고 함께 일하는 동료 개발자에게 무례하게 굴거나 굳이 공격적인 태도를 보일 필요가 없다 라는걸 이 책을 통해 다시금 다짐하게 된다.

리뷰

위의 내용 외에도 디버깅, 생산성 측정, 리팩토링, 테스트주도 개발, 보안 등 프로그래밍 이라는 분야에 몸 담고 있다면 한번쯤은 생각해봐야할 내용들이 담겨있고 책을 보는 독자가 필드에있는 개발자인지 관리자급인지 혹은 개발자 출신의 경영자, 리더, 팀장 인지에 따라서도 충분히 공감하고 이해 할 수 있는 내용들로 담겨져있다.

아직은 난 이 분야에 들어온지도 얼마 안되었고 팀장이나 리더의 자리에 있지도않다. 그래서 이 책을 읽는 방법은 내가 눈이 가고 관심이 가는챕터를 우선적으로 읽고 또 현업하다가 혹은 진급해서 내가 관리자급이 되었을때도 다시한번 되새기며 읽어보고 곱씹어보며 프로그래머로써 살아간다면 평생이고 두고두고 봐야만하는 책이 아닐까 싶다.

아마 다음에 이 책을 다시 볼때에는 다른 챕터에 대한 느낀점 그리고 실제 내가 겪었던 사례들이 좀더 생기지 않을까 싶다.