어라, 맞는데 왜 틀리지?

AWS 아키텍처와 관련한 발표 영상입니다.
발표한지는 좀 됐는데 이제야 블로그에 작성하네요.

JWT 사용과 관련한 발표 영상입니다.
발표한지는 좀 됐는데 이제야 블로그에 작성하네요.

이전 포스팅에서 Issue를 중심으로 한 오픈소스 읽기 훈련에 대해 말하였습니다.

이번에 선택한 오픈소스는 lombok인데요 자바진영에서 매우 높은 인기를 가지며 보일러 플레이트 코드를 줄여주는 귀인이라 생각됩니다.
항상 사용해왔던 것인데 막상 실제 코드레벨에서 어떻게 구현됐는지를 찾아본 적은 없었기 때문에 이번 기회를 통해 읽어봤습니다. 

흥미로운 Issue

Missed null checks in record constructor when non-Lombok annotations are used

record에서 non-Lombok annotations 사용시 null 체크가 안되는 문제가 있다 합니다.
또 찾아보니 이와같은 이슈를 겪는 사람들이 많은 것 같습니다.

테스트 코드를 실행해보니..

실제로 null 체킹이 안되는 문제를 발견했습니다.

비슷한 Issue를 조금 더 찾아보니

record의 경우에는 Compact Constructor를 기본으로 생성하기 때문에
이런 문제가 발생한다고 합니다

근데 lombok은 record에 대해서도 null 체킹을 하니까...
lombok의 NonNull은 record에 대해서 별도 처리를 한다는 가설을 새울 수 있습니다.

lombok의 NonNull은 record에 대해서 추가적인 처리를 하는가?

lombok의 프로젝트 구조입니다.
core안에 익숙해 보이는 이름의 파일이 존재합니다.

우리가 사용하는 lombok 어노테이션은 src/core 아래에 있는것으로 보입니다.

lombok은 기본적으로 컴파일 타임때 AST(Abstract Syntax Tree)를 순회하면서 어노테인션을 인지하고 코드를 주입합니다.

그래서 컴파일과 관련있어 보이는 javac패키지를 확인했고
javacAST , javacASTAdatprer , javacASTVisitor 등을 확인했습니다.

구조를 보니 Visitor는 스펙을 명시해놓은 인터페이스고 Adapter가 Visitor를 상속받아 실질적인 동작을 하는 것 처럼 보였습니다.
이름과 visitField , visitAnnotationOnField 등의 메서드 이름으로 추측하건데
AST를 순회하는 역할을 맡고있구나! 라고 생각했습니다.

JavacAST도 확인해보니

LombokNode -> AST -> JavacAST로 이어집니다.
따라서 JavacAST가 실질적으로 SyntaxTree를 구성하며 그 Tree를 이루는것은 각각의 Node겠구나 생각했습니다.

여기까지 읽은 후 나머지 키지를 클릭해보던 중 익숙한 이름을 발견합니다.

어라? 이거 클래스네? -> 그럼 실질적으로 동작이 일어나나보다 그리고...

이름으로 추측하건데 JavacAST를 Adapter가 순회하면서 어노테이션 확인하면 그에 맞는
Handler가 동작해 어노테이션을 처리하는 것 같다

또한 private 메서드는 안읽고 그냥 넘겼습니다
어차피 private이면 밖으로 오픈 안한다는 소리기 때문에 public으로 열려있는 메서드만 읽으면 충분하다 생각해요

그렇게 모든 private메서드를 넘기고 처음 나오는 public는 handle메서드 입니다.

근데 이거... @override 돼있습니다 그말은 표준화된 스펙을 구현한 메서드란 소리며
이는 곧 handle메서드에서 실질적인 처리가 일어남을 의미합니다. 그렇게 쭉 읽다보면...

record에 대해서 추가적인 처리를 하는것을 볼 수 있습니다.

아마 record인 경우에는 lombok이 Modify할 수 있도록 record에 의해 생성되는 compact constructor를 사용하지 않고
따로 만들어 넣어주는 것 같습니다.

따라서 우리는 lombok의 NonNull은 record에 대해서 추가적인 처리를 해주며 다른 벤더에서 제공하는 어노테이션들은
record에 대한 추가적인 처리가 없기 때문에 이런 Issue가 발생한다는 결론을 내릴 수 있습니다.

