Kwangshin's Positive Blog

오늘 인터넷 서핑을 하다가 다음과 같은 글을 보게 되었다.

Naming Conventions in Java - How to name Methods,Classes and Variables

When writing programs in the Java language, there are a set of standard conventions which should be followed. These are followed in almost all kind of projects. Beginners in Java language are not used to utilizing the namingconventions but as one writes code in modern day IDE’s these naming practices become a habit.

자바 언어로 프래그램을 작성할때, 몇 가지 표준 규칙들을 지켜주는 것이 좋다. 어떤 분야의 프로젝트를 진행중이건 간에 이러한 규칙들을 지켜주어야 한다. 자바 언어를 시작한지 얼마 되지 않았다면 이런 네이밍 규칙들이 생소하고, 적용하기에 익숙하지 않을 수도 있지만, 요즘 많이 사용되고 있는 통합 개발 환경(IDE)에서도 이러한 네이밍 규칙들을 지키고 있으므로 노력해서 습관이 될 수 있도록 하는 것이 좋다.

자바에서의 네이밍 규칙에 대해서 이야기 하고 있는 짧은 글이다. 특히 메서드(Methods), 클래스(Classes), 변수(Variables) 이름을 짓는 규칙에 대해서 이야기 하고 있다. 사실 이 글에서는 아주 일부분인 네이밍 규칙(Naming Convention)에 대해서만 언급하고 있지만, 사실 자바 프로그래밍 언어가 발표되고 얼마되지 않아서 자바 코딩 규칙에 관한 문서가 발표되었고, 13년 전인 1999년 4월 20일에 마지막으로 수정된 문서가 있다. (그 당시에는 링크가 Sun이었는데 지금은 Oracle이다.)

Code Conventions for the Java Programming Language
http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (HTML 버전 바로가기)

이 글을 보니 11년 전인 2001년도에 프로젝트에 적용하려고 번역해 놓은 문서가 떠올랐다.

[PDF 버전] Korean: Code Conventions for the Java Programming Language (한글) [PDF], 역자: 오광신
[HTML 버전] http://www.javastudy.co.kr/docs/lec_ProgrammingGuide/okshin/JavaCodeConventions.htm (자바스터디에 아직도 링크가 살아있다.)

왜 자바 코딩 규칙이 필요한가가 문서 초반에 나오고 있다. 자바를 만든 Sun에서 말하는 그 이유를 소개하면서 글을 마치고자 한다. 자바를 처음 시작하는 분이라면, 처음이 아니지만 한번도 자바 코딩 규칙에 대해서 들어본 적이 없는 자바 개발자라면 어렵지 않은 내용이니 꼭 한번 정독하시기를 추천한다.

80% of the lifetime cost of a piece of software goes to maintenance.
소프트웨어를 개발하는 일련의 모든 과정에 들어가는 비용 중 80%가 유지보수에 쓰여진다.

Hardly any software is maintained for its whole life by the original author.
소프트웨어의 유지보수를 그 소프트웨어를 직접 개발한 개발자가 담당하는 경우는 거의 보기 힘들다.

Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
코드 규칙을 지키면 다른 개발자가 그 소스코드를 처음 보았을 때, 더 빠른 시간안에 완벽하게 이해할 수 있도록 도와주기 때문에, 소프트웨어의 가독성이 높아진다.

PS. 예전 문서를 지금 보니 여기 저기 손댈 곳이 많아 보인다. 조만간 깔끔하게 업데이트를 해야겠다.

오늘 본 글 중에서 소프트웨어 개발자들의 이력서와 관련된 내용의 글이 있어서 공유합니다. 원본의 영어가 어렵지 않으니 원본을 확인하시면 더 큰 도움이 되리라 생각합니다.

원문 : How to make your CV Not Suck from Trisha's Ramblings

사실 이력서에 대한 정답은 없는 것 같습니다. 왜냐하면 이력서를 보는 사람들이 모두 다르기 때문에, 사람마다 이력서를 보는 기준이 다르기 때문이라고 생각합니다. 어떤 사람들은 이력서가 몇장이냐에 대해서 중요하게 생각해서 4장 이상 넘어가면 그냥 버린다는 사람들도 있고, 장수는 별로 중요하지 않다고 생각하는 사람들도 있는 것 같습니다. 하지만 대부분의 사람들이 중요하게 생각하는 것들에 대해서는 신경쓰고 이력서를 작성할 때 그렇게 작성하도록 노력하는 것이 좋을 것 같습니다.

