최근 레거시 코드 활용 전략이라는 책을 읽고 있다.

업계에서 흔히 레거시 코드라 불리는 코드를 많이 만져보게 되죠. 굳이 라이브팀이 아니더라도, 자주 만나게 된다.

제 주변에서도 흔히 사용하는 용어로써의 레거시 코드는 복잡한 코드, 결합도 높은 코드, 제약이 많은 코드, 너무 메소드 등을 통칭하는 용도로 쓰인다

 

대략 외국에서도 낡은 코드, 유효하지 않게 코드 등을 지칭할 때도 쓰는 보면, 레거시 코드의 개념이 부정적인 것은 확실한 가보다.

 

저도 그렇게 좋지 않은 코드에 대한 통칭으로 레거시 코드라는 용어를 사용해오던 찰나에 레거시 코드 활용 전략 (Working Effectively with LEGACY CODE) 라는 책을 읽게 되었다.

 

책에서의 레거시 코드에 대한 정의는 저에게 공감이 했다.

 

"내게 있어서 레거시 코드는 테스트 루틴이 없는 단순한 코드일 뿐으로, 난 그 정의에 대해 유감을 가져왔다.

코드가 얼마나 훌륭하게 작성되어 있는지 여부와는 상관없이 테스트 루틴이 없는 코드는 불량 코드다.

얼마나 멋지게 작성되어 있는가와 객체지향의 사용 여부, 그리고 캡슐화의 정도도 참작 요소가 전혀 되지 못한다. 테스트 루틴이 있으면 코드의 동작을 빠르고 검증 가능하게 변경시킬 수 있다. 하지만 테스트 루틴이 없으면 실제로 우리 코드가 더 나아지는지 더 나빠지는지를 알 수 없게 된다."

 

사실 좋은 코드의 기준은 너무 다양하다.

 

다른 사람이 작성해둔 코드 베이스 위에 작업해야 되는 경우, 선택지는 좁아진다.

내가 원치 않는 결합도, 내가 원치 않는 클래스 구조, 내가 원치 않는 기준으로 코드가 작성되어져 있고, 룰을 깨지 않는 선에서 작업해야 하는 경우가 많기 때문이다.

 

코드의 디테일을 보는 기준이 사람마다 다른 것도, 좋은 코드가 무엇인지의 논지를 흐리게 된다.

 

누군가는 속도, 누군가는 메모리 사용량, 누군가는 코드의 가독성 (나열한 중에 가장 주관적인 지표이기도 ) 지표로 삼기 때문이다.

 

이러한 주관적 여지가 있는 기준이 아닌, 명확한 기준인 테스트 루틴이 포함된 코드냐는 우리가 지향할 목표를 명확히 해준다.

 

결국엔 유닛 테스트를 강조하고, 기존 작성된 코드에 유닛 테스트를 붙이자는 이야기에 귀결된다.


그러기 위한 테크닉에는 여러가지가 있고, 결합도 낮추기 같은 것은 경험과 언어에 대한 능숙도에 귀결되기도 한다.

 

결합도란 다양한 언어의 특성과 표현력에 따라 맺어지기 때문이다.

 


실례로, 루비의 경우는 결합도 높게 작성해야 되는 프로그램에는 그리 적합치 않은데, 다행히도 그렇게 억지로 짜려고해도 쉽지 않다.

 

반대로 C++ 경우 적절하게 ( 말이 굉장히 모호한 말임을 인정한다) 쪼개져 있지 않은 경우, 슈퍼 메소드나, 슈퍼 클래스, 또는 클래스간 관계에 따른 지나치게 높은 결합도를 보여주곤 하니 말이다.

 

특히나 코드 작성자의 의도를 강조하기 위해 클래스간 결합도를 일부러 높은 코드도 수두룩하게 보아왔다.

 

그런 코드에 결합도를 낮추는 일은 쉬운 일이 아니다.

 

그렇기에 이런 책이 나온게 아닌가 싶다.

 

Test Driven Refactoring 알리기 위해서 말이다.


Posted by 엘키 엘키

댓글을 달아 주세요


제가 여러번 극찬한 임백준씨의 번역서입니다.


얼마나 좋았으면 직접 번역을 하셨을까 궁금하더군요.


이전에 번역하신 해커와 화가도 두고 두고 읽을만큼 색다른 시각이 좋았던지라, 이 책에 대한 기대도 그만큼 컸다고 볼 수 있습니다.



