E D R , A S I H C RSS
ZeroWiki

CleanCode (rev. 1.94)

Clean Code

[edit]

Clean Code

[edit]

5월 4일

  • 스터디 킥오프
  • 도서 : Clean Code
  • 서지혜의 my-calculator 코드를 피어 리뷰함.
[edit]

5월 11일

  • Clean Code 읽은 부분에 대해 토론(Chap 01, Chap 09)
    • Chapter 2 Meaningful Names - Naming Convention
      • 클래스의 이름을 지을 때는 -info, -data와 같은 일반적인 이름을 쓰지 말라.
      • Account를 만들면 되지 AccountInfo라는 클래스를 만들 필요는 없다. Account 클래스 내부에 들어가는 정보가 Info니까.
      • -List 라는 식의 이름을 지을 때는 정말로 List의 API들을 지원할 때에만 -List라고 붙여주는것이 좋다. 이름을 저렇게 지으면 -List의 API들을 지원할 것 같은 느낌이 들기 때문에 아닐 경우에는 -s나 다른 방식으로 하는게 좋을 것.
      • 아래와 같은 식으로 Account내부의 정보를 하나로 묶으면 AccountInfo 클래스와 getAccountInfo()등이 있을법하지 않은가? -> 저런 구조 자체가 잘못됐을 수 있다. getAccountInfo()와 같은 방법이 아니라 다른 방법으로 일을 시키는 모양이 더 낫다.

Class Account {
private AccountInfo info;
};
  • Chapter 9 Unit Tests
    • 문제를 들었을 때 테스트코드를 먼저 생각하는 습관을 들여야 할 것 같다. 문제를 해결하는 코드를 먼저 짜려고 하면 결국 테스트코드 작성이 아니라 직접 테스트를 하게 되는 듯 하다.
    • 피드백을 빨리 받기 위해서 테스트를 실시. 피드백을 받고 고칠 때까지의 주기가 짧아야 함. 코드를 짜고 유닛테스트를 만드는 것도 안되는건 아님. 피드백을 바로 받을 수 있으면 됨.
    • 코드를 깨끗하게 하고 싶으면 테스트 코드도 깨끗하게 유지해야 한다. 테스트 코드가 더러워지면 테스트를 잘 안하게 되니까 코드도 더러워지게 된다.
    • 테스트 시에는 올바른 input이 제대로 들어오는지를 먼저 확인하고 나서 코드가 잘못되었는지 생각해볼 것.
    • 실제로는 쓰지 않는데 테스트를 위한 메소드를 추가하게 되는 경우가 있을 수 있지 않은가? -> java의 경우는 reflection을 사용하면 메소드의 추가 없이 처리가 가능한 경우도 있지만 그것보다도 테스트용 framework(mockito 등)를 사용하는것이 좋다.
    • BDD, Given/When/Then

[edit]

5월 18일

  • 함수
    • 플래그는 추하다
      • guard clause를 쓰세요!
      • 함수는 하나의 일을 하는게 좋다고 하는데 플래그를 쓴다는 것은 함수가 플래그의 값에 따라서 다른 값을 한다고 말하는 것이므로.
      • 차라리 다른 일을 하는 함수를 여러개 만드는게 더 낫다.
    • abstraction level
      • String.append와 PathParser.render는 둘이 서로 문자열을 합치는 작업을 하더라도 직접적인 연산을 하는 것과 추상적인 연산을 하는 것의 차이로 서로 추상화 수준이 다르다고 할 수 있다.
      • 추상화 수준이 서로 다른 코드가 섞여있으면 보기에도 좋지 않다.
      • 추상화 레벨이 달라지는 것을 막기 위해서는 코드를 짧게 하고 메소드로 많이 나누면 한 코드 내에서 추상화 레벨이 달라지는 것을 막을 수 있다.
    • 함수 인자는 적을수록 좋다.
      • 함수 인자가 많아지게 되면 사용자가 인자들에 대해서 이해를 하기 힘들다.
      • 테스트 코드를 작성할 때 인자들의 조합 수에 따라 테스트 케이스가 늘어날 수 있기 때문에.
  • Error Handling
    • 에러를 방지하거나, 처리하는 코드 때문에 함수의 본 임무를 파악하기 힘들게 되면 안됩니다.
    • Consider using try-catch-finally instead of if statement.
    • Don't return null.
      • Returning null or undefined (Javascript) 
        var array = stringObject.match(/regexp/); // if there is no match, then the function returns null, if not returns array.
if(!array){
  // handle and return
}
array.forEach(/* handle found strings */)
...
      • Returning emtpy object (Javascript) 
        var array = stringObject.match(/regexp/) || []; // if the function returns null, then substitute empty array.

array.forEach(/* handle found strings */)

/* You can handle empty array with "array.length === 0" statement in anywhere after array is set. */
    • Don't pass null.
[edit]

