[워밍업 클럽 4기::DevOps] 1주차

왜 스터디를 하는가?쿠버네티스는 3년전 Amazon에서 EKS교육을 하면서 처음 접하게 되었다.물론 알고 들은 것도 아니고 전혀 그 부분에 대해 좋은 이유를 크게 느끼지 못하였다.하지만, 시간이 지나고 개발을 할 때 다양한 환경에서 개발을 하면서 쿠버네티스의 장점을 더욱 알게 되었다.기존에 회사에서 BeanStalk를 통한 배포환경 방식에서 ECS, ECR 환경으로 컨테이너화하여 개발을 하게 되었는데 그에 대한 CI/CD 구성이 너무 좋고 안정적이지만 EKS에 비해 ECS는 상당히 간소화된 부분과 성능 부분이 아쉽게 때문에 쿠버네티스에 대한 공부를 원했다.스터디 첫 느낌세가지 키워드로 정리할 수 있다.친절, 성장, 실용이렇게 세가지로 정의하려고 한다.1. 친절스터디는 매우 친절했다.함께 완주를 목표로 첫날 부터 팀으로 운영할 사람, 아닐 사람 등을 선정하고 랜덤팀에서 리더를 뽑는 등 강사님은 최대한 소통을 하기 위해, 그리고 친절하게 학습을 인도하였다.2. 성장3년전 나와 지금의 나는 확연히 다르다는게 느껴졌다.아무것도 모르는 상태에서 무지하게 쿠버네티스를 접한 나와 지금의 나는 상당히 다르다는 것을 느꼈다.그렇기 때문에 1년뒤, 2년뒤 내가 같은 개념을 공부해도 똑같이 생각하지 않기 위해 끊임없이 공부하고 노력해야한다는 것을 다시 다짐했다.3. 실용스터디에서 강의는 과감하게 실습위주로 진행하였다.사실, 하나하나의 기술이 뭔지 알아도 좋은데... 실용적이지 못하다 어짜피 실무에서 다양한 경험을 하게 되면 그 부분에 대해서는 알게 될 것이고 그리고 그 부분에 대해서 하나하나 알려주면 강의의 호흡 조절과 난도 조절이 안될것으로 보였다.2주차 계획물론, 강의를 듣는 것이고 나는 최종 계획이 내가 만들어서 런칭하는 프로젝트를 천천히 도커라이즈화 할 계획인데 그 계획에서 쿠버네티스를 운용해보는 것이 계획이다.혹자는 트래픽이 안나오는 그러한 시스템에 쿠버네티스는 오버스러운 일이라고 하지만 모니터링과 로깅 까지 Amazon에서 제공해주는 서비스로 뚝딱 만드는 것보다 다양한 로깅, 모니터링 툴을 써보고 싶다는 것은 아마 기술자로서의 열망이지 않을까 생각한다.

워밍업 클럽 그리고 그 이후 테스트코드와 클린코드 나의 생각