이전 글과 마찬가지로 단서를 통해 추측하고 읽어내야 할 부분을 최소화 하여 빠르게 결론에 다달하는 읽기 연습을 하는 중입니다.

같이 보시면 좋은 발표 영상입니다.

누구나 할 수 있는 오픈소스 Contribution

이전 포스팅에서 SIPE 합격 후기를 올렸었습니다.

이번엔 SIPE에서 진행하는 미션의 일부인 오픈소스를 활용한 읽기 훈련에 대해 말해보려 합니다.

저는 현재 인턴으로 근무중인데요 처음으로 일을 해보니
코드를 작성하는 시간보다 무언가를 읽는 시간이 더 큰 것 같다는 생각을 했습니다.

따라서, 한번도 해본적 없는 "읽기"훈련을 해보려 합니다.

왜 오픈소스?

제가 생각하는 오픈소스의 장점은 다음과 같습니다.

1. 우리가 많이 사용하지만 실제 코드는 모른다
   (사용안해본 개발자가 없는 SpringBoot , React..)
2. 이리 올라와 있는 Issue를 중심으로 읽기 가능
3. Contribution을 통한 지식공유와 피드백

특히나 지식공유가 가능하다는게 매우 마음에 들었습니다.

제가 블로그를 운영하는 이유도 제 나름의 지식공유 목적이며
나의 경험을 통해 누군에게 도움을 줄 수 있다는 것에 큰 가치를 두기 때문입니다.

오픈소스를 고른 기준

1. 실제로 사용해 본 것
2. 활성화된 업데이트와 커뮤니티
3. JVM기반 프로젝트
4. Fork , Star 500++
5. 실제로 Contribution 할 수 있는 것

제가 사용해봤던 서비스중 오픈소스인 것들을 리스트업했고 이중 실제로 Contribution까지 할 수 있는 것을 찾아봤습니다.
(SpringBoot, Spring Data JPA....등 정말 거대하고 복잡한 것들은 전부 제외했습니다)

또한 이미 등록돼있는 Issue를 중심으로 Contribution에 적합해 보이는 것을 찾았습니다.

필요한 부분을 가려내는 "메타읽기"

막상 시작해보니 생각보다 읽어야 할 내용이 방대했습니다.
커밋 자체도 3000개가 넘으며 구조를 확인하기 위해서는 상당한 시간이 필요해 보였습니다.

그래서... 비슷해 보이는 PR을 확인해 봤습니다.

.approaches 아래의 파일들이 PR로 올라온 내용입니다.

그렇게 읽어보던중 다음의 링크를 발견합니다.

링크를 좀 확인해보니 knapsack/introduction.md의 내용은
Dig deeper 아래의 내용을 담당하며

https://exercism.org/tracks/java/exercises/knapsack/dig_deeper 다음의 url을 가짐을 확인했습니다.

또한 .approaches/dynamic-programming는 Dig deeper옆에 보이는 Approaches의 내용이며 https://exercism.org/tracks/java/exercises/knapsack/approaches/recursive 다음의 url을 가집니다.

이를 통해...
내가 기여할 부분은 https://exercism.org/tracks/java/exercises/parallel-letter-frequency/dig_deeper 의 url을 가질 것이며

.approaches 아래에 페키지를 추가한다면
https://exercism.org/tracks/java/exercises/parallel-letter-frequency/dig_deeper/{내가 생성할 페키지이름} 의 url일 것임을
유추할 수 잇었습니다.

또한 snippet.txt는 예시코드 , content.md는 approaches의 내용을 의미하겠네요

그럼 이 Issue에 기여하기 위해 필요한 구조에 대한 이해는 끝났습니다.
내용만 작성하면 되는것이죠

사실... PR만 올리면 끝날 줄 알았는데 생각보다 리뷰를 정말 꼼꼼하게 해주더라구요 그래서

코멘트를 31개 받아본건 처음인것 같은데.. 결국엔 제가 이겼습니다.

영어로 작업해야 하는 부분이 많아서 개인적으로는 시간이 좀 걸렸네요

이렇게 Contribution까지 해보니...

일하는 방식과 비슷하다는 생각을 했습니다.

