[후기] 테스트 주도 개발

  • 지은이: 켄트 백
  • 옮긴이: 김창준, 강규영
  • 출판사: 인사이트
  • 출간일: 2014년 2월

 포인트1. 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.

 포인트2. 중복을 제거한다.

프로그래밍 순서

  • 빨강 – 실패하는 작은 테스트를 작성한다.
  • 초록 – 빨리 테스트가 통과하게끔 만든다.
  • 리팩토링 – 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복을 제거한다.

매크로를 이용하여 테스트를 작성한 후 얻은 교훈

  • 테스트가 충분히 빨라서 내가 직접, 자주 실행할 수 있게끔 만들자.
  • 많은 오류가 반드시 어머어마한 양의 문제는 아니다.

TDD가 XP의 어떤 부분을 향상 시키는가?

  1. 짝 프로그래밍
    TDD를 하면서 작성하게 되는 테스트는 짝 프로그래밍 과정에서 뛰어난 의사소통 수단이 된다.
  2. 활기차게 일하기
    XP에서는 기운이 있을 때 일을 시작해서 지치면 그만할 것을 권유한다. 테스트를 통과하지 못하겠거나, 어떤 테스트 두 개를 동시에 통과하도록 만들 방법을 모르겠다면 쉬어라.
  3. 지속적인 통합
    테스트를 좀더 자주 통할할 수 있게 해주기 때문에 아주 훌륭한 자원이 된다. 새로운 테스트를 통과시킨 후 중복을 제거했다면 커밋한다. 그렇게 되면 체크인 간격이 15~30분 정도로 단축된다.
  4. 단순 설계
    테스트를 통과하기 위해 필요한 만큼만 코딩하고 모든 중복을 제거한다면 요구사항에 딱 들어맞는 설계를 얻게 될 것이다.
  5. 리팩토링
    중복 제거 규칙은 리팩토링의 또 다른 이름이다. 테스트가 있다면 더 큰 리팩토링을 수행하더라도 시스템의 행위가 변하지 않았다는 자신감을 얻을 수 있게 된다.
  6. 지속적인 전달
    TDD 테스트들이 정말 당신 시스템의 MTBF(Mean Time Between Failure)를 개선한다면, 고개을 혼란시키지 않으면서도 훨씬 더 자주 코드를 출시할 수 있을 것이다.

추천 도서

  • Smalltalk Best Practice Patterns

[후기] 열혈강의 TCP/IP 소켓 프로그래밍

열혈 TCP / IP 프로그래밍

  • 저자: 윤성우
  • 출판사: 오렌지 미디어
  • 기간: 2016.07.13 ~2016.07.15

키워드

네트워크 프로그래밍

  1. TCP / IP
  2. Socket Options
  3. Linux 기반의 네트워크 프로그래밍
  4. Windows 기반의 네트워크 프로그래밍

본것

네트워크 프로그래밍의 기초에 대한 설명이 단계별로 잘 되어 있는 책이라는 생각이듭니다.
소켓(Socket), 주소체계, TCP, UDP, Gracefull Shutdown, 소켓 옵션, 서버 아키텍쳐등 많은 내용이 아주 체계적으로 잘 되어 있습니다.

그리고 Linux와 Windows에서 다르게 구현 되는 부분을 잘 설명해 놨기 때문에 두가지 환경에서 모두 구현하는데 도움이 될 만한 책인 것 같습니다.

책 중간에 나오는 잠시 JAVA 얘기를: 열려있는 사고를 지니자! 는 간략하지만 제가 느끼는 부분과 비슷한 내용인 것 같습니다.

예전에 학원 강좌에서 Java 네트워크 부분에서 Java에서는 소켓을 연결하지 아주 쉽습니다.

Socket s = new Socket("192.168.10.1", 8888);

위와 같이만 하면 연결 끝입니다. 이런 내용을 듣고 네트워크 프로그래밍 뭐 별거 아니네... 이런 생각을 했는데 프로그래밍을 하면 할 수록 네트워크 부분은 점점 어려워 지는 것 같습니다.

깨달은것

멀티 프로세스 방식은 Java로 서버 개발을 하면서 사용한 적이 없고 멀티 플렉싱 방식은 Java NIO 패키지의 비동기 소켓으로 예제 정도만 구현을 해봤는데 이전 보다 조금 더 알게 된 것 같습니다.

그리고 Windows IOCP는 예전 한국 리눅스 유저 그룹 에서 EPOLL과 열딘 토론의 글을 본적이 있어서 관심은 있었지만 실제로 사용해 본적이 없어 어떤 시스템이라는 막연한 부분이 있었는데 대략적으로 어떤 흐름이다라는 것은 알게 되었습니다.