4주간의 스터디… 그리고 그 이후 나는 도대체 무엇을 하고 있을까? 지금 현재 내가 배운 내용 그리고 그 전과 그 이후과 얼마나 달라졌을까 비교하며, 회고를 하고 다시 한 번 마음을 다잡아보려한다.클린코드의 적용이 부분은 개인적으로 원래 잘하고 있던 부분이였다고 생각한다.추상화의 고민, 관심사를 어떻게하면 공통으로 분리할까 나를 위한 읽기 쉬운 코드를 어떻게 만들까?물론 이러한 영향을 준 것은 회사내 동료들의 아름다운 코드들과 아름답지 못한 코드들이고, 그 방법론은 클린코드, 리팩토링 등등 고전적인 책들과 다양한 읽기좋은 코드에 관련된 서적을 읽으면서 내 나름의 규칙을 만들기 시작했다.한 달이 지난 지금 내가 잘했던 그 부분은 유지하되, 새로운 법칙이 생겼다.나만의 용어 사전사실 제일 못하는게 이름 짓는 부분이다.아직도 못한다.하지만, 이러한 이름을 더 효과적으로 짓기 위해서, 강사님이 말씀해주신 풀에서 꺼내서 쓰는 용어사전을 차츰차츰 나름 정리하기 시작했다.이러한 용어들은 잘 정리된 오픈소스들에서 찾아보려고 노력을 많이 하였다.과감한 오버로딩오버로딩에 대해 사실 병적으로 싫어하던 시절이 있었다.파라미터에 따라 그 메서드 이름이 참 보기 어려워서 장황한 메서드를 만든적도 있다.public User createUserByNameAndYearAndAge(String name, int year, int age); public User createUserByName(String name); 하지만, 문득 자바 Lists 인터페이스를 보게되었고 중요한것은 오버로딩하나로 가독성만 확보되면 된다는 부분이었다.주석 사용논쟁이 가장 많은 부분 중 하나로서, 주석을 사용하는가? 사용하지않는가? 라는 부분이다.나는 후자에 가까운 개발자로서, 잘 설계된 코드는 주석보다 높은 가치를 한다고 믿었다…그런데, 사실 잘 설계된 코드란 것은 그 때 내가 그렇게 믿는 것 뿐이지, 후대에 내가 다시보면 이해 못하는 코드가 많다.결국 이러한 부분에 대한 이해를 돕는데는 주석을 적절히 활용하거나, 애초에 간결한 메서드 이름을 짓는 방법 밖에 없다.테스트 코드테스트 코드는 정말로 이 스터디의 전과 후과 눈에 띄게 달라졌다고 해도 과언이 아니다.이전의 테스트 코드는 사실 동료와의 테스트 코드에 대한 고민, 그리고 클린코드를 읽고 테스트코드의 필요성과 리팩토링등 다양한 실무에 부딪히면서 나의 필요에 따라서 테스트 코드를 작성했다면, 강의 이후는 테스트코드를 하나의 테스트 도구로서 활용을 제대로 하고 테스트코드의 장점과 강점에 대해서 나름대로 정확하게 이해를 하게 되었다.물론, 회사에서 내가 이렇게 테스트코드를 적극 도입하고 도입한 테스트코드에 대해 공유하며 나의 테스트코드에 대한 철학을 좀 더 고도화 시키는 부분들이 도움이 되었다.TDD대부분의 개발자들 (5년미만의 개발자들)은 TDD에 대해 환상을 가지고 있다.TDD에 대한 환상을 가지고 있다면, 일단 한 번 도전해 보는 것을 추천한다.물론 TDD를 위해 기존 잘 돌아가는 프로젝트를 아예 끄집어서 뒤엎는 것 보다.사내에 도움이 될만한 프로덕트를 만들면서 TDD를 적용하는 것을 추천한다.참고로 나는 TDD를 위해 백오피스를 했다 😃내가 생각하는 TDD (테스트 코드)TDD를 도입했는데, 내 생산속도가 느려졌어 라는 이야기를 종종 듣는다.TDD가 아닌 테스트코드도 마찬가지다.일단, 강사님이 말씀해주신 부분 중 하나 모든 영역을 테스트 커버하려고 하지않아도 된다. 라는 이야기를 세션 도중에 하셨다.또한, 테스트 코드를 사용하면서 하나의 철학이 생겼다.나의 테스트 코드는 ‘실용주의 테스트 코드’ 라는 철학으로 정의할 수 있다.물론, 저 책에서 영감을 받은 것은 아니고… 그냥 단순한 나의 원칙이다.실용주의 테스트 코드를 위한 나의 원칙테스트 커버리지에 매몰되지 말자주니어 개발자들은 이러한 커버리지에 매몰되는 경우가 상당히 많이 있다. ”테스트 코드 95% 커버리지” 물론 좋다고 생각한다. 근데, 95%의 커버리지를 채우는 시간보다. 차라리 로직에 대해서 완성도를 높이거나, 그 시간을 어느정도 분배하는게 맞다고 생각한다. 물론, 혼자서 하는 프로젝트에 대해서는 95%든 100%든 자기 만족이기에 상관없다고 생각들지만, 비즈니스 프로덕트에 커버리지에 매몰되는 것 보다. DDD에서 어떤 영역에 테스트 코드를 주로 작성했고, 왜 그 영역에 테스트 코드를 작성했는지에 대한 고민과 철학을 녹여내는게 중요하다.테스트 코드는 유지보수가 필요하다테스트 코드에 대해 관심을 가지게 해주는 동료와 고민했던 부분은 테스트 코드를 과연 유지보수를 적게 설계 하려면 어떻게 해야할까 라는 이야기를 많이 했었다. 사실 이러한 부분들 때문에, 테스트 코드를 작성할 때마다 ‘어짜피 이거 곧 깨질텐데…’ 라는 생각을 하게 되었다. 중요한 것은 깨지는게 맞는거 같다. 깨지면 고치면되고, 깨진다는 것은 그에 대한 사이드 이펙트들도 확인 할 수 있다는 점이다. 코드는 생물학과 마찬가지로 끝 없이 진화하고 테스트 코드는 그에 대한 가설이다. 가설은 어떠한 부분을 검증하기 위해 깨어질 수도 있고 새로 정의되어질 수도 있다. 컴퓨터는 공학적인 측면도 강하지만 과학적인 측면도 강하다.테스트코드는 가설이다테스트코드는 가설이기 때문에, 실제로 가설을 세우기 위해서는 이 가설이 맞는지에 대한 전반적인 이해가 필요하다. 예를 들어 내가 진화론이라는 가설을 새울 떼 유전진화학에 대한 학문에 대한 이해가 피상적으로 있는 상태에서는 가능할까? 사실, 불가능에 가깝다. 좋은 테스트 코드란 테스트 코드를 작성하기 위한 그 도메인에 대한 전반적인 이해도를 요구하고 수반한다. 실용주의적인 테스트 코드는 테스트 코드를 통해 도메인에 대한 지식도 높이는데 기여한다라는 생각에 기반한다.성장끝으로 이번 세션 이후로 나의 성장이 많이 되었다는 것도 느끼지만 회사에서 코드가 깔끔할 뿐만 아니라 테스트 코드까지 합리적인 이유와 검증가능한 코드다 라는 이야기를 들었다.그리고, 최근 1000줄 가까이 되는 레거시의 가독성을 확보하고, 그에 대한 테스트 코드로 검증하는 과정을 걸치면서 코드의 현대화도 많이 이루어냈다.레거시라는 것은 개인적으로 이렇게 정의하려고한다.‘가장 중요하고 필요한 기능이지만, 그 누구도 고치려고 하지 않은 미지의 영역’바꿔말하면 가장 중요하기에 나만 알아야하는게 아닌 모두가 알아야하고 모두가 아는 비용을 줄이기 위해서, 고민을 한다면 그리고 이게 합리적 이유라면 클린코드와 테스트코드 도입하지 않을 이유가 없지 않을까?

