Recently in S/W 공학 Category

“쎈과 서연이의 행방불명” 블로그의 내용을 참조하여 eclipse의 mylyn과 google code의 issue 관리기능을 연동해 보았다.

혹시 몰라 내가 했던 작업을 복기해 본다.

 

1. google code 와 mylyn 연동 참조 사이트 검색

  google 검색을 통하여 발견한 아래 두 사이트에서 주요 정보를 얻었다.

  - http://eclipse.dzone.com/articles/using-mylyn-with-google-code-u

  - http://docs.ssen.name/entry/AS3-Friends-Mylyn-과-Google-Code-Project-Issue-연동하기

 

2. eclipse mylyn connector 설치

  - update site는 http://download.eclipse.org/tools/mylyn/update/incubator 임

  - 여기서 Mylyn connector : Web Templates(Advanced) 설치 ( Mylyn과 Mylyn Extras가 설치되었음을 가정 )

   

3. Task Repository 에서 google code 를 등록

  - window > show view > Task Repositories를 선택하여 Task Repositories를 표시한다.

  - Context Menu 에서 Add Task Repositories , Web Template(Advanced) 선택

  - server 에  http://code.google.com/p/${project name}/issues 입력 ( ${project name} 는 각자의 프로젝트 명으로 고치세요 )

  - Label은 Task Repositories 에 표시될 명칭임 아무거나 바꿔도 됨.

 

4. Query 생성

  - Task Repository 에서 Label 명을 선택하고 Context 메뉴에서 New Query 선택

  - 아래와 같이 입력

    Query URL : ${serverUrl}/csv?colspec=ID+Status+Type+Owner+Summary

    Query Pattern : "({Id}[0-9]+?)","({Status}.*?)","({Type}.*?)","({Owner}.*?)","({Description}.*?)"\n

   

 

5. 이슈 생성

    - Task List > New > Task > google repository(설정에 따라 다름) > Next > Finish

    - 이슈 등록

 

끝~

[오해]프로그래밍은 비자아적(egoless)이 될 수 있고,또 되어야 한다.

출처 : 소프트웨어 공학의 진실과 오해

