🌱 0. 서론
- 📣 스피커 : 이일민(Toby) - Epril
- 세션을 선택한 이유
스프링 개발자라면 당연히 토비님의 세션은 무조건 참여해야한다고 생각한다.
게다가 이번 세션 제목은 무려 '클린 스프링'.. 너무나 맛있어 보였다. 😋
✍🏻 1. 세션 정리
🍇 1. 클린코드란 무엇인가
클린코드 vs 구현능력
- 구현할 결심 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ....
- 클린코드를 지향할 수록, 점점 구현능력이 떨어진다?
개발바닥의 애청자로서, 위의 영상은 이미 재미있게 봤었다.
토비님도 위의 영상을 화두로 던지셨다.
클린코드를 지향하는 것과 구현능력, 즉 생산성은 대치되는 영역일까?
클린코드와 구현능력은 서로 대치되는가..?
- 주니어 개발자들이 클린 코드에 집중할수록 기능 구현 능력이 떨어지는 경향이 있다..?
- 좋은 코드에 대한 고민이 많아질 수록 실제 구현 속도가 떨어지는 현상이 있을 수 있다..?
- 좋은 코드, 구조, 설계에 대한 집착이 원인이 될 수 있다...?
🧐 이게 맞나..?
💡 Clean code 'THAT WORKS'!
'클린 코드' 라는 말은 누가 먼저 사용했는가?
- 테스트 주도 개발 (TDD) - 켄트 백
- 여기서 명확하게 밝히는 TDD 의 목적은 '작동하는 클린코드' 즉, Clean code 'that works' 임을 명확하게 천명하고 있다.
작동하지 않는 클린 코드? (구현되지 못한 클린코드?)
클린코드가 강조하는 것은 무엇인가?
- 읽기 좋은 코드
- 이해하기 좋은 코드
- 확장하기 좋은 코드
- 유지보수하기 좋은 코드
이것을 클린코드에서 강조하기 위해서는 당연히 '동작 하는 코드' 를 전제로 하는 것이다.
즉, 동작하지 않는 코드는 아무리 번쩍이고 께끗하고 멋져보여도 클린 코드라고 이야기 할 수 없다.
유지보수성
'유지보수'는 매일매일 매순간 일어난다.
- "기능을 확장하고 수정하고 변경하고 리팩토링 하는 것"
- 이것은 살아있는 프로그램은 매시간 매순간 일어나는 현상이다.
유지보수성
- 품질에 관한 요구사항(비 기능적 요구사항) 에서 유지보수성은 특별하다.
- 유지보수하기 좋은 코드는 확장하기 좋고, 안전하고, 신뢰할 수 있고, 좋은 성능으로 발전시킬 수 있고, 상호 호환성이 뛰어나서 변경하기 쉽다.
- 유지보수성은 코드의 변경가능성과 동의어다.
결국 유지보수성은 살아있는 프로그램이 계속 살아 숨쉴 수 있도록 끊임없이 고민하는 것을 의미한다.
왜곡된 유지보수성...
- 유지보수성에 집작하게 되면 위와 같은 집착과 더불어 역효과를 가져오게 된다. 😅
생산성
클린코드를 하면 생산성이 떨어진다?
유지보수하기 좋은 클린 코드는 개발생산성이 떨어지나?
아니다! 🙅🏻
개발 생산성과 유지보수성은 서로 영향을 주는 관계이다!
- 유지 보수성이 좋은 코드는 변경가능성이 좋아진다.
- 이런 빠른 변경가능성을 통해 코드는 생산성이 좋아지게 된다.
- 그리고 이 과정은 리팩터링을 통해 반복되어가며 더 품질이 좋은 코드로 진화하게 된다.
💸 2. 부채 (Dept) - 기술 부채
기술 부채 (Technical Debt)
'기술 부채' 라는 단어는 꽤나 익숙하게 들어봤다.
이 단어는 켄트 벡의 멘토이신 워드 커닝햄 형님께서 처음 사용하신 단어다.
소프트웨어의 개발과정에서 기술 부채 즉, 빚이 생기는 과정은 이러하다.
기술 부채가 발생하는 과정 💰
- 현재 이해도를 바탕으로 하여 코드를 작성하고 빠르게 소프트웨어를 출시하게 된다.
- 이 과정을 통해 기술적인 빚이 생기게 된다.
- 그 이후, 소프트웨어를 발전해 나가면서 배우게 되는 것들을 리팩토링을 통해 코드에 반영을 시킨다.
- 소프트웨어를 만들고 운영해나가면서 실무를 통해 깨닫게 되는 경우가 많아지게 된다.
- 이러한 깨달음과 변경지점을 발견해 나가면서 리팩토링을 진행하고 코드에 반영을 시켜나가야 한다.
- 이 과정을 통해 처음에 진 빚을 상환하게 된다.
- 리팩토링을 통해 빚을 상환하지 않게 되고 방치하게 된다면 빚이 이자가 쌓여서 더 큰 부담이 생기게 된다.
- 즉, 빚을 상환하지 않을 수록 이자는 불어나게 되는 것과 같다.
기술 부채에 대한 개념을 이야기할 때 잘못 이해하면 오해가 생길 수 있다.
오해 : 어차피 빚을 지는 거니까 대충 작성해도 되는건가?
- 아니다!!!!! 🚫
- 기술 부채라는 것, 즉 코드에 빚을 진다는 것은 코드를 대충 작성하라는 것이 아니다.
- 나쁜 코드에 대한 변명으로 기술 부채를 가져다 쓰는 것은 옳지 않다.
기술 부채는 빚을 진 후에, 그것을 갚는 과정을 모두 포함한다.
즉, 나쁜 코드, 리팩토링을 하기 힘든 코드는 빚을 갚는 것을 포기한 코드다.
처음부터 리팩토링 하기 좋은 코드를 바탕으로 시작해야한다.
빚을 내는 것도 능력이다.
그런 능력의 기반은 '기본 코드가 잘 작성된 것' 이라고 생각한다.
부채가 지속적으로 효과를 발휘하려면 리팩토링이 동력이 되어야 한다.
🧪 3. 클린 코드의 핵심, 테스트
클린코드를 시작해보자
그렇다면, 알겠는데.... 클린코드를 정작 시작은 어떻게 해야 할까?
1. 개발의 시작은 일단 빠르고 간단하게!
- 익숙한 기술을 사용할 것
- 핵심 기능에만 집중할 것
- 동작하는 코드를 작성할 것
- 가장 단순하게 코드를 작성할 것
2. 완벽함은 나중에 추구할것!
- 일부 기능을 완벽하게 만드는 것으로 시작하지 말 것
- 온갖것을 다 한번에 하려고 하지 말 것.
- 인프라, 캐시, k8s 등등... 절대 처음부터 하지 말것!!
클린코드를 잘하려면? 리팩토링!! 리펙토링을 잘하려면? 테스트!!
클린코드를 잘하려면 어떻게 해야할까?
바로 바로..!
📢 외쳐! 리팩토링!!
그렇다면 리팩토링을 잘 하려면 어떻게 해야할까?
📢 외쳐! 테스트!!
리팩토링을 잘하기 위해서는 반드시, 반드시, 반드시, 반드시 테스트가 필요하다.
🧐 : 테스트코드를 작성하면 또 구현 능력과 구현 속도가 느려지지 않나요?!
클린코드를 작성하는 것과 생산성은 대치되는게 아니라면서요!! 빼애애애앢!!🐤🐤🐤🐤🐤
맞다. ㅋㅋ.. 🤣
테스트를 작성하면 구현 능력과 구현 속도가 느려진다.
테스트코드에 들어가는 리소스는 당연히 존재한다.
실무에서 테스트에 들어가는 비용에 대해 부담을 느끼는 곳이 당연히 존재한다.
- 저 빨간 구간이 바로 초기 테스트를 구현할 때 발생하는 비용이다.
- 물론, 일정 시점이 지나면 테스트를 통해 구현한 어플리케이션의 생산성이 월등히 올라간다.
- 하지만, 실무에서는 저 초기 비용이 부담이 되는 경우가 허다하다.
토비 센세 👻 : "테스트를 빨리 만들면 되죠 ㅋㅋ..."
테스트를 빠르고 효과적으로 작성하면서 개발하는 능력이 필요하다.
- 테스트 코드는 연습이 필요하다.
- 연습이 있어야 한다.
- 효과적이고 빠르게, 그리고 꼼꼼하게 테스트 코드를 작성하는 것이 중요하다.
🪐 4. 삼체 문제 (Three Body Problem)
개발은 혼자 하는 것이 아니다.
세계적으로 유명한 SF 소설이고 넷플릭스에서도 드라마로 나왔던 삼체.
그 드라마에서도 다루는 '삼체 문제'는 아래와 같은 정의를 가진다.
삼체 문제
- 삼체문제(三體問題, three-body problem)는 세 물체 간의 중력이 어떻게 작용하고, 이 결과로 어떠한 궤도 움직임을 보이는지에 관하여 다루는 문제이다. 훗날 카오스 이론의 등장에 영향을 주었다.
- (나무위키)
즉, '쉽게 예측하기 어렵고 힘든 문제' 라는 것이다.
그리고, 그 이유는 각자 다른 주체의 영향도가 있을 때, 문제는 더욱 복잡하고 예측하기 어려워진다는 것을 말한다.
회사에서 팀과 함께 어플리케이션을 만들며 코드를 작성하는 것은 삼체문제와 같다.
'유지보수성', '팀워크', '생산성' 이라는 세개의 천체가 비선형적으로 예측 불가능한 운동을 한다.
개발자로서 고민하는 클린코드, 리팩토링, 테스트등은 모두 이러한 삼체문제를 해결 하기 위한 방법론이다.
즉, 나만을 위한 클린 코드는 존재할 수 없다.
클린 코드의 많은 원칙은 상황에 따라 다른 기준을 가지고 있다.
Great Teams Make Great People 👫
- 함께 코드를 작성하고, 읽고, 변경할 동료 개발자들에게 친절한 코드를 작성하도록 노력하자.
- 항상 동료에게, 그리고 자신에게 친절하자.
🙏🏻 2. 개인소감
'클린 스프링' 이라는 단어에 침흘리며 세션에 참여했다.
그리고, 내가 하고 있는 프로그래밍의 본질에 대해 다시 새로운 관점으로 고민할 수 있게 되었다.
삼체 문제에 빗대어 프로그래밍이라는 행위를 설명하고 풀어내는 것이 너무나 적절하다고 생각했다.
막연하게 클린코드와 생산성이 대치된다고 생각했던 내 생각 역시 바뀌게 되는 계기가 되었다.
너무나 따뜻했고, 즐거웠던 그리고 유익한 세션이었다.
토비님 최고! 👍🏻
