꿀팁 저장소

지난 3개월 동안 cafe24의 node.js호스팅을 사용하며 느낀 점들을 소개할까 합니다.

장단점이 있었습니다.

1. 장점

 - 가벼운 홈페이지 운영정도를 생각한다면 저렴한 가격으로 구축 가능하다는 것

 - 무엇보다 장점은 다른 세팅없이 node.js프로젝트만 구축해서 올리면 된다는 것

( 다른 세팅이라 하면, 포트포워딩이나 nginx설정 등 기타 작업들을 말합니다.)

 - 안정적인 서버를 저렴하게 구축할 수 있다는 것

2. 단점

 - 서비스 확장을 위해서는 상위 가격의 제품을 써야만 한다는 것(cafe24에 의존적)

(nginx 설정 등을 통해, 직접 load balancing등을 구현하는 것은 불가능 합니다. 일반적인 웹호스팅이라고 보시면 됩니다.)

 - 치명적인 단점으로 .env를 통해 환경변수에 접근할 수 없다는 것

(cafe24에서 자체적으로 사용해서 저희는 쓸수 없다고 하네요)

 - 보통 클라우드 서비스나, 서버호스팅과 달리 node_modules 폴더를 푸시할때 같이 올려야 한다는 것

(push하는데 엄청난 시간이 소요됩니다. 거의 뭐 5분... node_modules를 올리지 않으면 당연히 에러가 발생합니다 npm install같은 행위는 저희가 할수 없기 때문입니다.)

 - 디렉토리 구조에서 web.js(http혹은 https서버를 실행시키는 스크립트파일) 를 반드시 root directory에 위치시켜야 한다는 것

저는 앞으로 정말 가벼운 서비스를 운영할 때는 이용할지도 모르겠습니다만, 글쎄요...

개인적인 의견으로는 node.js는 aws서비스를 이용하시는것이 아무래도 정신건강에 이로운것 같습니다.

ps. cafe24의 고객센터 서비스는 정말 응답이 빠릅니다.  이 부분은 서비스 이용간 가장 만족스러운 부분이었습니다.

11장. 시스템

본 장은 필자가 이해에 있어 가장 어려움을 겪고있는 장이다. 핵심이 빠질수 있으며, 요약내용의 전달력이 떨어질 수 있으니 양해바랍니다.

 - 시스템을 제작하는 것과 사용하는 것은 아주 다르다. 이 의미를 여러번 곱씹어 생각해보길 바란다.

 - 시스템을 생성과 사용을 분리하는 한가지 방법으로는, 생성과 관련한 코드는 main(프로그램 실행시 돌아가는)이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 모든 의존성이 연결시킨다. 그리고 애플리케이션은 그저 객체를 사용하면 될 뿐이다. 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모른다.

 - TDD와 리팩토링으로 얻어지는 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다.하지만 시스템 아키텍처는 사전 계획이 필요하다. 단순한 아키텍처를 복잡한 아키텍처로 조금씩 키우는건 불가능한 것이 현실이다.

 - 코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 TDD아키텍처 구축이 가능해진다. 그때그때 새로운 기술을 채택해 단순한 아키텍처를 복잡한 아키텍처로 키워갈 수 있다. BUDF(구현 전 모든 사항을 설계하는 기법)를 추구할 필요가 없다.

 - 아주 단순하면서도 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 재빨리 출시한 후, 기반 구조를 추가하며 조금씩 확장해 나가도 괜찮다.

 - 반드시 그런것은 아니나 결정을 마지막 순간까지 미루는 방법은 최선이다. 게으르거나 무책임해서가 아니라, 최대한의 정보를 모아 최선의 결정을 내리기 위함이다. 성급한 결정은 불충분한 지식으로 내린 결정이다. 너무 일찍 결정하면 고객 피드백을 더 모으고, 프로젝트를 더 고민하고, 구현방안을 더 탐험할 기회가 사라진다.

[출처] 클린코드 - 로버트C.마틴 지음

10장. 클래스

 - 클래스를 만들 때 첫번 째 규칙은 크기다. 클래스는 작아야 한다. 두번째 규칙은 더 작아야 한다.

 - 클래스의 이름은 클래스의 책임을 기술해야 한다. 실제로 작명은 클래스의 크기를 줄이는 첫 관문이다. 클래스를 표현할 간결한 이름이 떠오르지 않는다면 필경 클래스의 크기가 너무 커서 그렇다. 혹은 클래스의 이름이 모호하다면 클래스의 책임이 너무 커서 그렇다.

 - 단일책임원칙(SRP)를 잊지말자. 클래스나 모듈을 변경할 이유는 단 하나뿐이어야 한다.

 - 도구상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇개를 두고 모두를 던져넣고 싶은가?

 - '함수를 작게, 매개변수 목록을 짧게'라는 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아진다. 이는 십중팔구 새로운 클래스로 쪼개야 한다는 신호다.

- OCP도 잊지말자. 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다.

 - 클래스에는 구체적인 클래스와 추상 클래스가 있다. 구체적인 클래스는 상세한 코드를 포함하며, 추상 클래스는 개념만 포함한다. 추상클래스 및 인터페이스를 사용해 구현이 미치는 영향을 격리시키자.

[출처] 클린코드 - 로버트C.마틴 지음