원문에서 저자가 중요하게 생각하는 포인트들을 요약해 보도록 하겠습니다. 제 개인적인 생각들이 들어갈 수도 있으니 이상하다고 생각되는 부분들에 대해서는 원문을 참조해 주세요~

이미지 출처 : 구글 이미지 검색

간단하지만 범하기 쉬운 실수들

철자를 틀리지 말자!

영문 이력서에서도 중요한 이야기이지만 한글 이력서를 작성할때도 놓치지 말아야 할 부분이라고 생각합니다. 잘 모르겠거나 헷갈리는 부분들이 있으면 꼭! 사전을 참고해서 작성하도록 해야 합니다. 섣부른 판단은 금물! 기술의 발달로 요즘 많이 사용되는 워드 프로그램들의 경우 철자가 기본적인 문법이 틀렸을 때 빨간줄로 표시를 해 줍니다. 이력서를 봤을때 이 빨간 줄이 특별하게 사용되는 용어들을 제외한 다른 부분에서 나타난다면 아주 큰 감점 요소가 되겠죠.

영어 대문자를 사용해야 하는 곳에는 꼭 영어 대문자를 사용하자!

한국어와는 달리 영어에는 대소문자가 있습니다. 가끔씩 아주 기본적인 것들을 놓치는 경우가 있습니다. 문장의 시작은 대문자로 해야 하는데, 문장의 시작에 소문자가 오는 경우가 있습니다. 그리고 내 자신을 얘기할 때 보통 소문자 i 보다는 대문자 I를 사용합니다. 영문 이력서를 작성할 때, 이런 기본적인 것들은 지켜주세요.

문법을 지키자!

인터넷 상에서 한글도 마찬가지인데 영어도 문법이 안 지켜지는 경우가 많이 발생하고 있습니다. 하지만 이력서의 경우 나 자신을 표현하는 것이므로 문법을 꼭 지켜야 합니다. 영어가 익숙하지 않다면, 영어 사전이나 문법책을 많이 참고하시고, 마지막에는 영어 원어민으로부터 리뷰를 받는 과정이 꼭 필요하다고 생각합니다. 원어민이 리뷰를 해 줄 경우, 문법적으로는 맞지만 사용하지 않거나 다른 표현을 더 많이 사용하는 부분들에 대해서는 추가로 교정을 받을 수 있습니다.

예를 들어 우리말로 "남의 떡이 더 커 보인다."라는 표현을 할 때, 이 말을 그대로 번역하면 의사소통에 어려움이 발생할 수도 있습니다. 미국의 경우 땅이 커서, 집이 크고 집마다 잔디밭이 있어서 그런지 "The grass always looks greener on the other side." (다른 집에 있는 잔디가 항상 더 푸르게 보인다.)라고 표현을 합니다. 이렇게 표현하는게 나의 뜻을 더 정확하게 전달할 수 있는 방법이라고 생각합니다.

더 끌리는 이력서로 만들어주는 방법들

스프링 프레임워크(Spring Framework)의 어떤 버전을 사용했는지에 대해서는 크게 신경쓰지 않는다.

이 부분에 대해서는 논란의 여지가 있을 수 있기도 한데, "어떤 버전을 사용했는지 언급하지마."라기 보다는 버전보다 더 중요한 것들에 대해서 신경을 쓰라는 조언으로 이해하시면 좋을 것 같습니다. 소프트웨어 개발자들의 이력서도 대부분 처음에는 헤드헌팅 회사들의 헤드헌터들이 먼저 보기 때문에 내가 사용할 수 있는 기술들을 나열하는 것도 좋은 방법입니다. 하지만 너무 이력서 이곳 저곳에 언급하지 말고, 한곳에 모아서 내가 사용할 수 있는 기술들과 프로그램들에 대해서 언급하는 것이 좋습니다. 한눈에 볼 수 있게 말이죠.