인프런 워밍업 클럽::네트워킹 데이

12월 13일 워밍업 클럽 수료자들을 대상으로 하는 네트워킹을 갔다왔다.주요 세션은 두 가지 내용이지만, 공통 관심사는 커리어였다.사실 우리가 공부하는 이유는 커리어 때문인걸까? 고민이 상당히 되었다.물론, 나의 인정이 커리어에서도 나오기는 하지만 더 나은 개발자 그리고 영향을 주는 개발자가 되고 싶어서 끊임없이 공부를 한다.네트워킹을 하면서 느낀 것은 여러가지가 있지만, 가장 크게 하나였다."더 잘하자" 이제 부터 간단하게 네트워킹 데이의 좋은 점과 아쉬운 점을 적어보려고 한다.좋은 점밥이 너무 맛있다...?? 솔직하게 편식이 너무 심한편인데 닭강정이 너무 맛있었다.근데, 네트워킹 데이말고 전에 워밍업클럽 수료식 때는 맥주가 있었는데...ㅋㅋㅋ하지만, 전반적으로 인프런 직원분들이 고생을 하고 준비하신게 보여서 감사했다.강의 내용이 알찼다.준비와 구성이 훌륭했다.스피치의 전달력과 그에 대한 화법들이 상당히 좋았다.특히나 모두가 관심있어할 만한 주제를 한 번에 꿰뚫는 관통력은 매우 좋았었다.1부 네트워킹 세션같은 직군끼리 모여서 서로 이야기를 할 수 있다는게 좋았다.같은 직군이다 보니 서로 공통 관심사를 관통시켜 이야기를 하고, 다양한 주제를 서로 나눠가지면서 이야기를 할 수 있었다.또한, 인프런 직원분들도 군데 군데 있어서, 하나의 공통관심사를 꿰뚫게 만드는 점도 좋았다. 아쉬운 점1. 사진을 안찍는다...직원들의 고군분투에도 ㅠㅠ 사진을 안찍어주시는 분들이 많았다물론 나도~~ ㅋㅋ사실 같이 간 동료들하고 사진을 찍고 싶었는데, 아무도 안찍으려했다..속상 😢2. 시작 -> 끝? 무슨 모임이든 끝이 있기 마련이지만, 갑자기 어... 끝? 그런 느낌이 강했다.시작에 대한 부분은 명확했지만, 끝은 너무 약간 엄... 대관시간때문인거는 아는데, 몇 분전에 끝을 고지해주고 토픽에 대한 마무리를 하면서 네트워킹을 마무리 하는게 좋았는데 그게 아쉬웠다...또한, 고생한 직원들과 그런 시간도 조금 있으면 좋겠는데 갑자기 서둘러서 나가는 분위기라 아쉬웠다!3. 2부 네트워킹 세션 일단, 당연하게 어떤 네트워킹도 항상 만족을 주는 것을 불가능하지만 2부 네트워킹 세션은 돌아보니 실망이 있었다.특히나 우리팀은 백엔드 전원에 한 명만 취준생인 프론트 개발자가 있었는데, 이것은 사실 인프랩 주최측의 잘못이라기 보다는... 그냥 뭐 ㅋㅋㅋ 네트워킹 하려는 사람들이 잘못인거 같다.배려가 없었다.공통 관심 주제를 캐치하고 다 같이 이야기를 해야하는데, 너무 의욕적으로 자신이 궁금한 주제만 이야기하는 시간이되어서 몇몇은 소위 말하는 꿔다 놓은 보릿자루가 되었다...결론다음에 갈거야? 라고 물어봤을 때 대답은 가야지! 라는 대답이다.뭐든 좋은거 아쉬운거 다 있지만, 결국 한 단계 도약하는 기회와 내가 원하는 이상향과 현재 위치를 가늠해 볼 수 있는 좋은 기회였다.뭐... 그리고 평소 말이 많은 성격이라 궁금한 것들도 다 어느정도 해소했고 ㅋㅋ끝으로는 상 받았다~~!! (저는 나호진이 아니에용 ㅠㅠ... 발음이 안좋다 내가 ㅠㅠㅠ)

