실무자의 경험이 많이 담겨있는 책이라 학부생 위치에서 이해하기 어려운 부분도 있었다. 하지만 서비스 기획팀과 개발자 간의 소통 부재로 인한 문제 상황, 면접관 관점에서의 면접 등 알기 어려운 부분을 알게 되었다.
소프트웨어 장인
흥분을 감추지 못하고 나무르의 사무실로 가서 “다 끝냈습니다. 동작도 합니다.”라고 외치자, 그는 타이핑을 멈추고 나를 돌아봤다. “코딩이 직업인 사람이 동작하는 코드를 만드는 건 기본이에요.” 그는 조용히 말했다. “일을 끝냈다는 말에는 제대로 동작한다는 것이 당연히 포함되어 있죠.” 시비를 거는 말투였다.
“여기 앉아서 작업한 코드를 같이 봅시다.” 나무르 옆에 앉았다. 내가 작성한 코드는 200줄 남짓이었다. 나무르는 첫 번째 라인으로 커서를 옮기고 한 줄 한 줄 보기 시작했다. 다섯 줄마다 잠시 멈춰서 “여기서 메모리 할당/해제를 하면 무슨 일이 일어나는지 알고 있나요? 이 부분을 보세요. 한 메서드에서 메모리를 할당하고 다른 메서드에서 해제하고 있어요. 이런 코드는 잠재적으로 메모리 릭을 일으켜요. 여기 이 코드들을 보세요. 좀 더 생각해 보면 이 여덟 줄은 두 줄로 줄일 수 있어요. 이 변수와 메서드의 이름은 적절해요? 원래 의도한 의미가 뭐죠? 다른 동료가 이 코드를 수정할 일이 생기면 어떻게 될까요? 정보도 부족하고 이 코드가 작성된 맥락을 전혀 알 수가 없어요. 여기에 하드 코딩된 비트들은 뭐죠? ··· (중략)” 그는 계속 말을 이어갔다.
1990년대에는 다른 사람이 알아볼 수 없는 난해한 코드를 짤 수 있는 사람이 실력있는 개발자로 통했다. 나 역시 내가 얼마나 똑똑한지 보이려고 난해한 코드들을 조금 집어넣었다. 나무르는 그 코드가 무엇을 하는지 알아냈다. 나는 내 기분을 띄워줄 말을 기대했다. “이 코드가 얼마나 무례한지 알고 있습니까?” 그는 조용히 말했다. “모든 개발자들이 이런 식으로 으스대려고 난해한 코드를 만들면 코드를 이해하기가 얼마나 어려워질지 생각해봤나요?” 그의 말은 이제 시비가 아니라 공격이었다.
부분적인 애자일 전환
똑같은 습관을 가진 사람들이 갑자기 멋진 소프트웨어를 만들기 시작할 것이라 믿는다. “코딩은 쉽다. 코딩은 그냥 지엽적인 세부 사항일 뿐이다. 우리는 더 나은 절차만 있으면 된다.” 불행하게도 결코 그렇지 않다.
기술적 탁월함보다 절차가 더 중요해지면서 애자일의 배경이 되는 기본 원칙이 잊혀졌다. 애자일의 모든 절차에는 기술적 탁월함이 전제되어 있다.
스크럼을 도입하고, 스탠딩업 미팅을 하고, 백로그 관리툴을 사용하는 것만으로 갑자기 소프트웨어의 품질이 더 좋아지거나 개발자들의 역량이 높아질 수는 없다. 기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미하다.
실행을 넘어선 장인정신으로
동작하는 소프트웨어라고 해서 잘 만들어진 애플리케이션이라고 할 수 있을까? 좋은 소프트웨어라면 그 애플리케이션이 얼마나 오래되었든 간에 개발자가 쉽게 이해할 수 있어야 한다.
높은 커버리지에 신뢰할 수 있는 테스트가 가능해야 하고, 명료하고 단순한 디자인과 비즈니스 용어로 잘 기술된 코드여야 한다. 소스 코드는 예측가능하고 유지보수될 수 있는 상태여야 한다. 수정 자체가 두려운 상황에 처하지 않도록 해야 한다. 애플리케이션이 진화하려면 개발자들이 애플리케이션을 수정하는 일을 부담스러워해서는 안 된다.
내 커리어의 주인은 누구인가
고객을 만족시키기 위한 투자는 스스로 해야 한다. 그러한 투자를 하지 않으면 고객을 만족시키기 못해 평판이 나빠지고 시장에서 퇴출되는 수순을 밟는다.
자신이 일하는 회사가 새 지식을 가르쳐 주길 기대한다면 이는 프로페셔널 소프트웨어 개발자가 아니다. 개발자로 가장한 공장 노동자일 뿐이다.
자기계발을 위한 블로그
다른 사람들이 그 기록에 대해서 어떻게 생각할지 너무 걱정할 필요는 없다. 나 자신을 위한 기록이 가장 우선이다. 현재 배우는 것이 무엇이든 글로 써서 기록을 남기는 것은 가치가 있다.
정원 돌보기
코드는 기계장치라기보다는 유기물이다. 코드는 정원처럼 지속적인 유지보수가 필요하다. 짧은 기간이라도 돌보기를 게을리하면 다시 아름답게 가꾸는 데 훨씬 더 많은 노력을 해야 한다. 오래 방치할수록 다시 보고 즐길 수 있는 상태로 되돌리는 데 더 많은 수고가 필요하다.
우리는 올바른 것을 하길 원한다
소프트웨어 개발자의 삶에 있어 압박은 피할 수 없다. 우리는 압박을 받는다고 느낄 때 중심을 잃고 고만고만해진다. 게으른 탓이 아니다. 더 빨리 해야 한다고 느끼기 때문에 그렇게 한다.
내겐 없는 여유, 다른 누군가에겐 있는 여유
QA 전담 팀은 지양해야 할 안티패턴이다. 테스터는 아무런 문제도 발견할 수 없어야 한다. 테스터가 버그를 발견하는 것은 개발자로서 대단히 수치스러운 일이다.
단위 테스트 작성은 별개의 업무인가
단위 테스트는 우리가 코드를 작성하는 방식에 이미 녹아있는 것이지 별도의 작업이 아니다. 테스트하지 않았다면 코드 작성을 완료했다고 할 수 없다. 기능 구현이 완료되었다고 할 수 있으려면 반드시 테스트까지 되어야 한다.
자신이 짠 코드는 어떻게 동작하는지 잘 알고 있고 문제가 없을 터이니 테스트 코드를 따로 안 만들어도 된다고 주장하는 개발자는 대단히 자기중심적이고 이기적인 사람이다. 소프트웨어 프로젝트는 팀워크다. 특정 개발자 한 사람을 위한 것이 아니다.
잘못된 방향으로 동기 부여하기
잘못된 테스트는 아예 테스트가 없는 것보다 못하다. 거꾸로 끼워 맞춘 그 테스트들은 비즈니스 맥락을 전혀 모르는 외부 개발자들이 자기 마음대로 이해한 수준에서 검증되었다.
우리는 교훈 하나를 얻었다. 사람들에게 새로운 절차나 새로운 실행 관례를 강제한다고 해서 조직을 변화시킬 수 없으며 우리는 배움의 문화를 만들어 내야 한다. 사람들 스스로 모든 것을 더 나아지게 하고싶어 하는 동기를 부여할 수 있어야 한다.
비범함과 평범함
비범한 개발자는 요구사항을 충족하는 가장 단순한 코드를 만들어 경험이 적은 개발자가 이해하는 데 아무런 문제가 없도록 한다. 문제를 단순하고 우아한 방법으로 해결하는 것은, 복잡하고 과잉된 방법으로 해결하기보다 훨씬 어렵다.
