기술사 합격 후 할 일

아래 기술한 5가지는 해 놓으시면 좋습니다.
차후에 관련해서 큰 고민을 덜어놓을수 있으니까요.

1. 과학기술인공제회 가입
2. 한이음 멘토 신청
3. 산업통상자원부 전문가 풀 등록
4. 감리원 교육 신청
5. Skill up of an English Speaking (울트라 캡숑 초싸이언 리미티드 수퍼 중요!!!!)

자 그럼 하나씩 풀어보도록 하죠 ^^

1. 과학기술인공제회(SEMA) 에 가입.

    [가입방법]
    1) 한국기술사회 등록 (http://www.kpea.or.kr)
        - 회비 납입 이전까지 진행하십니다.
        - 기술사 인증 과정을 수행합니다.
           

    2) 과학기술인공제회 가입 신청 (http://www.sema.or.kr)
        

        - 가입승인을 기다립니다.
        - SMS로 받은 지로납부번호를 보관합니다.

    3) 은행으로 가서 지로에 대한 자동이체 신청
        - 적립식 연금
        - 매월 10일 출금되도록

    4) 2-3주 정도 지난 다음, 가입 축하 메시지와 가입증명서 확인이 가능

   [뭐가 좋은데?]
    1. 연 복리 6% -> 복리 복리 복리 복리
    2. 휴양시설, 제휴복지, 의료기관 지정 할인, 무료법률상담, 복지카드 발급 등
    3. 목돈 마련이 필요할 시 
        - 1년 4.5%, 2년 5%, 3년 5.5% 복리 이자 지급 상품 가입하시면 됩니다.