[워밍업 클럽 스터디 2기::백엔드] 후기

스터디 회고4주간 스터디를 쉼없이 달려왔다.여러가지 일이 있었고, 재미있는 지점도 지루한 지점도 존재하였다.하지만 중요한 건 포기하지 않고 계속 한다 라는 가장 원론적이고 근본적인 자세다! 이미 지나간 말인데 중요한 건 꺾이지 않는 마음이라는 것 같다! 감상적인 이야기는 여기서 끝내고, 회고답게 이 스터디에서 얻어간거 추천하는 것 등등 모든 것을 빠짐 없이 기록하여 3기를 참여하고자 하는 사람들에게 도움을 주고자한다. 스터디 추천도무조건 추천한다! 다만, 끝까지 완주할 의지가 있을 경우에만 추천한다.완주라는게 어떤 사람들은 4주의 진도를 막힘없이 따라가는 것이고, 어떤 사람들은 진도가 중요한게 아니라 4주안에 어떻게든 끝내는 것이 될 수 있다.인프런에서는 4주의 진도를 막힘없이 따라가면 완주러너, 그리고 거기서 더 잘하면 우수러너라는게 있다.즉, 동기부여가 될게 두 가지가 있다는 것이다. 완주러너 & 우수러너하지만 가장 큰 동기부여는 무언가를 뛰어넘어 성장한 자기자신이지 않을까?약간 나는 애니덕후 기질이 있어서 나의 히어로 아카데미아를 좋아하는데 한계를 뛰어넘어라는 이야기를 이야기를 좋아한다.각자 외부에서 주는 동기부여가 아닌 내부에서 주는 동기부여로 한계를 뛰어넘는데 의의가 있는 것이다. 커리큘럼의 난이도또 하나 중요한거 나는 클린코드 & 테스트코드 스터디를 진행하게 되었는데, 시원하게 오픈하면 나는 2년차 백엔드 개발자다 (이번주에 진짜 2년이 되요~~!! 🥳)혹자가 봤을 땐 아닐 수도 있는데, 아직 나는 응애 아가 개발자 중 하나라는 것이다.그런 내가 보았을 때 난이도는 적절한편이다. 중립적인 단어인거 같은데, 어려운 부분은 어려웠다.쉬운부분은 쉬웠고, 그니깐 난도 조절을 정말 잘했다는 것이다... 이것은 강사님의 강의의 퀄리티가 좋다! 라는 것과 일맥상통하는데, 나는 강의에 금액 투자를 신중하게 한다.강사님들에게는 죄송한 이야기지만 어찌되었든간에 나는 소비자니깐! 소비하려는 제품이 얼마나 좋은지 봐야하는데, 확실한 제품아니면 잘 안 구매한다ㅋㅋ...그렇지만! 이번 강의는 진짜 좋다! 더 나은 백엔드 개발자를 고민하였다면 구매를 추천한다! 정리하자면Readable Code 강의는 클린코드를 읽어만 본 사람들, 혹은 적용을 하는데 많이 못하는 사람들에게 추천하는 난이도다.근데, 기본적으로 자바에 대해서 혹은 OOP에 대해서 잘 모른다하면 권장하지 않는다.https://www.inflearn.com/course/practical-testing-%EC%8B%A4%EC%9A%A9%EC%A0%81%EC%9D%B8-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B0%80%EC%9D%B4%EB%93%9C/dashboardTest Code 강의는 아이러니한 부분이긴 한데, 클린코드를 읽어 보거나 회사 실무내에서 테스트코드가 없이 테스트 하는 것에 대해 한계를 느낀 개발자들에게 추천하는 난이도이다.근데, 기본적으로 다양한 테스트를 경험해보지 않는다면... 테스트코드가 얼마나 좋은지 모를지도 모른다.그냥 내 발목을 붙잡는 쓸모없는 거라고 생각할 수도?https://www.inflearn.com/course/readable-code-%EC%9D%BD%EA%B8%B0%EC%A2%8B%EC%9D%80%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%82%AC%EA%B3%A0%EB%B2%95/dashboard 이건 좋아요첫번째, 강사님의 빠른 피드백과 코드 리뷰 너무 좋았다.코드 리뷰도 신청하면 대부분 다 해줘서, 진짜 너무 좋았다.이게 참 강사님 입장에서도 시간적으로 비용일텐데 이렇게 우리 수강생들에게 엄청난 투자를 해줬다는 것에 대해 압도적으로 감사를 가진다!두번째, 전반적인 운영이 매끄러웠다.'인프런에서 진행해서...' 라는 이야기를 안하고, 여타 다른 운영과 비교해 보았을 때 꽤나 괜찮은 운영이라고 느껴졌다.특히나, 디스코드 내에서 직원분들이 이것저것 질문에 대해서 답변을 빠르게 해주거나 아니면 수강생들끼리 채널을 열 수 있게 하는 그런 것들을 하나의 시스템 제도로 만들어서 참 잘 활용하는 것 같다.세번째, 동료들이 자극을 준다.물론 나는 회사동료들하고 같이해서 서로가 서로에게 자극을 주었지만, 이 스터디는 디스코드로 진행되어 자유롭게 이야기를 할 수 있다.여기서 자유롭게 이야기를 할 때 많은 사람들이 스터디 관련해서 이야기 하고 어떤 분은 공부시간 체크, 오늘 한 것 체크 등등 엄청난 분들이 있다 (이름도 외웠다 ㅋㅋㅋㅋ)사실 그 분들을 보면서 엄청 자극이 되서 나도 열심히 공부하게 되는 경우가 있었다. 이건 나빠요좋은 말만 쓰는 것은 싫다 ㅋㅋ 억까라해도 스터디의 단점으로서 장점처럼 세가지를 정할 것이다.첫번째, 야생이다.자신이 진짜 누군가 케어를 해줘야만 공부를 하는 타입이라면, 중도 포기할 가능성이 높다.특히나, 이 스터디는 본인의 의지가 중요한 것이기 때문에, 중간에 '아 밀렸어 안해 포기!' 이렇게 되는 이상 돌이킬 수 없다...두번째, 짧은 네트워킹 타임일단 네트워킹 타임이 50분이라는게 좀 아쉽다... 사람에 따라 다를 수 있는데, 나는 좀 말이 많고 다른 사람들하고 이야기 하는 것을 좋아해서 다른 사람들 그리고 다른 회사에서 어떻게 일하는지 궁금하고 그게 나의 인사이트가 되고 싶은데... 뭔가 엔진이 과열될만 하면 끝나버린다!충분히 이해할 수 있는게 한정된 시간 속에서 진행하는 거고 다 나 같은 사람일거라 생각하지 않기 때문에 이해하는 부분이다.세번째, 낯가리는 우리들...문제는 우리다! 다들 낯을 너무 많이 가린다... 스터디를 함으로서 제2차 파생된 그룹이 나오거나 하는 선순환이 많이 나와야하는데 공개적으로는 두개? 밖에 못본거 같다! 물론, 나도 이건 할 말이 없는데!다음에 스터디를 하게 된다면, 나도 낯을 안가리고 조금 주도하는 역할로 롤을 변경해봐야하지 않나 싶다! 혼자 공부하는게 아니라 같이 공부해야만 내 공부와 내 가설이 맞는지 검증이 되기 때문이다. 진짜 마지막참 우여곡절이 많은 스터디다.뭐 잘하지도 않고, 글재주도 안좋고 마지막만 사진 좀 넣었는데 ㅋㅋㅋ 평소에는 사진도 안넣는다.비효율적인 것을 극도로 자제하는 스타일이라 이런 것을 싫어한다.그런 내게 우수러너라는 상을 준 것에 대해 진짜 너무 감사하고 함께 스터디를 한 내 동료들 진짜 항상 같이 스터디 하는 동료들을 보며 느낀게, 우리가 지금은 이 자리에 있지만 앞으로 더 나아가자는 이야기를 하는데 진짜 진심이다.믿고 의지할 수 있는 동료고 더 높은 자리에서 서로를 볼 수 있을거라고 확신한다. 마지막은 우수러너로 받은 잔, 근데 하이볼을 곁들인 ㅇ_

