High Cohesion, Loose Coupling

프로그래밍 2007/10/03 02:40

상속과 인터페이스

여러분은 OO 하고 있습니까??



High Cohesion, Loose Coupling

높은 응집도 그리고 낮은 결합도(또는 느슨한 결합)


  학교에서 소프트웨어 공학 시간을 통해서 배웠고, 또한 '임백준의 소프트웨어 산책'이라는 책을 읽으면서 다시한번 개념 다지기에 들어갔다. 그리고 나는 은근히 이것들에 집착(?)한다.

  소프트웨어에게도 수명이라는 것이 있다. 시간이 지날수록 나이는 먹어가고.. 그러다가 많은 시간이 흘러 나이를 많이 먹으면 죽는거다.(단순히 나이를 많이 먹어서 죽는 것은 아니지만)


  건강하게 태어난 소프트웨어는 살아가는 동안 쉼없이 자신을 확장하게 된다. 새로운 능력이 더 필요하다면 그는 얼마든지 자신을 확장한다. 부족한 부분이 있다면 그것에 대한 보완도 하며 그는 열심히 살아간다. 아~주~ 오래오래 행복하게 살아간다. 오래오래 행복하게 살아가는 소프트웨어를 보고 있자면 그를 태어나게한 개발자들도 그를 기특하게 여기며 뿌듯해 한다.


  탄생하면서 스파게티 소스를 간직하고 태어난 허약한 소프트웨어는 수명이 매우 짧다. 비운의 소프트웨어다. 아.. 상상하니 눈물이 마구 흘러내린다.ㅠㅠ

  어느날 허약한 소프트웨어에게 앞으로 해야 할 일은 오른팔을 많이 사용해야 하니 오른팔을 단련해 두라는 지시가 내려왔다. 그는 열심히 팔의 근육을 확장해서 새로운 업무에 필요한 튼튼한 오른팔을 만들어냈다. 그런데 이게 왠일인가. 오른팔만을 확장했을 뿐인데 갑작스레 왼발이 저려온다. 이유는 알 수 없지만 왼발이 자꾸 저려서 그는 쩔뚝쩔뚝 다리를 절어 가면서 일을하게 된다. 일단 일은 할 수 있으니 다행이다. 다음번엔 왼팔을 확장했는데 오른쪽 다리가 저려온다. 자꾸자꾸 몸에 원인모를 이상증세가 찾아오다 결국 그는 일을 할 수 없게 되었고 그는 얼마 지나지 않아 죽게되었다. 스파게티 소스때문에..ㅠㅠ 불쌍한 친구..ㅠㅠ

  그가 계속 살아갈 수 있는 방법은 있었다. 리팩토링(Refactoring)이라는 수술을 받으면 그는 살아갈 수 있다고 했다. 하지만 비교적 작은 수술로 재기할 수 있었던 건강한 소프트웨어와는 다르게 그는 큰 수술을 필요로 했고 수술비도 만만치가 않았다. 태어나면서부터 선천적으로 가진 '스파게티 소스'라는 병 아닌 병 때문에 말이다.


  건강한 소프트웨어를 만들고 싶다. 건강하게 오래오래 사는 소프트웨어는 높은 응집도와 낮은 결합도를 가지고 있다. 그는 유연해서 어떤 일이든 어렵지 않게 배운다. 유연하고 모든 쉽게 잘 할 수 있는 이런 녀석이 정말 튼튼하고 건강한 놈이다.

  그래서 나는 코드를 만들때 결합도와 응집도에 대한 많은 고민을 한다. 그가 다른것에 의지하지 않도록 다른 객체와는 느슨하게 결합하고, 응집도는 높게 독립적으로 만들려고 고민을 한다. 그런데 슬프게도 난 고민만 열심히 했지 High Cohesion, Loose Coupling을 충족하게 만들지는 못하고 있다. 다만 스파게티를 뽑아내지 않으려 노력하고 있을 뿐이다. 나는 요리사가 아니니까 말이다.

  여러분은 OO하고 있습니까?.... 뜬금없다..ㅋㅋㅋS

OO: Object Oriented
top
     TAG 객체지향, 프로그래밍