후기

  • 민관
    • + : 코드 리팩토링을 해봐서 좋았다. 화이트보드에 적어가면서 읽어본 부분 공유하니까 정리된 느낌.
    • - : 프로젝트 방식과 방향이 흐릿한 느낌이다.
    • F : 시간을 컴팩트하게 진행하고 싶다. 늘어지는 경향이 있다.
  • 진경
    • + : 리팩토링을 시도해보았다. 다른 사람의 코드를 리팩토링 할 수 있다는 생각을 하게 되었다.
    • - : 본인의 코드를 리뷰받고 싶었는데 정리가 되지 않아 받지 못했다.
    • F : 주중에도 스터디를! 온라인 협업 툴을 이용할 수 있다.
  • 영주
    • + : 책 얘기만 한게 아니라 책의 예제를 시도해봤다.
    • - : 각자 예제를 리팩토링했다. 따로 논 느낌.
      • 사실 그런 느낌이 들어도 결국 코드 짜는 부분은 따로 할 수밖에 없는 것 같으니 어쩔 수 없는 것 같기도 하지만요. - 서영주
    • F : 스터디를 제대로 하고 있는지 알고싶다. (멘토가 있었으면 좋겠다?)
      • 코칭을 받고 싶다는 말인듯 - 서지혜
      • 가르쳐주는 것 까지는 아니고 잘 하고 있는건지 아닌지를 알 수 있었으면 좋겠다는거죠. 목표 얘기 하신건 확실히 제대로 하고 있는지 참고가 될 것 같습니다. - 서영주
      • 네 그래서 일부러 코칭이라고 썼어요ㅋㅋ 멘토링은 아닌 것 같고 티칭은 지양하고싶고, 스터디가 잘 되어가고 있는지를 확인하고 싶다는 맥락에선 코칭이 제일 유사한 것같아서리.. - 서지혜
  • 희정
    • + : 처음 나올때 떨렸는데 많이 신경 써 줘서 좋았다.
    • - : 배경지식이 부족한 듯 하다.
    • F : 스터디중에 어떻게 진행해야 하나에 대한 얘기를 너무 많이 한다.
  • 지혜
    • + : 다른 사람들이 리팩토링 하는 것을 보았다. 새로운 사람 추가
    • - : 리팩토링을 할 때 리팩토링에 대한 요구사항, 리팩토링을 멈출 수 있는 수준을 제시하지 못하였다.
      • '이것'을 제시할 수가 있나?
    • F : 스터디 첫날 정했던 각자의 목적과 목표(어디갔지?)를 통해 스터디가 제대로 진행되어 가고 있는지 체크할 수 있을것.
      • 그러나 자신의 실력이 더 나음을 어떻게 비교할 수 있을까? 학습 곡선도 무시할 수 없다.
[edit]

5월 25일

  • ajax (callback에 대한 이해를 위해)
    • javascript를 이용한 비동기 http 요청.
    • UI를 그리는 흐름(thread)과 http 요청에 대한 흐름(thread)이 따로 존재함.
    • http 요청 쪽은 언제 작업이 끝날지 알 수 없음.
      • callback 함수라는 것을 이용해서 작업이 끝났을 때 처리할 방법을 정할 수 있다.
  • 진경이 코드(CauBooks) 살펴보기
    • javascript 소스 코드에서 한꺼번에 인자를 넘기는 방식.
      • 로그인 성공, 실패에 따른 callback 함수를 한 번에 넘기고 있다.
      • 현재는 callback 함수에 이름을 붙여서 인자에 넣고 있지만 주로 익명 함수를 쓰는 js의 특징이나 프로그래머가 직접 이름을 붙여서 관리를 해야 하는 등의 불편함을 고려하여 다른 방식으로 수정하고 싶다.
    • 한꺼번에 { id:, password:, success:, fail: }을 하나의 객체로 만들어서 넘기는 방식.
      • id, password와 success, fail은 관계가 별로 없는데 같이 묶어서 넘기면 나중에 login 내에서 각각의 파트를 또 뽑아내야 한다.
      • 객체가 넘어가는 거니까 특정 property의 유무에 따라 에러를 일으킬 수 있다.
    • module.login(id, password).success(function() {...}).fail(function() {...})으로 수정할 경우.
      • 각 callback 함수에 대한 의도가 보다 잘 드러남.
  • 좋은 코드?
    • 현재 CleanCode에서 좋은 코드로 너무 가독성만을 중시하고 있는 것은 아닌가.
      • 읽을 사람의 수준을 고려하는 것도 필요하다. (너무 다 풀어 쓴 코드보다는 읽는 사람이 이해할 수 있을 정도의 난이도 + 효율적인 코드가 낫지 않은가)
        • 동감합니다. 제가 클린코드 스터디를 하는 이유는 궁극적으로 생산성 향상입니다(제가 요즘 강조하는? ㅋㅋ). 지혜 누나가 언급했듯 코드는 일단 동작해야 하는 것이 첫 번째. 제 취향대로 약간 추상화하자면 요구사항을 충족하는 것. 임베디드 개발에서는 퍼포먼스 향상을 위해 '정석적인(?)' 구조나 방법론을 깨는 경우도 있습니다. 요구사항을 충족하지 못 하면, 실질적으로는 아무 것도 생산하지 않은 것과 같을 수도 있으니까요. - 정진경
        • 산문이냐 운문이냐의 차이라는 생각이 듭니다. - 서지혜

  • 서지혜의 my-calculator 테스트 코드 리뷰
    • spec에 지정되어 있지 않은 경우에 테스트 코드를 작성해야 하는가?
      • spec에 지정되어 있지 않다는건 무슨 의미지?? - 서지혜
      • 예를들면 입력이 들어왔을 때 A라는 출력이 나와야 한다고만 spec에 정의돼있으면 입력이 없을 때에 대한 테스트 코드는 무슨 기준으로 작성하느냐 또는 에러처리를 해야 하는가에 대한 기준을 말하는것 같습니다. - 서영주
      • 아, 그런말 한 것 같네요. 이경우는 코드가 아니라 요구사항(아키텍처) 단계에서 정의가 필요한 일이네요. - 서지혜
      • 실제 일하는데서는 어떤가요? 이런 부분에 대한 요구사항이 없을 경우에는 어떤식으로 처리를 하는지가 궁금합니다. 먼저 처리하고 어떻게 처리했다고 따로 보고하나요? 아니면 없으니까 이런걸 정의해줘야 한다고 건의를 하고 대답이 오면 그 때 처리를 하나요? - 서영주
  • Ruby StyleGuide - 코딩 스타일 자체보다 왜 그런 스타일을 선택했는지에 대해 생각해 보는 것이 중요함.
