2017년 8월 20일 일요일

TDD 가 유용한점

Ruby on rails 를 작성한 한넨마이어한슨(DHH) 인가 하는 친구가
TDD는 죽었다라는 글을 쓴것을 보았다.
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

읽어보니 지나친 unit test 를 많이 하더라도 궁극적으로 통합 테스트를 잘하는 것이
훨씬더 중요하다는 그러한 이야기였다.

하지만 그것은 순수하게 test의 유용성을 리그레션 측면에서 본것같다.

TDD로 코드를 작성하면서 개인적으로 가장 유용한점은 2가지이다.
1. 예제로서의 코드를 만들다 보니 디자인이 깔끔해짐.
2. xUnit 등은 예제로서의 코드를 만들기가 무척 편해서 다양한 예제를 추가하는 부담이 없다.


예를들어서 아래와 같은 python 코드를 보자
테스트를 넣을 공간이 쉽게 마련되다보니
테스트 추가가 용이하다. 만약에 이런 공간이 없다면 테스트를 자주 만들지 않게 되는것 같다.
verilog 에도 아래와 같은 case를 쉽게 추가하는 공간이 있다면 매우 유용할것 같다.
(물론 자체적으로 회사에서 사용하고있는 know how도 있으나 여기서 밝히기는 -.-;)


class MyTest : 
   def test_simple_test(): 
         어쩌구저쩌구...
         return


그럼에도 DHH가 쓴글에   Test는 오래 살아남아야한다는 부분은 매우 중요하게 강조하고싶다.
우리 팀은 15년 이상된 Test Code도 reuse하고 있기때문에 공감가는 부분이다.
HDD는 너무 작은 UnitTest를 많이 만드는것은 Test reuse에 도움이 안된다는 말을 강조하고 싶었던것 같다.
TDD에 대해서 회의를 느끼는것은 HDD가 매우 뛰어난 디자이너이기 때문인것 같다.
그는 TDD를 안해도 디자인이 깔끔한 사람으로 보인다.

하지만 평범한 사람은 xUnit과 같은 example을 다듬는 공간이 필요하다.




실용주의 프로그래머를 3번째 읽고나서


실용주의 프로그래머


10년간 세번째로 읽어보았습니다.
역시 ... 경험이 쌓일수록 보이는것이 달라집니다.
이전에는 안보였던것들이 이번에 다시 다르게 느껴지네요.
특별히 아래 내용들에서 느낀점을 정리해야될것 같아서. 정리합니다.. (5년쯤 있다가 다시 읽어보게)
1. 고양이가 내 소스코드를 삼켰어요 
2. 소프트웨어 엔트로피 
3. 돌멩이 수프와 개구리 삶기 
4. 적당히 괜찮은 소프트웨어 
5. 지식 포트폴리오 
  끝업는 공부를 강조합니다. 하나의 지식만 너무 파는것은 위험할수가 있고,

  주식처럼 지식도 적절히 분산해서 잘 투자하고, 투자 가치가 높은것들에 잘 투자를 해야겠지요.
  앞으로 어떤지식에 투자를 해야할지 잘 모르겠지만 
  개인적으로는 kaggle등에 도전해보는게 의미가 있을것 같습니다. 
  다들 딥러닝을 공부하고있지만, 중요한것은 데이터에서 유의미한 feature 들을 뽑아내는 사람들만
  살아남을것 같네요. 
  안전표준 26262 등에 대한 투자도 의미가 있을것 같습니다. 

6. 소통하라! 
7. 중복의 해악 
8. 직교성 
9. 가역성 
10. 예광탄 
11. 프로토타입과 포스트-잍 
12. 도메인 언어 
13. 추정 
14. 일반 텍스트의 힘 
   이건 많이 익숙해졌네요.
   요즘 unix의 철학을 공부하다보니, 일반 텍스트에 많이 의존하게 됩니다.
   어떤 SoC의 tool을 만들더라도 반드시 텍스트로 config 할수 있게 합니다.
   왜 텍스트로 만들어야할까요? 그건 디버깅이 용이하기 때문입니다.
 
  
15. 조개 놀이 
    조그만 것을 모아서 더 강력한것을 만드는 unix의 철학
    저는 gvim에서 아래와 같은것들을 즐겨씁니다.

     %perl -lane 'print($F[0])'  | xarg ... 
    
16. 파워 에디팅 
     Emacs는 잘모르겠고 vi는 익숙해지니 너무 좋습니다.
     뭐가 좋은가 하면 아래와 같은것들로 쉽게 정보를 가공할수가 있습니다.
     %!sort | uniq
     %!grep
     %!perl -lane 'print($F[0])'