[워밍업 클럽 스터디 2기::백엔드] 4주차 발자국

1주일간의 학습 회고이미 3주차에 완강을 했기 때문에, 이번주에는 집중적으로 학습하려고 했던 계획은 실제 회사 프로덕트 코드에서 녹여내기와 함께 숙제였다.하지만, 장례식으로 인해서 제대로 되지 못했다.이번주 상을 치루는 동안 공부 + 프로덕트 녹여내기를 시작했다.이번주는 학습보다 허무주의와 하루하루 더 열심히 살자 이 두 가지에서 고민을 했던거 같다... 이제부터 나의 마지막 학습 회고를 적으려고 한다.숙제1Q. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이를 한번 정리해 봅시다.사실 강의를 보면서, 이것들의 정의를 정리하면서 했기 때문에 쉬운 내용이었다.숙제를 풀기 위해서 중요한 부분은 위의 어노테이션의 차이를 정리하는게 아니라 위 어노테이션들은 Mock 테스트에 사용된다라는 것과 Spring의 중요 개념인 DI에 대해서 세삼 놀랍다고 생각하였다.사실 DI는 Spring에서의 중요 개념이 아닌 대부분의 프로그래밍 언어의 디자인 패턴에서 중요한 개념이다.정리를 하자면 위의 내용에 대해 별도로 이 포스트에서는 정리하지 않겠다.가장 중요한 것은, 이 기술들 사용하는 이유와 이 기술이 쓰이는 원인들이 중요하다고 생각한다. 숙제2두 번째 숙제는 너무 직접적인 내용을 포스트로 올리면 안되기 때문에, 후기로만 대략적으로 적는다면... 쉬웠다!BDD로 테스트코드를 작성해서 그런가... 사실 많이 쉬웠다. 이번 주 학습에서 잘한 점사내에서 백오피스를 혼자서 개발하는데 '나야 TDD, 근데 BDD를 곁들인' 그런 식으로 혼자서 개발하고 동료들에게 공유하고 있었다... 이번 주는 개인적인 일때문에 공유를 많이 못했지만, 디스코드로 소통하면서 공유를 조금씩 하였다.총평회사의 동료들과 처음으로 인프런 워밍업 클럽을 하였다.일단, 회사 동료들과 하는 나는 참 축복받았다는 생각을 하게 되었고, 이 학습을 나만 공부하는게 아닌 다 같이 공유해서 토론하고 발전해 나가는 과정이 좋았다.항상 보고자 했던 강의 였는데 이러한 기회가 생겨서 너무 좋았고....이제는... 개인적인 마음과의 싸움을 시작해야하는 시간이다