1. 거대한 코드베이스에서 내가 필요한 부분만 확인
2. 전체 프로젝트를 읽기보다는 추측을 통한 메타 읽기
3. 실질적인 기여

프로젝트 구조를 파악하고 코드를 읽는 훈련을 하고싶다면 오픈소스의 Issue를 중심으로 읽어내는 것이 정말 좋은 방식인 것 같습니다.

또 내가 작업한 작업물이 많은 사람들에게 공유되어 도움일 된다고 생각하면 뿌듯하기도 합니다 

https://exercism.org/tracks/java/exercises/parallel-letter-frequency/dig_deeper

같이 보시면 좋은 발표 영상입니다.

안녕하세요 SIPE에 합격해 OT를 다녀왔습니다.
https://sipe.team/

사실 붙을거라곤 생각은 못했는데요 지원 동기를 1줄로 작성했거든요 

귀찮아서 이렇게 작성했다...기 보다는 실제로 제가 생각하는 지원동기는 저게 다였거든요
따라서 양을 채우기 위해 억지로 길게 늘여서 쓸 필요는 없겠다 생각했습니다.

난 나를 소개하는 글을 작성하는 것 뿐이고 평가는 당신들의 몫이다. 정도겠네요
서류 합격 후에 간단한 면접과 더불어 최종적으로 합격하게 됐고 OT또한 다녀왔습니다.


처음 구성원들을 만나는 시간이다보니 SIPE라는 조직에 대한 이해가 부족했는데요 만나 보고서 느낀 것은
동아리보다는 "동호회"에 가깝지 않나? 였습니다.

왜냐하면 제가 OT에서 만났던 모든 분들은 대부분 경력3~4년차의 현직자 분들이셨거든요 
실제로 이번 기수가 대학생을 받은 최초의 기수기도 했습니다.

또 구성원들의 수준또한 굉장히 높다는 생각이 들었습니다.
꿈의 직장이라 생각하는 기업에 재직중이신 분들 또한 많았고 그런 타이틀이 없다 하더라도
대학생인 저의 고민과 경험으로는 그들과 공감할 수 없는 차이가 있다고 느껴졌거든요

그러다보니 괜히 위축되고 "내가 너무 모자라 보이면 어떡하지?" 라는 생각도 들었습니다.

그런데... 사실 어찌보면 당연하거거든요 내가 그들과 비슷하면 대학생안하고 판교에서 개발하고있겠지...
깔끔하게 인정하기로 했습니다. 

누가 나를 멍청하게 보면 어떡하지? -> 나보다 다 똑똑한 사람 밖에 없어?? 완전 럭키비키잖아~

20살때는 술먹고 토해도 누구나 봐주듯이, 대학생 신분을 방패삼아 현업에서 질문하면 큰일날 질문을 하기로 마음먹었습니다.

이제 동아리의 첫 발을 막 디뎠는데요  앞으로 "나"다운 모습을 많이 보여주는 것을 목표로 활동할 것 같습니다.

우잉... 판교 개발자들 부럽당..



사진 첨부하고 마치겠습니다. (직접 만드셨다 들었는데 퀄리티가 좋아서 놀랐습니다)

프로그래머스에서 주관하는 데커톡에 다녀왔습니다.
오프라인 100명을 추첨해 선발하는 방식인데 , 저의 경우에는 블로그를 어필하여 참여할 수 있게 됐습니다.

특히나 참여하고 싶었던 이유는 인프런 CTO로 유명하신 이동욱님의 발표와 실시간Q&A가 가능하다는 점이였습니다.
이동욱님의 발표는 인프콘을 통해서도 겪어봤는데요 사실 인프콘은 너무 큰 행사이다 보니 가까이서 보기에도 또 질문을 하기에도 조금 어려웠거든요

하지만 이번 행사는 소규모로 진행되고 질문하기에도 굉장히 편한 환경이라 정말 마음에 들었습니다.

내용중에 테스트코드에 대한 내용이 나왔었는데요

이것과 관련해 최근 제가 하고있는 고민들에 대해서 질문을 드리기도 했습니다.

