JasonPA

프로그래머가 바라본「진보에 장애가 되는 습관」
주목받는 SW 개발방법론「비교 분석」
「논쟁에서 승리하는」개발자가 되려면?

우선 오래된 글인데, 위 세가지 글을 읽어보라고 나 자신에게 권하고 싶다. 어떤 기술에 대해서 관심을 가져야 하며, 어떤것이 도움이 될 것인가? 또 어떤 것을 개선해야하는 항목으로 선정해야 할 것이며, 또 어떤 것을 버리고 어떤 것을 도입해야 할것인가???

모든 질문은 최근 몇일간 나 자신에게 던져진 질문인데, 위 링크의 첫번째 글 " 진보에 장애가 되는 습관 " 이란 글을읽고 다시 생각하는 계기가 되었다. "아 난 자신의 어떤 도그마에 빠져있었구나" .... 고기를 낚았으면 그물을 버리라니?고기를 잡는 방법은 그물만 있는 것이 아니라니? 도대체 상식적으로 이해하기 어려운 것 같으면서도 왠지 공감이 갈려고 하는 이분위기는 뭐지?

본능적으로 쿨한 것에 끌리는 나로서는 왠지 이 글을 읽고나서 반응이 오는 느낌을 갖게된다... 아 뭔가 다시 생각할 부분이 있구나.

새로운 기술들을 도입하는데, 새로운 뭔가를 찾아 헤메이는데 지금 갖고 있는 것을 버리지 못하고 있었다.

“어떤 관습이 편안하게 느껴질 때 그것을 때려 부숴라.” -- 니코스 카잔차키스

지금 편하게 느끼고 있는 기술은 무었인가? 지금 버리지 못하고 애물단지 처럼 안고 놓지 않는 기술은 무었인가?
제일 편하다고 느끼는 것에서 문제의식을 느껴야 한다. 버려야 한다.

"우리의 탐구나 수련으로 통해 얻게 된 지식은 그 자체로서 완결되는 것이 아니라 결국 어느 순간, 과정 내지는 다른 지식을 위한 초석이 된다"

멋진 말이다.

결국 우리가 안주하고 있는 기존의 패러다임. (RM - Engine?) 이 적절한 비유가 될까? 이것을 걍 버리라는 말이 아니다.
"대부분 패러다임의 변화는 이전 패러다임의 한계와 오류를 극복한 대안이기 때문에 오히려 패러다임에 대해 깊은 이해를 가지면 다음 패러다임의 예측도 가능합니다."

이제는 과거의 패러다임에서 벗어나야 할 때가 온 것 같다.

스스로 반문하는 일이 요즘들어서 많아졌다. 근래에 들어서 더더욱 고민하는 꺼리도 많아졌다. 새삼스러울 것도 없지만, 뭔가개인적으로 주기 같은 것이 있는데, 최근에 읽었던 책의 목록들을 살펴봐도 내가 내심 어떤 것을 원하는지를 알고 싶어하는 것같았다.

최근 3개월 이내에 내가 읽은 책들은

• 조엘의 두번째 책
• 대체 뭐가문제야?
• 백만불짜리 습관
• 마인드 혁명
• 삶의 에너지를 높이는 습관들

이다. 많지는 않지만, 대체로 개인적으로 뭔가 개선할 만한 꺼리를 찾고 있었던 것 같다. 3개월이 지난 지금에 와서도비슷한 행태를 계속 하고 있는 중이기도 하고... 이 와중에 또 김창준 님이 쓰신 블로그 내용을 보고 다시금 또 반성을 하고있는 중이다 ㅡㅡ;; 도무지 운동이란 것에 담쌓고 사는 것이 얼마나 무지한 일인가 깨닫게 해주는 내용인 것 같다. (다시생각해보니 과거에 김창준님이 쓰신 무술과 프로그래밍을 연관지어 쓴 내용을 봤을 때도 그랬던 것 같다).

역시나 게으른 것이 제일 문제였던가 보다... 잠시 수많은 일들을 떨처버리려고 고민만 하던 패턴을 약간 바꿔볼 필요가 있겠다. 머 거창하게 시작하면 나 자신을 잘 아는 나로써는 오래가지 못할 것을 알기에, 간편한
것부터 시작해봐야겠다.

워드프레스의 버그인가? 아래부터 내용이 주욱 잘려서 다시 씀

