같이 일하고 싶은 개발자

결론 선 공개개인과 팀의 성장의 영양분으로 애자일이라는 방식을 채택했다면 애자일적 사고 방식이 중요하다.애자일을 애자일 다운 방식으로 도입하는 것은 중요하다.본론가을의 냄새가 물씬 풍겨오는 어느 오후였습니다, 팀 동료와 합법적인 월급 루팡??을 하다가 이직과 관련된 이야기가 나왔습니다. 티타임이라 쓰고 합법적인 월급 루팡이라 읽는 현장을 다 같이 보시죠 본인 : 만약에 다음에 이직을 하게 된다면 어떤 도메인으로 가고 싶으신가요?팀 동료 : 가고 싶은 도메인이 특정해 있진 않은데 피하고 싶은 도메인은 있습니다본인 : 혹시 이런 상상 해보신 적 있으신가요? 만약 지금의 회사의 제휴사으로 이직하는 상상...팀 동료 : 해본적 있습니다... 재잘재잘.... 본인 : 우리 회사에 내가 제휴사로 미팅라하려고 온다?..

취업 후 쉴 새 없이 달려오다보니 어느덧 2년차 백엔드 개발자가 되어 있었습니다.그동안 많은 일들도 있었고 다양한 영역의 지식과 도메인의 지식을 흡수하면서 나름대로 이제 어떤 문제가 발생해도 잘 해결할 수있으리라 생각했습니다.   그러나 개발이라는 거대한 야생에서는 얕은 지식만으로 해결되지 않는 문제들이 정말정말정말 많습니다. 한번은 어플리케이션 영역을 넘어선 인프라적 문제가 발생했던 경험이 있습니다. 당연히 인프라적 인사이트는 저에게 개방되지 않은 미지의 동굴과 같았기에 어떻게 해결할 수있는지에 관한 문제 해결 능력과 경험치가 부족했고 잘 모르는 영역이다보니 생각을 확장하기가 어려웠습니다. 어떻게 하면 조금 쉽고 편하게 지식을 습득하고 내가 가진 궁금증들에 관한 생각들을 확장할 수 있을까?에 관한 답변..

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를 고려빠르게 변화는 비즈니스 영역에 대응하기 위해서 등등 이러한 문제점을 해결하기 위해 우리는 좋은 코드를 만들도록 노력합니다.그럼 우리가 말하는 좋은코드란 무엇일까요? 흔히 말하는 좋은 코드는 가독성도 좋아야 하고, 변경도 쉬워야 하고, 재사용성이 높고, 효율적인 코드라고 알고 있을..