트랙백 0 : 댓글 2

트랙백 주소 :: http://signpen.net/blog/trackback/2510831

학교에서 배운 지식은 죽은 지식이다??

프로그래밍 2007/08/20 23:13
사용자 삽입 이미지
  얼마전에 읽은 '나는 프로그래머다'라는 책에서 임베디드 프로그래머 유영창님의 파트에서 '학교에서 배운 지식은 죽은 지식이 아니다'라는 제목의 글이 있었다.

  우선 '나는 프로그래머다'라는 책에 대해서 간략하게 설명하자면 같은 IT분야이지만 서로 다른 분야에 있는 7명의 프로그래머가 모여서 엮은 책입니다. '임백준의 소프트웨어 산책'의 저자인 임백준씨와 임베디드 프로그래머 유영창씨, SI분야의 원은희씨, 게임프로그래머 김용준씨, 기업 전산실에 대해서 글을 쓰신 김종호씨, 데이터 아키텍트에 대한 글을 쓰신 이춘식씨 그리고 OKJSP사이트의 운영자이자 웹프로그래머이신 허광남씨. 이렇게 같으면서도 다른 분야의 7명의 IT인의 글이 실려있는 책이다.

  프로그래머를 꿈꾸는 한 명의 후배로서 다양한 분야의 선배님들의 글을 참 재미있게 읽었고 또한 좋은 말들은 마음속에 새기며 즐겁게 책을 읽을 수 있었다. 현업에서 뛰고 있는 프로그래머들이 어떤 일을 하며 어떻게 생활하며, 어떤 생각을 가지고 살아가는지도 무척 궁금했었는데 어렴풋이나마 느낄 수도 있게 해 주었던 책이었다.


  오늘 쓰고자 하는 것은 임베디드프로그래머 유영창씨의 글 중에 있었던 제목인 '학교에서 배운 지식은 죽은 지식이 아니다'라는 것에 대한 이야기이다.

  나 역시 학교에서 배운 지식은 죽은 지식이 아니라고 생각하고 있다. 다른 분야는 잘 모르겠지만 전산학과에서 만큼은 확실히 진실이다. 친구들이나 전산학과에 있는 몇몇 사람들을 보면서 참 자주 들었던 이야기가 "학교에서 배운건 참 쓸데없다"라는 뉘앙스의 이야기였다. 하지만 난 그렇게 생각하질 않는걸.

  대부분의 학교에서 비슷 하겠지만 전산학과에선 참 많은 것들을 배운다. 기본적으로 프로그래밍 언어부터 데이터베이스, 자료구조, 알고리즘, 컴파일러, 운영체제, 소프트웨어 공학, 논리회로, 인공지능 등등 참 배우는 것도 많다.(전산수학은 그냥 뺐습니다. 분명 필요한 과목이지만 전 싫어요..ㅠㅠ)

  모두 중요한 과목인데 프로그래밍언어 외의 각각 과목은 '도대체 이걸 어디다 써먹는걸까?', '써먹을데는 있는걸까?', '이건 그냥 고리타분한 이론들이잖아.' 라는 생각을 갖게 만들기 일수이다.

  Automata, Hash, List, SortAlgorithm, Tree.. 뭐 이런걸 알아다가 어디다 쓸까. 하지만 분명 쓰일 일이 있고 알아야 할 때가 있다. 전공을 살려서 직업을 선택하게 된다면 말이다. 평생 알 필요 없이 잘만 살 수도 있으나 내가 생각하기엔 알면 편하고 알면 좋고, 알면 모르는 사람보다 훨씬(!) 유리하다.

  간단하게 자바의 ArrayList를 생각해 보자. 내부적으로는 리스트구조로 만들어 져 있다는 이야기를 들은적이 있다. 사실 나도 자세하게 공부하진 않아서 깊은 지식까지는 없지만 일단 예로 들어보고자 한다. 이미 만들어져 있는 API이니 우리는 그냥 대충 이해하고서도 충분히 프로그램을 짤 수 있고 지장은 없다. 하지만 필요에 의해서 ArrayList를 확장(extend)해서 사용하게 되거나 어쩔 수 없는 상황에 의해서 ArrayList처럼 리스트구조로 된 업무에 필요한 API를 만들어서 사용해야 할 일이 있다고 생각해보자. 그럼 그 때가 되어서 대학시절 배웠던 자료구조 책을 찾아 가면서 다시 공부하고 뒤져가면서 만들텐가?

  물론 필요하다면 다시 책을 찾고 공부를 하면서 만들어야 하겠지만 대학시절 관심있게 공부했던 상태에서 책을 찾는것과 전혀 관심을 두지 않아 아무것도 모르는 상태에서 책을 뒤지는 것과 어느 쪽이 유리할까?

  자료구조 뿐만 아니라 컴파일러, 알고리즘도 프로그래밍에 대해서 깊게 공부해야 할 수록 많은 도움이 된다. 여러 가지를 공부함에 있어서 학교에서 배운 지식이 쓸데 없는 것이 아니라는 것을 느끼며 당시 수업을 들었던 것이 지금 공부하는 것의 이해에 많은 도움이 된다는 것을 알아가고 있다. 가끔은 당시에 대충 수업을 들었던 것에 대한 후회를 일으키기도 한다.


  아는 것도 적고 글 재주도 없어서 이렇게 밖에 설명을 못하겠지만 '나는 프로그래머다'라는 책을 읽어보면 학교에서 배운 지식은 죽은 지식이 아니라는 것을 좀 더 와닿게 느낄 것이다. 아무래도 나 보다는 더 많은 것들을 겪은 선배들의 글이니까 말이다.

  아, 관련해서 또 생각나는 이야기가 게임프로그래머 김용준씨의 글을 읽어보면 게임프로그래밍에서는 자료구조를 정말 잘 알아야 한다고 합니다. 자료구조가 필요한게 게임프로그래밍 뿐이겠냐만은 게임프로그래밍에선 더 중요한가 봅니다.S