2. 한이음 멘토링 신청

    기술사로서 확실히 눈도장 찍을 수 있으며 재능기부할 수 있는 분야라 생각됩니다.
    [가입방법]
    1. 한이음 사이트에 회원 가입 (http:://www.hanium.or.kr)
    2. 멘토 신청
        - http://www.hanium.or.kr/jsp/egovframework/portal/track/project/mentoProposeProcess.jsp
    3. 필요 서류
        - 이력서 (파일 첨부 했으니 확인해보세요)
        - 재직 증명서
        - 석박사의 경우 학위 증명서 (졸업증명서가 되겟죠?)
        - 기술사 자격증명서 (미리 PDF로 스캔하여 준비해 두세요)
        - 제출처 : 이메일 (hanium@fkii.org)

    [뭐가 좋은데?]
    1. 활동비로 한달에 15만원 지급 (1년 한도 있습니다)
    2. 산학 협동에 따른 자긍심은 입에 바르기 좋은 구실이구요 ^^
        
        일단, 재밌어요
        그리고, 같이 발전하는 계기와 풋풋한 대학생들의 생기발랄 기운도 얻고,,


3. 산업통상자원부 전문가 풀 등록

    [가입방법]
    1. 회원 가입 (http://www.ernd.go.kr/ernd/index.html)
    2. 평가 위원 신청
        

    3. 정보 입력
        - 임명기술분야 -> 입금계좌정보 -> 경력 -> 학력 -> 자격증 -> 논문 
           -> 지식재산권 -> 저서 -> 소속협회 순으로 입력합니다.
        - 경력 및 학력 입력시에는 "재직증명서 " 및 "졸업증명서" 첨부하시면 됩니다.

    [뭐가 좋은데?]
     - 저도 아직까지 위촉되어 본적이 없어서, 딱히 뭐가 좋은것이 모르겠어요 ^^


4. 감리원 교육을 신청.

    1) 정보통신특급감리원 신청
        - 회원가입 (http://www.kica.or.kr)
        - 기술자격자신청
           

       - 기술자격 신청을 위한 서류 작성 및 준비
           

        - 감리원자격신청
           

       - 감리원자격 신청을 위한 서류 작성 및 준비
           

        - 사진 4매를 준비하시고 한국정보통신공사협회를 방문하여 접수하시면 됩니다.
        - 입교시기 선택
           
           

        - SMS로 전송받은 번호를 입력하면 됩니다.

    2) 정보시스템감리원 신청
        - 회원가입 (http://www.kaisa.or.kr)
        - 교육 신청

         

5. 영어스피킹 능력 향상

    이제는 글로벌 시대라서
    영어 말하기 점수가 필수가 되었습니다.

    OPIc 또는 토익스피킹 점수는 확보해 두세요..

    OPIc 기준 IM3 이상,
    토익스피킹 기준 150점 이상,

    이것이 갖추어져 있을 경우,
    당신은 이미 준비된 인재가 되어 여기저기에서 수없이 불려다니실 겁니다. ㅋ

[One more thing]

- 정보통신기술사 협회에 가입하시어 많은 활동 부탁드려요.

   URL (http://www.gisulsa.org)

   홈페이지 주소가 참.. 머.. 음.. 그렇습니다. ^^

   중소기업역량강화 사업(멘토), 교육사업(강의), 사업전략(제안서), 법제, 홍보 등등

   많은 활동분야가 있으니,

   조직의 일원으로서 본인의 역량을 빛내어 주시기 바랍니다.



출처 : http://blog.naver.com/winipe/150163254178

easy used function

  함수가 없는 프로그래밍은 생각할 수 없다. 어떤 프로그래밍 언어를 선택하든지 함수가 기본 단위가 된다. 이렇게 기본이 되는 함수를 잘 만들어야 이해하기 쉬운 코드를 만들수 있다는데 다들 공감할 것이다. 이야기를 꺼내기에 앞서 학부시절 에피소드를 소개하고자 한다.

  학부시절 과제로 만든 C언어 프로그램 코드는 그 크기는 작고 수준도 낮았겟지만 다양한 코드를 읽어볼 수 있는 좋은 기회였던 것 같다. 어려운 과제가 나오면 삼삼오오 모여서 간밤에 서로 만들었던 코드를 비교해 보곤했다. 다른 사람은 200~300줄로 구현한것을 A4 1장에 구현한 친구를 보고 다들 신기해한 기억이 난다. 성적도 좋아 장학금을 받는 친구들이 대부분이다. 돌려보면 동작 속도도 빠르다. '나와는 다른 세계의 똑똑한 친구가 만든 코드라서 내가 이해할 수 없는 것이다'라고 다들 생각했던 것 같다. 우리는 컴퓨터가 잘 이해하는 코드에 무슨 문제가 있겠는가 생각했다. 우리가 그들보다 지적 수준이 낮아서 그들의 고귀한 코드를 이해하지 못할 뿐이라고 자책할뿐이였다.

  중복을 줄이다보면 코드가 줄어들고 좋은 코드가 된다고 한다. 그러나 앞에서 소개한 이야기는 그러한 것과는 다른 이야기 이다. 주석도 없이 변수는 3~4자의 알파벳으로 되어 있고 for, if등은 가로로 가지런히 줄을 서있다. 창의적인 압축코드였다. 얼마전 TV에서 초코렛에 밥을 비벼먹는 사람이 소개되었다. 당신의 애인이 창의력을 발휘해서 초코렛 비빔밥을 정성껏 만들어준다면 맛있게 먹겠는가? 한두번은 몰라도 매일은 힘들것 같다. 코드도 그렇다. 내가 만든다고 내 마음대로 해서는 안된다.
  자, 그렇다면 좋은 함수는 어떤 것일까? 물론 다들 생각이 조금씩 다를 것이다. 나는 로버트 마틴의 주장에 공감하고 그의 주장을 이야기 하고자 한다.


1. 한가지만 하는 짧은 코드가 좋은 코드이다.
  십수만 라인의 C 프로그램을 만들다가 어느 날 3000 라인이 넘는 함수를 몇시간만에 작석하고는 무척 괴로워했던 기억이 있다. 매우 복잡한 자료구조와 정교한 포인터들로 범벅이된 코드이기 때문에 함수들로 추상화하면 길을 잃을 것 같았다. 동료들은 내 C언어 실력이 뛰어나다는 말을 해주었지만 동료들이 이해할 수 없는 암호를 만들어 버린 것 같아 괴로웠다. 그 함수는 무척 빨랐고 메모리도 효율적으로 사용했고 수년간 버그가 발견되지 않았다. 그러나 난 그 함수를 읽기 쉽게 할 수 없었다. 아이스크림을 바닥에 떨어뜨리고 어쩔줄 몰라 울어버리는 아이와 바를바 없었다.
  어느날 3000줄 짜리 함수를 고쳐야 한다고 생각해보자. if와 for가 여기 저기 4중 5중 중접되어있다. 주석은 있는데 도대체 왜 달아놨는지 한심하기만 하다. 일주일을 봤지만 이해가 안간다. 고쳐보니 프로그램이 뻗어버린다. 원인을 알 수 없다. 이런 상황을 힘들게 이겨낸 것을 무용담처럼 후배들에게 떠들지 말자. 그냥 똥을 치웠을뿐이다.
  이쯤되면 긴 함수가 나쁘다는 생각이 들것이다. 그렇다면 길다는 기준이 있어야 하는데 그게 참 어렵다. 길다는 말자체가 모호하기 짝이 없다. 예전에 어떤 분은 자기 모니터가 해상도가 얼마라서 font크기를 몇으로 하니 한 화면에 몇줄이 들어가서 함수 길이를 그정도 이내로 한다고 한다. 쉽게 말해 자기 컴퓨터에서 한 화면에 나오면 좋아한다. 좋아보이는가? 그러나 난 이것도 길다고 생각한다. 함수 본문은 5줄을 넘으면 안된다. 애정남처럼 딱 정했으면 좋겠다. 사람은 한번에 6~8개 정도를 기억하고 처리할 수 있다고 한다(심리학에서 이 단위를 chunk라고 한다). 우리의 메모리 용량이 7인것이다. 메모리보다 큰 파일을 한번에 읽으면 어떻게 되는지 프로그래머라면 잘 알것이다. 함수의 signature 선언으로 함수 앞뒤에 2줄을 사용한다. 5+2=7 . That's it.
  경험이 많지 않거나 관성으로만 코딩을 해오신 분이라면 당황할지도 모르겠다. 필자를 사기꾼이라 하고 싶은가? 자신이 할 수 없으니 불가능하다고 생각하지 말자. 잘 짜여진 코드는 하나의 작업 책임만 가진다. if문 안에 주절주절 떠들지 않으면 된다. try catch 구문속에 수다를 널어놓지 말자. 한줄씩이면 충분하다. if else 구문은 1줄씩 해서 총 4줄로 구현하는 식으로 추상화 레벨을 높일 수 있다. 그런식으로 했가다는 함수가 너무 많아져서 관리 할 수 없다고? 1000줄짜리 함수 하나와 5줄자리 함수 50개중에 어느것이 더 이해하기 쉽겠는가? (200개가 아니라 50개라고 한것은 대부분 추상화 수준을 올리면 중복이 줄일 기회가 많아지기 때문이다.)


2. "switch"는 묻어버려라.
  "switch"는 작게 만들기 어렵다. "switch"가 있으면 한가지가 아니라 N가지 일을 하는 함수가 된다. 그렇다고 쓰기 않으려고 하니 너무 불편하다. 추상화 레벨의 저수준에서만 딱한번씩만 switch를 사용하여 factory를 구현하고, 분기에 따른 로직은 다형성으로 구현하자. 이러라고 OOP가 있는 것이다. 지저분한 switch는 땅속 깊이 묻어버리고 우리는 고상한 코드만 볼 수 있을 것이다. 물론 어쩔수 없이 상위 로직에서 switch를 써야 할 일도 있을 것이다. 하지만 정말 불가피한지 고민해봐야 한다.


3. 함수의 매개변수는 2개 이하
  매개변수가 없는 함수는 최고다. 1개가 있어도 좋다. 2개까지는 봐주자. 3개는 불쾌하다. 4개의 매개변수를 가진 함수를 만들려면 만들지 말고 차라리 옆사람에게 키보드를 넘겨라. 그런건 필요 없다.
  정수 8개를 매개변수로 받는 함수를 생각해보자. 인기가 좋아 여기 저기 호출된다고 생각해보자. 인기가 좋다니 나도 한번 호출해본다. 8개중에 하나만 순서가 틀려도 찾기 힘든 버그가 된다. 아주 긴장해야 한다. 살짝 녹은 겨울강의 얼음을 밟고 건너듯 조심해야 한다. 다른 사람도 이러게 호출했을 것이다. 그러나 누군가는 얼음이 깨져 겨울 강물에 빠지게 된다. 당신 잘못이 아니다. 호출하기 어렵고 실수하기 쉽게 만든 사람이 나쁘다. 그러나 곤경에 빠진건 당신이다.


4. 매개변수에 boolean은 절대 금지
  매개변수에 true나 false가 들어가서 호출된 함수를 보면 눈살을 찌푸리게 된다. 이런 양다리 바람둥이 같으니!! 이 함수는 분명 2가지 일을 한다. 함수는 칫솔과 같다. 친구와 같이 쓰지 말고 각자의 것을 마련해라. 왜냐고? 더러우니까. 사소한 이유로 당신의 코드를 더럽히지 말자.
  saveReportFile(true);
  이런 코드가 무슨일을 짐작도 하기 어렵다. 이런 코드는 양다리 바람둥이니까.


5. Side effect를 발생시키지 말자.
  함수 이름과 관련 없는 일은 하지 말자. "isValidUser(User user)" 이 함수는 무엇을 하는 함수일지 짐작이 될 것이다. 올바른 사용자가 아니라고 user 객체의 필드들을 모두 null로 초기화 해버린다면 어떨까? 사용자가 알수 없게 저렇게 캡슐화 하는게 진정한 추상화라 생각하는가? 저 함수를 쓸 때마다 뒤에 숨은 저런 기능을 기억해야 한다. 난 그런 것들을 모두 다 기억할 정도로 머리가 좋지 않다. 물론 기억이라는 것도 저런 side effect 때문에 몇시간을 디버깅으로 고생한 다음이겠지만 말이다.
  이 예제는 몇가지 의미가 더 있다. 매개변수로 넘어온 객체의 내부상태를 변경하려 하지 말라는 것이다. 출력은 매개변수로 하지 말고 return하라는 말이다. 그리고 함수는 질문에 답하거나 어떤 행위를 하거나  하나만 해야 한다.
  boolean setSession(Session session);
  이 함수는 뭘 하는 함수 일까? session 객체값을 이용해 세션을 변경하는 것일까? 아니면 세션이 설정이 되었는지 확인 하는 것일까? 반환값은 세션 설정에 성공하면 true일까? 아니면 세션이 잘 설정되어 있으면 true일까? 이런 저런 짐작으로 저 함수의 코드를 열어봐야 한다면 함수를 작게 나눈 의미가 없다. 그냥 긴 함수로 만들어라. 작은 함수들로 나누면 이해하기 어렵다고 불평하는 당신은 추상화에 대한 무지함을 드러낼 뿐이다.


6. 오류 코드보다는 예외 사용하자
  함수가 성공하면 1을 반환하고 실패하면 0을 반환하는 것과 비슷한 코드를 많이 보았다. 그런데 누구는 성공하면 0이고 실패하면 -1이란다. 실패하면 100~200 사이의 오류 코드를 반환하고 싶을 수도 있다. 오류 코드를 잘못 체크하거나 안해도 컴파일러는 알수 없다. 이런 것 때문에 발생하느 버그는 지옥이다. 이런것때문에 생일날 친구들과 약속을 잡았는데 새벽 2시까지 야근한다고 생각해보자. GG
  자바에서 예외는 checked exception과 runtime exception에 대해 구분해서 사용하는 것이 중요하다.  그러나 이 글의 주제에서 벗어나므로 나중에 기회가 다루면 예외의 사용법에 대해 포스팅하겠다. 예외를 사용하면 에러 체크를 가시화 할 수 있고 함수 호출부에서 에러코드를 체크하는 지저분한 if else의 반복을 제거하여 가독성이 올라간다는 것만 기억하면 좋겠다.

마치며..
  짧고 읽기 쉽게 잘 추상화 해놓은 코드를 보면 놀랍기만 하고 나는 저런 것을 절대 만들수 없을 것 같다는 생각을 할 수 있다. 원래 코드란게 그렇다. 그러나 대부분의 좋은 코드는 한번에 작성되는 경우는 거의 없다. 글짓기와 비슷하다. 우선 말이 되게 하고 고쳐보자.


출처 : http://dsmoon.tistory.com/entry/%EC%9D%BD%EA%B8%B0-%EC%89%AC%EC%9A%B4-%ED%95%A8%EC%88%98

가독성을 높이는 오류 처리

  유비무환. 이런 저런 책이나 강의에서 수도 없이 들어온 말이지만, 미리 준비한다는게 그리 쉽지만은 않다. 열심히 만든 SW도 여러 오류 상황들에 품질에 대한 혹평을 받게 되기도 한다. 나름 잘 나가는 수많은 SW 엔지니어들이 개발하고 있는 윈도우는 많이 좋아졌다고는 하나 알수 없는 오류를 종종 내뱉곤 한다.
  이러한 현실에 대처하는 초보 개발자의 모습은 크게 두가지중 하나일 것이다. 똑똑한 내가 만들었으니 버그가 없을 거라고 자신하는 멍청한 낙관 주의자이거나, 여기 저기 에러 체크 if문을 남발하는 지저분한 비관주의자 일 것이다. 경험이 풍부한 개발자라면 이러한 상황 둘 다 좋지 않음을 알 것이다. 오류 처리는 반드시 필요하지만 처음에 우리가 구현하고자 했던 로직을 덮어버려 읽을 수 없도록 해서는 안된다.
  자바 문법책 한두권 보고 자바를 할 줄 안다고 하는 개발자들의 코드를 들여다 보면 코드가 읽기 어려운 경우가 종종 있다. 의외로 경력도 제법 되고 회사에서 인정도 받는 사람이 이렇다면 난감할 뿐이다. 추상화가 안되어 있고 긴 함수에 상속을 남발하는 등의 문제가 복합적으로 나타난다. 그러나 이중 제일 난감하면서도 이해시키기 힘든 부분중 하나가 오류 처리이다. if( result == ***) 이런식의 코드로 오염된 코드는 혼돈이 넘실거린다. 그러나 코드를 작성한 사람은 그 부분을 제일 자랑 스러워 할 지도 모르겠다. 나는 경험이 많아서 이렇게 오류 처리를 꼼꼼히 했노라고. 이런 사람은 노력을 통한 자기 발전을 뒤로한채 관성에 의해서만 일해왔을 가능성이 많다.
  이해가 안될 수도 있다. 아래의 예제를 보자.

 위의 함수는 자바코드이지만 전형적인 C언어 스타일이다. 이래선 객체고 상속이고 열심히 해봐야 좋은 코드를 만들기 어렵다. 이런 코드는 아래와 같이 오류 처리의 책임을 담당하는 함수를 만들어서 오류처리와 비즈니스로직을 분리해야 한다.

  어떤가? 읽기 쉽지 아니한다. 물론 위의 코드가 아래 처럼 되려면 많은 refactoring 단계를 거쳐야 할 것이다. 이 과정은 이번 주제에서 벗어남으로 생략하겠다. 궁금하다면 마틴 파울러의 Refactoring 이란 책을 구해서 보길 바란다.
  위의 두 예제에서 이야기하고자 하는 것은 두가지이다. 첫째, 오류코드를 반환하는 함수보다 자바의 예외를 적극 활용하자. 자바라는 언어를 만든 언어 개발자들이 예외를 왜 만들었는지 생각해보자. 우리는 자바가 나오기 전에도 잘 개발해 오지 않았는가. 그러나 오류 코드를 반환하는 코드는 클라이언트에 오류체크를 강요 할 수도 없었고, 여기 저기 지저분한 코드만 양산했을 뿐이다. 대부분의 오류 상황은 로그를 남기거나 오류 메세지를 보여주거나 하는 등의 대처밖에 할 수 없다. DB 접속이 안되거나 파일을 읽을 권한이 없거나 사용하려는 값이 null 인 상황에서 할 수 있는 것은 많이 없다. 그러나 해결할 수 없는 상황을 위한 코드들이 코드의 보수 유지성을 망치도록 두어서는 안된다.
  둘째, 오류처리 자체를 하나의 책임으로 봐야 한다. 오류 처리를 여기저기 붙여 넣기 하고 중첩된 if문을 남발하지 말자. try-catch 문이라도 다르지 않다. try-catch 구문은 트랜잭션과 같이 다루어야 하고 하나의 중요한 기능으로 보아 별도의 함수로 구현해야 한다. try-catch 구문을 읽느라 중요한 비즈니스 로직을 구현한 코드의 가독성을 망쳐서는 안된다. 위 예제에서 보면 예외처리만 별도의 함수로 구성한 것을 볼 수 있다. 물론 처음부터 저런 구조가 아닐 수 도 있다. 그러나 리팩토링을 통해서 저런 코드를 commit하도록 하자.

Checked exception은 가급적 사용하지 말자
  자바 언어를 만든 언어개발자들은 checked exception이란 것을 만들었다. 이 함수는 어떤 예외가 발생할 수 있으니 함수를 호출할 때 예외 처리를 명시적으로 하지 않으면 컴파일도 못하게 하겠다는 것이다. 어떤 함수가 성공하면 0을 반환하고 실패하면 1~100 사이의 에러코드를 반환하는 경우 대부분 결과값이 0인지만 체크한다. 이렇게 못하게 하겠다는 것이다. 아름답지만 실용적이지 못했다. C#, C++ 은 checked exception을 지원하지 않지만 멋진 프로그램을 만드는데 지장이 없다.
  Checked exception은 좋은 의도에서 시작하였지만 너무 비싼 비용때문에 사용하지 않게 되었다. SOLID 법칙 중에 Open Closed Principle(OCP)를 위반하는 비용을 치뤄야 한다. 하나의 변화에 여기저기 수정하는 것은 직관적으로도 보수유지를 어렵게 한다는 것을 알 수 있다. 하위 로직에서 checked exception을 던지면 이를 호출하는 상위 함수와 그 함수들을 호출하는 더 상위의 함수들은 모두 이 exception을 정의 해야 한다. 여기 저기 지저분안 throws 구문이 들어갈 뿐 아니라, 하위에서의 변경이 모든 상위 함수로 전파된다. 다른 계층의 코드들이 강한 결합도를 갖게 되는 것이다.
  물론 checked exception도 그 태생이 가지는 장점이 있다. 중요 라이브러리의 공개 인터페이스에서는 예외를 선언해 주는 것이 좋을 수도 있다. 클라이언트에세 어떤 예외가 발생할 수 있으니 명시적으로 알려주는 것이다. 사용자는 예외를 처리하는 wrapper를 만들 수 있을 것이다. 그러나 일반적인 용도로는 이익보다 비용이 비싸다는 것을 기억하자.

Null을 반환하지도 전달하지도 말자.
  함수를 한줄 호출할 때마다 결과 값이  null인지 체크하는 if문이 들어간 코드는 읽기에 불편하다. Null object pattern은 이런 경우 좋은 해결법일 수 있다. 그러나 Null object pattern은 매우 주의 깊게 코딩하지 않으면 통계가 중요한 어플리케이션에서 오동작 할 수 있다. 그리고 List를 반환하는 함수라면 null대신 빈 List를 반환하도록 하자. 클라이언트에 null체크의 책임을 전가하는 것은 가독성을 해치는 것을 넘어서 실수로 인한 null pointer exception을 유발한다. 이러한 오류는 비교적 잡기 쉬운 버그이지만 고객은 이미 마음이 상한 다음일 수도 있다.
  Null을 매개변수로 넘기는 것도 문제가 있다. 매개변수를 사용하기 전에 null 체크를 하라고 학교에서 배웠을 수도 있다. 사용전에 validation check를 하는 것을 좋을 수도 있다. 그러나 이런 코드가 여기 저기 들어갈 수록 가독성을 멀어진다. 실수도 잦아진다. If문이던 assert문이던 가독성을 해친다는 것은 변치 않는다. 애초에 null을 넘지기 않는다는 정책이 깨끗한 코드를 만드는 큰 발걸음이 될 것이다. 알수 없는 오류의 발생도 적어지니 소프트웨어의 품질도 올라갈 것이다.
  물론 null 검사를 완전히 제거하기는 어렵다. 로버트 마틴과 켄트백은 null pointer exception이 발생한다면 그것은 null 발생에 대한 테스트 코드가 부족해서 라고 말한다. 우리가 어렵지만 TDD를 해야 하는 또 하나의 이유이다.

출처 : http://dsmoon.tistory.com/entry/%EA%B0%80%EB%8F%85%EC%84%B1%EC%9D%84-%EB%86%92%EC%9D%B4%EB%8A%94-%EC%98%A4%EB%A5%98-%EC%B2%98%EB%A6%AC

클래스 설계시에...

  눈도 고치고, 코도 고치고, 입도 고치고, 여기 저기 성형 수술한 사람을 얼마전 TV에서 보았다. 다들 놀랐다. 그렇게 많은 돈을 들여서 수술했음에도 우리가 생각했던 그런 미인은 아니였다. 이상하게 보이기까지 했다. 눈도 크고, 코도 오똑하고, 입술도 도톰하게 돈을 들이셨지만 결과는 망했다. 디테일도 중요하지만 얼굴이라는 전체적인 관점에서도 신경써야 한다.
  예쁜 코드도 이와 같다. 변수와 함수등에 신경을 많이 쓰더라도 클래스 관점에서 신경쓰지 않는다면 결국엔 노력하고도 좌절하는 일이 생긴다. Clean code는 clean class 없이는 불가능하다. 

클래스는 최대한 작게 만들자.
  변수를 수십개, 함수를 수십개 가진 클래스는 수정뿐만 아니라 사용하기도 어렵고 혼란스럽기까지 하다. 이 클래스틑 여러가지 이유로 변경되므로 보수 유지도 어렵게 한다. 이것 저것 다 쑤셔 넣어놓고 맥가이버 칼 같이 만능 클래스를 만들었다고 자랑스러워 하지 말자. 이것저것 남은 음식을 모아놓은 음식쓰레기와 같은 것을 만들었을 뿐이다. 그런것은 더럽고 다시 보고 싶지도 않다.
  그렇다면 얼마나 작아야 할까? 함수 10개? 5개? 1개? 함수나 변수 갯수의 기준을 숫자로 제한하기는 어렵다. 우선 클래스 이름에 해당 클래스의 모든 책임이 드러나게 이름을 지어보자. Manager, Super, Processor 등의 모호한 단어가 이름에 들어간다면 여러가지 책임을 하고 있을 것이다. 명확한 이름을 짓고 그에 해당하는 함수들만 모여 있어야 한다.
  클래스에 대한 설명도 적어보자. "~할 때에", "그리고", "~이거나", "~하지만", "~하면서", "~라면" 등의 말을 사용하지 않고 25단어 이내로 기술해보자. 이게 어렵다면 클래스를 책임에 따라 여러개로 나누어야 한다는 신호일 수 있다.

Single Responsibility Principle (SRP)
  잘 알려진 SOLID 법칙중 하나인 SRP는 클래스나 모듈의 변경 이슈가 하나여야 한다는 규칙이다. 대부분 SRP를 설명하면서 쉬운 규칙인데 잘 적용하지 않는다고 한다. 솔직히 고백하자면 나는 아직도 SRP가 어렵다. 우선 "책임"이란 것의 크기가 모호하다는 것이다. 내가 생각하는 "책임"과 동료가 생각하는 "책임"의 크기가 다를 수도 있다. 내가 어제 생각한 "책임"의 크기와 오늘 생각한 "책임"의 크기도 같다고 보장할 수 없다. 이러한 모호함을 없애기 위해 책임을 수정에 대한 이유로 정의 하기도 하지만 이 경우도 애매하다. 로버트 마틴은 actor를 기준으로 하면 모호함이 더 줄어든다고 한다. SRP는 그 자체 만으로도 큰 주제이므로 여기서 접어두고 다음으로 이야기를 이어가겠다.
  실제로 하나의 책임만 가지는 클래스로 잘게 나눈다는 것은 많은 연습을 해도 하기가 정말 어렵다. 인간의 두뇌는 비슷한 사실을 모아서 개념와 하도록 발달되었다. "둥굴고 빨간색이며 나무에 달린 것은 사과다." 라고 세상의 수많은 사과들을 하나의 개념으로 모은다. 이런 이유로 프로그램도 여러 비슷한 개념들을 자꾸 하나의 클래스나 모듈로 모아야 안심이 된다. 만능 클래스는 심리적 안정감을 주기까지 한다. 이것만 있으면 무엇이든 할 수 있다는 생각이 든다. 그러나 이런 저런 이슈로 그 클래스들을 수정할 때 쯤 되서야 내가 무슨 짓을 저질렀는지 후회하며 초과 근무를 하게 된다.
  최대한 잘게 나누자. 작은 것이 아름답다고 생각하자. 수많은 클래스에서 긿을 잃을 것이라고? 당신이 vi로 코딩하고 터미널에서 javac로 하나씩 컴파일하고 있다면 맞는 말일 수도 있다. 그러나 되도록이면 IDE를 사용하자. IDE는 멋진 네비게이션이 되어 줄 것이다. 우리는 많은 기능을 제공하는 무료 IDE를 사용할 수 있는 멋진 시대에 살고 있지 않은가. 

High Cohesion(높은 응집도)
  클래스는 내부 구성요소들이 똘똘 뭉쳐 있어야 한다. 한가지 수정하면 클래스내 여기저기를 고쳐야 하거나 클래스를 새로 짜야 한다면 응집도가 높은 것이다. 이상하게 들릴수도 있다. 한군데만 수정되는게 좋지 클래스를 통채로 수정한다고? 낮은 결합도(low coupling)과 같이 생각하면 이해하기 쉬울 것이다. 하나의 변경의 이유가 하나의 클래스의 변경만 가져오도록 하자는 것이다. 클래스 내부의 응집도는 높게, 클래스 사이의 결합도는 낮게 해서, 변경시 사고의 폭을 하나의 클래스로 제한하자는 것이다.
  높은 응집도를 가진 클래스는 자연스럽게 그 크기가 작아진다. 클래스의 각 메소드들은 거의 모든 멤버변수들을 골고루 사용한다. 몇개의 함수들이 일부 변수만 집중적으로 사용한다면 이들은 별도의 클래스로 분리 해야 한다. 이때 분리해야 할 함수들이 privat 속성이라 망설이게 되는 경우도 있다. 모두 공개되지 말아야할 내부 함수처럼 보일 수도 있다. 이런 경우 별도의 클래스로 분리하게 되면 public으로 공개해도 되는 면제부가 생긴다고 생각하자. 새로운 클래스로 위치가 바뀌었으니 공개의 기준이 바뀌는 것은 당연하다. 브라질에서 후보였던 축구 선수가 다른 나라로 옮기고 주전이 된다고 해서 이상하게 생각할 것은 아닌듯하다.

  좋은 클래스를 만드는 방법은 여기서 이야기 한 것들이 전부는 아니겠지만, 기본적으로 중요한 부분들은 대부분 조금씩 언급한듯하다. 물론 너무 짧은 지면에 많은 이야기를 하려다보니 이해가 잘 안되는 내용도 있을 것이다. 짧은 글 하나로 하루 아침에 모든 것을 이룰 수는 없다. 보수유지 하기 쉬운 클래스를 만드는 방법을 알기위해 공부해야 할 것들에 대한 화두를 던질 글 정도로 봐줬으면 한다.



출처 : http://dsmoon.tistory.com/category/Programming/Clean%20code%20%28by%20D.%20Moon%29