이클립스 mylyn과
http://code.google.com/p/okjsp 연결을 위한 플러그인을 다룹니다.
plugin url: http://knittig.de/googlecode-mylyn-connector/update/


KDF 발표자료입니다.


http://findbugs.sourceforge.net 메릴랜드(Maryland) 대학에서 공개한 도구입니다. 자바의 버그패턴에 맞춰서 자바 소스코드를 컴파일된 바이트코드로 정적 분석한 후에 어느 부분이 문제가 되는지 자동 리포팅해줍니다.
누군가 내 코드를 검사한다는 것이 개발자에게는 탐탁치 않지만 임신진단시약처럼 자가테스트를 한다면 다른 얘기가 되겠죠. 남에게 보이기 전에 자신의 코드를 깔끔하게 만들 수 있으니까요.

그러나 바쁜 현대인을 위해서 지속적인 통합툴에서 대신해 주기도 합니다. (참고: http://www.ibm.com/developerworks/kr/library/tutorial/j-cq11207/section11.html )

이클립스 플러그인도 있습니다. findbugs의 수많은 옵션을 알지 못해도 간단하게 마우스 버튼으로 조작해서 사용할 수 있습니다. (참고: http://findbugs.sourceforge.net/manual/eclipse.html )

QA역할을 하는 동료가 짐을 덜었다고 좋아하던데, 자기가 짠 코드의 결함 검사는 스스로하는 것이 바람직할 듯 합니다. 경기 후 어지러진 관중석을 보는 듯한 코드는 으윽 이니까요.
요즘 개발할 때 소스코드 보험은 필수입니다. CVS나 Subversion 같은 것 말이죠.
xcode에도 이 기능을 지원하네요.
메뉴에 SCM을 선택합니다. Source Code Management 의 약자일까요?
사용자 삽입 이미지

Xcode Preferences 창이 뜨면서 SCM 메뉴가 선택되어있습니다. 좌측 하단의 +를 클릭합니다.
사용자 삽입 이미지

okjsp 사이트 소스는 공개되어있습니다. anoncvs 계정과 anoncvs 패스워드로 접속가능합니다.
사용자 삽입 이미지

등록을 마치고 메뉴에서 Repositories 를 선택하면 접속이 됩니다.
사용자 삽입 이미지


좋군요.

작년 11월부터 손에 가지고 다닌 책입니다.
다 읽기는 했지만 글자만 다 읽었습니다. ^^; 사실 솔직히 얘기하면 마지막 10% 부분은 많이 설렁설렁 읽었습니다.

읽고난 후 소감은 음... "해 냈다."입니다. core j2ee patterns 이어서 두 번 째 완독한 원서라고 할까요.

사용자 삽입 이미지


책은 누더기가 되었습니다. ^^;
이제 몸으로 읽을 때가 된 듯 합니다. 체득해야죠.
경품은 트럼프였습니다. 뭐 대단한 것을 받을 줄 알았는데 좀 실망이 쩝. ^^; 풀긴 풀었단 얘기죠. 같이 간 김차장님과 같이 협의해 가면서 세 시간 동안 세션에 들어가지 않고 열심히 문제를 풀었습니다.
사용자 삽입 이미지

저 말고도 많은 사람들이 문제를 풀고 있었고, 옆에서 답 푸는 것을 듣지도 보지도 못하게 많은 사람들이 방어하더군요. 가운데 오른쪽에 흰 티셔츠를 입고 있는 사람이 정답 채점관입니다. Andrew 씨인데, 쩝, 굉장히 까칠하게 조목조목 보더군요. 이 아저씨에게 5차례 빠꾸당했습니다.
사용자 삽입 이미지
아마존 부쓰에 써있는 문구는 프로그래머의 자존심을 자극하는 문구들이었습니다. 우리는 똑똑한 사람을 원한다는 뭐 그런... 쩝. ㅡㅡ;
사용자 삽입 이미지

코드 닌자라고 불리는 첫 날의 문제는 다음과 같습니다. 답은 알고 있습니다만 적지는 않겠습니다.
사용자 삽입 이미지
다른 각도에서 한 컷.
사용자 삽입 이미지
메모지에 열심히 풀었습니다. 그것도 모자라서 프로그램도 검증하는 프로그램도 짰지요. ㅡㅡ;
사용자 삽입 이미지

다음 날 두 번째 문제는 풀지 않았습니다. 그냥 찍기만 했죠. ^^; 관심있으신 분들은 한 번 풀어보시는 것도 좋지만 상품은 없습니다.
사용자 삽입 이미지

인재를 구하기 위한 방법도 여러가지인 듯 합니다. ^^;
여튼 다음 날 앤드류에게 "You win"이라는 소리를 들으니 기분 괜찮았습니다.

http://www.okjsp.pe.kr 에서 주최한 부산세미나입니다.

주제는 레거시 코드 관리 전략이고, 중앙 ITEA 부산 서면센터에서 열렸습니다.

JCO 자바컨퍼런스 내용을 조금 더 보충했습니다.





강의자료 링크입니다.
http://member.thinkfree.com/show.se?f=c93f8edf420459ab68316f75a595c1c1
Working Effectively with Legacy Code 책의 p.147에 있는 내용입니다.
메소드 또는 함수는 두 가지 타입의 역할을 하게 됩니다. 동작의 명령(Command)이 첫번째이고 결과값이 필요한 질의(Query)가 다른 역할입니다.

메소드는 이 두 가지 타입의 역할이 구분되어 있어야 되고, 메소드 내에서 두 가지가 혼용이 된다면 그 메소드의 재활용은 예상치 못한 결과를 초래하게 됩니다.

특히나 메소드 간에 통용되는 필드변수의 값에 변동이 다른 메소드에 영향을 주게 된다면 그 메소드의 독립성은 저하되는 것이고, 이에 따라 코드의 재활용과 테스트 가능성도 낮아지게 됩니다.

내용이 많이 어렵습니다만, 부작용(Side Effect) 없는 코드를 만들기 위해서 중요한 기준 원칙이라 생각합니다.

좋은 예가 생각나면 공유하도록 하겠습니다.
아침에 제목만 쓰고 집에와서 내용 씁니다.
(블로그 일기에 빈 날짜가 있을까봐요. ^^;)

비즈니스를 하는 원칙 중 하나가, 확장 -> 내실 -> 확장 -> 내실... 입니다.
두 블로그에서 까인 JCO 행사였지만, 기우였다는 게 밝혀져서 다행입니다.

사실 새옹지마라고 예측은 할 수 없지만, 지나고 나면 쉽게 풀리는 게 인생입니다.
---- 이상 술김에 얘기한 것입니다. ----

오늘 발표는 무사히 넘어갔습니다. 웃어주신 분들께 고맙고, 웃음소리 들으신 만큼 복받으실 겁니다.

현재 개발자로 특히나 자바 개발자로 살아가는 많은 분들을 보고 찍었습니다. 아침에 한시간 이상을 줄 서면서도 그리고 속으로 욕하면서도 자리를 지키신 분들께 고맙습니다.
싫어도 불편해도 자리를 지킨다는 것은 자체가 쉽지 않기 때문입니다.

심형래 처럼 꿈을 쫓는 돈키호테를 제 인생의 모델로 삼았습니다. 둘시네아라는 결혼하지 못한 여자가 있고(저는 좀 낫습니다. ^^; 애가 둘이니까요.) 미친 놈처럼 풍차랑 싸우고...

후회없이 사는 것... 미련없이(미련하지 않게 스마트하게) 사는 것...

제 숙제입니다.

모두 수고하셨습니다.
^^ 내일은 더 행복하세요.
웹에서 유니코드 문자열을 다루는 일은 제법 걸림이 됩니다. 어제도 웹서비스를 스트림으로 읽어서 처리하는 가운데 한글이 유니코드 문자열로 반환되는 바람에 애를 먹었었는데, 다행히 2004년에 비슷한 이유로 만든 코드를 이용해서 해결했습니다.

유니코드문자열을 캐릭터문자열로 바꾸는 클래스, 작은 것이지만 구글 코드를 통해서 공유합니다. http://code.google.com/p/unicodereader
사용자 삽입 이미지

테스트케이스도 같이 있기 때문에 쉽게 적용하실 수 있을 것입니다.
라이센스는 아파치 라이센스 2.0 입니다. 제가 이해하기로는 맘대로 쓰셔도 될 것입니다. 메소드 주석의 저작자 @author 만 남겨주세요. ^^


서브버전을 통해서 이클립스 프로젝트 형태로 등록도 해 놓았습니다. 모쪼록 개발에 도움이 되길 바랍니다. 행복하세요.

원고 토픽 목록입니다. 정리한 내용은 다음달 마소에서 뵙겠습니다.
-----------------------------------------------------------------

21세기 프로페셔널 프로그래머

프로페셔널(professional)의 정의

해커? 프로그래머?
프로그램은 종류에 따라 나뉘어집니다.
그에 따라 프로그래머의 성격이나 스타일도 변합니다.
애플리케이션
비즈니스 애플리케이션
초정밀 애플리케이션

프로그램의 특성 중 하나는 갈수록 복잡해진다. 프로토타입은 간단, 리팩토링 필요. 명세 필요
If가 많은 프로그램은 생각의 분기를 발생시키기 때문에 코드의 가독성이 떨어진다.
기능의 추가 변경으로 인한 사이드이펙트

팀개발의 특성을 이해
오케스트라는 독주회가 아닙니다.
의사결정권한 가진 사람과 그 비즈니스 특성에 관한 이해
나밖에 이해 못하는 코드
시간이 흘러 나도 이해 못하는 코드. 청문회용 코드

코드리뷰를 통해서 널리 알리자.
코드리뷰에 대한 팁
마녀 사냥이 되어서는 안 된다.
랜덤 선택

팀간 코드 패턴에 관한 토론
내용정리 필수, wiki 이용.
동료와 코드로 얘기해 본지 얼마나 되었나.

지우지 못하는 코드
나중에 시간 날 때 정리하면 지는 거다.

깨진 유리창 법칙을 기억하라
누가 휴지를 버리고 방치해 두면 머지 않아 쓰레기 버리는 곳이 된다.
리팩토링은 쓰레기 청소하는 방정리와 같다.
군대에서 관물정리를 하는 이유는 간단하다. 보기 좋으라고 하는 것이 아니라. 전시에 불이 꺼진 상태에도 어디에 무엇이 있는지 빨리 찾아서 입고 출동하기 위해서이다. 짱 밖아 놓은 것이 많은 관물대는 스릴 만빵이다.

개발자와 오픈소스
자기가 만든 소스를 적들에게 알리지 말라. 내 밥줄인 소스를 공개할 수 없다.
독불장군 스타일의 혼자 노는 개발자

다른 사람과의 협업을 통해서 더 나은 프로그램을 만들 수 있다.
협업(collaborate)이라는 단어는 함께(col) 일하는(labor) 방법이다.
협동하는 방법
네비게이터
유저
패처
문서작성자
기여자

오픈소스를 이용하는 이유는 프로그램의 제어권을 잡을 수 있기 때문.
감사하는 마음을 갖자.
아주 나쁜 소스 도용.

프로페셔널 프로그래머는 과연

+ Recent posts