Update 2007/8/22
곰곰히 생각해보니 가장 많이 써먹는 자료구조로 스택하고 큐가 있네요. 이걸 예로 들었으면 더 좋았을껄..;;;

Update 2007/8/23
본문에 자바의 컬렉션프레임워크 중 하나인 ArrayList를 가지고 예를 만들어 적었었으나 제가 잘못 알고 있는 부분이 있는 것 같습니다. 자세하게 설명해 주실 분 안계신가요?ㅠㅠ 지식이 얕으니 글쓰기가 항상 조심스럽네요^^ㅋ

top
     TAG 전산학, 프로그래밍
트랙백 0 : 댓글 4

트랙백 주소 :: http://signpen.net/blog/trackback/2510811

보고싶은 코드, 보기싫은 코드

프로그래밍 2007/08/11 01:15
  사람들마다 성격이 다르고 생각이 다르고 개성이 다르다. 그렇지만 내가 지금까지 수 없이 만나왔던 '보기싫은 코드'는 내가 장담컨데 사람의 스타일이 달라서가 아니었다.

  한 때 KLDP에서 썬의 코딩스타일과 GNU의 코딩스타일에 관련된 게시물을 하나 읽게 되었고 코딩스타일에 대해서 잠시동안이나마 고민을 해 본적이 있었다. 썬의 코딩스타일, GNU의 코딩스타일의 차이 중 중괄호의 표기방법에 대한 것이었는데 두 스타일의 차이는 이렇다.

GNU의 스타일

while(var)
{
    if(0 < a)
    {
        continue;
    }
    else
    {
        break;
    }
}

썬의 스타일