[워밍업 클럽 스터디 2기::백엔드] 3주차 발자국

1주일간의 학습 회고테스트코드의 강의를 완강하였다.이번 주 공부한 분량은 생각보다 많지는 않았다.중점적으로 관심있던 부분은 TestFixture와 RestDocs였다.TestFixture 강의 내에서 나온 TextFixture는 많은 내용이 없었지만, 실제로 프로젝트에서 이 강의를 보기전에 적용해 본 적이 있다.가장 도움이 되었던 내용은 토스의 기술 블로그였다. (하단 참조)https://toss.tech/article/how-to-manage-test-dependency-in-gradle예전에 프로젝트에서 적용하면서 느낀 장점과 단점에 대해 간단하게 기술해보면 다음과 같다.사실 적용법은 너무 많은 블로그에 나와 있기 때문에, 개인적인 장/단점을 공유하는게 옳다고 생각한다.장점Fixture관리가 편하다테스트 코드에서 Fixture를 파편화 시켜서 사용하지 않아도 된다.Gradle에서 지원한다단점Fixture도 관리 대상이 된다실제로 Entity나 DTO가 변경될 때 Fixture를 변경하지 않아서 빌드가 안되거나 하는 경우가 있었는데, 너무 번거롭다.모든 팀원들이 인지하지 않으면 꽤나 힘들다... (개인적인 생각이다)깊은 연관관계가 되어 있는 경우에는 결국 여러개의 Fixture와 Fixture 시나리오를 구성해야하기 때문에 꽤나 번거롭다.위와 같은 문제점을 해결하기 위해서, 고민을 덜기 위해 FixtureMonkey 라는 것도 고민을 해보았는데, 막상 생각보다 그렇게 와우 모먼트를 이끌만하지 않았기에 Fixture를 계속 사용하였다. RestDocs강사님이 이야기한것들 중에 정말 많은게 공감이 되었다.강사님은 RestDocs, Swagger 비교를 하셨지만 거기서 더 나아가서 PostMan과 같은 상용 API 문서화 툴까지 비교를 하자면, 회사 내 우리팀은 BFF 로서 백엔드 프론트가 나뉘어져 있다. 그렇기에 API 문서화가 중요한데 API 문서화 툴의 단점은 업데이트 주기가 사람한테 맞추어져있다는 점이다.그래서, Swagger를 도입하느냐 마느냐에 대한 이야기가 있었다. 개인적으로... Swagger를 반대하는 이유는 강의내용과 같다. Swagger가 프로덕션 코드에 침투하는게 너무 싫다!! 그러나... RestDocs를 사용하는 이야기는 하지 않았다... 왤까?이유는 다음과 같다. 아스키독스에 대한 학습이 싫다 -> 빠르게 도입을 해야할 때 발목을 잡을 수 있다TestCode에 대한 지식이 모든 팀원이 100%가 아니다 -> 사실 위 내용이 컸다....좋은 방안과 툴이여도 결국 회사의 상황과 역량에 따라 어쩔 수 없지만, 개인적인 프로젝트에서는 도입을 해볼 계획이다.해봐야 ㅋㅋ 이게 효율적인지 아닌지 알거 같다! 이번 주 학습에서 잘한 점사내에 개선점들이 있어서 개선에 도움을 주고자 간단한 프로젝트를 자체 개발하고 있었다...프로젝트를 하면서, 느리지만 개인적으로 한달정도를 예상하고 있어서 TDD를 통해서 그리고 읽기좋은 코드로 만들고 있다.향후 유지보수와 문서화를 위해서 내가 공부한 내용을 적용할 수 있게 했다. 아쉬웠던 점금요일에!! 깜짝 세션이 있었다... 참여를 못했다!!!같이 공부하는 팀원들과 함께 질문할것이 있었는데 ㅠㅠㅠ 하지를 못했다... 내 질문은 TDD의 영역이다...TDD의 영역이란 테스트 커버리지 퍼센트가 아닌 실용적인 이야기다...개인적으로 실용주의적인 개발자라 생각하여 나는 테스트코드가 100% 커버리지 혹은 90% 이상 커버리지를 좋다고 생각하지는 않는다.그래서 TDD의 영역에 대해 물어보려 했는데ㅠㅠ.... 회사 팀원들과의 협업TDD의 영역에 대해 같이 공부하고 있는 회사 동료들에게 물어봤다! 동료 중 한 명이 강사님에게 물어보라 했는데 ㅠㅠ 까먹었다... 또한 그 동료가! 물어본 것들 중 하나가... 인터페이스의 테스트 영역에 대해서 세명이서 토론하다가 이것도 물어보자! 해서 끝났다...좋은 동료와 좋은 스터디를 하고 이런 개념들을 발전해 나가서 너무 좋다!