대략 책 제목에서도 알 수 있듯이, 어떠한 코드가 읽기 좋은 코드인지에 대한 기준을 제시하는 책입니다.



한빛 미디어 사이트 목차에서 발췌하자면, 담고 있는 내용은 아래와 같습니다.


1장. 코드는 이해하기 쉬워야 한다
   01. 무엇이 코드를 '더 좋게' 만드는가?  
   02. 가독성의 기본 정리  
   03. 분량이 적으면 항상 더 좋은가?  
   04. 이해를 위한 시간은 다른 목표와 충돌하는가?  
   05. 어려운 부분  

PART I. 표면적 수준에서의 개선

2장. 이름에 정보 담기
   01. 특정한 단어 고르기  
   02. tmp나 retval 같은 보편적인 이름 피하기  
   03. 추상적인 이름보다 구체적인 이름을 선호하라  
   04. 추가적인 정보를 이름에 추가하기  
   05. 이름은 얼마나 길어야 하는가?  
   06. 이름 포메팅으로 의미를 전달하라  
   요약  

3장. 오해할 수 없는 이름들
   01. 예: Filter()  
   02. 예: Clip(text, length)  
   03. 경계를 포함하는 한계값을 다룰 때는 min과 max를 사용하라  
   04. 경계를 포함하는 범위에는 first와 last를 사용하라  
   05. 경계를 포함하고/배제하는 범위에는 begin과 end를 사용하라  
   06. 불리언 변수에 이름 붙이기  
   07. 사용자의 기대에 부응하기  
   08. 예: 이름을 짓기 위해서 복수의 후보를 평가하기  
   요약  

4장. 미학
   01. 미학이 무슨 상관인가?  
   02. 일관성과 간결성을 위해서 줄 바꿈을 재정렬하기  
   03. 메소드를 활용하여 불규칙성을 정리하라  
   04. 도움이 된다면 코드의 열을 맞춰라  
   05. 의미 있는 순서를 선택하고 일관성 있게 사용하라  
   06. 선언문을 블록으로 구성하라  
   07. 코드를 '문단'으로 쪼개라  
   08. 개인적인 스타일 대 일관성  
   요약  	
	
5장. 주석에 담아야 하는 대상
   01. 설명하지 말아야 하는 것  
   02. 생각을 기록하라  
   03. 코드를 읽는 사람의 입장이 되어라  
   04. 마지막 고찰 - 글 쓰는 두려움을 떨쳐내라  
   요약  
	
6장 명확하고 간결한 주석 달기
   01. 주석을 간결하게 하라  
   02. 모호한 대명사는 피하라  
   03. 엉터리 문장을 다듬어라  
   04. 함수의 동작을 명확하게 설명하라  
   05. 코너케이스를 설명해주는 입/출력 예를 사용하라  
   06. 코드의 의도를 명시하라  
   07. 이름을 가진 함수 파라미터 주석  
   08. 정보 축약형 단어를 사용하라  
   요약  
	
PART II. 루프와 논리를 단순화하기

7장. 읽기 쉽게 흐름제어 만들기
   01. 조건문에서 인수의 순서  
   02. if/else 블록의 순서  
   03. (삼항 연산자로 알려진)?:를 이용하는 조건문 표현  
   04. do/while 루프를 피하라  
   05. 함수 중간에서 반환하기  
   06. 악명 높은 goto  
   07. 중첩을 최소화하기  
   08. 실행 흐름을 따라올 수 있는가?  
   요약  
	
8장. 거대한 표현을 잘게 쪼개기
   01. 설명 변수  
   02. 요약 변수  
   03. 드모르간의 법칙 사용하기  
   04. 쇼트 서킷 논리 오용하기  
   05. 예: 복잡한 논리와 씨름하기  
   06. 거대한 구문 나누기  
   07. 표현을 단순화하는 다른 창의적인 방법들  
   요약  
	
9장. 변수와 가독성
   01. 변수 제거하기  
   02. 변수의 범위를 좁혀라  
   03. 값을 한 번만 할당하는 변수를 선호하라  
   04. 마지막 예  
   요약  
	
PART III. 코드 재작성하기