Q: 테스트코드라는게 결국에 생산성을 위한 도구라 생각한다. TC를 만듦으로서 유지보수에 들어가는 코스트를 줄일 수 있고 이로인해 결과적으로 생산성이 높아지는 것인데 테스트코드 또한 공짜는 아니라 생각한다.
분명히 개발공수가 들어가는 작업이고 이것은 비용에 해당한다. 그렇다면 어떠한 도구를 도입한다고 했을 때
도입에 필요한 비용보다 생산성의 증가가 더 높다고 판단하는 기준이나 가치관같은 것이 존재하냐?

A-1: 말이 반정도만 맞다. 테스트코드를 작성하는 것은 유지보수에 들어가는 비용을 줄이는 것 뿐 아니라, 개발속도 또한 빠르게 만든다.
테스트코드를 작성하기 때문에 스프링부트 돌려서 톰켓띄우고 포스트맨으로 url치고 바디넣고 요청보내고 결과 확인하고 수정하고... 이런 절차를 생략할 수 있다.

따라서 테스트코드를 작성하는 것이 개발 생산성이 더 높다. 만약 테스트코드를 작성해서 개발속도가 느리다면 그건 테스트코드를 작성하는 것이 익숙치 않아 개발을 못하고 있는거다.

A-2: 어떠한 도구를 도입하는데 가장 중요하게 생각하는 부분은 병목현상을 해결할 수 있는가이다.
A단계 , B단계 , C단계가 존재했을때 C단계에서 병목현상이 발생한다면 A,B단계를 개선하는건 아무런 의미가 없다.
도구를 도입하는 기준은 그 도구가 C단계의 병목현상을 해결할 수 있는가다.

이 과정에서 이동욱님이 말한 개발 생산성에 대한 부분은 생각하지 못하고 있었습니다.
저의 경우에 실제로 개발할때도
코드작성 -> 스프링 실행 -> 컴파일에러 안뜨네? -> 종료 -> 테스트코드 작성 -> 테스트코드 실행 -> push 의 단계를 거칩니다.

그런데 테스트코드 자체를 유지보수성에 초점을 두다보니 코드를 실행하는 것과 검증하는 부분에서의 비용 절감을 놓치고있었습니다.
실제로는 그런식으로 개발을해 그 장점을 누리고 있으면서도요

그 외에도 "동료"로서 중요하게 생각하는 것들, 개발자로서의 성장과정 등등.. 다양한 얘기를 해주셨고 이 또한 굉장히 감명깊었습니다.

그리고 질문을 통해 이동욱님의 저서또한 얻게돼서 기분이 좋네요

또 뒷 세션의 데브코스 팀장님께도 질문을 드렸습니다.

Q: 말씀해주신 내용들이 참여자들이 데브코스를 통해 어떤것을 얻어갈 수 있는지에 대해 중점적으로 설명해 주신 것 같다. 그렇다면 반대로 프로그래머스가 데브코스를 통해 얻어가고 싶은 건 무엇인가?

A: 원래는 개발자 평가쪽만 관여하는 부분이였음, 그러던중 채용까지 확장하게 되었고 교육은 원래 주된 목표가 아니였지만 기업관계자들의 의견을 받게됨 "너네가 평가도 하는데 교육도 해주면 좋을 것 같은데?" 따라서 교육 서비스쪽으로도 기반을 확장하는 과정에 있다.

뿐만 아니라 실제로 데브코스의 커리큘럼을 설계하고 평가를 담당하는 분들의 생각과 의견또한 받을 수 있었습니다.

사실 저는 이런 활동에 참여하기전에 항상 이런 생각을 합니다.
신청도 귀찮고.. 글도 써야하고.. 멀기도하고.. 진짜 도움될지도 모르겠고.. 그런데 항상 참여하고 난 후에는 
그래도 오길 잘했다, 생각보다 재밌네? 등의 생각을 합니다. 여러분도 이런 행사에 많이 참여해보시길 바랍니다.

왠지 모르겠지만 대부분의 사람들이 맨 앞자리에 앉는것을 싫어해 운좋게도 맨앞에서 직관하며 질문또한 할 수 있는 좋은 경험이였습니다.   
그리고 오면 굿즈도 줍니다... 귀여워요

마지막으로 이동욱님과 함께 찍은 사진 올리면서 마무리 하도록 하겠습니다.
몰랐는데 키가 크시더라구요 멋있습니다.

클린 코드는 무엇일까요? 보통 "읽기 좋은 코드"라는 말을 하곤 합니다.
그런데 "읽기 좋다"는 무엇을 의미할까요?