[워밍업 클럽 스터디 2기::백엔드] 2주차 발자국

1주일간의 학습 회고테스트코드의 강의를 듣기 시작하였다.80% 정도 듣게 되었고, 항상 회사에서 테스트 코드에 대한 필요성을 느끼며 팀원 몇 명과 함께 테스트 코드를 작성하고 있었는데, 팀원이 추천한 강의로 항상 이 강의의 개념에 대해서 적용하도록 도와주었다...그 때 보라할 때 볼걸 그랬다...ㅠㅠㅠ 코드 리뷰를 받다강의를 일찍 끝내서 숙제를 강사님에게 빨리 제출하였다.내가 잘해서 검사를 맡은게 아니라 코드가 형편 없어도 200명 앞에서 내 코드는 이래요~~!! 하는 자신감을 보여줘야한다고 생각해서, 코드 리뷰를 신청했다. 일단, 결론은 더 잘하기 위한 동기부여가 되었다. 동기부여가 왜 되었을까?일단 나의 지적사항은 두 가지 그리고 질문도 두 가지였다. 첫번째, 내가 잘해서 지적이 두 가지라고 생각하지 않는다.두번째, 나는 못하니깐 많은 사람들 앞에서 까이고 싶다. 그래야만 더 잘하려고 노력하기 때문이다.세번째, 질문... 내가 고민하는 것들은 많은 사람들이 고민하는 거라는 것을 느꼈다. 첫번째 지적 사항public enum StudyCafePassType { ... public static StudyCafePassType sendTypeBy(String userInput) { try { int inputCode = Integer.parseInt(userInput); return Arrays.stream(values()) .filter(type -> type.inputCode == inputCode) .findFirst() .orElseThrow(() -> new AppException("잘못된 입력입니다.")); } catch (NumberFormatException e) { throw new AppException("입력값은 숫자가 되어야합니다."); } } }이러한 코드를 enum에서 작성하였다.일단, 작성하면서도 코드 스멜을 느꼈다.'비즈니스 로직에 대해서 Enum이 너무 깊게 연관하는게 아닐까?'위의 고민을 가지면서, 만들었는데 아니나 다를까 강사님은 역할과 책임을 이야기 하면서 이 부분의 코드를 지적하였다. 참고로 ㅋㅋ 같이 워밍업 클럽 참여하는 동료도 회사내 클린코드 적용하면서 이런식으로 적용했는데... 그 날 당일에 나는 저 코드는 문제 있는거 같다고 계속해서 지적했다! 두번째 지적 사항은... 그냥 실수다... static 남발인데... 이게 가끔씩 ㅋㅋ 귀찮아서 static 쓰는 경우가 있는데... 이 부분은 진짜 화끈거렸다... 이번 주 학습에서 잘한 점이번 주 학습에서 내가 스스로 잘했다고 생각한 부분은 숙제를 하면서 나 스스로 생각을 많이 했다는 것이다.물론, 코드에서 좋은 것들을 가져와서 쓸 수 있지만, 내가 하는거고 나의 공부기 때문에 강사님의 코드 스타일 포맷을 그대로 따라가지 않으려고 노력했었다. 아쉬웠던 점: 리뷰를 하자성격이라 그런가... 숙제나 그런거를 낼 때는 그냥 리뷰를 안한다...그러다가 이번처럼 참 ㅋㅋ 어이없는 실수를 해서 지적할 받을 때가 있다... 이것을 그냥 '아, 이건 실수~' 하고 무시하는게 아니라 이게 실력이다 ㅠㅠ... 회사 팀원들과의 협업팀 동료 중 한 분이 이번에 인프런 워밍업 클럽을 들으면서 클린코드를 적용하였다.정말, 너무 좋았고 같이 듣는 동료와 함께 세명이서 그 코드에 대해서 토론하고 좋은 방향 등에 대해서 이야기를 하였다.배움이, 단지 배움이 아니라 실제적으로 적용되서 살아있는 공부가 되었다.앞으로도 이러한 스터디를 하고 이러한 문화를 팀동료들과 계속해서 이뤄가고 싶다.그러려면 더 잘해야겠지 ㅠㅠ...