하지만 헤드헌터를 통해서 실제 이력서를 리뷰하는 실무진들에게 이력서가 넘어가게 되면, 그들은 어떤 프로그램이나 어떤 프레임워크를 사용해 봤는지를 더 중요하게 보지 굳이 버전까지는 중요하게 보지 않는 경우도 많습니다. 버전 하나 하나에 너무 민감하게 작성하실 필요는 없고, 내가 어떤 프로그램이나 어떤 프레임워크를 사용해 보았는지가 잘 나타나면 좋을 것 같습니다.

당신이 어떤 열정을 가지고 있는지 알고 싶어한다.

예전에는 취미나 흥미를 보지 않고 그냥 넘겨버리고는 했는데, 요즘에는 취미가 흥미에 대해서 이력서에 아예 언급을 안 하는 것이 더 나을 수도 있다. 취미나 흥미 때문에 실무진들에게 쓸데없는 선입견을 주는 경우가 발생할 수 있기 때문이다.

대신 소프트웨어 개발자로서 블로그를 가지고 있거나 어떤 오픈 소스 소프트웨어에 참여하고 있는지, 또는 자바 유저 그룹 같은 곳에서 활동하고 있는지 등을 통해서 당신이 어떤 열정을 가지고 있는지 알고 싶어한다. 이력서에 이런 종류의 열정들이 없다고 해서 그 이력서를 미리 탈락시키지는 않지만, 이런 열정들이 이력서에 나타난다면 당연히 큰 영향을 줄 수가 있다.

테크놀로지(Technology)쪽에만 관심이 있는 사람인지 비지니스에도 눈을 열고 있는지 알고 싶어한다.

사실 좋은 팀을 꾸려나가기 위해서는 테크놀로지쪽에만 관심을 가지는 사람, 그리고 테크놀로지 부분이 조금은 부족하지만 비지니스를 이해하고 관심을 가지는 사람, 아니면 그 중간 정도에 위치하는 사람, 모두가 필요한 건 사실이다. 또 다른 기준으로는 사람과 프로세스가 있다. 사람과의 관계를 더 중요시 하는 사람이 있을 수도 있고, 프로세스를 더 중요시 하는 사람이 있을 수도 있다.

사실 테크놀로지에만 관심이 있는 사람이라고 해서 그 사람의 이력서를 탈락시켜버리지는 않지만, 그 테크놀로지들이 어떻게 비지니스를 만들어가는가에 대해서 관심이 있고 그러한 부분들을 이력서에 언급하는 경우에 더 끌리게 된다.

즉, 이력서에 그냥 자기가 사용했던 테크놀로지들에 대해서만 쭉 언급하기 보다는, 실제 요구사항이 어떠한 것이었고, 그 요구사항들을 만족시켜주기 위해서 어떤 테크놀로지들을 사용했으며, 그렇게 만들어진 제품을 통하여서 어떤 비지니스가 이루어졌는지 잘 풀어서 쓸 경우에 더 매력적인 이력서가 될 수 있다.

당신의 이력서를 보고 있는 회사들이 당신의 뒤를 몰래 캐 보기도 한다.

사실 짧은 시간안에 이력서를 검토해야 하기 때문에, 지원자의 페이스북이나 인터넷에서의 활동들을 확인하지 못하는 경우도 많다.

하지만 지원자가 직접 쓰거나 번역한 책이 있다면 아마존(Amazon)에 가서 책에 관해서 그리고 책 서평들을 읽어볼 것이다. 또한 다른 출판물이나 소스 코드가 인터넷에 있다면 찾아볼 용의도 있다. 만약 지원자가 다니고 있는 회사에 아는 사람이 있다면 링크드인(LinkedIn)을 통해서 그 사람이 어떤 사람인지 알아보려고 할 것이다. 이력서 만으로는 확신이 안 선다면 당연히 링크드인을 통해서 좀 더 알아볼 것이다.

그렇게 때문에 소프트웨어 개발자라면 인터넷 공간에서의 활동에 대해서 긍정적으로 생각하고 참여할 필요가 있다. 특히 직장에서의 인간관계를 나타내주는 링크드인과 같은 서비스를 잘 활용한다면 인터뷰와 합격의 기회에 한 발 더 다가갈 수 있다.

