Sn._.Jay

- 요즘 공부를 하면서 전회사에서 꼴에 클린 코드를 지향하며 하였지만 개발자들 간에 규칙을 정하지 않고 문서화를 하지 않으시는 분들이 많아 깨끗한 것과 거리가 멀어졌었는지를 느낀다.. 다시 그 때를 복기하고 지금과 비교하며 책을 정리해본다 관심사 분리 어플리케이션을 서로 겹치지 않는 개별 단위로 나누는 과정 즉 잘게 잘 쪼개야한다는거 이 때 객체를 생성하거나 의존성을 연결할 때 모듈성이 깨지지 않게 해야하고 관심사를 잘 분리해야 이를 높게 유지할 수 있다. 시스템 생성과 시스템 사용을 분리해야한다. 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮긴다. 모든 의존성이 main에서 애플리케이션으로 향한다. 애플리케이션은 main이나 객체가 생성되는 과정을 모른다. 애플리케이션은 모든 객..

외부 라이브러리를 사용하는 것에 대한 이야기 외부 라이브러리를 사용하는 부분을 Wrapper Class로 따로 감싸줘야 한다. 앞서 예외 처리를 한 원리와 동일하게 라이브러리의 값이 바뀌게 되더라도 사용하는 쪽에서 변경할 사항이 없도록 클래스 내부에서 처리해야 한다. 그리고 Map이 가지고 있는 무수한 function들이 많은데 그냥 바로 HashMap()으로 개발 수 있게 하면 안에 모든 function을 난잡하게 사용할 수 있게 되는데 Wrapper class을 사용해서 통제하며 개발하면 특정 function만 사용하며 개발할 수 있도록 개발이 가능하다. // Before Map sensors = new HashMap(); // Sensor가 필요한 객체 코드는 이렇게밖에 받지 못 한다. Sensor..

필자는 '깨끗한' 예외 처리가 클린 코드를 위한 요소 중 하나라고 말한다. 그리고 이를 위한 '깨끗한' 오류 처리의 기준은 아래와 같다. 오류 코드를 반환하지 말고 예외 처리를 하라 이는 예컨데 DeviceHandle.INVALID와 같은 오류를 값으로 return하고 받지 말고 try..catch로 묶어야 한다. try.. catch를 사용하라 try .. catch 문 자체가 트랜잭션과 같이 범위를 정의할 수 있어 구조적으로 깔끔해진다. 미확인 예외를 사용하라 이건 뭔가 반대로 생각했었던거임 필자는 확인된 예외는 OCP(Open Closed Principle)을 위반한다고 한다. OCP (개방폐쇄원칙) : 확장에는 열려있어야 하고 변경에는 닫혀있어야한다. 이는 메서드에서 추가로 확인된 예외를 던졌는데..

3. 주석 - 저자는 주석에 대해 Clean Code를 코드로만 달성하는 것이 실패해서 넣는 것을 주석이라고 말한다. - 특히 그는 주석은 오래될 수록 실제 돌아가는 코드와 멀어지게 되며 프로그래머들이 주석까지 다 유지보수를 하기엔 쉽지 않다고 말하고 있다. 주석은 애시당초 처음부터 나쁜 코드는 보완하지 못 한다. 코드로 의도를 표현해야 한다. // 직원에게 복지 혜택을 받을 자격이 있는지 검사한다. if ((employee.flags & HOURLY_FLAG) && (employee.age > 65)) { ... } if (employee.isEligibleForFullBenefits()) { ... } 처음부터 주석으로 설명해야만 하는 코드가 아닌 후자처럼 주석이 필요없는 코드가 이상적이다. 그나마 ..

2. 함수 - 이 내용은 TDD, Clean code 스터디 할 때 배웠던 내용이 다수 있다. 함수는 최대한 작게 하라 하나의 기능만 들어갈 수 있도록 함수 당 추상화 수준은 하나로 해야한다. 즉 if안에 if 넣지 마라 애시당초 if안에 if가 들어가게 되는 구조라면 하나의 function에서 multi 기능을 담당하고 있는 것이다. Switch문이나 if / else if 등으로 붙는 코드들은 이렇게 지키기는 어렵다고 필자도 인정한다. 그래도 다형적 객체를 생성하는 코드에 한해서만 인정하고 있다. 같은 모듈내에서의 함수는 어느정도의 일관성이 존재해야한다. 같은 문구, 동사, 명사를 사용하는 것 처럼 함수 parameter는 3개부터는 가급적 피해야 하고 4개 이상은 반드시 이렇게 해야하는 이유가 있어..