적용할 것

  • 멀티프로세스 방식, 멀티플렉싱 방식 그리고 멀티 스레드 방식의 서버를 각각 구현해 성능 테스트를 해보자.
  • Windows IOCP 서버를 구현해보자.
  • 네트워크프로그래밍 강좌에서 받은 Windows IOCP 배틀넷 서버 소스를 분석해보자.

[후기] 리눅스 그냥 재미로(Just for fun)

리눅스 그냥 재미로

  • 제목: 리눅스 그냥 재미로(Just for fun)
  • 저자: 리누스 토발즈, 데이비드 다이아몬트(안진환 역)
  • 출판사: 한겨례신문사
  • 기간: 2016.07.19~2016.07.19

본것

  • 리눅스를 만들게 된 동기와 오픈소스에 대한 철학을 볼 수 있다.
  • 과학 스스로는 돈을 벌어주지 못한다. 부를 창출하는 것은 과학의 부차적 효과이다. 오픈 소스도 마찬가지다.
  • 유닉스는 “작은 것이 아름답다” 라는 철학을 가지고 있다.

외에 전반적인 리누스가 왜 운영체제 개발을 시작했고 어떤식으로 오픈소스 프로젝트를 시작했는지 그리고 현재까지 유지할 수 있었던 방법은 어떤 것인지에 대한 이야기가 나와있다.

그리고 대학 연구조교를 나와 기업에 취직할 때도 비리눅스 기업에 취직하는 내용은 정말 대단한 사람이라는 생각이 들었다. 이익 보다는 소신을 지키는 내용이 멋있었다.

깨달은것

리누스는 컴퓨터를 처음 사용하면서 프로그래밍을 접하고 그것을 보다 효율적으로 사용하기 위한 방법을 많이 생각했던 것 같다. 나의 어린 시절과 비교를 하면 나는 대부분의 학생들과 마찬가지로 컴퓨터를 가지고 게임을 할 생각만 했지 컴퓨터를 가지고 프로그래밍을 할 생각은 못했던 것 같다.

물론 베이직(GW Basic) 언어를 이용하는 프로그래밍을 배우기는 했지만 그것은 단순 컴퓨터 학원의 커리큘럼 이었을 뿐 집에서 그것을 가지고 내가 원하는 기능을 직접 만들어 본다는 것은 생각조차 하지 않았던 것 같다.

Java라는 언어를 내 기반으로 두고 사용하기에 하드웨어에 대해 모른다는 것을 별로 민감하게 받아들이지 않았지만 좋은 개발자가 되기 위해서는 하드웨어에 대한 지식도 이제는 필수라고 생각한다.

적용할 것

  1. DOS와 같은 운영체제를 만들기(?)

솔직히 위의 운영체제 만들기는 어려울 것 같다는 생각이 들지만 한번 시도를 해보면 정말 많은 도움이 될 것 같다는 생각이 든다. 그렇기 때문에 적용할 것 에 추가해본다.

[후기] 좋은 코딩 나쁜 코딩

읽기 쉬운 코드가 좋은 코드다.

  • 제목: 좋은 코딩 나쁜 코딩
  • 저자: 박진수
  • 출판사: 한빛미디어
  • 기간: 2015.09.28~2015.09.30

키워드

코딩 스타일(Coding Style)

  1. 논리를 표현하는 방식
  2. 알고리즘을 표현하는 방식
  3. 문장을 표현하는 방식
  4. 표현식을 표현하는 방식

본것

  • 함수와 함수 사이는 빈줄을 추가하여 가독성이 좋게 한다.
  • 프로그램의 주석에는 작성자, 파일명, 목적, 사용방식, 사용 파일, 제한사항, 오류처리, 이력사항을 포함하도록 한다.
  • while문의 조건 판별부에 대입 연산을 사용하지 않는다.
  • 연산자 우선 순위만 믿지말고 괄호를 적용하라.
  • 나눗셈 연산에는 주의하라
  • 변수명 및 함수명을 정의 할 때는 주의해서 작성하라.

깨달은것

C언어 스타일의 가이드로 되어 있어 보기도 편했고 모르던 내용도 많이 있어 도움이 되었다.