10장. 상관없는 하위문제 추출하기
   01. 소개를 위한 예: findClosestLocation()  
   02. 순수한 유틸리티 코드  
   03. 일반적인 목적의 코드  
   04. 일반적인 목적을 가진 코드를 많이 만들어라  
   05. 특정한 프로젝트를 위한 기능  
   06. 기존의 인터페이스를 단순화하기  
   07. 자신의 필요에 맞춰서 인터페이스의 형태를 바꾸기  
   08. 지나치게 추출하기  
   요약  
	
11장. 한 번에 하나씩
   01. 작업은 작을 수 있다  
   02. 객체에서 값 추출하기  
   03. 더 큰 예제  
   요약  
	
12장. 생각을 코드로 만들기
   01. 논리를 명확하게 설명하기  
   02. 라이브러리를 알면 도움이 된다  
   03. 논리를 쉬운 말로 표현하는 방법을 더 큰 문제에 적용하기  
   요약  
	
13장. 코드 분량 줄이기
   01. 그 기능을 구현하려고 애쓰지 마라 - 그럴 필요가 없다  
   02. 요구사항에 질문을 던지고 질문을 잘게 나누어 분석하라  
   03. 코드베이스를 작게 유지하기  
   04. 자기 주변에 있는 라이브러리에 친숙해져라  
   05. 예: 코딩 대신 유닉스 도구를 활용하기  
   요약  

PART IV. 선택된 주제들
	
   14장. 테스트와 가독성
   01. 읽거나 유지보수하기 쉽게 테스트를 만들어라  
   02. 이 테스트는 어떤 점이 잘못되었을까?  
   03. 이 테스트를 더 읽기 쉽게 만들기  
   04. 읽기 편한 메시지 만들기  
   05. 좋은 테스트 입력값의 선택  
   06. 테스트 함수에 이름 붙이기  
   07. 이 테스트 코드는 무엇이 잘못되었는가?  
   08. 테스트에 친숙한 개발  
   09. 지나친 테스트  
   요약  
	
15장. '분/시간 카운터'를 설계하고 구현하기
   01. 문제  
   02. 클래스 인터페이스 정의하기  
   03. 시도1: 순진한 해결책  
   04. 시도2: 컨베이어 벨트 설계  
   05. 시도3: 시간-바구니 설계  
   06. 3가지 해결책 비교하기  
   요약  
	
Appendix 추가적인 도서목록
   01. 높은 수준의 코드를 쓰는 방법을 다루는 책들  
   02. 다양한 프로그래밍 주제에 대한 책들  
   03. 역사적 사례를 담고 있는 책들  
   찾아보기



이 중 가장 유용했던 내용이라면 주석에 대한 내용입니다.

Doxygen을 쓰다보니 강제당한 주석이 너무 당연한 내용을 너무 많이 담고 있었습니다.


물론 제가 Doxygen 규격을 따라가다 느낀 장점은, 당연한 내용을 작성하던 중에 다시 한번 생각하게 된다라는 점이었는데요, 그런 점을 제외하고는 사실 커다란 이득을 보기 어려웠던게 사실입니다.


특히나 최초 작성시에는 그렇다쳐도, 추후 유지보수에는 더더욱이 큰 메리트는 없다고 볼 수 있었습니다.


그렇다고 주석이 필요 없는 코드가 좋다고 항변하기엔, 그런 코드만 작성할 수 있는 것도 아니고 말이죠.



생각을 기록하라라는 이야기도 꽤나 크게 와닿았습니다.


또, 결함을 설명하라는 이 책에 대한 만족도를 크게 높여줬다고 볼 수 있었죠.


TODO: 아직 하지 않은일

FIXME: 오작동을 일으킨다고 알려진코드

HACK: 아름답지 않은 해결책

XXX: 위험! 여기에 큰 문제가 있다.

TextMate:ESC (이게 뭔뜻인지 아시는분?)



조금 아쉬웠던 것은, 저도 반대하면서도 장점과 단점을 명확히 제시하고 싶었던 goto에대한 설명이 아주 짧게 쓰여있다는 점이었습니다만...뭐 그분들도 제대로 설명하기 어려웠던 걸려나요?



아참! 제가 요새 절실히 깨닳고 있는, 코드 분량줄이기 챕터도 아주 좋습니다.


