같이 일하고 싶은 개발자

본 내용은 인프런 - 백기선님의 리팩토링 강의를 듣고 정리한 내용입니다. 1. 짧은 함수 vs 긴 함수 함수가 길 수록 오히려 더 이해하기 어렵다. 그 이유는 긴 함수의 각 각 문장들을 해석하기 위해 에너지를 많이 써야하고 다양한 함수의 네이밍에 사용된 단어들을 해석하는데 사람마다 지식이 달라 다른 방향으로 해석될 여지가 있다. 짧은 함수는 더 많은 문맥 전환을 필요로 한다. "과거"에는 작은 함수를 사용하는 경우 더 많은 서브 루틴 호출로 인한 오버헤드가 있었다. (그러나 "오늘"에서는 미미함 ) 작은 함수에 "좋은 이름"을 사용했다면 해당 함수의 코드를 보지 않고도 이해가 가능하다. 어떤 코드에 "주석"을 남기고 싶다면, 주석 대신 함수를 만들고 함수의 이름으로 "의도"를 표현해보자 해당 내용에 사용..

효율적으로 코드를 짜기 위해선 앞서 설명한 네이밍 관련 규칙들과 중복된 코드를 줄이는 것이 중요합니다. 이번 챕터에서는 중복된 코드를 줄일 수 있는 방법론 들을 설명했습니다. 중복코드의 단점은 코드의 변경 시, 동일한 모든 곳의 코드를 변경해야합니다. 이러한 단점을 개선하기 위해 사용할 수있는 리팩토링 기술은 다음과 같습니다. Extract Funcation ( 함수 추출 ) - 동일한 코드를 여러 메소드에서 사용하는 경우 Slide Statements ( 코드 분리 ) - 비슷하게 생겼지만 완전히 같지는 않은 경우 Pul Up Method( 메소드 올리기 ) - 여러 하위 클래스에 동일한 코드가 있다면 메소드 올리기 1. 함수 추출하기 "의도"와 "구현" 분리하기 의도와 구현? 어떤 일을 하려는지

우리는 코딩을 처음 시작하면 변수명, 메서드명, 클래스 명 등등 여러가지 이름을 고민해서 짓기 마련입니다. 당연히 이름을 지을 때, 해당 기능이나 단위 등 명확하고 직관적인 이름을 짓고싶을 것입니다. 그러나 시간이 지나면 왜 이렇게 지었을까? 라는 의문이 들기도 하지만 우리는 그 순간에 최선을 다해서 네이밍을 했을 것입니다. 위에서 발생한 문제를 해결하기 위해 3가지의 리팩토링 기술을 전수해주고 있습니다 1. 함수 선언 변경하기 (Change Function Declaration) 함수 이름 변경, 메소드 이름 변경, 매개변수 추가,삭제, 시그니처 변경 당연히 좋은 이름을 가진 함수는 이름만 보더라도 이해가 가능할 것이다. 그럼 과연 좋은 이름을 찾아내는 방법이란 무엇인가? - 함수에 주석을 작성한 다음..

[ 바로가기 목차 ] 들어가기 알아보기 마무리 [ 들어가기 ] 여러 테이블 혹은 DB에서 데이터를 가져와서 원하는 작업을 하는 방법에는 여러가지가 있습니다. 가져온 데이터를 원하는 형식이나 여러 객체를 하나의 객체로 합치는 일은 매우 흔한 일입니다. 이때 이러한 매핑 작업을 직접 개발자가 하게 된다면 문제가 발생할 수 있습니다. - 코드의 중복 - 생산성 저하 - 실수로 인한 데이터 누락 - 복잡한 로직까지 추가된다면 코드 가독성 저하 이러한 문제를 해결하기 위해 스프링(Spring)에서는 라이브러리를 지원합니다. - Mapstruct - ModelMapper 맵 스트럭트(MapStruct) 와 모델 매퍼(ModelMapper)의 차이점을 간단하게 설명하자면 객체의 생성 방식에 조금의 차이를 가지고 있습..

[ 목차 ] 들어가기 레이어드 아키텍쳐 장점> 참고 레퍼런스 [ 들어가기 ] 개발자는 어떻게 하면 더욱 코드를 효율적으로 작성하고, 유지보수가 쉽고, 성능이 좋은 코드를 작성할 수있을지 고민을 해야합니다. 이러한 내용을 바탕으로 서비스를 개선하고, 기술이 변하더라도 쉽고 빠르게 대응 가능하고 좋은 코드를 만들 수 있습니다. 이러한 고민속에는 아키텍쳐 설계가 코어로 자리잡고 있다고 생각합니다. 아키텍쳐를 설계하다보면 자연스레 계층과 관련된 레퍼런스를 접할 수 있습니다. 결국 잘 설계된 아키텍쳐를 기반으로 품질이 좋은 코드와 유지보수가 좋은 코드, 유연성 있는 소프트웨어가 나온다고 해도 과언이 아닙니다. 저 역시도 Layered architecture과 같은 내용을 많이 접했습니다. 그래서 과연 Layere..