주석을 아예 달지 않으면 읽기 좋은 코드일까요? 이건 좀 아닌 것 같고...
변수의 이름을 잘 짓는 것? 이것만으로는 좀 부족한 것 같고...

이런 고민을 해결하고자 클린 코드 & 테스트 스터디에 참여해 활동한 지 1주 차가 됐습니다.

첫 주차는 객체 지향의 가장 기본이 되는 "추상화"에 대해서 말하는 시간이었습니다.
물리적으로 나뉜 세션은 여러 가지였지만, 다룬 내용들이 대부분 "추상화"를 뒷받침하는 요소였기 때문에 1주 동안 추상화에 대해서 말했다 해도 괜찮을 것 같습니다.

그리고 이 부분은 매우 중요하다고 생각하는 것이, 기본이 곧 쉽다는 의미는 아니기 때문입니다.
기본은 너무나 중요해서 기본이라 부르는 것이지, 쉬워서 기본이라 부르는 것은 아니니까요.

스터디의 진행은 기본적으로 인프런을 통해 온라인으로 학습하고 미션을 통해 학습도를 점검하는 방식으로 진행됩니다.

1주차 미션 자체는 실질적으로 코드를 작성하여 검증하는 느낌은 아니었고, "나는 강의에서 이렇게 말했는데, 너는 어떻게 생각해?"라는 느낌이었습니다.
그 생각을 묻는 질문에 대한 답변이 곧 미션이고, 저의 경우에는 블로그에 글을 기재하는 방식으로 수행했습니다.

https://masiljangajji-coding.tistory.com/66

https://masiljangajji-coding.tistory.com/68

이 글에서 가장 하고 싶은 말은 "클린 코드", "TDD", "DDD" 등은 그저 도구라는 것입니다.
저 모든 것들은 단순히 "이렇게 하면 좋다더라~"를 한 단어로 묶어 개념화한 도구입니다.
따라서 도입하는 것이 생산성을 높이면 도입하면 되는 것이고, 떨어지면? 도입하지 않아도 됩니다.

주석을 달았더니 팀이 코드를 더 쉽게 이해하고 생산성이 증가하는데? -> 그럼 주석을 다는 게 클린 코드입니다.
주석을 다는 행위로 인해 코드의 가독성이 증가했기 때문입니다.

소프트웨어를 개발하는 사람들은 생각도 soft하게 할 필요가 있지 않나 생각합니다.
어떻게 커스터마이징하느냐에 따라서 우리 팀만의 클린코드 컨벤션이 존재할 수 있다고 생각합니다.

한 줄로 정리하면, XX를 하면 클린 코드? XX를 안 하면 클린 코드? 이런 게 아니라,
생산성을 증가시키면 그게 뭐가 됐든 클린 코드라 생각합니다.

강의 내용에 대해서 말하자면 평소에 생각하던 부분들과 일치하는 부분이 많아 그리 어렵지 않게 들을 수 있었습니다.
그런데 가끔 "아, 이렇게도 생각할 수 있네?", "이런 게 기준이 될 수 있겠네?" 하는 부분들이 있어 생각했던 것보다 이미 많은 것을 얻어간 느낌입니다.

사실 강의 자체의 퀄리티가 좋습니다. 

이번 주는 강의를 듣고 미션을 수행하는 것이 조금 버거웠습니다.
강의의 양 자체가 적지 않기도 했고, 더 우선적으로 수행해야 할 과제들이 있어 더욱 그러지 않았나 생각됩니다.

주말 동안 재충전의 시간을 갖고 돌아오는 월요일부터는 다시 달려보도록 하겠습니다.

제가 저번 글에서 다음과 같이 말한적이 있습니다.

https://masiljangajji-coding.tistory.com/66

이러한 말을 한 이유는 클린코드, SOLID , DDD , TDD.... 등등의 것들은 전부 생산성을 위한 것이거든요
아~ 이렇게하면 생산성이 늘어나던데? 좋던데?와 같은 말인것이죠 , 또 그들은 일종의 "상품"으로서 작용되는 부분도 있습니다.
TDD라는 용어가 만들어지기 전까지는 Test코드를 작성을 안했을까요?? 그렇진 않을 것 입니다.