트위터에서 알게 된 한빛 미디어 기사 번역 서비스에서 관심있는 주제가 있어서 신청하고 번역을 했다. 공부도 되고,  다음에 한빛 미디어 도서를 구매할 때 사용할 수 있는 이코인도 주기 때문에 자주 참여해야 할 것 같다.

원문은 Tom Barker의 Why Aren't You Agile?이고 번역기사는 왜 애자일(Agile) 개발자가 되기 힘들까? 이다.

사실 애자일에 대해서 설명하는 글은 아니고, 필자가 애자일을 프로젝트에 적용하면서 어렵다고 느꼈던 부분에 대해서 써 내려간 일기 형식의 글이라는 표현이 더 어울릴 것 같다.

길지 않은 글이고 깊게 생각하게 만드는 글은 아니니 잠깐 짬 내서 읽어보면 좋을 것 같다.

----------------------------------------------------------------------------

왜 애자일(Agile) 개발자가 되기 힘들까?

소프트웨어를 개발하면서 스크럼(Scrum) 또는 다른 애자일 개발방법론을 적용하고 있지 않다면, 아직도 애자일을 실천하지 못하는 이유가 무엇인지 생각해봐야 할 때가 온 것 같다. 지금까지 여러 다른 회사에서 일해왔지만, 거의 모든 회사들이 애자일을 실천하기 위해서 모든 노력을 기울이곤 했다. 하지만 애자일을 실천하는 회사가 되기 위한 다방면의 지원에도 불구하고, 여러가지 이유로 실패하는 경우가 대부분이다. 왜 그럴까?

이 글에서는 애자일을 실천하는데 내가 경험했던 가장 큰 걸림돌이 무엇인지 그리고 그러한 걸림돌을 어떻게 하면 해결해 나갈 수 있는지에 대해서 소개하려고 한다. 사실 애자일을 도입하고 실천함에 있어 가장 큰 도움이 되는 것은 "애자일 전도사(evangelist)"이다.

외부 걸림돌 - 애자일을 오해하고 있는 비지니스 팀과 사장님

사실 이 문제가 내가 겪은 가장 큰 어려움이었다. 일반적으로 회사를 이끌어 나가는 경영자의 경우 애자일 개발자들은 관리하기 힘들다는 오해나 애자일에 대해서 잘 모른다는 이유로, 개발자들이 애자일을 받아들이는 것을 반대하기 쉽다. 하지만 개발자들이 애자일을 받아들이고 나서 가장 큰 이득을 얻게 되는 사람들은 개발자들 자기 자신이 아니라, 바로 비지니스 팀이다. 개발자들이 애자일을 받아들이게 되면, 비지니스 팀이 현재 개발이 진행중인 자사의 제품 뿐만 아니라 산업 전반의 흐름을 한 눈에 볼 수 있도록 도와주고, 짧은 주기를 가지고 릴리즈되는 제품에 새로운 기능들을 추가하는 일련의 작업들을 이전보다 더 쉽게 만들어준다. 사실 폭포수(Waterfall) 개발 방법론을 사용하는 프로젝트에서는, 이미 개발이 시작된 상태에서 기존에 논의되지 않았던 새로운 기능을 추가하려고 하면, 개발 기간이 많이 지연된다거나 아니면 다음 릴리즈에서나 추가가 가능하다는 답변을 받기가 쉽다.

회사를 이끌어 나가는 경영자들이 이러한 경험을 한 번이라도 하게 된다면, 애자일의 열렬한 지지자가 될 것이다.

내부 걸림돌 - 개발팀 내부에서의 반발

어떤 사람이 5년, 10년 또는 20년 동안 동일한 일을 해 왔다면, 변화를 두려워하는 것이 당연할 것이다. 정말 솔직하게 털어놓자면, 폭포수 개발 방법론을 사용하는 프로젝트에서는 개발자가 매일 매일 자신이 하는 일들을 관리자나 경영진에게 어느 정도 감추는 것이 가능하다. 하지만, 프로젝트가 애자일을 받아들이게 되면, 프로젝트에 관여하고 있는 모든 사람들이 프로젝트의 진행 상황을 매일 매일 직접 확인할 수 있다.

