뉴욕의 프로그래머

뉴욕의 프로그래머.. 그리고 노란색 표지가 눈에 띄는 책이 었다.

책은 한국인 프로그래머의 관점에서 주로 이야기가 전개 되었다.

내용은 한국인 프로그래머가 외국에서 일을 하면서 겪는 것을 중점으로 진행이 된다.

주변의 우수한 프로그래머에 대한 이야기, 최악의 프로그래머, 버그 잡는 일,

어떤 시스템에 대한 이야기.. 프로그래머가 읽기에 친숙한 내용들이 었다.

그리고 처음 보는 용어나 아! 이런 식으로 하는구나! 하는 등의 프로그래밍을 하는데 있어서 좋은 정보를 많이 제공해 주었다.

---

개발하는데 있어서 시스템의 설계나 패턴을 이용하는 것이 얼마나 중요한지에 대해 항상 강조하고 있는 분위기로 내용이 진행 되었다.

그리고 그로 인한 많은 문제들을 보여주었고, 특히 숲을 보지 않고, 나무만을 보고 있을 때 문제의 심각성에 대해 알려주었다.

아직은 학생의 신분 이여서 프로젝트라 해봤자 적당히 기능이 수행되고, 잘 뻦지 않는 정도로 짜면 되기 때문에 이런 것을 아직

몸소 체험을 해보지는 않았지만 현업에 가기전에 1년 정도 밖에 남지 않았지만, 그 기간 동안 이라도 특별한 기술도 중요하지만

숲을 보는 시야를 가져야 할 것 같다. 일단 프로젝트를 진행하기 전에 명세서, UML 을 꼭 한번 그려보고 꼼꼼히 살펴보는

습관이 중요한 것 같다. 특히 나는 항상 이런 이런 식으로 짜면 되겠지 하고, 종이에 끄적이긴 하지만 금방이다... 하지만

개발을 하다 중반정도 가게 되면 처음 생각했던 것 만큼이나 일이 더 생기게 되고 나중에 되면 내가 소스를 해깔릴 정도로

구조가 복잡해 지기 일수 였다. 그리고, 디자인 패턴, 리팩토링, 이펙티브 C++ 을 알아둬야 할 것 같다. 흠.. 다 중요하지만

일단은 이런 책들을 보면서 좀 더 시야를 넓혀 가고.. 기본적인 코딩 스타일 과 협업 하는 방법에 관련 된 책을 한번 찾아봐서

읽어 봐야 할 것 같다. 다른 팀들은 보니 변수 선언 법이나 등등 협업과 관련해서 문서를 남기고, 프로젝트를 하기 위한 공동의

공간을 두고, 서로의 일정을 항상 알고 토론하는 등 시스템이 잘 구축되어 진행이 되어 가는 것 같았다. 불행히 아직까지 나는

그런 경험을 제대로 못해 본 것 같아서 걱정이다. 항상 혼자 코딩하는 것을 편해 했기 때문이다... 큰 프로그램이 아니더라도

체계적으로 시스템을 구축해서 프로그래밍을 해보고 싶다. 그러기 이전에 내가 먼저 적극적으로 공부를 해야 될 것 같다.

공부도 공부지만 개발자 라면 자신의 의견을 굽힐 줄 알고, 남의 의견을 존중하는 것이 꼭 필요한 것 같다.

책에서도 나오지만 정말 남들이 전혀 알아 볼 수 없도록 스파게티 소스 를 짜놓거나 그리고 다른 사람이 이건 잘못 되었다고

했을 때도 무조건 고집만을 피우며 귀를 틀어 막는 개발자가 최악의 개발자 인 것 같다. 실력은 부족하지만 남의 의견을 존중하고,

그것으로 배운다면 큰 발전의 가능성을 가지고 있으며 배움의 자세를 갖추었다고 할 수 있지만, 자신의 편견에 사로 잡혀서 혼자

고집을 피우는 사람은 절대 발전을 할 수 없다. 이 세상에는 수많은 개발자가 존재 하고 그리고, 내 위에 수많은 뛰어난 개발자가 많이 있다.

아무리 자신이 미친듯이 해서 공부를 했다 하더라도, 선천적으로 머리가 좋아 남들 보다 훨씬 앞을 보고 개발을 하는 프로그래머들이

수두룩하다. 얼핏 보기에 나보다 못하는것 처럼 보이지만 나에게 없는 다른 장점이 있을 수도 있다. 항상 겸손하고, 배우는 자세를 가지고

프로그램을 해야 할 것 같다. 그리고 잘못 된 것을 꼬집어 주는 사람에게 항상 고마워하는 마음을 가져야 할 것이다. 책에 보면 한 남자가

회사에 가서 개발을 하는데 입사 한지 얼마 되지 않아 버그를 하나 수정하라는 명령이 떨어지고 그 개발자는 시스템을 제대로 이해하지

못해 걱정을 했지만, 버그를 보고 단순한 것으로 생각하고 전체 시스템의 흐름은 생각지도 않은체 그 버그 난 부분만을 생각하고,

금방 버그를 고치게 된다. 하지만 곧 그 실수는 시스템의 치명적인 버그로 남게 되고, 회사에 큰 손실을 가져다 준다. 그리고, 그 개발자는

자책을 하며 일을 그만두어 버린다. 주변의 프로그래머는 그를 보고 꾸짖기 보다는 많은 실망을 하게 된다. 어떤 뛰어난 프로그래머든