그렇지만 책이 나온지 10년정도 되어서 코딩 가이드에 약간의 변화가 있을 수도 있을 것 같다. 최근에 본 코딩 스타일 가이드 강좌(https://cleancoders.com/) 에서 나오는 내용과 상반되는 내용이 많이 있다.

책의 저자 및 클린코드의 강사중 어느 쪽을 반드시 따라야 한다는 규칙은 없을 것 같다. 자신 또는 팀의 성격에 맞는 방식을 따르면 좋을 것 같다는 생각이다.

예를 들면 책의 내용중에 버전 변경 이력에 대한 내용을 작성자, 변경일, 변경내용을 기록해야 한다고 설명되어 있다. 그렇지만 클린코드의 저자는 변경 내용에 대한 이력 관리는 버전 관리 시스템에서 하기 때문에 소스코드에 불필요한 내용을 적지 않아도 된다는 내용을 설명한다.

그리고 변수에 대한 주석도 상반된다. 코드를 이해할 수 있다면 별도의 주석을 필요 없다는게 클린코드의 설명이고, 저자는 변수에 주석을 달아 놓으면 다른 사람이 작업할 때 훨씬 편리하다라는 내용이다.

코딩 스타일에 관한 자료를 검색하다가 가장 마음에 와닿는 글을 게시한 블로그가 있었다.(주소는 생각나지 않음)

그 블로그에서는 주석을 달기 전에 자신이 작성한 코드에 혼란을 일으킬 수 있는 부분이 있는가 또는 자신의 코드의 잘못된 부분을 인식시키기 위해 주석을 작성할 것인가를 생각해보고 주석을 추가하라고 한다.

개인적으로 블로그에 나온글이 맘에 든다.

Objc 로 코딩을 하다보니 viewWillDisappear(), viewDidLoaded() 와 같은 함수와 TableView를 구현하기 위해 상속받는 함수들의 이름이 짧지 않고 함수명에 이 함수는 무엇이다라는 것을 정의한 것처럼 작성이 되어 있다. viewWillDisappear() 함수는 뷰가 사라질 것이라는 의미를 함수명에 내포하고 있어서 LifeCycle을 확인하지 않아도 대략적인 시점을 예측할 수 있다.

함수명이 무조건 길어진다고 좋은 것만은 아니지만 가독성에 도움을 준다면 어느정도의 길이는 상관이 없다고 생각이 된다. 그리고 최근에는 IDE 환경이 좋아서 소스 코드 전체를 키보드로만 입력하지 않아도 되기 때문에 가능한 일인것 같다.

적용할 것

  1. 현재 작성중인 코드의 변수명 및 함수명이 어떤 내용을 의미하는지를 내포하고 있는지 확인한다.
  2. 최신의 코딩 스타일이 무엇인지 확인한다.
  3. 본문에 포함된 코드중 이해가 안되는 코드는 실행해본다.

[후기] 앱스토어 골드러시

  • 출판사: 이지북
  • 저자: 정태훈
  • 시작일: 2015. 09. 04
  • 종료일: 2015. 09. 07

한줄요약

 모바일 앱이라는 것을 통해 나름의 성공을 할 수 있다는 약간의 성공 신화와 같은 느낌. 

앱은 개발자가 만들지만 누구나 자신만의 아이디어를 이용해서 앱을 만들 수 있다.

내용 정리

저자가 무서운카메라 라는 어플리케이션과 iCan'tTalk 라는 어플리케이션을 출시하면서 스스로 조사하고 프리랜서 개발자와 디자이너를 섭외하는 과정들이 상세하게 기술되어 앱을 만들고 싶은데 어찌해야 되나 다른 사람에게 좋을 것 같다는 생각이다.

개발자로서 책의 내용중에 가장 마음에 와닫는 말은 앱을 기획한 사람이 정확하게 어떤 기능이 있는지와 어떤 디자인을 원하는지 디테일하게 설명하는 부분이다.

파워포인트를 이용해 UI화면을 개발자에 전달하면서 버튼의 상태가 어떻게 변경되고 기능이 어떻게 된다라는 설명이 너무 자세하게 작성되어 개발자로서 볻받아야 된다는 생각이 들었다.

그리고 디자이너에게 전달하는 내용은 샘플 이미지 같은 것을 넣어 디자이너에게 자신이 원하는 바를 정확하게 전달하는 부분이 좋았다.

마지막으로 최고로 좋은 점은 누구나 어플리케이션을 개발할 수 있다는 내용이다.

아쉬운점

책의 후반에 가면 애플 개발자 자격 신청 및 앱 등록하는 절차를 너무 자세하게 적었다는 느낌이 든다. 스크린샷이 많이 첨부되었지만 애플 사이트를 캡처한 내용은 사이트가 자주 바뀌면 있던 메뉴가 사라질 수도 있는거라 차라리 블로그나 출판사 홈페이지를 통해 지속적으로 업데이트 하는게 좋지 않았나 하는 생각이다.

현재 나의 생각

애플이 개발자에게 무한한 시장을 열어줬다는 생각은 내가 앱스토어에 회사용 어플리케이션을 출시하면서부터 들은 생각이다.
이번에 친구와 기획해서 제작한 HOW2TOEFL을 앱스토어에 출시하면서 약간의 돈벌이는 되겠지라는 생각을 했었는데 결과는 처참하다.

책이 쓰여진 시점이 2010년도인데 2015년도인 지금은 앱스토어에 무수히 많은 어플리케이션이 있다. 어플리케이션이 아무리 좋더라도 사용자가 그 어플리케이션이 존재하는지 모른다면 다운로드 하지 않을 것이다.
특히 흥미 유발성 어플리케이션이 아니라면 더욱더 마케팅이 중요하지 않은가 하는 생각이다.

Git, 분산버전 관리 시스템 요약

책정보


  • 출판사: 인사이트
  • 저자: 트라비스 스위스굿
  • 번역: 김성안, 이두원
  • 기간: 2015. 08. 06

책 중요 내용 정리


SVN만 사용하다 Git을 회사 버전 관리 시스템으로 사용하면서 온라인의 예제 또는 내용만 읽다 체계적으로 정리된 Git에 대한 내용을 볼 수 있어 좋았습니다.
책 내용중 상당 부분이 예제를 통해 명령어를 설명하는 부분인데 기본 기능을 설명하기에는 부족함이 없었습니다.

Git방식으로 버전 관리하기


[무엇을 저장해야 하나?]
프로젝트를 진행하는 데 필요한 전부, ‘X가 없어도 프로젝트에서 작업하는 데 지장이 없는가?’ 라고 판단을 했을때 스스로 질문하고 문제가 있다면 프로젝트 관리에 포함한다.

[커밋 로그 메시지에 어떤 내용을 넣어야 할까?]
커밋 메시지는 메시지만으로도 의도를 드러내도록 커밋의 ‘이유’를 설명하는 모든 메타데이터를 포함해야 한다.

잘 작성된 커밋 메시지의 예
– 가동성을 위해 중첩된 if/elseif 구문을 switch 구문으로 변경
– 유용하지 않다고 검증한 실험 코드 삭제
완벽한 로그 메시지를 만드는 데는 장인정신이 필요한다.

브랜치(Branch) 이해


기본적으로 하나의 브랜치 즉 마스터 브랜치만 사용해도 버전 관리 시스템이 제공하는 모든 이점을 얻을 수 있다. Git을 사용하면 이력을 추적하고 다른 개발자와 협업할 수 있다. 또한, 갑자기 중요한 파일이 지워지는 상황도 대처 할 수 있다. 하지만 이 정도로 Git을 사용한다면 마치 경주용 자동차를 타고 출퇴근을 하는 것과 같다. 목적지에 도착은 하겠지만, 출근시간인 오전 8시에는 결코 경주용 차의 성능을 제대로 끌어낼 수 없다.

[브랜치 생성시 고려사항]
– 실험적인 변경 사항
– 새로운 기능
– 버그 수정

[브랜치 간의 변경 사항 합치기 ]
– 바로 합치기(Straight Merge): 하나의 브랜치와 다른 브랜치의 변경 이력 전체를 합치기
– 커밋 합치기(Squashed Commit): 한 브랜치의 이력을 압축하여 다른 브랜치의 최신 커밋 하나로 만드는 방법
– 선택하여 합치기(Cherry-picking): 다른 브랜치에서 하나의 커밋을 가져와서 현재 브랜치에 적용하는 방법

태그 (Tag)


서브버전 사용자에게 익숙한 태그와 달리 Git의 태그는 읽기 전용이다. 읽기만 가능하다는 말은 브랜치와는 다르게 태그의 내용을 변경할 수 없음을 의미한다. (물론 Tag에서 새로운 브랜치를 생성하는 것이 가능하다.)

[후기] 대한민국 소프트웨어 리스타트 위기를 넘어 도약으로

 

한줄 요약

개발자로 시작해 PM및 컨설턴트로 활약 중인 저자분이 IT 생활에 도움이 되면 좋겠다는 글들을 모아놓은 것.

 

현재 나의 생각

최근 회사내 일정 및 업무 분담으로 인해 팀원들의 사기가 좋지 않은 시점에 해당 글을 읽으니 가슴에 팍팍 새겨드는 말이 많습니다.
회사내 자신의 입지를 유지하기 위해 항상 노력하고 남들보다 열심히 해야 하고 또한 가정의 화목을 위해 가족을 위해 봉사해야하는 현재의 제  상황 아니 많은 IT 개발자분들에게 도움이 되는 말이 많은 것 같습니다.
 
책에 나와 있는데로 모든 일이 처리되면 좋겠지만 현실은 제가 원하는 것과는 다르게 가려 하기 때문에…
약간이나마 책을 읽으면 현실을 책에 나온 가이드데로 맞춰보고 싶은 생각입니다.
 
개발자님들 힘내시고 … 고고씽..