17. 소스코드 관리 
      이제는 git이  짱일것 같습니다.
       뭐.. github가 더 짱인것 같아서 회사에 도입하고 싶은데 돈을주고 사야되서 고민이네요.

18. 디버깅 
19. 텍스트 처리 
20. 코드 생성기 
   저자들은 perl로 많이하는데... 
   저도 사실 10년전에 이책을 보고 perl을 배웠는데
   이책의 저자들이 ruby책을 썻길래 ruby로 갈아탔습니다.
   text 처리나 코드 생성은 역시 ruby가 짱입니다. 

21. 계약에 의한 설계 
  이건 무슨 말인지.. 아직도 별로 재미가 없군요. 아직 계약에 의한 설계를 제대로 해본적이 없어서 그런것 같습니다. 
   물론SoC에서도 formal verification이라고 SVA(system verilog assertion) 등을 가지고 
   형식 검사를 하는 도구들이 있습니다. 
  
  
22. 죽은 프로그램은 거짓말을 하지 않는다 
23. 단언적 프로그래밍 
24. 언제 예외를 사용할까 
25. 리소스 사용의 균형 
  리소스를 할당한 쪽에서 해제도 수행하라는 내용입니다. 
  뭔가 심리적인 문제가 있는것 같습니다. 사용자들이 그렇게 기대하기 때문일수도 있고, 디버깅이 용이하기 때문일수도 있구요. 

26. 결합도 줄이기와 데미테르 법칙 
27. 메타프로그래밍 
28. 시간적 결합 
  동시성 프로그래밍시에 work-queue기반의 구조가 좋다는 이야기를 하는것 같습니다. 
  저도 직접 만들어 본 경험에 의하면 그런것 같네요. 
29. 단지 뷰일 뿐이야 
30. 칠판 
  칠판 시스템에 JavaSpace 나 Linda같은것이 있다는것을 이전에는 별로 중요하게 생각하지 않았는데,

  동시성 프로그래밍을 조금 해보니까 이런게 얼마나 중요한지 느껴지네요.
  Linda와 같은 시스템은 SoC 에서 시뮬레이션을 요청하기위한 submit queue등을 만들때도 사용할수 있을것 같네요.
  
31. 우연에 맡기는 프로그래밍 
 뭔가 이해하지 않고 시작하는것은 우연에 맡기는 거라고 하네요.

 뭔가 시작하기전에 분석을 철저히 하고 시작하는것이 중요하구요.
 저는 개발할때 아래와 같이 일정을 할당합니다.
    분석+이해+명세 : (3/6)
    구현 : (1/6)
    단위테스트 : (2/6)
    통합 테스트 : (2/6)
실행하기전에 이해가 먼저입니다!.

32. 알고리즘의 속도 
33. 리팩터링 
   아... 이제는 리팩터링이 훈련이 되서 어느정도 나도 하는것 같네요.

34. 테스트하기 쉬운 코드 
  xUnit와 같은 TDD도구가 왜 쓸모가 있는가 생각해보았습니다. 하나는 리펙터링할때 필요하고요. 
  또 하나는 디자인의 인터페이스가 좋아집니다.
  2번째점이 저는 더 중요하다고 느껴지는데요. 예제를 더 쉽게 많이 작성하다보니 (xUnit testcase 하나의 수십개의 테스트를 밀어넣을수 있다보니... 정말 테스트 추가하기가 쉽습니다.)
  interface 가 예쁘게 나옵니다.
  이걸보면 SoC설계시 verilog도 쉽게 테스트를 추가할수 있는 환경이 있으면 테스트를 더 많이하게 되고 인터페이스도 더 좋아질것 같네요. 

35. 사악한 마법사 
36. 요구사항의 구렁텅이 
  요구사항은 needs 다! 라는 말이 와닫습니다.

  아직도 요구사항을 제대로 채굴을 못하는것 같습니다. 
37. 불가능한 퍼즐 풀기 
38. 준비가 되어야만 
  일단 시작하기 싫을때, 무언가 프로토타입으로 시작해보라는 내용입니다.

  가볍게 시작하면 문제를 빨리 파악할수 있고, 본격적으로 시작하기가 쉬워지지요.
  공부를 하더라도 공부하기싫을때 문제 1개만 먼저 풀어보기 시작하는것과 유사합니다.
39. 명세의 함정 
  명세로 모든것을 다 기술을 할수는 없으니, 소통을 잘하라고 합니다. 
40. 동그라미와 화살표 
41. 실용주의 팀 
42. 유비쿼터스 자동화 
43. 가차 없는 테스트 
44. 결국은 모두 글쓰기 
   다시 읽어보니 명세에 기반한 개발이네요.
   현재 팀내에서 아주잘 활용하고 있는 내용입니다.

   명세만 만들고 코드는 작성하지 않아야한다는 내용에 공감하고 있습니다.