이 책에서는 The Psychology of Computer Programming(http://weinbergonwriting.blogspot.com/)에서 말한 "프로그래머는 그들이 만드는 제품에 자신의 자아(ego)를 투영해서는 안 된다." 라는 주장에 대해서 논하고 있다.

당연한 주장으로 받아 들일 수 있는 부분이다. 프로젝트에서 오류보고서, 동료검토 등을 인신공격으로 받아 들이는 개발자들이 너무도 많이 보아왔고 나 역시도 그 부분에 자유롭다고 말할 수는 없다.

그렇다면 그냥 "자아를 투영하지 말라" 라고 교훈을 주는 것이 끝일까? 사실 어느 누구도 프로그래밍에 자아를 투입시키지 않을 자신이 있는 사람은 없을것이다. 그럴수 있다고 말하는 사람은 어쩌면 프로그래밍에 정성을 쏟지 않는 다는 의미 일 수 도 있다.

이런 점에서 어떤 형태이든 팀 프로그래밍이 다른 대안보다 나은 것으로 인정되고 있다.

설계자가 숙지한 기본단위(primitive) 수준으로 문제가 분해됐을때 설계에서 코딩으로 전환된다. 설계자와 코더(coder)가 동일한 사람이 아니라면, 설계자와 코더의 기본단위가 같지 않을수 있고, 이는 문제를 초래할 수 있다.

출처: 소프트웨어 공학의 사실과 오해

요즘 공정분리에 대한 관심이 높다. 얼핏 설계의 상세성에 대한 논란이 많다. 내가 속한 조직에서는 설계는 무조건 상세 해야 한다는 식의 논리가 힘을 얻고 있는 듯 보인다.  이는 들쭉 날쭉한 코더의 개발 역량, 원격지에서의 커뮤니케이션 오류 등을 모두 염두에 두고 생각하는 듯 하다.

다만 이런 식의 공정분리가 우리에게 주는 것이 무엇일까? 첫번째 경제성에 대해 생각해보다. 얼핏 봐도 설계의 비용이 늘어서 경제적인 이득이 있다는건 아닌 것 같다. 인건비가 싼 중국, 인도에 코딩을 아웃소싱 한다 치더라도 설계의 비용이 늘어난 것에 대한 보전에 지나지 않을 것이다.

두번째, 개발프로세스에 대해 생각해보면.. 요즘 방법론은 Waterfall 방법론의 약점을 보완하기 위하여 점진적인 방법론의 성향을 띈다. 더 나아가 Agile방법론에서는 일주일단위의 iteration을 운영하는 방법을 쓰기도한다. 이런 방법론에 공정분리가 적절한가?  iteration이 잦을 수록 공정분리에 따른 커뮤니케이션 비용, 시간이 증가할 것이다.

세번째, 고객이 공정분리가 가치있는 것이라고 생각하겠느냐? 공정분리를 한다고 고객에게 설득하는 것이 쉽지 않다고 한다. 얼핏 생각해도 설계 이후엔 요구사항의 변경이 힘들것 같다는 생각이 지나간다.고객의 입장에서도 한번 내 뱉은 요구사항을 번복하기가 쉽지 않다는 것을 받아들이기가 어려울것이다.

지금까지 공정분리에 대해 심하게 깐것 같지만 공정분리라는 말이 나온 것은 다른 곳에 있는 것 같다. 설계/코드 를 1인이 하는 경우에 설계의 품질이 엉망이라는 판단에서 일 것이다. 문제는 문제가 있는 곳에서 해결하라는 말을 하고 싶다.
설계의 품질이 엉망이란 것은 아직도 우리가 Waterfall에서 벗어나지 못해서 초기 설계에 대한 수정 없이 그냥 진행해 버리는 것 일수도 있고, 개발자(설계자+코더)들은 자신에게 Burden으로만 느껴지는 무거운 산출물을 본능적으로 무시고 싶을 것 같기도 하다. 그런면에서 Agile 방법론이 빨리 빨리 자라줬으면 한다.

소프트웨어 문제에 대해 최상의 솔루션이 하나인 경우는 거의 없다.

출처 : 소프트웨어 공학의 사실과 오해

프로젝트에서 어떤 문제에 부딛혔을 때,  PM이 물어 본다.

PM: "이거 해결할려면 어떻게 해야 하지?"
나 : "이걸 이렇게 해결하려면 A방법과 B방법이 있습니다. 음.. 그런데 A방법은 당장 X솔루션을 구매 해야 하기 때문에 추가 비용이 발생합니다. 그리고 B방법은 개발 공수가 많이 들고 품질이 떨어질 우려가 있습니다. "
PM: ...
PM: 그럼 어떻게 하면 좋겠는가?

이런식으로 대화가 진행된다. 여기서 판단은 PM이 해줘야 하는 것 아닌가? 비용, 시간 , 품질 등을 놓고 저울질 해야 하는 사람이 당신이 아니오??? 라고 강하게 말하고 싶은데.. 현실을 그렇지 않다.

나 : (반복) A는 돈이 들고 B는 개발자가 고생하고 품질이 떨어질수 있습니다.
PM : 그래서 뭘로 하자는 거야?

짜증이다... !!

"개인차"에 관한 연구에 따르면, 최상의 프로그래머는 최악의 프로그래머 보다 28배 더 뛰어나다, 여기에 비례해서 이들에게 임금을 28배 주는 것이 아니라면, 이들은 소프트웨어 분야에서 가장 값싸고 훌륭한 자원이다.

출처 : 소프트웨어 공학의 사실과 오해


SI프로젝트에 SW아키텍트로서 참여해 오면서 몇번 개발자의 면접을 본 적이 있다. 그리고 내손으로 뽑은 개발자와 함께 프로젝트를 진행해 오면서 "앗차 이사람은 뽑지 말았어야 했는데..!", "이 사람은 개발 역량이 너무 없어..!", "이 사람과 2년만 같이 일하면 속터져 죽을거야..!!!" 등의 후회를 해 본적이 있다.

그 때마다 정말 뛰어난 개발자를 알아보는 방법이 있을까?
지난 수년간 프로그래머 자질 테스트, 각종 인증시험 등..으로 알아낸 결과는 이 시험과 실무 능력은 별 상관이 없는 것 같다...

특히 SI 프로젝트에서와 같이 단기 프로젝트에서는 더욱더 막막한 일이다.  개발자들과 같이 일하고 1개월 정도이면 어느 정도 개발자의 생산성을 파악할 수 있는데... 6개월 근처의 납기를 가진 프로젝트에서는 그 인력을 교체하기에 이미 늦었다고 볼 수 있다.

 

 

OKJSP에서 개발자 면접에 대한 고민의 댓글 중에 쓸만한 놈을 가지고 왔다.

 

1. Object, Class, Instance를 각각 설명하시오.
2. 개발환경을 스스로 구축해 본적이 있는가?
3. 지금껏 문자열을 다루면서 가장 곤란했던 경험을 이야기하고 해결과정을 설명하시오(한글문제 포함)
4. static 키워드의 의미를 설명하시오
5. stack과 queue를 각각 설명하시오.
7. 오버로딩과 오버라이딩의 차이를 설명하고 간단한 적용 예를 구현해 보시오(종이&연필)
8. interface의 의미를 설명하고 interface를 이용하여 간단한 패턴을 구현해 보시오.(종이&연필)
9. Collection Framework에 대하여 설명하시오.
10. 가장 최근에 수행했던 프로젝트에 대하여 설명하고, 어려웠던 점, 보람찼던 점, 팀원들에 대하여 이야기하시오..