개발자들이 부담을 가질 수도 있겠지만, 개발자에게 결코 나쁜 것만은 아니다!

폭포수 개발 방법론을 실제로 사용한 적이 있다면, 여러개의 프로젝트를 동시에 진행했던 경험이 있을 것이다. 그 중에 꽤 많은 프로젝트들이 단지 경영진들의 우선순위가 바뀌어서 지연되거나 심지어는 무산되기도 한다. 때로는 경영진들이 우선순위를 다시 정하거나, 전체 프로젝트의 범위를 바꾸면서도, 한달내로 마무리 하라는 무리한 요구를 하기도 한다.

프로젝트에 애자일을 적용하게 되면, 릴리즈의 주기가 짧아져서 자주 바뀌는 경영진들의 요구를 만족시켜줄 수 있다. 개발자가 새로 추가한 부분들이 일주일 단위로 실제 서비스에 포함될 가능성을 가지고 있는 것이다. 애자일 코치(스크럼 마스터)는 이미 개발자에 의해 구현된 부분을 가지고 경영진과 프로젝트를 조율할 수 있고, 개발자는 그 프로젝트에 더 이상 신경쓰지 않고 자신이 하던 일에 집중할 수 있게 된다. 프로젝트의 모든 기능들은 개발자와 경영진이 더 쉽게 이해하고 접근할 수 있도록 작은 단위로 쪼개어져서 관리되고 개발되어진다.

애자일을 적용하는 개발팀이 어떻게 개발을 진행하는지 실제로 느껴보기 위해서라도, 한달만이라도 애자일 개발자가 되어보는 것은 어떨까?

프로젝트 팀원들이 애자일에 대한 지식이 없을때

개발부서라면 당연히 교육에 대한 예산이 있어야 한다고 생각한다. 현재 일하고 있는 부서에 이런 예산이 없다면, 그것은 애자일을 적용하는 것보다 더 심각한 회사 조직에 관한 이슈가 될 것이다. 교육을 위한 예산이 있다면, 개발자들을 애자일 교육에 보내도록 해라.

개발팀의 관리자들과 개발자들을 차례 차례 모두 교육에 보내서, 모든 프로젝트 팀원들이 애자일이 무엇인지 배워서 실제 프로젝트에 적용할 수 있도록 지원해보자. 경영진들 또한 애자일 교육에 가서 직접 느껴보는 것이, 짧은 시간내에 큰 문제없이 애자일을 도입할 수 있는 방법이 될 수도있다.

망설임 또한 폭포수 개발 방법론을 계속 사용하겠다는 또 다른 결정이다

개발 부서가 애자일을 새로운 개발 방법론으로 받아들이는 것에 실패한다면, 계속해서 폭포수 개발 방법론을 사용하겠다는 결정으로 받아들일 수 있다. 망설임 또한 또 다른 결정이다.

이러한 설득에도 불구하고 애자일을 받아들이는 것이 계속 망설여 지는 경우라면, 가장 효과적인 방법은 당신이 직접 애자일 전도사가 되는 것이다. 지금은 애자일 전도사가 당신 혼자일지라도 여러가지 새로운 아이디어를 내서, 그들의 마음이 바뀌도록 노력해 보자. 지금까지 함께 나눈 나의 경험들이 도움이 될 것이다.

지난 번에는 애자일 소프트웨어 개발 선언문을 번역을 했었는데, 이번에는 좀 더 자세한 애자일 선언문의 바탕이 되는 기본 원칙들을 번역해 보았다.  원문은 http://agilemanifesto.org/principles.html 에서 확인할 수 있다.

애자일 선언문의 바탕이 되는 신념

우리는 다음과 같은 신념을 지키고 따른다:

우리에게 가장 중요한 것은
가치있는 소프트웨어를 좀 더 빨리 그리고 계속적으로 제공함으로써
고객들을 만족시키는 것이다.

개발의 마지막 단계에서 요구 사항이 변경된다 할지라도 기꺼이 받아들인다.
 애자일 프로세스는 고객들이 더 큰 경쟁력을 가질 수 있도록