45. 위대한 유산 (기대 넘어서기)
   이건 해석을 잘못했군요! 위대한 기대! 라고 해야하는데 , 왜? 유산인거죠?

   구글포토가 놀라운건 우리의 기대를 뛰어넘었기 때문이네요. 
   고객의 기대를 뛰어 넘어야 한다고 합니다.
46. 오만과 편견 

   .
.

2017 - 8월까지 그동안 읽은 책들


협업의 기술

기존에 협업에 대해서 나왔던 책들은 대부분 팀장의 측면에서 쓴 책들이 많았다. 
하지만 이책은 같은 동료 사이에 협업하는 기술에 대해서 보여주고 있다. 
사실 협업하는것중에 가장중요한 것은 겸손인것 같다. 
겸손하려면 많이 책을 읽어야한다. 내가 얼마나 못하는지 깨닫고 나면 그때부터 협업이 잘될것인데,
문제는 공부하지 않는 동료들과 어떻게 협업할수 있는가도 생각해봐야 한다. 

 밑바닥 부터 시작하는 딥러닝

딥러닝 책들은 많이 나와있는데 다들 별로였고 -.-; 
이책은 직접 구현하는 부분들이 잘 나와있는 게 좋았다.
특히 backpropagation시에 sigmiod와 cross entropy를 어떻게 처리하는지 보고나서 아하... 
하는 느낌이 들었다.  

구글의 스프린트


정말 감동받은책이다. 
애자일 스프린트가 아니고, 구글의 스프린트는 간단한 브레인스토밍을 할때  1주일만 가지고 하는 방법을 알려준다. 모여서 브레인 스토밍 아무리 해봤자 별로다라는것을 저자는 진작에 인식했던것 같다.
어찌보면 개인의 아이디어가 더 뛰어날수 있고, 이런 아이디어를 어떻게 수집하고 실행하는가에 대한
아주 잘 정리된 방법론이다. 

 가장 빨리만나는 딥러닝 Caffe

이런 책은 왜쓰는지 모르겠다.
그냥 공부하고 싶은 독자들의 욕구를 노리고 상술로서 만들어지는게 아닌가한다.
내용도 완전 얇팍하고, 이정도면 인터넷 웹사이트에 올려도 되지 않는가?
어쨌건 Caffe 보다는 Tensorflow를 추천한다.

프로그래머가 몰랐던 멀티코어 CPU이야기



인텔에서 일했던 경험이 있는 저자라서 아주 깊은 이해를 하고 있다.
SoC를 설계하는 나도 잘 모르는 내용인데 잘 설명을 해주더라.
교양으로 읽어볼만한 책 

제럴드 와인버그의 글쓰기 


이 책은 처음에는 조금 재미있다가 뒤로가면서 너무 지겨워서 대충 봤습니다.
요점은 글을 잘쓰려면 아이템들을 매일매일 떠오를때마다 잘 정리해놓고 나중에 그것들을
책으로 내라라는 내용입니다.
이내용의 책은 뭔가 하나하나 보면 아주 주옥같은 내용인데, 전체적으로 보면 한방이 없습니다. (확 나를 업그레이드 시켜주는 그런거)

코딩호러의 이펙티브 프로그래밍

StackOverflow 의 창립자가 쓴 책입니다. 상당히 현대적인 내용이 많이 들어있습니다.
같은회사의 공동창업자가 조엘 스폴스키라고 조엘온 소프트웨어의 저자입니다.
아주 잘하는 사람이 모여서 회사를 차렸군요... 부러울 따름입니다.
공동 창업자는 같은 것에 value(가치)가 있다고 느끼는게 중요한데요.
책의 내용은 조엘온 소프트웨어 같은 느낌이 있으면서도 그와는 약간 반대되는 내용도 있어서 재미가 있구요.
저자가 조엘과 의견이 다른 부분도 부분부분 제시하고 있어서 아주 즐겁게 봤습니다. 

부러운것은 미국 사람들은 일단 안정적인것 같네요. 
일단 기본적으로 생활이 안정되니까 기술도 여유있게 재미를 느끼면서 할수 있는것 같습니다. 실패를 해도 되구요. 
열정이 있는것에 시간을 많이 투자할수 있습니다.
한국에서는 참 힘드네요...

모두를 위한 딥러닝

딥러닝 공부에는 홍콩 과기대 김성교수의 강의가 아주 도움이 되네요.
언젠가는 한국의 앤드류 응이라 불릴수있기를 바랍니다.
아주 감사한 교수님입니다.