일주일에 코드 몇만줄 짜냐느니 등으로 일을 열심히했다는 바로미터로 삼는 한심한 일도 비일비재하지만, 대다수의 능력있는 프로그래머들은 적은양의 코드를 작성하면서 원하는 목표를 달성하는 일이 얼마나 가치있는지 잘 아실테니까요.



책 페이지 수도 많지 않고 (부록 제외 240여 페이지), 내용들도 쉽게 쉽게 읽히는 편인지라, C++ 코딩의 정석 만큼이나 추천드리고 싶은 책입니다.


물론, C++ 코딩의 정석은 실수 사례도 모은 느낌이고, 이 책은 코드 작성 + 코드 읽기 관점이지만 말이지요.


팀 내 가이드로 삼아도 될만큼 좋은 책입니다. 추천!

Posted by 엘키 엘키

댓글을 달아 주세요



조엘은 좋은 글을 쓰는 것만이 아니라, 좋은 글을 보는 눈도 역시나 탁월합니다.


조엘의 글은 IT 분야 글 읽는거 같지 않게 재밌게 잘 읽히는 경향이 있는데요, 조엘이 고른 블로그 베스트 29선 글들도 그런 글이 많습니다.


특히나 29. 여우캐릭터와 함께하는 빠르고 쉬운 루비 강좌는 꼭 읽어보시길 권합니다.


저도 이 책을 읽은게 2006년인데, 올해 되서야 제대로 루비를 쓰고 있는 정도지만, 루비에 대한 호감도를 올리고 쉽게 접근하기엔 아주 적절한 글이거든요.



경제학을 반드시 가볍게라도 익혀야 한다는 조엘씨의 지론답게, 간격 좁히기는 고객과 제품간의 이야기를 다룹니다.


제가 몇년전 그토록 많이 고뇌했던 좋은 프로그래머란 무엇인가는, 사실 좋은 제품을 만들어 고객에게 만족을 주는 소프트웨어를 만드는 것도 포함되는 의미입니다.


물론 이 챕터에서 말하고 있진 않지만, 같이 일하는 팀원들과의 관계와의 밸런스도 당연히 중요한 요인임은 물론입니다.




20. 래리 소프트웨어 공학의 법칙 제2조: 테스터를 단순한 잣대로 평가하지 마십시오. 는 좋은 테스터와 프로그래머와의 상관관계에 대해서 아주 적나라하게 설명해준 챕터였습니다.


테스터와 버그 추적 시스템은 결코 찾아낸 버그의 갯수와, 버그의 레벨을 평가해선 안된다는 점을 논리적으로 잘 설명해준 글이라고 볼 수 있습니다.



사실 여러모로 크게 와닿았던 챕터는 바로 21. 팀 보상제도 인데요, 팀웍을 해치는 보상 시스템을 채용하고 있는 것이 사실입니다.


"아니 내가 저사람보다 못한게 뭐야?" 라는 얘기나, "저 사람은 평가자와 친해서 더 좋은 평가를 받은건가?" 같은 수위의 갈등까지는 아니더라도, 팀 내부 갈등의 주범이 되곤 하는 것이 바로 팀 보상 제도 내지는, 팀 평가제도라 볼 수 있는 것이지요.


팀 끼리 팀웍을 최대한 발휘해도, 좋은 제품을 만들까 말까인데 과연 이런 평가 시스템이 좋은 팀을 만드는 데에 긍정적일까요? 전 아니라고 봅니다.

언제나 저보다 뛰어난 팀원들과 같이 일하고 싶었던 저로썬, 이런 상대평가를 받게된다는걸 알고나니  제가 가진 생각을 유지하는 것이 썩 달갑지 않아졌습니다.

팀보다 개인을 생각하게 되더군요.


이러한 부분들을 잘 설명한 장애요인은 다음과 같습니다.

1. 경쟁

2. 불공평에 대한 인식

3. 불가능에 대한 인식

4. 부분 최적화

5. 고유 동기 말살


대부분의 팀이 의욕 고취를 위해 취하는 보상제도가 이런 문제들을 낳고 있다니... 아이러니하죠?

이런 폐해를 막기 위해 이 글에서 제시한 가이드 라인은 다음 다섯 가지입니다.


1. 승진 제도에 논쟁의 여지가 없게 하라.

2. 성과급 제도의 의존도를 낮추라.

3. 이익 분배와 경제 활동의 원동력을 연계 시켜라.

4. 책임 범위가 아니라 영향 범위에 의한 보상제도를 확립 하라.