그저 테스트와 관련한 여러가지 산재돼있는 개념을 TDD라는 명칭으로 묶어 만든 일종의 "상품"이라고 생각합니다.
또 이런것들은 전부 생산성을 늘리는 Best Practice중 하나다 라고 볼 수 있습니다.


따라서 우리는 이것을 일종의 원칙이나 법처럼 적용시켜 개발할 이유는 없다고 생각합니다.
당장 내일 새로운 기능을 배포를 해야하는 상황에서 "클린코드를 위해서 리팩토링을 10시간 하겠습니다" 이런 말을 한다면
아마 팀장님한테 혼나겠죠


다른 예시로 "클린코드를 지향하니까 주석은 안답니다"같은 말씀을 하시는 분들이 계십니다.
근데 주석을 안단다고 진짜 코드가 클린해지나요? 조금 의문인 부분도 있거든요

강의에서도 비슷한 말을 합니다. "무조건"이 아니라는 것이죠
개인적으로는 "이런식으로 하면 좋던데??" 정도로 받아들이는 것이 가장 좋지 않을까 생각합니다.

객체를 만들 때 1개의 관심사로 책임이 정의돼있는지 확인하는 것은 굉장히 중요합니다.
저는 개인적으로는 "객체"라는 표현보다는 "타입"이라는 표현을 더 좋아합니다.


클래스를 만든다는 것과 타입을 만든다는 것은 동일한 것인데 어감에서 오는 차이가 크다고 생각하거든요
타입에 대해 말하는 것이 훨씬 더 명확하게 의도가 전달된다 생각합니다.
이 타입이 가져야 할 역할은 무엇이지? , 이 타입으로 나는 무엇을 하고싶지? , 이 타입이 해야만 하는 일은 뭐지? 와 같이 말이죠


int라는 타입을 생각해 봤을 때 마땅히 숫자형 데이터가 해야할 무언가가 떠오르지 않나요?
int 객체라고 하면 그런 부분에서 직관성이 떨어진다 생각합니다.

"setter를 자제하자" 이건 사실 당연한데요 setter로 열려있는 경우에는 누구나 해당 값을 임의로 변경할 수 있기 때문에
최대한 지양하는 것이 좋습니다.

특히 dto같은 경우에는 setter가 더욱 필요 없는데 사용자가 준 값을 내가 임의로 바꿀일이 많지는 않거든요
하지만 재밌는점은 "getter도 사용하지말자"입니다.

사실 getter의 경우에는 그냥 lombok으로 달아놓고 자유롭게 쓰거든요
setter의 경우만 고민을 합니다. 근데 getter도 사용하지말자? 이건 좀 재밌게 느껴졌습니다.

예시를 보면 바로 알 수 있는 부분인데요 1번코드와 2번코드 무엇이 더 직관적인가요?
당연히 2번코드지 않나 생각합니다.

또 관련된 설명을 하면서 이것이 person이라는 객체를 존중하지 않는 폭력적인 코드라는 설명하시는데
이 부분이 가장 흥미있고 재밌었습니다.

쉽게 말하면 객체는 캡슐화돼있는 것인데 getter를 남발하면 캡슐화를 왜 하냐?
getter를 쓸수도 있지만 안쓸수도 있지 않을까?? 라는 것 이죠

참 중요한 걸 얻고 가는데요

"캡슐화돼있는 데이터를 바깥에서 알고있다고 생각하지 말아라"
"우리는 알고있지만 바깥에있는 객체도 알고있을거라 생각하지마"
이것이 캡슐화의 전부인 것 같습니다.

"주니어를 위한 면접질문" 같은 곳에 가면 꼭 등장하는 SOLID입니다.

매우 간단한 코드로도 SOLID를 표현 가능하다 생각하는데요

public class ChefService {

    private final Chef chef; // Interface Chef라는 타입이 해야할 역할을 정의한 Specification

    public ChefService(Chef chef) { // subTyping 이용 , Chef타입의 서브타입을 주입 가능
        this.chef = chef;           // 나는 Korean,American 선택해서 넣을 수 있음
    }                               // 후에 다른 Chef가 추가되어도 생성할때 넣는 인자만 변경하면 됨 OCP , DIP 