1. 의도가 분명하게 이름을 지으라 변수나 함수, 클래스 이름은 다음 질문에 답할 수 있어야 한다. 존재 이유는? / 수행 기능은? / 사용 방법은? 즉 magin number와 같은 그래서 왜 status가 3이면 안 되는데? 같은 의문을 낳으면 안 된다. 그릇된 정보를 담으면 안 된다. 여러 계정을 그룹으로 묶을 때 List로 담는게 아닌데 accountList로 변수명을 선언해선 안 된다. 그리고 억지로 단어를 약어로 줄여 헷갈리게 해서도 안 된다. 의미 있게 구분하라 function parameter들을 input1, input2 이런 식으로 선언해선 안 된다. 개념은 구분하지 않은채 이름만 달리한 경우도 없어야 한다. ProductInfo, ProductData로 변수를 다르게 선언한 경우 ge..

- 새로운 회사에 들어오고 한동안 책을 읽지 못 한 나에게 가장 먼저 떨어진게 매주 진행하는 클린코드에 관한 책을 읽는 스터디 같이 하자는 것이였고 읽으면서 무릎 탁 치게 만드는 건 정리하고자 함 - 책의 시작은 개발자 우리 모두가 알지만 우리 모두가 같은 이유로 잘 지키지 않고 있는 클린 코드를 왜 지켜야하고 계속 끊임없이 생각해야하는지 정말 많은 사례를 가져오며 역설하고 있다. 나도 전 회사에서 정말 고착화된 레거시 코드를 일단 새로 계약을 따야하고 고객을 유치해야 한다는 명목아래 방치했다가 고착화된 레거시 코드가 결국 추후 서비스 개선을 위한 기획에 영향을 주어 진행조차 못 하게 막을 수 있다는 것을 봤기 때문에 책을 안 보지 않아도 그 때의 기분과 생각이 나에게 알랴준다 ㅠ 그리고 이런 레거시 코..

- 이전 플젝에선 Webpack을 사용하다가 다음 회사에서 Kubernetes를 사용하게 됨에 따라 공부하던 와중 webpack을 근본적으로 왜 사용하게 됐을 까를 알기 위해 정리함. (이를 위해 앞의 1에서 stream에 대한 개념을 잡았다.) task runners / package bundler와의 차이 Package Bundler : 종속성을 가진 어플리케이션 모듈을 정적인 소스로 재생산 Task Runner : 반복 가능한 특정 작업들을 단순 자동화한 것 즉 소스들을 하나의 패키지화 하는 것이 Webpack이고 Gulp는 미리 정의해 놓은 어떠한 작업들 (배포, 테스트와 같은)을 자동화하여 실행하는 것임 - node.js 기반의 task runners로 자동화된 빌드 툴로 알면 된다. 이 때 n..

- python, typescript로 개발되었던 기존 프로젝트에서는 webpack을 통해 개발, 관리되었음. 그리고 이제 node기반 typescript로 이루어진 개발 프로젝트에 붙게 되면서 typescript, node 공부를 하면서 이것저것 하다가 습관적으로 kubernetes로 관리된다고 하셨던 말을 까먹고 webpack으로 개발하다가 다시 엎어야하는 것을 기념삼아 정리함 - 공부하면서 쿠버네티스랑 차이점이 궁금하면서 생각해보니 webpack이 구체적으로 어떻게 돌아가는지 궁금해짐 -> 그러면서 gulp랑은 또 차이가 뭐지 궁금해짐 -> 일단 대충 찾아보니 gulp 방식이 stream 방식이네 이거 지금 공부하는 node에도 나오에도 나오던데 - 정리 순서 노드의 stream 그렇다면 gulp..

- 일단 테스트 Project을 간단히 만들기 위해 Express를 통하여 web project 생성 - Express 모듈 : 웹 어플리케이션을 개발할 때 가장 대중적으로 사용되고 있는 모듈이고 http 모듈에 비해 기능이 많음 + jade, ejs 같은 동적 웹 페이지 파일을 지원하고 있음 - express 기본 기능 express() : express 모듈에서 제공하는 기능을 사용할 수 있는 객체를 반환하는 함수 @get / @post : get/post 방식으로 요청이 발생했을 때 호출될 함수를 등록 listen() : 서버 가동 - 라우팅? 사용자 요청에 따라 응답 결과를 달리 전달하는 것을 라우팅이라고 한다. app.get("/page", function(req, res){ res.render..