같이 일하고 싶은 개발자

서론 본론 결론 서론 다들 트랜잭션에 관한 고민을 해보신 적이 있으신가요? 저는 서비스 로직을 짜거나, 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..

Chapter.6 객체와 자료구조 💡 이번 CHAPTER에서는 객체와 자료구조에 대한 이야기를 하고 있습니다. 먼저 변수를 Private(비공개)로 만드는 이유를 “남들이 변수에 의존하지 않게 만들고 싶어서”라고 이야기 하고 있습니다.여기서 곰곰히 생각해보았습니다. 왜 변수를 Private으로 만드는가?저는 여기서 떠오르는 키워드가 정보은닉(Data hiding) 밖에 없었습니다.접근을 제한하기 위해서 ( Access Modifier )Public 은 외부에서 접근 가능, Private는 외부에서 접근 불가능코드로 간단히 이해해보겠습니다.public class Test{ public static void main(String[] args) { Car car = new Ca..

예시를 이용한 형식 이해하기들여쓰기5장 형식 맞추기개발은 혼자 하는 것이 아닌, 여러 사람이 진행합니다. 그래서 형식을 논의하고 다 같이 맞추는 것이 매우 중요합니다. 프로젝트의 전반적인 완성도는 사전에 협의된 형식에서부터 시작합니다. 팀 단위로 약속한 형식을 지키는 것이 코드의 품질을 결정하고 향후 Next Step으로 나아가기도 훨씬 수월합니다. 그래서 코드의 형식을 맞춤으로써 우리는 상대방과 의사소통하며 원활하게 맡은 업무를 진행할 수 있습니다. 예시를 이용한 형식 이해하기우리는 코드를 작성하거나, 읽을 때 TOP에서 BOTTOM으로 이동하고 있으며, IDE 내부에 있는 형식을 일반적으로 활용하고 있습니다.  위 코드를 살펴보면 저자가 강조하는 형식이 잘 지켜짐을 확인할 수 있습니다.신문 기사처럼 ..

목차서론주석은 양날의 검? 저자가 말하는 좋은, 나쁜 주석이란 무엇일까? 4장 주석서론주석이라는 chapter를 읽으면서 주석이 왜 필요한지에 대해 생각해보았습니다. 개발자가 작성하는 코드는 개발자의 배경과 경험, 지식 등을 반영하여 탄생합니다. 그래서 개인이 작성한 코드는 제 각각일 것입니다. 이러한 제 각각의 코드가 하나의 프로그램에 합해진 형태로 존재하는데, 만약 작성자에 비해 경험과 수준이 부족하거나, 다른 협력자들이 코드만 보고 작성자의 의도를 바로 이해할 수 있을까요? 아마 이해하는데 적지않은 시간이 소요되거나, 추가적인 설명 및 잘못된 네이밍으로 코드들은 직관적이지 못할 수 있습니다. 이럴 때 주석은 큰 힘을 발휘합니다. 일반적으로 주석은 작성한 코드에 타인이 이해하기 어렵거나, 해당 로직이..

3장 함수 chapter에서 가장 중요한 내용은 작게 만들어라, 그리고 한 가지만 해라" 입니다 1. 작게 만들어라, 그리고 한 가지만 해라public static String renderPageWithSetupsAndTearDowns(PageData pageData, boolean isSuite) throws Excetpion{boolean isTestPage = pageData.hasAttribute("test"); if(isTestPage){ WikiPAge testPage = pageData.getWikiPage(); StringBuffer newPageContent = new StringBuffer(); includeSetupPages(testPage, newPageContent, isSu..

해당 chapter에서 가장 강조하는 바는 “의미있는 이름”입니다. 좋은 코드를 만들어 내기 위해서 우리는 하루에 최소 2번은 고민합니다. 왜 좋은 코드를 만들어 내기 위해 고민할까요? 과연 그럼 좋은 코드란 무엇일까요?? 우리는 이 문제의 답을 이미 알고 있습니다. 좋은 코드가 필요한 이유는 다음과 같습니다.향후 제 3자가, 혹은 작성자가 유지 보수를 편히 할 수 있게 하고, 잘못된 이름에서 발생하는 Side Effect를 고려빠르게 변화는 비즈니스 영역에 대응하기 위해서 등등 이러한 문제점을 해결하기 위해 우리는 좋은 코드를 만들도록 노력합니다.그럼 우리가 말하는 좋은코드란 무엇일까요? 흔히 말하는 좋은 코드는 가독성도 좋아야 하고, 변경도 쉬워야 하고, 재사용성이 높고, 효율적인 코드라고 알고 있을..