    public void makeFood(){
        chef.cook(); // korean,american의 코드가 변경되도 ChefService가 신경 쓸 부분은 아님
        // cook이라는 행위를 Chef에 정의해 둠으로써 통일화된 추상화를 제공함
        // Korean,American의 cook메서드의 내부 구현이 바뀌어도 신경 안써도 됨

    }

}

이 코드로 SOLID의 모든 것을 표현 가능합니다.

DIP = 의존성 역전 원칙 -> 추상화에 의존해라
Chef라는 추상화 정도가 높은 Interface 타입을 받음으로써 ChefService는 추상화에 의존하고있습니다.

그로인해 각각의 Chef를 하나의 모듈처럼 사용가능합니다.
Korean을 넣었다가...American넣었다가... 아니면 다른 Chef을 만들어 주입해도 문제가없습니다.
따라서 OCP 원칙을 지키는 길이기도 합니다.

OCP = 개방 폐쇠원칙 -> 확장은 열려 있고 수정은 닫혀 있다.
Chef 타입 1000개 만들어서 사용해도 생성자 주입할때 들어가는 코드만 변경해주면 문제없음.

public interface Chef {

    void cook(); // 요리하세요
}

public class AmericanChef implements Chef{
    @Override
    public void cook() {
        // 양식요리
    }
}

public class KoreanChef implements Chef{
    @Override
    public void cook() {
        // 한식요리
    }
}

LSP = 리스코프 치환 원칙 -> Super Type이 정의한 근본적인 역할을 따라야 한다.
SuperType인 Chef에 cook이라는 기능이 명시돼 있습니다.
마땅히 요리하는 행위를 생각하겠죠??


근런데 갑자기 KoreanChef의 cook() 메서드를 음식을 먹는 기능으로 변경한다고 해보겠습니다.
이러면 위에서 정의내린 Chef타입의 근본적인 기능이 변경되는 것 입니다.
하지만 우리의 코드는 SuperType이 정의한 "요리" 행위를 잘 하는것으로 보이니 LSP를 지키는 것으로 보입니다.


ISP , SRP = 인터페이스 분리 원칙 , 단일 책임 원칙 -> 하나의 책임만 가져라 
Chef는 요리하는 행위만 신경쓰면 됩니다. 그것이 Chef이라는 타입이 해야할 책임입니다.


그런데 갑자기 Chef에게 drive() 기능을 주면 어떤가요? 요리사라는 타입이 해야할 일인가요??
이경우 SRP가 깨진다고 볼 수 있습니다. ISP도 일맥상통한다 생각합니다.


SOLID 개념은 각각의 것들이 유기적으로 결합되어 있어 SOLID중에 3가지만 만족한다, 4가지만 만족한다, 이런 건 없다고 생각합니다.
하나가 안지켜지면 전체적으로 안지켜지고 하나만 잘 지켜도 전체적으로 완성이되는 개념이라 봅니다.

마지막으로 간단하게 코드를 변경해 보았는데요
개인적으로는, [직관적인 코드 = 읽기 쉬운 코드 = 좋은 코드 = 클린코드] 라는 생각이 있습니다.
그래서 사람에게 말하는듯이 이름을 작성하는 것을 좋아합니다.

특히 boolean 타입의 경우에는 isXXX~ 식으로 많이 작성하는 것 같습니다.

public boolean validateOrder(Order order) {
    if (order.getItems().size() == 0) {
        log.info("주문 항목이 없습니다.");
        return false;
    } else {
        if (order.getTotalPrice() > 0) {
            if (!order.hasCustomerInfo()) {
                log.info("사용자 정보가 없습니다.");
                return false;
            } else {
                return true;
            }
        } else if (!(order.getTotalPrice() > 0)) {
            log.info("올바르지 않은 총 가격입니다.");
            return false;
        }
    }
    return true;
}

읽기쉽게 , 내가 생각하는 clean code로 변경

    public boolean validateOrder(Order order) {

        if (order.isEmpty()) {
            log.info("주문 항목이 없습니다.");
            return false;
        }

        if (order.isTotalPriceNegative()) {
            log.info("올바르지 않은 총 가격입니다.");
            return false;
        }

        if (order.isCustomerInfoMissing()) {
            log.info("사용자 정보가 없습니다.");
            return false;
        }

        return true;
    }