2012/07 7

[책정리]읽기 좋은 코드가 좋은 코드다

읽기 좋은 코드가 좋은 코드다저자더스틴 보즈웰 지음출판사한빛미디어 | 2012-04-06 출간카테고리컴퓨터/IT책소개이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리... ( 맨날 뭐 하려고 하면 거창하게 생각하고 거창하게 시작해서 아무것도 못하는 것 같아서... 스텝 바이 스텝으로 천천히 생각하기로 했다. 오늘부터 한 챕터씩 '읽기 좋은 코드가 좋은 코드다' 를 정리해보기로 했다. '소설처럼 읽히는 코드' - 이게 내 평소 지론이다. 이것을 도와주는 책으로는 국내 책중에는 현재까지는 Clean Code 가 최고였다만,,,, 이 책 역시 던져주는 메시지가 꽤 좋으므로... 정리. 목차는 다음과 같다. 1장. 코드는 이해하기 쉬워야 한다 01. 무엇이 코드를 '더 좋게' 만드는가? 02. 가..

개발의 즐거움 2012.07.14

mysql5.5 초기 설정(사용자추가)

사용자 추가 하다가... 기록. 이전 5.0 대 버전에서의 사용자 추가는 아래같은 설정으로 우분투에서 추가했었다. ( mysql server setting ) $ sudo apt-get install mysql-server mysql-client root 패스워드 : root 로 설정 sudo vi /etc/mysql/my.cnf#bind-address = 127.0.0.1 --> 로 처리 sudo /etc/init.d/mysql restart mysql -u root -p use mysql select host, user from user ; #사용자추가INSERT INTO user (Host, User, Password) VALUES ('%','root',password('root'));INSERT ..

computer driven communication (?)

일을 하면서 대화를 하다보면 최초에 이야기 한 것과 달라져서 당황해 하는 나를 발견할 때가 있다. 우리가 어떤 일을 처리하거나 서로간의 대화를 통해서 이야기를 풀어나가는 프로세스를 분석하고 싶어졌다. 나는 프로그래머다. 정확한 정보가 없으면 솔루션을 제시할 수도 해결의 단초를 생각하기도 힘들다.때로는 해결책을 겨우 생각해 내고 이야기를 진행해 가는데 진행하다보면 전혀 다른 문제여서 접근법을 달리 해야 한다는 생각이 들때 당황하면서 상대를 질책하게 된다. 그렇기 때문에 Garbage in garbage out 의 규칙에 생각조차도 얽매여 있는 것 같다는 생각이 든다. 반대로 컨설팅 및 멘토링의 프로세스는 무언가를 꺼내어 놓을 지 모르는 상대방을 탐구하고 상대방과 대화를 하면서 욕구를 끄집어 내는 것을 먼저..

개발의 즐거움 2012.07.10

엔터프라이즈 환경에서 아키텍처 팀의 역할

- 이 글 역시 바로 전 글과 같은 맥락에서 작성을 했는데.... 고민의 시간과 작성 시간이 아까워서 블로그에 남겨본다. 프로젝트를 해요?~~~프로젝트 사업을 만든다, 고객의 요구사항을 듣는다,제안서를 작성한다, 요구사항 분석서를 작성한다, 고객의 요구사항 중 비기능 요구사항을 식별한다, 비기능 요구사항에 따른 기술구조를 선택하고 솔루션을 선택한다, 아키텍처를 설계하고 검증을 위한 선도 개발을 한다 , 개발 표준을 제시하고 개발 표준의 준수여부를 체크한다. 위의 일련의 행위를 통해서 프로젝트가 만들어지고 진행되어집니다. 프로젝트가 진행되다 보면 팀간의 상호 인터페이스에서 부딪히는 역할 문제와 책임문제에서 자유로울 수 없습니다. 그런 역할 문제와 책임문제를 의사결정 해주고 승인해주는 것은 누구의 역할일까요..

아키텍트의 역할과 자질에 대한 고찰

- 1년쯤 전에 써본 아티클인데... 부끄러운 글이지만,,, 그리고 꽤 짜집기를 했지만, 이 짧을 글을 쓴다고 안돌아가는 머리 고생하고 고민을 꽤 한 시간이 아까워서 이렇게 블로그에 기록으로 남깁니다. 다시 읽어보니까,,,너무 나열식이다. ㅎㅎㅎㅎ. 왜 아키텍트일까? 흔히 IT 아키텍처를 말할 때 비교하는 건축 도메인과의 비교를 해 보면 고객의 요구사항을 받고 뼈대를 잡고 그 뼈대에 필요한 것들을 쌓아서 고객의 요구사항을 구현한다. 몇 천년 동안 지어진 건축물을 보면서 노하우가 쌓이고 시행착오를 극복해온 건축쪽 도메인과 달리 소프트웨어 분야는 역사도 짧을 뿐더러 아키텍처 자체가 기업의 자산과 보안이 되는 관계로 공유가 그다지 많지 않다. 그나마 인터넷의 발달과 오픈소스의 발전 그리고 블로그의 기술 포스팅..