5. 돈, 그 이상의 동기를 찾아내라.


예. 모두 그리 쉽지 않은 이야기입니다. 하지만, 이정도 노력없이 성과를 내고 있는 좋은팀을 지속적으로 유지 할 수 있을까요?


이렇듯, 조엘씨의 조엘 온 소프트웨어나, 조엘이 엄선한 소프트웨어 블로그 29선처럼 외국 개발자들도 우리네와 별반 다르지 않습니다. 그들도 어떠한 상황에 대해서 느끼는 감정이나, 고뇌는 비슷한거 같더군요.



이외에도 엄선된 글들이 전반적으로 다 좋은 내용을 담고 있습니다.

요즘들어 기술서적보다, 이런 내용의 글들이 읽고 싶어지던 시기에 다시금 꺼내봤는데 역시나 좋습니다.추천해요!

Posted by 엘키 엘키

댓글을 달아 주세요



조엘 온 소프트웨어 (http://elky.tistory.com/52를 너무나도 재밌게 읽고, 2010년초에 사서 읽었지만 이제서야 서평을 남기게 되네요.


서평을 올리지만 않았다뿐, 요즘도 책은 나름 꾸준히 읽고 있었습니다.


롤하다 닷지하고 주로 읽었....쿨럭!



여하튼, MS에서 프로그램 매니저로 일했고, 포그 크릭을 운영중인 그의 시야는 여전히 놀라웠습니다.

유독 와닿는 몇가지 컬럼이 있었는데요, 


자바만 가르치는 위험한 대학과, 예일 대학 강연, 틀린 코드를 틀리게 보이도록 만들기가 바로 그것이었습니다.,



8. 자바만 가르치는 위험한 대학

우리나라 커리큘럼도 이렇게 변해가고 있다는 사실이 저는 매우 걱정됩니다.

자바가 좋은 언어냐 아니냐는 논점을 흐리기 때문에 배제한다고 봤을 때, 조엘씨가 얘기하신 "자바는 뛰어난 프로그래머와 고만고만한 프로그래머를 구별할 만큼 어려운 언어가 아니란 점이 문제라고 얘기하신 점에 공감합니다.

저는 분명히 C언어를 고르지 않았다면 자료구조를 직접 만들어내지 못했을 겁니다.


"이봐, 자바를 쓴다면, 자료구조를 직접 만들어낼 필요가 없다구"

라고 얘기하신다 해도, 저는 포인터와 재귀를 이해하지 못한다면, 이해 못할 분야가 너무나 많아 진다고 생각합니다.


프로그래밍을 중도 포기하는 사람이 너무 많아서 모두를 하향 평준화하려는건 아닐까요?

분명, C와 자바를 동시에 가르치던 시기에 프로그래밍을 포기하는 비율이 높았다는 것은 알고 있습니다.

그렇다고해서, 더 많은 것을 이해할 수 있는 기본이 될 C언어를 학교에서 가르치지 않는다면 어디에서 배우게 될까요?


모두가 자바에서 제공되는 것 이상은 무엇도 할 수 없는 현실이 되는 것은 누구도 원치 않을텐데 말이죠.



9. 예일 대학 강연

MS에서 일하셨던 분 답게, 윈도우에 대한 이야기를 꽤나 많이 하시는 편입니다.


The Art of unix Programming에 나올 법한 내용들과, 윈도우 개발 282 스토리에 나올법한 내용들을 많이 얘기하시는 편인데요,


역시나 윈도우의 개발 문화에 대한 단점 지적 부분은 들을 떄마다 큰 공감이 됩니다.


C언어를 배우며 모두가 거치는 코스인 CLI 프로그램에서, GUI 기반 프로그래밍을 접하고 난 뒤 겪는 혼돈, 그리고  그 문화가 낳은 재앙(?)들에 대해서 말이죠.

저도 아주 여실히 깨닳고 있습니다. 명령행 프로그램 (CLI)위에 GUI를 얹는 구조가 아닌, GUI 기반 프로그래밍이라니요...


이렇게 배워온 많은 것들이, 코드 재사용, 기능 재사용등을 막는 제약이 되고 있다는 사실이 안타깝습니다.

게다가, Run and fix나, 조작 순서가 조금만 달라져도 돌지 않는 프로그램 따위를 양산했기 떄문입니다.


물론 좋은 프로그래머인 여러분들은 그렇지 않으실거란건 알고 있습니다.


또 자동화된 테스트만으로 좋은 사용성과 버그를 모두 제거할 수 없다는 사실에 대한 얘기도 흥미롭습니다.
품질은 단순히 기술에 치우치지 않는다라... 저도 동의합니다. 이 의견에 동의하면서도 건망증이라도 걸린건지,  종종, 아니 꽤나 자주 품질=기술이란 의미로서 생각하곤 하지만 말이죠.


몇몇 분들이 울컥하실수도 있는 일이지만, 사내 소프트웨어 개발자가 되면 안되는 이유에 대해서도 공감합니다.

기업의 주력 업무에 일하지 못한다면 좋은 대우를 받기 어렵기 떄문이지요.



23. 틀린 코드를 틀리게 보이기


이건 그냥 조엘씨 의견 거의 그대로 붙여 쓰겠습니다.


일반 규칙 

* 함수를 짧게 유지하라

* 변수는 쓰기 직전에 정의하라.

* 매크로를 남발하여 자기만 아는 프로그래밍 언어를 만들지 마라.

* goto를 쓰지 마라.

* 중괄호로 묶이는 블록은 한 화면에 다 보이게 하라.


아무래도 C언어를 예로 든 만큼, 크게 와닿는군요.

매크로...음 국지적 사용만 하는데도 곤욕을 겪을때가 많아 공감합니다.


앱스 헝가리안과 시스템 헝가리안

잘못 퍼진 헝가리안 표기법에 대한 오해를 풀어주고 계십니다.

요새 자주 보게 되는 코드가 boost나, linux쪽 코드라 그런지 헝가리안 표기법이 별로 없는데,
일정 부분 헝가리안 표기법을 축소해서 사용하고 있는 중인지라, 잘못알고 있던 헝가리안 표기법에 대한 이해를 도와준 점이 좋더군요.


예외 때려부수기

예외가 정확히 프로그램이 원하는 동작을 보장할 거라는 확신을 갖기 어렵게 만든다는 이야기군요.

물론 저는 MS에서 일해본적은 없지만, 진입점마다 예외 처리 구문을 넣고 단순 실수를 잡는 식으로 커버리지를 높이는 방법으로 사용하고 있고,

return값 만으로 알리기 어려운 상황에서 코드의 흐름을 멈추는 용도로 쓰고 있다보니, 조엘씨가 얘기하시는 예외처리가 갖게되는 문제에 대해서 100% 공감할 순 없었습니다.


조각 코드만으로 이 코드가 완전 무결할 것이라는 확신을 갖기 어렵다는 점에서는 공감합니다.




이외에도 책에 실린 내용 하나하나가 내공과 통찰에서 뿜어 나오는 좋은 교훈이나, 때론 논쟁거리가 많습니다.

현재 운영중이신 포그 크릭이 얼마나 좋은 회사인지, 그리고 좋은 프로그램 회사의 오너가 왜 프로그래머여야 하는지 등 여러가지를 느낄 수 있게 해주는 분이라고 생각합니다.


전반적으로 언어의 제약이 없이, 좋은 내용이 가득합니다.

꼭 읽어보세요. 가능하다면, More Joel no Software보다, Joel on software 부터요.

Posted by 엘키 엘키

댓글을 달아 주세요



사실 이 책은 네트워크 관련 공부에 관심을 가지다가, 해킹 방법에 대해 조금 알아야 겠다는 생각으로 접한 책이었습니다. 


그렇지만 이 책은 그 보다 큰 교훈을 주었습니다.

바로 근본 기술에 대한 이야기인데, 프로그래머들이 자주 겪는 딜레마는 내가 배운 기술이 한순간에 쓸모없어 지는것이 아닐까 내가 신기술에 적응 못하게 되는게 아닐까 하는 부분이 많습니다.

저자는 이 부분에 대해서 근본 기술에 대한 이야기를 함으로써, 그 근본으로 돌아가면 신 기술이 나온다하여도 금방 적응할수 있고, 그 원리를 이해 하는것이 IT에서의 해결책이라고 주장했습니다.

그 주장에 전적으로 동의하며, 그가 가르쳐준 PE포맷, API후킹, 메모리 다루기 등 모두 즐겁게 보았죠.

애초에 이 책을 접한 시기가 학생이었던 때이다보니 더더욱 좋게 와닿았단 책입니다. 리버싱을 살짝 다루긴했지만 조금 라이트하게 다루고 있습니다.

하지만 흥미를 불러 일으킬만큼은 맛볼수 있으니, 이 책에서 다룬 여러 주제들로 인해 관심분야의 폭이 늘어나는 데에 큰 도움이 되었죠.

적은 페이지로 다양한 내용을 다루다보니, 디테일하게 접근하려면 다른 책들을 참고해야했지만 그거야 다른 책들도 마찬가지인경우가 많으니.. 게다가 애초에 포지션 자체가 다른거라고 생각하시면 될거 같습니다.

아주조금 아쉬었던건, CD에 담긴 소스 파일의 내용과, 책에 나와있는 소스 코드의 내용이 다르다는 것입니다. CD에 담긴 파일에 오류가 있기도하고...-_-;;

뭐 직접 고치면서 도움이 되긴했지만요~

리버싱/어셈/프로그래밍 기본 소양이 무엇인지에 대해 가볍게 접하고 싶으신 분들에게 추천합니다.


Posted by 엘키 엘키

댓글을 달아 주세요


해커이면서 동시에 미술적인 분야에 눈을떠 색다른 시각의 의견을 자주 내놓는다는 폴 그레이엄!


기대를 갖고 본 책이었습니다. 역자이신 임백준씨의 추천이 이 책을 고르게 되는데에 한몫했죠.

제가 조엘 온 소프트웨어를 읽으며 들었던 생각이 그가 주로 프로그래머로서의 시각으로 이야기 했다면, 폴 그레이엄은, 책 이름과는 달리 사람 그 자체에 대해 이야기를 한 부분도 많았습니다.

애초에 해커 (프로그래머나 코더를 일컷는 의미가 아닙니다)는 화가는 매우 유사하다고 말하는 그에게서 진정 프로그래밍을 즐기는 것이 무엇인지 느낄 수 있었습니다. (임백준씨에게서 느꼈던 것과 비슷한 감정이었지요. 그래서 임백준씨가 극찬하며 추천하신게 아닌가 싶습니다)

발상 자체가 워낙 폭이 크다보니, 범인인 저로썬 '오 이렇게도 생각할 수 있겠구나 하고 감탄하면서 보게 됐습니다.

다만 워낙 오해의 소지가 많은 내용이 많다보니 자칫 잘못하면 심기가 불편해질 수 있는 주제가 많았습니다.

허나 그가 뛰어난 프로그래머이며, 통찰력 있고, 좋은 결론을 도출해내는 사람이다 라는 점에 있어선 이견을 제시할 수 없었습니다.

이 책은 그저 평범한 자기 자랑이나 하는 그런책이 아닙니다.

해커 (크래커 아닌건 아시죠?) 가 되고자 하시는 분이라면, 프로그래머로써 여러가지 종류의 회의에 빠지신 분들이라면 꼭 한번 읽어보시길 권하고 싶습니다.


Posted by 엘키 엘키

댓글을 달아 주세요



이 책의 이름을 듣자마자 들었던 생각은 레이몬드 첸이 누구길래 윈도우 개발 스토리를 썼을까 하는 궁금증이었습니다.

읽다보니 알게된 것이었지만, 오랜 기간 동안 윈도우를 개발한 분 답게 윈도우에 대한 다양한 일화를 들으셨고, 경험 하셨더군요.

레이몬드 첸씨는 윈도우가 지금의 모습을 갖추게 된 이유에 대해 대부분 납득할만한 이유를 내놓고 있습니다.

윈도우는 대부분 사용자 편의에 큰 가치를 두고 있고, 그 대표적인 방침중 하나가 하위 호환이라 할 수 있죠.

하위 호환을 위해 유지해야 했던 문제 되는 함수들, 잘못된 사용법으로 인해 윈도우가 망가졌던 일, 그런 사용에도 망가지지 않기 위해 했던 예외처리 등 윈도우의 파란만장한 주옥같은 일화들이 많이 있었습니다.

아마 제가 그 상황이라면 저 역시 그런 선택을 할 수 밖에 없었을 거라는 생각이 드는 부분들이 많았기에 더더욱 와 닿은거 같습니다.

사실 게임 개발을 하다보면, 기획자나 그래픽 디자이너가 힘든 방법이지만, 내가 편하거나, 코드 상으로 간결한 해결책을 가져다 주는 방법을 선택하고 싶은 욕심이 생길때가 있고, 실제 그런 선택을 할 때가 있습니다.

어찌보면 프로그래머로써 우선시 여기는 유지보수 쉬운 코드, 퍼포먼스 좋은 코드 같은 가치 보다, 중요한 가치가 팀웍이 될 수도, 다른 동료들에 대한 배려가 될 수도 있는것이라는 생각이 들기도 했습니다.

물론 이 책을 다 읽고 난 지금도 여전히 저에게 우선 되는 가치는 유지보수 쉬운 코드나 퍼포먼스 좋은 코드이지만, 적어도 생각의 폭이 넓어졌고, 윈도우에 대한 이해도가 높아졌다는 점에서 좋았습니다.

이 책은 제가 전공서를 읽을때 조차 중요시 여기는 가치인 재미를 주는 책이었고, 최고의 번역까진 아니어도 준수한 번역으로 이해에 큰 지장은 없었습니다.

윈도우 프로그래머이고, 윈도우를 사용하는 사용자이기도 한 사람으로써 교양서 읽듯이 가벼운 마음으로 읽으셔도 되는 책이 아니었나 싶네요.


Posted by 엘키 엘키

댓글을 달아 주세요


요새 내 주변에는 모두가 입을 모아 한 기기를 찬양하는 상황이 펼쳐지고 있다.

바로 아이폰이다! 

아이팟 터치도 혁신적인 기기였지만, 아이폰은 그 이상이다. 3G망을 이용한 무선 네트웍 기능은 언제 어디서나 원하는 정보를 이라는 컨셉에 매우 잘 부합한다.


과연 이 것을 노린 것일까, 요행일까?

아마도 '그'라면 노렸을 지도 모른단 생각이 든다.

바로 '스티븐 잡스'다.


매킨토시를 만들어 낸 장본인으로, 새로운 것을 시도하고 실현 하는 것에 탁월한 재주가 있는 그의 '작품'들은 나오는 제품마다 큰 관심사가 되고 있다.

발매되자마자 매진 행렬을 보여주고 있는 아이패드가 그 반증이다.


개인적으로 스티븐 잡스와 관련된 서적은 '잡스처럼 일한다는 것' (http://elky.tistory.com/203) 을 읽었었다.

잡스가 얼만큼 뛰어난 인물이고 뛰어난 리더였는지를 조명한 책이었는데, 이번책은 그의 사업적인 측면에 좀 더 집중한 느낌이 강했다.

그의 사업적인 판단이 어긋났을 때도 꽤나 많기에, 결과론 적인 이야기들이 된 것이지만, 원래 세상이란 그런 것 아닌가?

내 개인적인 애플의 제품들에 대한 느낌은, 혁신보다도 '섬세함'이다.

아이폰 이전에도 무선 인터넷은 있었고, 모바일 어플리케이션 들도 있었다. 어플리케이션의 네트웍 기능도, 모바일 운영체제도, SDK도 있었다. 앱스토어? 이 것도 사실 새로운 것이라 보기엔 무리지 않을까? 아이튠즈도 마찬가지고.

아이폰/아이팟 터치의 성공 비결은 기존에 존재하던 것 들을 사용자 관점에서 바라보고, 이를 쉽게 접할 수 있고 활용 할 수 있게 도와주는 것에 집중했다. 그렇다보니 기존에 어렵고 복잡한 과정으로 인해 알아도 사용하지 못하던 기능들이, 또 아이디어들이 실현되고 있기에 아이폰과 아이팟 터치가 사용자들에게 사랑받은 것이다.

'사용자 중심'적인 잡스의 발상이야말로 분야를 막론하고 필요한 것이다. 사용자를 중심에 놓으면 어려워선 안되고 호기심을 자극해야 한다. 쉽게 접근하려면 섬세해야 한다. 섬세한 배려만이 사용자에게 편리함을 가져다 줄 수 있다.

우리가 놓치고 있는 2%. 우리는 너무 쉽게 보고 있는건 아닐까?


Posted by 엘키 엘키

댓글을 달아 주세요


블로그 이미지
Software Engineer
엘키

공지사항

Yesterday31
Today29
Total1,605,483

달력

 « |  » 2020.8
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

글 보관함