2014의 게시물 표시

로지컬씽킹의 기술

생각과 고민은 다르다. 고민을 생각으로 전환하라. 논리적 사고력을 향상시키는 환경 1. 내용을 시각화한다. 2. 질문이 많다. 3. 시간에 엄격하다. 4. 발언과 반론이 자유롭다. 5. 자료가 정리되어 있다. 나에게 당연하다고 해서 다른사람에게도 당연한것은 아니다. 말꼬투리 잡는 질문을 나 스스로에게 해보라. 도식화, 즉 그림으로 그려라. (도식화하는 방법은 관련책 참조) MECE(중복과 누락이 없는것) 단어를 명확히 정의하라. 다양한 관점과 시각으로 바라볼수 있는 능력이 중요하다. 1. WHAT 트리 - 문제의 전체 그림을 정리한다. 2. WHY 트리 - 원인 파악 3. HOW 트리 - 어떻게 해결할것인가. 상식을 의심하는 습관을 들여라. (내가 지금 개발하고 있는 방식 이외에 다른 더 좋은 방법은 없(었)을까?) 본래의 목적이 무엇인가? 프로젝트의 목적이 무엇인가? 애매한 단어를 사용해서 말하지 말자. -> 습관의 문제  - 매우, 많이, 모두가, 소수의, 가능한 한, 글로벌, 솔루션, 전략, 비전 등  - 이러한 단어 대신 좀더 명확한 단어(수치가 포함된)를 선택해서 사용해라. '한마디로 말하면 ~’ ‘정리하면 ~’ ‘즉,~’ ‘결론적으로, ~’ http://book.daum.net/detail/book.do?bookid=KOR9788997575206

vim 개발환경 셋팅하기

이런 구닥다리 같은 글이 아직 있다니.. https://github.com/amix/vimrc 이런거 쓰자.  - 2016. 3. 설치할 플러그인  - pathogen.vim (vim 플러그인 path 관리)  - NERDTree (vim에서 파일시스템을 tree 구조로 볼수 있게 해준다.)  - sensible.vim (.vimrc가 누더기가 되는게 싫다면 이걸 설치한다. vim을 사용하면 기본적으로 설정해야 하는것들.)  - AutoComplPop (자동완성) 묻지도 따지지도 말고 실행 ~/.vimrc 를 열고 아래 코드를 붙혀 넣는다.

Git flow

'Vincent Driessen ' 이라는 사람의 브랜칭 모델 을 기반으로 한 git extension. 설치방법: https://github.com/nvie/gitflow/wiki/Installation Homebrew를 사용한다면 아래처럼 brew install git-flow 간략한 설명 (복잡한 설명은 원문 참조) Vincent Driessen's branching model에는 다섯개의 브랜치를 사용한다. 그 중에서 메인 브랜치는 master 와 develop - master origin/master 브랜치의 HEAD는 항상 production-ready상태이어야 한다. - develop origin/develop 브랜치(integration branch라고도 부름)의 HEAD는 다음 릴리즈 버전을 위한 가장 최근의 변경사항을 반영하고 있어야 한다. 다음 릴리즈를 위한 개발이 완료되었다면 master로 merge된다. 그리고 태그를 붙힌다. master로 merge가 되었다는것은 새로운 릴리즈가 완성되었다는 의미이다. master에 merge하는 이벤트가 발생하면 git hook을 사용해서 곧바로 production 서버로 올릴수도 있다. 이 밖의 추가적인 브랜치 - Feature branches(Topic branches) develop 브랜치로부터 생성되고, develop 브랜치에 merge 되어야 한다. feature branch는 바로 다음 릴리즈에 merge될수도 있고 나중에 merge될수도 있다. feature branch는 origin repo가 아닌 개발자 repo에 있어야 한다. merge 할때는 --no-ff 옵션을 추가한다.(나머지 브랜치 merge도 마찬가지) - Release branches develop 브랜치로부터 생성되고, develop 또는 master 브랜치로 merge 된다. 새로운 production을 위해 준비중인 브랜치라고 보면 된

Test-Driven Development

"Red, Green, Refactor." 0. Think 1. Red : 아주 짧은 코드(5줄 이하)로 이루어진 test를 만든다. 그리고 test는 실패한다. 2. Green : 일단 test를 통과하게 만든다. 디자인, 성능 등에는 신경쓰지 말고, 하드코딩이 들어가도 상관없으니 일단 통과만 하게 한다. 3. Refactor : 이제 가다듬을 차례이다. 중복된 코드를 제거하고, 소프트웨어의 디자인을 개선한다. test는 통과해야 한다. 4. Repeat Red/Green/Refactor 싸이클의 주기는 짧은 속도로 반복되어야 한다.