서론 본론 결론 서론 다들 트랜잭션에 관한 고민을 해보신 적이 있으신가요? 저는 서비스 로직을 짜거나, TestCode를 작성하거나 JPA와 같은 ORM을 사용할 때 트랜잭션에 대한 고민들이 많이 있었습니다. " 어떤 단위까지 한 트랜잭션으로 간주해야 할 까?" " 외부 API를 호출하는 로직에서 만약 트랜잭션을 걸고, 해당 로직에서 문제가 발생하면??" " 만약 A 라는 서비스 로직에서 @Transactional 어노테이션을 추가하거나, 추가 하지 않거나 두 결과값이 어떻게 다를까? " " 그럼 과연 어느 서비스 로직에서는 @Transactional을 추가해야하고, 어떤 서비스 로직에서는 추가하지 않아야 할까? " 이렇게 다양한 고민들이 있었습니다. 오늘은 제가 입사하고 맡은 업무에서 경험한 트랜잭션과..

올해 상반기에 대학 졸업 이후 취업에 성공하고 백엔드 개발자로 일한 지 어느덧 3개월이라는 시간이 흘렀습니다. 이 과정에서 많은 일이 있었고, 많은 것을 경험하고 느끼며 내가 개발자로서, 어른으로서 더욱 성장할 수 있었습니다. 치열한 현장에서 직접 땀을 흘려보니 과거의 노력이 값진 순간임을 알게 되었고, 겸손하고 더욱 노력해야 함을 알게 되었습니다. 학부 시절에 작은 프로젝트를 진행하면서 느낀 부분들과 현업에서 느끼는 부분은 크게 다르지는 않았지만, 그 '농도'는 달랐습니다. 자신의 직군에서 다른 직군을 이해하기는 어렵습니다. 그러나 특히 현업에서는 그러한 이해관계들이 매우 중요하고 좋은 관계를 유지할 수 있도록 노력해야합니다. 그러나 이 이상적인 내용을 적용하기 어려운 상황도 분명히 존재하기 마련입니다..

10장 클래스사실 클래스 챕터에서는 우리가 기존에 아는 내용을 다시 한번 리마인드 하는 형식으로 알려주고 있다.이 챕터를 이해하려면 결국 응집도와 결합도 그리고 SOLID 원칙이 무엇인지 한번 더 확인하고 해당 챕터를 학습하는 것이 좋겠다.클래스는 작아야 한다.단순히 메서드 수가 작은 것이 아니라 책임의 수가 작아야 한다.여기서 적용되는 원칙은 단일 책임 원칙 (Single Responsibility Principle, SRP)클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙여러 책임을 하고 있는 클래스보다는 한 책임을 다하고 있는 여러 클래스의 상호 작용과 협력을 이용해 시스템에 필요한 동작을 수행해야 함.응집도 ( Cohesion )클래스는 인스턴스 변수가 작아야 한다.응집도가 높다는..

과거에 테스트 코드 관련 글을 정리한 것이 있어 링크만 첨부하고, 책에서 뽑아온 내용만 기입도록 하겠습니다.  단위 테스트 ( Unit Test )클린코드의 9장에서는 단위 테스트 ( Unit Test )에 대해서 다루고 있습니다. 💡 개발자들은 테스트 코드가 주는 이점을 잘 알고 있습니다. 그러나 잘못된 테스트 코드를 작성하거나 우리가 의도한 바를 정확하게 표현하지 못하면 100%의 효율성을 내기 어렵습니다. 그래서 많은 개발자들이 테스트 코드를 작성하다 쉽게 포기하곤 합니다. 우선 테스트를 작성하면 다음과 같은 이점을 얻을 수 있습니다.유연성유지 보수성재사용성이러한 이점으로부터 얻을 수 있는 것이 무엇이냐? 바로 쉬운 변경입니다.왜 쉬운 변경이라는 이점을 얻을 수 있을까요? 💡 제가 생각하기엔 한..

Chapter.7 오류 처리 예외를 던지고 코드를 분리함으로써 각 개념을 독립적으로 이해할 수 있습니다. 오류로 코드를 처리하게되면 코드의 가독성이 낮아지고 계층의 깊이가 깊어집니다.그래서 예외를 던지는 것이 더욱 좋습니다. 💡 Checked Exeption(확인된 예외)는 OCP (Open Closed Principle)를 위배한다.메서드에서 확인된 예외를 던졌는데, Catch 블록이 3단계 위에 있다면 그 사이 메서드 모두가 선언부에 해당 예외를 저의해야 한다.즉, 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 함을 의미한다.결국 하위 메서드나 함수에서 throws를 선언해줘야 한다.그래서 미확인 예외 (Unchecked Exeption)을 사용해야합니다. 확인된 예외(Che..