[워밍업 클럽 스터디 2기::백엔드] 1주차 발자국

1주일간의 학습 회고이번 한 주 동안 운이 좋게도 시간을 내어 강의를 모두 들을 수 있었다. 강의를 들으면서 강사님이 예제로 주신 프로젝트를 리팩토링하는 시간을 가졌고, 이를 어떻게 하면 더 효율적으로 리팩토링할 수 있을지 고민도 많이 했다. 나의 개발 철학: 누구나 이해할 수 있는 코드내가 코드를 작성할 때 가장 중요하게 생각하는 점은 바로 누구나 이해할 수 있는 코드다. 아무리 정교하고 복잡한 로직이라도 나 외에 다른 사람들이 이해하지 못한다면, 코드 자체는 잘 작성했을지 모르지만 그 코드는 좋은 코드라고 할 수 없다. 개발자는 혼자 일하는 것이 아니라 여러 명과 협업하는 직업이다. 또한 코드는 끊임없이 변화하고 발전하는 유기체라고 생각한다. 그렇기에 모든 사람이 이해할 수 있고, 지속적으로 유지보수할 수 있는 코드가 좋은 코드라고 생각한다. 이번 주 학습에서 잘한 점이번 주 학습에서 내가 스스로 잘했다고 생각한 부분은 기존에 알고 있던 개념들, 예를 들어 톰 롱의 좋은 코드 나쁜 코드, 켄트 백의 Tidy First, 로버트 C. 마틴의 클린 코드와 같은 책에서 배운 내용을 확장시켰다는 점이다. 또한, 내가 경험한 부분들을 도입해서 좀 더 깊이 있게 이해하려고 노력했다는 점이 좋았다. 아쉬웠던 점: 집중력 유지의 어려움하지만 아쉬웠던 점도 있었다. 집중력 유지가 생각보다 쉽지 않았던 것이다. 외부적 요인이든 내부적 요인이든 컨디션에 따라 학습의 진도가 들쑥날쑥했다. 컨디션이 좋은 날은 많은 진도를 나갔지만, 좋지 않은 날은 적은 진도를 공부하게 됐다. 그럼에도 꾸준히 공부하고 성취를 이뤄냈다는 점은 매우 중요한 성과다. 이번 주에 목표했던 학습을 어느 정도 완료했고, 다가오는 한 주는 더 구체적인 목표를 세워 동료와 함께 학습 내용을 토론하며 우리 회사에 적용해 볼 계획이다. 실습과 이론이 어우러진 미션이번 주차에는 두 가지 미션이 주어졌다. 하나는 구체라는 개념을 일상생활에 빗대어 설명하는 미션이었고, 다른 하나는 주어진 코드를 SOLID 원칙에 맞게 리팩토링하는 과제였다. 구체를 일상생활에 빗대어 설명하는 과제는 매우 흥미로웠다. 프로그래밍을 공부하다 보면 언어 자체가 번역투로 이루어져 있거나 어려운 용어가 많아 쉽게 이해하기 힘들 때가 많다. 하지만 일상생활에 비유해 설명하니 훨씬 쉽게 이해할 수 있었고, 동료들에게도 설명할 때 유용했다. SOLID 원칙 과제에서는 내가 생각하는 중복 문제를 예시로 들고 설명했다. 이 과정에서 초등학생에게 설명한다는 가정하에 설명을 시도해 보았다. 초등학생도 이해하지 못한다면, 나 역시 완전히 이해하지 못한 것이기 때문이다. 이는 전문가는 어려운 개념을 쉽게 설명할 수 있지만, 사기꾼은 쉬운 개념을 어렵게 설명한다는 유명한 말과 일맥상통한다. 회사 팀원들과의 협업이번 스터디는 회사 팀원들과 함께 진행하고 있는데, 팀원들과 함께 성장할 수 있는 좋은 기회가 되고 있다. 강의 내용도 매우 만족스러웠고, 팀원들의 반응도 긍정적이다. 누군가 이 강의를 추천하냐고 물어봤을 때, 나는 이렇게 대답했다. “클린 코드 책 읽어보셨나요? 읽으셨다면 좋은 강의고, 안 읽으셨다면 꼭 들어야 할 강의에요.” 클린 코드는 한 사람의 의견만이 정답은 아니라고 생각한다. 여러 사람의 이야기와 경험이 모여야 비로소 읽기 좋은 코드가 완성된다고 본다.