http://www.yes24.com/Product/Goods/64586851 레거시 코드 활용 전략 - YES24 시스템 내에 오래된 코드를 다루는 방법을 배울 수 있다. 오래된 코드, 즉 레거시 코드는 그 코드에 익숙한 사람도 없고, 테스트 루틴도 없어 관리하기 어렵다. 저자는 다년간의 현장 경험과 실 www.yes24.com 코드 레벨에 대한 설명이 많아 이는 생략하고 보편적인 가치 위주로 정리합니다. (😛) 은 사견입니다. 레거시 코드 저자가 생각하는 레거시 코드란 단순히 테스트 루틴이 없는 코드다. 다만 이 정의는 다소 불완전하다. 테스트 루틴이 없는 코드는 나쁜코드다. 코드가 얼마나 훌륭하게 작성돼 있는지는 상관없다. 아무리 깔끔하고 객체 지향적이며 캡슐화가 잘돼 있어도 소용없다. 테스트 루틴..

비욘세 규칙과 BDD 구글의 소프트웨어 엔지니어링이라는 책을 읽다보면 비욘세 규칙이라는 말이 나옵니다. 비욘세의 노래 Single ladies 중 가사 Cause if you like it, then you shoulda put a ring on it (네가 나를 좋았다면 프로포즈를 해줫어야지) 라는 내용에서 기인한 규칙이라는데요. 이걸 테스트 코드 작성과 연결해서 생각한다고 합니다. 구글에서 말하는 비욘세 규칙은 "필요했으면 테스트 했었어야지" 정도로 의역할 수 있을 것 같습니다. 책에서는 비욘세 규칙을 설명하면서 구글의 인프라 팀이 이 규칙을 활용해서 얻을 수 있었던 장점에대해 이야기합니다. 보통 인프라팀은 사내에 있는 대부분의 코드 베이스와 연관되어있고 긴밀한 협력관계에 있는 팀입니다. 따라서 인프..

회사에서 테스트 코드 전환을 시작한지 두 달 정도가 지난 것 같습니다. 연말이기도하고 짧은 기간동안 프로젝트가 어떤 변화를 거쳤고, 어떻게 발전해가고 있는지 정리하면 좋을 것 같아서 글을 남깁니다. 두 달간의 회고 테스트 코드 전환은 생각했던 것보다 순항 중이라고 생각합니다. 사내에 테스트 코드를 넣기 시작한 계기와 필요성을 어필할 수 있었던 자리가 있었는데, 대부분 긍정적으로 봐주셔서 너무 감사했습니다. 덕분에 작업하면서 올바른 방향으로 프로젝트가 발전하고 있다고 확신하고 작업할 수 있었던 것 같습니다. https://kok202.tistory.com/335 스프링 테스트 코드 전환기 근황1 (0/0) 발표 자료 https://kok202.tistory.com/331?category=979769 테스트..

https://kok202.tistory.com/331?category=979769 테스트 코드 전환기 시작 (1/3): 테스트가 필요하다 느꼈다. 트로이 목마 트로이 목마에 당했습니다. 실제 데스크탑이 트로이 목마 바이러스에 걸렸다는 의미는 아닙니다. 테스트 문화를 전파하는 너무나 강력한 트로이 목마에 걸렸습니다. 올해 초의 일 kok202.tistory.com 테스트 코드 전환을 하겠다고 말한지 두달 정도가 지났는데, 현재 상황은 어떻고 어떤식으로 진행되고있는지 글을 쓰려합니다. 그 전에 테스트 관련 공부를 하면서 느꼈던 점과, 왜 이런 프로젝트를 진행하고 있는지 회사 동료분들께 소개시켜드리고자 발표를 한번 한적이 있는데요. 이때 발표하면서 쓰였던 자료를 올려봅니다. * 파트내에 공유하는 목적으로 만..

테스트 작성의 어려움 방향도 정했겠다. 단위 테스트는 어떻게 늘려가면 좋을까요? 진짜 간략하게 현재 프로젝트 코드에 대해 설명드리자면 아래와 같이 작성되어 있었습니다. @Service public class ServiceA { @Autowired private RepositoryA repositoryA; @Autowired private RepositoryB repositoryB; @Autowired private RepositoryC repositoryC; public void functionA () { A a = repositoryA.find(); B b = repositoryB.find(); C c = repositoryC.find(); // 정말 간단한 비즈니스 로직 repositoryA.save..

구글에서 말하는 테스트 책이 워낙 방대하니 책에서 말하는 테스트가 필요한 이유를 요약하겠습니다. 요점은 시스템이 확장하는데 테스트가 없다면 수정이 자유롭지 못하게 된다는 것입니다. 테스트 코드가 없다면 이 코드가 어디까지 영향을 줄지 예측할 수 없기 때문에, 개발자들은 코드 한번 수정하는데 소극적이게 됩니다. 그 결과 구글도 2000년대에 구글 웹서버를 확장하기 위해 수 많은 인력을 투입했으나 개발 속도에 진전이 없었다고합니다. 그리고 버그도 크게 줄어들지 않았다고 합니다. 개인적으로 올해 시스템이 커지면서 업무 상에 실수가 많았다고 생각하는데, 상황이 상황이었던지라 이런 대목을 읽으니 크게 공감하였습니다. 구글에서 정의한 테스트의 세 분류 구글에서 정의한 테스트는 크게 3가지로 분류할 수 있습니다. 소..