• 국선도, 내가 예전부터 좋아했었고 한동안 하던 수련인데 자식넘 태어나고 부터 계속 못했었다.
• 수영, 이건 접영만 아직 못하는데 최소한 접영까지는 마스터할 수 있도록 해야겠다.
• 줄넘기, 얼마전부터 시작한 것인데 생각보다 무지 힘들다. 이렇게 힘든 건지 몰랐지만, 짬짬히 해서 시간을 더 늘려갈 수 있도록 해야겠다.

쩝, 기억력의 한계인가? 뭔가를 작성하고 포스팅하고나면 다 잊어버린다니까 ㅡㅡ;; 더 생각이 안난다. 여기서 접어야겠다. (이것도 운동 꾸준히 하면 좋아지려나?)

원문 : http://software.ericsink.com/No_Programmers.html

개발자와 프로그래머의 차이에 대해서 기술한 블로그 내용.

여기서 '프로그래머'란 새로운 기능을 코딩하고 운이 좋으면 버그를 고치는 일만 하는 사람입니다. 프로그래머는 스펙을작성하지 않습니다. 자동화 테스트케이스를 작성하지도 않습니다. 그리고 자동화 빌드 시스템을 최신으로 유지하는데 도움을 주지도않습니다. 또 고객이 힘든 문제를 해결하는 걸 돕지도 않습니다. 설명서를 작성하는 데 힘을 보태지도 않고, 테스트에 참여하지도않습니다. 코드를 읽는 일조차 하지 않습니다. 프로그래머가 하는 일은 오로지 새 코드를 작성하는 것뿐입니다. 소규모 ISV에서는이런 사람을 원하지 않습니다. 여러분에게는 코드를 작성하는 특수 임무를 맡은 '프로그래머'가 아니라, 성공적인 제품 개발을 위해다양한 방식으로 기여하는 '개발자'가 필요합니다.

라는 내용의 글을 에릭싱크 자신의 블로그에 올려놓았다. 위 글을 언급하는 이유는? 최근에 다시금 어떻게 하면 무지막지하게고생하는 팀원들과 나 자신에게 좀더 테스트 코드를 작성하고 활용하게 할 수 있을까에 대한 고민을 다시 새로이 시작하는 시점에참고가 될만한 내용이라고 생각해서이다.

물론 테스트코드 .. 작성하면 된다. 무조건 통과할 수 있도록 거기에 맞추어서 코드를 추가할 수도 있다. 형식적인 자료만될 수 있는 코드도 무지하게 추가할 수 있다. 하지만, 스스로가 이건 정말 도움이 되는 것 같다... 정말 도움이 되었다. 라고느끼지 않는 다면 얼마 지나지 않아서 다시 이런 자동화된 테스트 코드를 작성하는 것을그만 둘 것이다. 나 자신도 물론 그럴것이고.

문제는 현재까지는 이런 테스트 코드를 작성하는 일이 재미도 없고, 그리 도움이 될만하다고 느껴본적이 없으며, 쉽게 느껴지지도 않는다는 것이다.

어떻게 하면 진정으로 도움이 되는 테스트라고 생각할 수 있을까? 어떻게 하면 이런 것을 경험할 수 있을까? 누군가 나서서 이렇게 하자!! 라고 지속적으로 외치기만 해서 해결될 수 있을까?

일단 위에나온 에릭 싱크의 말처럼 접근을 시작하는 것도 좋겠다. 누구나 자신이 발전하는 것을 좋아하기 때문이다. 이렇지않는 사람이라면 전혀 재고의 가치도 없을 것이다. 발전을 원하는 사람들에게라면 어느정도 씨앗이 될 수 있을 만한 거리를제공하고, 어떻게는 테스트 코드를 작성하는 것도 하나의 일이며, 이런 일을 할 수 있는 시간을 확보해서 제공하는 것만이 결국에는모두에게 이익이며 개발비용을 오히려 절감할 수 있는 것이라는 사실을 윗사람들에게도 제공할 수 있도록 데이타가 축적되어야 하겠다.

# 우선 작은 성공을 경험할 수 있도록 제공하자.

# 쉽다고 느낄 수 있도록 자동화할 수 있는 방법을 고민하자.

# 신입사원도 자연스럽게 할 수 있는 상태가 되면 누구에게나 쉬운 것이다.

거창하게 모든 것을 한꺼번에 통합할 필요성은 없다. 단위테스트 코드들이 늘어날 수록 테스트를 자동화해서 매번 거치는코드들은 그만큼 검증되었다고 인정해주는 분위기가 되어갈 때 즐거움을 느끼는 '개발자' 단계로 들어가는 것임을 상기시켜야 하겠다.