인프런에 강의를 하나 올리게 되서 홍보차 글을 작성하네요! 올해의 버킷 리스트중 하나로 강의를 하나 찍어서 올리는 게 있었는데요. 연말이 가기 전에 어떻게 마무리해서 결국 오픈하게 됐습니다. :) 그리하여 홍보차 글쓰기 위해 전단지를 돌리는 중인데, 관심 있으신 분들은 오셔서 한번 씩 봐주시고 가시면 감사하겠습니다. 초급자를 위해 준비한 [백엔드, 개발 · 프로그래밍] 강의이고요. https://www.youtube.com/watch?v=PAYouphJvT4&ab_channel=woogeunkim 아래와 같은 내용을 다룹니다. 주니어 개발자가 많이 하는 실수 교정 주니어 개발자가 스프링을 쓰면서 많이 하는 실수 교정 의존성 / Entity 등에 대한 잘못된 오해 교정 실무에 필요한 개념 정리 (MSA, ..

비욘세 규칙과 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가지로 분류할 수 있습니다. 소..