실수는 하기 마련이다. 어떤 천재라도 말이다. 그리고 사람이 만든 프로그램이기 때문에 어떤 프로그래머든 버그는 있기 마련이다.

Window조차 정말 수 많은 버그를 가지고 있지 않은가. 잘 생각해 보면 우리가 사용하는 프로그램들 중에 버그가 없는 프로그램이 없다.

메신저나 동영상 플레이어 등 갑자기 꺼진거나 전달이 안되거나 등 정말 많은 버그를 가지고 있다.

실수를 못견뎌하고 두려워 하는 사람은 실수로 부터 아무 것도 배우지 못하는 사람 만큼이나 성장 가능성이 없다.

나날이 성장하는 사람은 실수를 두려워 하지도 거부 하지도 않는다. 실수는 고통을 안겨주지만 성장하는 사람은 그것을

자신의 일부로 끌어안고 실수와 함께 나아간다

라고 책에서 언급하고 있다. 실패는 성공의 어머니라는 말도 있지 않은가.. 이 말을 항상 염두해 두고, 자신을 자책하지 말아야 할 것이다.

하지만 그렇다고 해서 버그를 너무 당연시 여기거나 나태해지면 안 될 것이다 항상 배우도록 해야 할 것이다.

마지막으로 이 책에서 가장 인상 깊었던 말이 있었다.

지난 37년 동안 나는 하루에 14시간씩 연습을 했다. 그러고 났더니 사람들은 나를 천재라고 부르더라.

라는 말이다. 그렇다.. 어떤 천재라도 노력하지 않는 천재가 없다는 것을.. 그리고 누구든 노력하면 천재처럼 될 수 있다는 것을..

항상 부단히 노력하는 사람이 되도록 해야겠다.

 

 

아래의 내용은 책을 읽으면서 찾아볼 만한 내용. 또는 괜찮은 내용

디자인 리뷰, 코드리뷰, 유닛테스트

 

GUI컴포넌트들에 대한 관찰자( observer )를 생성해서 맵(map)에 저장하는 부분을 포함하고 있었다.

 

기능 뿐만 아니라 성능이나 메모리 용량 같은 부분도 정확히 따져가면 프로그래밍을 해야 한다.

 

버그를 바라보는데 두종류의 사람이 있다.

첫번째는 시스템이 동작하는 방식을 정확하게 이해하고, 전체적인 측면을 사용자 입장에서 차분하게 바라보는 사람이 있는가 하면,

매우 근시안적인 시각을 가지고 눈앞에서 벌어지는 일에만 집착하는 사람이 있다.

 

패어 프로그래밍( pair programming )

 

코딩이 끝나는 시점은 소스코드의 변경이 끝나는 시점이 아니라 자신의 코드를 확인하기 위한 유닛테스트 코드의 작성이 끝나고,

요구사항이나 버그 리포트에 적힌 내용을 한 줄 씩 확인하면서 철저하게 기능적 테스트를 수행하고, 필요한 부분이 있으면 다시 한 번 수정하고,

최종적으로 코드 리뷰가 끝나는 시점을 의미한다.

 

감각적인 의미에서 성능을 향상 시킨다는 의미는 어떤 동작이 수행되고 결과가 돌아오는데 걸리는 시간은 같지만

마우스가 화살표 모양으로 바뀌고, 프로그레스 바가 움직이고, html코드가 받은데로 순차대로 뿌려주게 되면

사용자는 덜 지루함을 느끼게 된다. 만약, 결과가 나올때 까지 그저 흰 그림만을 계속 보고 있어야한다면

사용자는 손톱을 깨물며 그저 기다리기만 해야한다.

 

 

익스트림 프로그래밍 : 불필요한 절차의 과감한 생략을 통해서 프로그래머와 사용자 사이에서 빠르고 정확한

의사소통이 일어나도록 할 것을 강조하는 소프트웨어 프로젝트의 한 방법론. 보통 XP 라 부름.

 

 fail-fast : 한 쓰레드가 iterator를 이용해서 데이터를 읽어나가는 동안 다른 쓰레드에 의해서 구조 변경이 되는 상황이

        발생 이때 iterator는 concurrent exception 을 발생

 

IntelliJ IDE : 이클립스, 넷빈즈와 함께 자바 프로그래머들이 가장 많이 사용하는 통합개발환경의 하나.

www.jetbrains.com/idea/

 

getList와 같은 메쏘드를 작성 할 때는 참조가 아니라 복사본을 리턴 하는 것이 기본

그렇지 않으면 캡슐화가 전혀 지켜지지 않게 되고 직접 데이터의 변형이 가능하다.

 

명령어 패턴( command pattern )

 

자신의 일에 열정을 가지고 하고 겸손. 상대방의 말을 중간에 끊지 말고 충분히 말할 시간을 주고 상대의 생각을 다 듣고 자신의 의견을 밝힌다.

 

"프로그래밍 펄 " 책.. 해커와 화가들....

 

유닛테스트 unit test 프레임 워크

 

client -> server  10초마다 ping message를 전달

메세지를 받은 서버는 클라이언트의 세션 객체가 가지고 있는 시간(timestamp)값을 현재 시간으로 업데이트

한다음 client에게 응답을 보낸다.

server는 ping message 가 6번 이상 연속적으로 실패하면 네트워크가 다운되었다고 간주하여

client 는 자동 로그아웃.

 

버그가 발생하면 버그의 내용을 신중히 생각하여 판단하라. 지레 짐작으로 코드를 변경하지 마라.

 

 

이 글은 스프링노트에서 작성되었습니다.