while(var){
    if(0 < a){
        continue;
    }else{
        break;
    }
}

  위의 두 코드는 내용이 없는 임의로 작성한 코드이니 코드의 내용보다 중괄호의 형태를  살펴보자.

  나는 처음 배울 때 부터 썬의 스타일로 배웠고 썬의 스타일로 표기된 책 밖엔 보질 못했었다. 그랬기에 GNU의 스타일을 처음 봤을때 무척이나 신선했다. 썬의 스타일과는 다르게 GNU스타일은 괄호의 범위나 반대쪽 짝을 알아보기가 훨씬 수월하다.

  중괄호가 여러개 중첩된 코드를 작성하게 될 때마다 중괄호의 범위를 혼동해서 실수할 때가 많았기 때문에 들여쓰기는 그 무엇보다 우선해서 철저하게 하는 편이었다. 코드의 가독성을 높이고 실수를 줄이기 위한 내 나름대로의 자구책은 철저한 들여쓰기였는데 다른 방법으로 중괄호를 표기하는 방법이 있었다는 것은 미처 생각치 못했었다.

  그래서 GNU스타일이라는 것을 보게 된 이후에 한동한 GNU스타일로 중괄호를 표기하는 코딩을 한적도 있었다. 그러나 눈에 익은게 더 편한법이라 얼마 지나지 않아 다시 원래의 스타일을 사용했고 들여쓰기를 철저하게 지키려 노력하고 있다.


  코드의 가독성을 고민해 보지 않은 사람이라면 절대 저 중괄호의 의미를 모를 것이다. 들여쓰기가 왜 필요한지도 모를 것이다. 이건 정말 간단하면서도 중요한 문제인데도 말이다.

  내가 지금까지 접했던 '보고싶은 코드'와 '보기싫은 코드'에는 코딩스타일(위에 적은 스타일속성과는 전혀 다른)이 크게 작용한 편이다. 들여쓰기가 잘 되어있고 중괄호의 범위를 잘 알 수 있게 만들어두고 연관성있는 이름으로 변수명, 메소드명, 클래스명을 표기 해 놓은 코드는 그 코드가 무슨 내용을 담고있던 간에 한번쯤 보고싶게 만드는 코드들이었다. 반면에 들여쓰기가 엉망이고 제멋대로의 변수명에 루프나 메소드의 범위조차 알아보기 힘들게 중괄호를 던져놓은(내팽겨쳐 놓은) 코드들은 그 코드가 아무리 위대한(?) 내용을 담고 있어도 나에겐 그저 '보기싫은 코드' 중에 하나일 뿐이다.

  젠장, 아무리 대단한 내용물이 있어도 알아먹을 수 있어야 쳐다보지.. 코드를 읽느라고 스트레스 받아가며 끙끙대며 시간을 투자할 바에는 대단한 내용물을 포기해 버리는게 낫다. 사실 들여쓰기 엉망에 변수명 엉망인 코드들은 대단한 내용을 갖고 있을 확률은 희박하다^^ㅋ

  코딩스타일에 대해서는 블로그를 통해서 몇 번인가 썼던적이 있다. 내가 적었던 글 중에 이런 내용도 있었다.


  가끔 생각하는 것인데, 정말 누군가를 저주해서 제거해 버리고 싶을 때 이런 방법이 있을 수 있다. 주석하나 없고 이해하기 힘든 변수명이 나열되어있는 긴 소스코드에 추가적으로 어떠한 기능을 더 넣고싶다라는 요구사항과 함께 제거해버리고 싶은 사람에게 넘겨준다. 물론 소스에 대한 어떠한 설명을 해 주어서도 안되며 기왕이면 들여쓰기를 엉망으로 해서 만들어 준다면 효과는 배 이상이 된다. 중간중간 철자가 틀리거나 세미콜론(;)을 빼 두어서 에러를 유발해도 좋다.

    class aA{
      int bb;
    flat AA
    for(S = DD; S > bb; S++){   ...
      ...
             }
         tackle(h);}



  대략 이런 형태이면 매우 만족!! 얼마 지나지 않아 좋은 소식이 올것이다. 그는 이미 머리가 터져서 피를 쏟으며 쓰러져 있을 것이다.