[edit]

회고

  1. 지혜
    + : 회사에서 짐을 나르다가 왔는데(이삿짐 나름.. 주말에.. 젠장), 오기를 잘 한 것 같다.
    - : 원래 올 계획이 아니었기 때문에 필요한 노트북이나 책 등을 챙겨오지 못 했다.
  2. 서영주
    + : 무작정 클린 코드에 대해 이야기를 했었는데 좋은 코드에 대한 얘기를 하면서 클린 코드에 대해 다시 생각하게 됨.
    - : 좋은 코드를 구해 오자고 했는데 하다 보니 생각보다 어려워서 못 찾아온 것에 대한 미안함.
  3. 진경
    + : 서영주가 코드에 대해 리뷰를 하고 생각을 적어 준 것. -> 누가 코드를 봐 줬으니 다음 주에 또 작업을 할 동기가 됨.
    - : 스터디 시간의 경계선이 아직 뚜렷하지 않음.
    f : - 줄이고 + 늘리게
  4. 박희정 <= 자기 코드 들고 오면 좋겠다
    + : 초반에 callback, ajax에 대해 따로 설명을 해 준 게 좋았음
    - : 말하는 내용을 완전히 이해하기가 힘들다.
  5. 서민관
    + : 따로 준비 해 온 게 없었지만 그래도 다른 분들 덕분에 진행이 잘 되었다. 준비를 하지 않더라도 참가에 의미가 있다는 생각을 할 수 있게 되었다.
    - : 시간 줄일 수 없을까? 책진행? 코드 진행? 진행을 어떤 식으로 해야 할지 아직도 매끄럽지 않은 느낌이 있다.

[edit]

6월 1일

[edit]

회고

[edit]

6월 8일

  1. 4장 코멘트
  2. CleanCoders 강의 맛보기.
    1. 에피소드 1은 1달러여서 싼 줄 알았는데 그 이후부턴 12달러...ㅠㅠ
    2. 지원금으로 구매하는게 좋겠음.
  3. SE titan 코드 리뷰
  4. 회식 - 7만원 지원받음
[edit]

회고

  1. 서지혜
    회고를 회식으로 적을 뻔 했다.
  2. 서영주
  3. 정진경
  4. 박희정
  5. 서민관
  6. 안혁준
  7. 고한종
[edit]

6월 22일

  • 정진경, 김남규(환영!), 박희정
  • 남규 C 코드 리뷰. 아직 채점되지 않은 과제물이라 코드는 나중에..?
  • 꿀잠
    • 제가 지루한 강의를 하는 바람에...
[edit]

comment me

  • 스터디 이름 정합시다. 아름다움을 추구하니까 소니 에릭슨? - 서지혜
    • 아름다운 걸로 하자면 unit sphere 같은 게 아름다울 것 같긴 한데... 그건 좀 아닌 것 같죠 -_-;; - 서민관
  • 후기를 +, -, F 방식으로 나누어 작성했네요! 좋은 방식인듯ㅋㅋ - 김민재
    • 엇 난 거슬려서 바꿀랬는데 그냥 냅둬야지ㅋㅋ - 서지혜
Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2021-02-07 05:22:54
Processing time 0.0504 sec