언제든지 요구 사항의 변경을 지원한다.

동작하는 소프트웨어를 자주 고객들에게 제공한다.
몇 주에 한번, 또는 몇 달에 한번이 될 수도 있겠지만,
그 기간을 최대한 줄이기 위해 노력한다.

비지니스 담당자와 개발자는 프로제트가 진행되는 동안
항상 협조하며 매일 매일 함께 일한다.

프로젝트 참여자들에게 동기를 부여한다.
프로젝트가 성공할 것이라고 믿음을 가지고,
그들이 원하는 환경을 만들어주고 최대한 지원한다.

개발팀의 내,외부적으로 모든 정보들을 공유하며 전달할수 있는
가장 유용하고 효과적인 방법은
서로 얼굴과 얼굴 맞대고 대화하는 것이다.

프로젝트의 진척 상태를 확인할때 가장 기본이 되는 것은 소프트웨어가 동작하는지 보는 것이다.

애자일 프로세스는 지속적인 개발이 가능할 수 있도록 도와준다.
스폰서, 개발자, 사용자 모두 프로젝트가 끊임없이 계속 진행될 수 있도록 노력해야 한다.

새로운 우수한 기술들과 더 좋은 설계에 지속적으로 관심을 가진다.

꼭 필요한 일만 할 수 있도록 도와주는 단순성(Simplicity)은 항상 염두에 두어야 하는 꼭 필요한 것이다

내부적으로 스스로 발전하는 팀들만이
최고의 아키텍처, 요구사항, 설계를 가질 수 있다.

주기적으로 어떻게 하면 더 효과적인 팀이 될 수 있는지 고민해야 한다.
그리고 그 고민에서 나온 아이디어들을 행동에 옮겨라.

꼭 한번 번역해 보고 싶었던 기사를 번역해 보았습니다. 원문은 America’s Real Dream Team by THOMAS L. FRIEDMAN에서 확인하실 수 있습니다. 라이센스 문제는 잘 모르겠지만, 개인 블로그이니까 괜찮지 않을까 하는 생각에...^^; 혹시라도 문제가 된다면 알려주시기 바랍니다.

그리고, 단어 하나 하나를 빼 놓지 않는 직역보다는, 제가 느낀 그대로 의역을 했습니다. 몇몇 부분에서 동의하지 않으시는 부분은 원문을 참고해 주세요. ^^

좋은 글 소개해 주신 America’s Real Dream Team-토머스 프리드먼 by 임정욱님께서 감사드립니다.

-----------------------------------------

미국을 이끌어갈 드림팀

글쓴이: 토머스 프리드먼
날짜: 2010년 3월 20일

지난주에 워싱턴에서 있었던 저녁 만찬에 다녀왔다. 이미 상상할 수 있겠지만, 커다란 홀에 검정색 넥타이를 맨 신사들, 그리고 드레스를 갖춰 입은 숙녀들이 초대된 그런 저녁 만찬이었다. 하지만 보통의 평범한 그런 저녁 만찬이 아니었다.  40명의 특별하게 초대된 손님들이 있었다. 자 여기서 퀴즈 하나: 특별히 초대된 40명의 이름을 여기에 나열할테니, 이 저녁 만찬이 어떤 모임인지 맞춰보도록 하자. 자, 여기 그 이름들이 있다:

토머스 프리드먼

Linda Zhou, Alice Wei Zhao, Lori Ying, Angela Yu-Yun Yeung, Lynnelle Lin Ye, Kevin Young Xu, Benjamin Chang Sun, Jane Yoonhae Suh, Katheryn Cheng Shi, Sunanda Sharma, Sarine Gayaneh Shahmirian, Arjun Ranganath Puranik, Raman Venkat Nelakant, Akhil Mathew, Paul Masih Das, David Chienyun Liu, Elisa Bisi Lin, Yifan Li, Lanair Amaad Lett, Ruoyi Jiang, Otana Agape Jakpor, Peter Danming Hu, Yale Wang Fan, Yuval Yaacov Calev, Levent Alpoge, John Vincenzo Capodilupo and Namrata Anand.