-초급개발자가 본 어의없는 프로젝트 진행 - 싸인펜


  당시에 위의 내용을 쓰면서 농담처럼 다른사람을 제거하는 방법이라 적었었는데, 실제로 제거될 수 있다는 사실을 꼭 명심하자. 제거되지 않았더라도 상대방은 엉망의 코드를 보면서 몇 번이고 자살충동을 느꼈을 것이라는 것만은 알자.


  당신이 들여쓰기, 변수명, 기타등등 모두가 엉망인 코드를 인수인계 받아서 그 코드를 관리하고 유지보수 하는 업무를 맡게 되었다고 생각해보라. 당장이라도 회사를 때려치우고 싶은 심정일꺼다. 이해를 최대한 쉽게 만들어 놓은 코드도 이해하려면 어려운 법인데, 엉망인 코드를 건네 주는것은 그냥 그것을 보지 말라는 소리다. 알아보기 힘들게 만들어진 코드들 에러 잡아내고 내용 이해하고 하시는 분들은 정말 존경한다.


  나 자신도 초보자이면서 이런소리 함부로 하면 건방지게 들릴지는 몰라도 들여쓰기 안되어있고 변수명 내키는대로 쓴 코드를 작성하는 사람은 '정말 완젼 초보자'이다. 한글로 따지면 띄어쓰기 안하고 딱딱 붙여서 장문을 쓴다는 소린데 한글을 제대로 배운 사람이라면 그렇게 할까. 정말 '정말 완젼 한글의 초보자'인 한글을 배우는 외국인들이나 할 수 있는 일이다. 프로그래밍 언어도 똑 같다. 언어 제대로 배운 사람이 들여쓰기 안할까. 들여쓰기 변수명 제대로 안하는 사람은 정말 초보자다. 코드만 딱 보면 그냥 안다.


  코드를 작성할 때 본인을 위해서 작성하지 말고, 다른 사람에게 보여주는 코드라 생각하고 작성하자. 나 편한대로 하지 말고 다른 사람을 위해서 작성하자. 결국 다른사람과 동시에 본인을 위한 길이기도 하다. 코드 엉망으로 작성해놓고 에러 안잡힌다고 울고불고 해 봤자 도와줄 수 있는 사람 아무도 없다. 다른 사람이 그 코드를 봤을 때 알아먹을 수 있어야 도움을 주지...

  다른 사람에게 코드를 보여줄 때 초보티 내고싶지 않고 '코드 잘 짰다', '가독성이 좋다', '코드가 눈에 편한데?' 정도의 평가를 듣고 싶다면 예전에 내가 썼던 '코딩스타일' 이라는 글을 참고하길 바란다. 딱 요정도만 지켜줘도 코드갖고 욕먹는 일은 없을 것이다.

  내가 접한 '보기싫은 코드'는 사람의 스타일 처럼 사람마다의 개성 때문이 절대 아니었다. 개성을 떠나서 기본적으로 지켜줘야 할 것들을 지켜주지 않았던 코드들이 내가 겪었던 '보기싫은 코드'의 전형적인 모습들이었으니까. 혼자서 작성하는 코드이기에 코딩컨벤션같은게 없더라도 그것과의 별개인 기본을 말하는 겁니다.S


UPDATE 2008.1.20

제가 잘못 알고 있었던 코딩 스타일에 대한 내용이 자세하게 정리되어 있는 링크를 추가합니다. GNU스타일로 알고 있었던 코딩스타일은 Allman방식이었고 썬 스타일의 정확한 명칭은 K&R방식이었군요.


top
     TAG 가독성, 코딩, 프로그래밍
트랙백 1 : 댓글 10

트랙백 주소 :: http://signpen.net/blog/trackback/2510804

  1. 트랙백 발송지 : 최익필의 이름없는 블로그 2008/09/07 15:45 삭제

    제목 : 항목 47 : 쓰기 전용(write-only) 코드는 만들지 말자.

    내가 STL에 조예가 깊어서 글을 남기는 것이 아니라, Effecitve STL 을 공부하는 사람들이 이 글을 보고, 도움이 되었으면 하는 생각과, 혹시 내가 틀린것이 있다면 지적해 주시지 않을까 란 생각으로 글을 올리는것임을 미리 밝힙니다. - 최익필 처음 나는 쓰기전용 코드라 하길래, 무슨 말인고 했더니, 코드를 쓰기가 편한데로 쓴 코드를 쓰기 전용(write-only) 코드라고 한다. 즉 이런 코드... vector<int> v; int x,..
◀ 이전 : [1] : [2] : [3] : [4] : [5] : ... [8] : 이후 ▶