본문 바로가기

전체 글

(154)
클린코드 7장 : 오류 처리 이 부분의 요약은 생각보다 간단하고 사례들이 중요했다. 다음과 같은 방식을 통해 코드를 깔끔하게 하고, 안정성을 높이는 걸 권장한다. 예외를 사용해라. - 오류 코드는 코드를 복잡하게 한다. 예외를 이용하면 코드가 깔끔해진다. - 예외가 발생하는 코드는 일단 try-catch로 시작해라 예외클래스 - 아래처럼 예외를 잡아 변환하는 감싸기 클래스로 예외클래스를 만들면 매우 편리하다. - 외부 API를 사용하는 경우, 예외 클래스를 설정하고 그 안에 외부 API 클래스를 넣는다. 이 방법은 라이브러리 전환 시 의존성 최소화, 테스트 코드 작성의 편리함, 예외 처리를 통일할 수 있는 이점을 가진다. // 오류를 형편없이 분류한 사례 ACMEPort port = new ACMEPort(12); try{ port..
[유튜브] 소프트웨어 아키텍처의 중요성 위 영상은 마틴 파울러씨가 좋은 아키텍처에 대해서 설명하는 내용이다.짧은 영상이라 내용은 간단하지만, 말하는 내용이 명확하고 핵심을 찔러서 정리해본다. 아키텍처의 정의 The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles governing its design and evolution:시스템의 구성 요소, (시스템 및 구성요소의) 상호 관계 및 환경과의 관계, 시스템의 설계 및 진화를 관리하는 원칙으로 구현되는 기본 조직ANSI / IEEE 1471-2000 IEEE(Institute of Elect..
클린코드 6장 : 객체와 자료구조 변수를 비공개로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다. 그렇다면 어째서 수많은 프로그래머가 조회(get) 함수와 설정(set) 함수를 당연하게 공개(public)해 비공개 변수를 외부에 노출할까? 자료 추상화 // 6-1 : 구체적인 point 클래스 public class Point { private double x; private double y; } // 6-2 : 추상적인 point 클래스 public interface Point { double getX(); double getY(); void setCatesian(double x, double y); double getR(); double getTheta(); void setPolar(double r, double..
클린 코드 5장: 형식 맞추기 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야한다. 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 적절한 코드 길이 - 파일 크기(행 수) : 작을 수록 좋다. 위처럼 대규모 프로젝트들도 평균 65줄, 대부분 200줄 이하로 구성되어 있다. - 행 길이 : 작을수록 좋다. 대부분 80자가 넘지 않는다. 저자도 120자 이를 권한다. ※ JUnit, FitNesse, testNG, Time and Money, JDepend, Ant, Tomcat의 조사 결과를 기반으로 함. 신문 기사처럼 작성해라 - 신문기사는 제목 -> 요약 -> 세부 내용 순으로 작성된다. - 코드 또한, 이름 -> 개념/알고리즘 -> 세부 내용 순으로 묘사하면 읽기 쉽다. 세로 밀집도(세로로 코드를 짜..
클린코드 4장 : 주석 잘 달린 주석은 그 어떤 정보보다 유용하다. 오래되고 조잡한 주석은 거짓과 잘못된 정보를 퍼트려 해악을 미친다. 저자는 주석을 써야할 때가 분명 있지만, 가능한한 줄이는 걸 권장한다. 특히, 오래된 주석, 잘못된 주석을 경계하라한다. 주석은 나쁜 코드를 보완하지 못한다. - 코드가 읽기 힘들고 짜임새가 나쁘다면, 주석을 달지 말고 코드를 정리해라. - 주석이 아니라 코드로 주석을 표현해라 좋은 주석 - 법적인/ 정책상 필요한 주석 : 이는 코드에서 나타날 수 없어서 최상단에 쓰면 좋다. - 정보 제공 주석 : 날짜형식 등 부가정보를 전달할 때 쓰면 좋다. - 의도를 설명하는 주석 : 알고리즘을 왜 이렇게 짰는 지 등 로직의 의도를 설명해야할 때 쓰면 좋다. - 의미를 명료하게 설명하는 주석 : 라이브러리..
클린 코드 3장 : 함수 클린 코드 3장 함수에 대한 인용과 부가 설명 요약 그리고 내가 한 잘못들에 대해서 서술해보았다. -는 저자의 생각을 요약한 것. *는 내 경험에 의한 부가설명 및 반성이다. 본문 작게 만들어라 - 저자의 경험 상, 함수는 작을수록 좋다. 어느정도 작냐면 20줄보다도 작은 게 좋다한다. 들여쓰기는 1단,2단까지만 : 더 들어가면 가독성이 나빠진다. * if문 두 개 겹쳐있으면, 진짜 읽고싶지 않다. 매우 동의한다. 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. - 함수 내에 또 다른 함수를 뽑아서 이름을 붙일 수 있다면, 한 가지만 하는 것이 아니다 - 함수 내 추상화 수준이 동일해야한다 (아래 부가 설명) 함수 내 추상화 수준이 동일해야한다. - 추상화 수준이..
컴포넌트는 어떻게 설계해야할까? 컴포넌트를 어떻게 설계해야할까? 요즘 최대 고민이고, 이에 대한 내 의견을 적어두려합니다. 자문자답인 만큼 더 많은 경험에 의해서 바뀔 수 있으며, 중간 정답으로 봐주시면 좋을 거 같습니다. 글을 읽고 피드백을 해주신다면, 정말 감사합니다. 컴포넌트란?컴포넌트는 화면의 구성요소를 의미한다. 작은 단위로는 button, input 등이 있을 거고 점점 커져가서 dropdown, header, carousel, 화면 그 자체 등 화면에 보이는 거의 모든 요소가 컴포넌트가 될 수 있습니다.  그러면 컴포넌트는 왜 나누는 걸까요?보통은 "복잡성을 줄이기 위해서"과 "반복되는 코드를 줄이기 위해서 (재사용성을 통해 생산성을 높이기 위해서)" 나누게 됩니다. 1. 복잡성을 줄이기 위해서구글 코드가 20억줄이라 하는..
다시 시작하는 블로그 지금까지 나는 글을 쓰지 못하고 있었다. 본질적인 의문이 들었기 때문인데, 어느 순간부터 블로그의 글 쓰는 것에 집착하는 거 같았다. "나는 왜 블로그에 집착을 할까?" 라고 스스로에게 물어보니, "면접 때, 서류 때 잘보일려고 쓰는 거 같아"라는 답이 하나 나왔다. 이 답에 자괴감이 들어서, TIL (Today I Learned) 하던 것도 멈추고, 블로그 글도 못 쓰게 되었다. 그 이후, 4개월의 시간이 지났다. 블로그를 운영하면서 얻은 다양한 이점들을 자각하게 되었고, 다시 블로그를 운영해야겠다 결심이 섰다. 내가 얻은 다양한 이점들은 아래와 같았다. 1. 정확한 정보와 출저가 존재한다. - 나는 생각보다 부정확한 정보에 대해서 굉장히 겁을 낸다. 그래서 최대한 공식문서나 공식적인 기관의 글을 기준..