실용주의 프로그래머
실속 있고 유연한 소프트웨어를 만들기 위해 어떤 프로그래머가 되어야 할까?
껍데기만 화려한 소프트웨어가 아니라 실속 있고 유연하며 정말 사용자를 기쁘게 하는 소프트웨어를 만들고 싶은가? 그렇다면 이 책이 안성맞춤일 것이다.
책을 읽으면서 이미 내가 알게 모르게 하던 방법들에 대해서는 선명도를 높일 수 있었고 심적 지지 또한 얻을 수 있었다. 몰랐던 방법들에 대해서는 당연하게도 새로운 시야를 얻을 수 있는 기회가 되었다.
소개된 많은 방법들 중 감명 깊었던 몇 개를 소개하고 느낀 바를 적어보려고 한다.
깨진 창문을 고치지 않은 채로 내버려 두지 말라
마을에서 오랜 기간 수리되지 않은 깨진 창문 하나는 어떤 이에겐 마을이 버려졌다는 느낌을 들게 한다. 곧이어 깨진 창문뿐만 아니라 벽에 낙서까지 등장한다. 이러한 현상은 전염병처럼 마을 전체로 퍼져나간다.
심리학자들은 절망감이 전염된다는 연구를 발표했다. 깨진 창문으로 인해 느껴지는 절망감이 사람들을 전염시켜 다른 것들까지 망가트릴 수 있다는 것이다.
이처럼 깨진 창문은 내버려두면 안된다. 나쁜 설계와 잘못된 결정, 형편없는 코드까지 모두 깨진 창문이다. 발견하자마자 바로 고쳐야 한다. 시간이 없다면? 가령 주석이라도 달아놓는 등 응급조치라도 해두어야 한다.
이 방법은 하루에도 몇 번씩 적용하곤 한다. 설령 다른 사람의 코드더라도 즉시 논의한 다음, 더 좋은 방향으로 고쳐나가고 있다. 꽤나 부담되는 작업이라면 팀 회의에서 언급이라도 해서 되도록이면 일정을 잡고 있고 그것도 힘들다면 백로그로 쌓아두고 있다.
변화의 촉매가 되어라
어떤 조직이든 크고 작은 변화가 필요한 순간은 항상 있다. 이 때 누군가는 보수적일 수 있다. 이 때 작게라도 잘 개발해서 반복적으로 보여주고 경탄하게 만들어라. 계속해서 성공하는 미래를 살짝씩 보여주는 것이다. 그리고 이 성공이 그다지 별 것 아닌 척 가장해라. 그러면 사람들은 이걸 도와주기 위해 기꺼이 모여들 것이다.
'우리 개발팀에서 이걸 해보면 정말 좋을텐데..!'라는 생각을 자주 한다. 이것에 대해 팀원들과 얘기하다보면 누군가는 낙관적인 반면 당연하게도 누군가는 비관적이기 마련이다. 어떻게 비관적인 팀원들을 설득할 수 있을까?
이 때 책에서 말하는 방법을 적용해보면 좋을 것 같다. 일단 작게 성공해서 보여주는 것이다. 말로만 떠들곤 했는데, 이렇게 작게라도 근사하게 성공 가능성을 보여주면 그걸 버리기보단 발전하는 방향으로 논의가 되지 않을까 싶다.
사용자를 기쁘게 하라
개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다.
어떤 기술을 사용했는지나 어떤 언어를 사용했는지와 같은 소프트웨어 자체가 아니라, 절감한 비용이나 고객 잔존율 혹은 늘어난 MAU와 같은 프로젝트의 성공 척도가 진짜로 의미 있는 사업 가치이다.
요즘 반성을 많이 하게 만드는 대목이다. 뒤쳐지지 않을까? 과연 나는 성장하고 있는 것이 맞을까?라는 의문에 여러 기술에 집착하게 되는 것 같다. 이 부분에서 감명을 받은 후인 지금도 그러고 있다. 본질적으로 사용자에게 도움이 되는지 항상 의식하며 개발을 해야겠다.
나는 개발자임에도 불구하고 개발 서적 1권을 끝까지 읽은 적이 없다. 참으로 부끄러운 일이다.
정말 고마운 회사 동료분의 추천을 받아 참여한 스터디 덕분에 정독할 수 있었다. 같이 학습하는 것의 가치를 다시금 느끼게 되었다.
어쨋든, 이 책은 거시적인 관점 말고도 문서화, 테스트 코드, 유한 상태 기계와 같은 패턴, 실용적인 개발 도구(IDE, 버전 관리, 단축키 등), 개발 방법론, 협업 등 실용적인 개발과 관련된 내용을 광범위하게 다룬다.
종종 이해하기 어려운 부분이 나오기도 한다. 아예 몰랐던 부분도 있었고, 엘릭서나 루비 등 나에게 생소한 언어로 예시를 든 부분도 있었다. 그래서 사진처럼 밑줄을 그어가면서 이해하려고 하거나 답답함에 의문점을 적어두곤 했었던 것 같다.
여담으로, 2판을 기준으로 얘기하자면 중간에 슬랙이 언급되는 만큼 꽤나 최근에 다시 쓰여진 책이다. 혹시나 너무 오래된 내용을 담고 있진 않을까라는 걱정을 덜 수 있었다.