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)을 통해서 그 사람이 어떤 사람인지 알아보려고 할 것이다. 이력서 만으로는 확신이 안 선다면 당연히 링크드인을 통해서 좀 더 알아볼 것이다.

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

Q: How can I find out the version of my Red Hat Linux Server?

A:

(1) Check the file "/etc/redhat-release".

To check the file, you can simply use "cat" command as the following:

cat /etc/redhat-release

Then you can see the following format:

Red Hat Enterprise Linux Server release 5.7 (Tikanga)

(2) Use the "uname -a" command.

You can find out the main release version using the "uname -a" command.

uname -a

Then you can see the following result:

Linux XXXXXXXXX 2.6.18-274.el5 #1 ....

From here, "el5" means "Enterprise Linux 5".

Please see the following screenshot:

JavaOne is the *must* watch event if you are working in area related Java. JavaOne 2011 held in San Francisco from 2 Oct to 6 Oct. Yes, I know and understand that it is very hard to get the chance to attend the conference. Fortunately we can re-vist the JavaOne 2011 conference online.

First of all, you can visit JavaOne Official Site and get the plenty of information.

Screen Shot : JavaOne Official Site

From there you can find out more information, here are some useful links:

1. JavaOne Keynotes and Interviews (on-demand video) - Do *not* miss the Keynotes!
2. JavaOne Content Catalog - You can download the PDF presentation files.
3. Select JavaOne technical and Birds-of-a-Feather sessions are available free on Parleys.com (look for the Java Channel) - Or you can go directly to Parleys.com JavaOne 2011 space.
4. Java.net Blog posts - You can find out more insight blog posts from Java.net Blog.

If we have passion, there are lots of articles, audio files, video files, books, etc within our reach.

One of the most popular buzzwords in IT nowadays, is the *cloud*. As a Java developer, I have been watching the *cloud* for several years. I would like to share the useful article "Writing Java code in the cloud" by Cameron McKenzie and James Denman.

You can click the link and then read full article. Yes, it is called as "Tutorial", but don't worry too much. It is a short article showing the concept of cloud in the perspective of Java. It has the following 3 parts, you can guess what kind of information is included in this article if you see:

• What is the cloud, and is it the right time for adoption?
• Extreme scaling in the cloud
• Cloud computing as a Java development platform

I want to share just a few sentences I agree:

However, the cloud may not be suitable for everyone.

Interestingly, the Java programming language itself, due to the way it manages references and collections, will often generate problems when infinitely scaling, which is why so many other programming languages that run on the Java platform are becoming popular.

Another of the advantages to using a cloud platform for developing enterprise applications is the relative ease of trouble shooting the applications.

Java developers often have a broad range of in-depth skills, but dealing with a cloud infrastructure may be a new challenge for many of them.

Additionally this article includes the links of good articles. If you read the more following articles, then it would be helpful to understand more about Java and cloud:

1. Cloud Computing vs SOA - SOA Was Just a Fad says SpringSource's Rod Johnson
2. Platform as a Service: gaining traction or slippery slope?
3. Say No To The Cloud? There Are Reasons Why
4. High Scalable & Distributed Architecture with EJB & Spring Framework
5. Platform as a Service (PaaS)
6. Snapshots in the cloud: The developers friend
7. Don't PAAS Up This Opportunity
8. Make yourself cloud-ready with Platform as a Service (PaaS) skills

The role of leadership in software development

[Youtube]

Google Tech Talks
Speaker: Mary Poppendieck
6 May, 2008
1 hour 32 minutes 04 seconds

ABSTRACT from Youtube Page

When you look around, there are a lot of leaders recommended for software development. We have the functional manager and the project manager, the scrum master and the black belt, the product owner and the customer-on-site, the technical leader and the architect, the product manager and the chief engineer.

Clearly that's too many leaders. So how many leaders should there be, what should they do, what shouldn't they do, and what skills do they need?

This will be a presentation and discussion of leadership roles in software development -- what works, what doesn't and why.

Summary by Kwangshin

1850's Train Wreck Management
> Six Principles of Administration

1880's Command Intent

1910's The One Best Way
> Frederick Winslow Taylor
-. The Principles of Scientific Management

1920's Industrial Training
> Charles R. Allen - New Bedford, Massachusetts
-. On-the job training
-. By a master at the job
-. Four Step Method
* Preparation, Presentation, Application, Testing

1930's Unit Command

1940's Wartime Production
> Training within Industry (TWI)
-. Train first line supervisors
* Job Instruction - how to train workers
* Job Methods - how to improve the way work is done
* Job Relations - how to treat workers with respoect
> Statistical Process Control (SPC)

1950's TWI & SPC move to Japan

Meanwhile in the USA - The Polaris Project
> Success was attributed to "PERT"

Why Polaris was Successful
> Quality of Leadership
> Focus on Deployment
> Decentralized, Competitive Organization
> Emphasis on Reliability
> Esprit de corps

1960's Toyota Production System
> Taiichi Ohno
-. Just-in-Time Flow
-. Stop-the-Line Culture
-. Relentless Improvement

Taiichi Ohno Standard Work

1970's Theory X - Theory Z
> Kaoru Ishikawa
-. "The fundamental principle of sucessful management is to allow subordinates to make full use of their ability."

1980's If Japan can, why can't we?

1990's The Decade of Process

Plank Road Fever

High Reliability Organizations
> Common Characteristic : Mindfulness

Mindfulness
> Preoccupation with Failure
> Reluctance to Simplify
> Sensitivity to Operations
> Commitment to Resilience
> Deference to Expertise

Mission Command vs. Detailed Command : A Comparison
> Where does Software fit?

The Product Leader
> Example: Chief Engineer at Toyota

Functional Leader

Leadership Roles
> Marketing Leader
-. Business Responsibility
-. Customer Understanding
-. Release Planning
-. Tradeoffs

> Technical Leader
-. System Architecture
-. Technical Guidance

> Functional Leader
-. Preserve Knowledge
-. Solve Problems
-. Grow People

> Project Leader
-. Funding
-. Scheduling
-. Tracking

What are You Building?
> "I'm cutting stones."
> "I'm earning a living."
> "I'm building a cathedral."

Cathedral Builders
> Move responsibility and decision-making to the lowest possible level.

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

If you have any interests in above keywords I extracted, then it is worth watching this 1 and half hours video.

If someone ask you "What are you doing as a software engineer?", then what will be your response?

"I'm typing keyboard to do a programming.", "I'm doing my programming job to earn money to live."

Or "I'm developing great software helping people do their work faster and more efficiently."

오늘 인도 개발자가 만든 소스를 수정할 일이 생겨서 보다가 기절하는 줄 알았다... ㅠ.ㅠ

If-Else의 사용에 대해서는 사실 이미 많은 토론이 오고 간 주제이고 이해하고 있었는데, 실제로 이렇게 만나게 될 줄이야...

다음의 영문 사이트를 참고하면 왜 If-Else가 code smell인지 이해할 수 있다.

Else Considered Smelly

요약하자면, 다음과 같은 If-Else문을 사용할 경우 3가지 code smell에 대해서 조심을 해야 한다.

if (condition()) {

ifBlock();

}

else {

elseBlock();

}

1. 첫번째 smell

condition()에 해당하는 조건문이 길어져서 복잡해지면, else인 경우를 찾는것이 두배로 복잡해 진다. 왜냐하면, 이미 너무 복잡해진 condition() 조건문을 반대로 생각해야 하기 때문이다.

2. 두번째 smell

ifBlock()에 해당되는 부분이 개발자가 보고 이해하기 힘들 정도로 길어지면, condition() 즉 조건이 무엇이었는지 기억하기가 어렵다. 오늘 내가 만난 경우 ifBlock()이 200 라인을 넘어갔다. ㅠ.ㅠ

3.  세번째 smell

중첩 If-Else를 사용하게 되면 문제는 더욱 더 복잡해 진다. 오늘 내가 만난 소스 코드는 If-Else를 무려 3번이나 중첩해서 사용했다. 데이터베이스 레코드가 많아질수록 처리 시간이 점점 더 늘어나는 원인이 무엇인지 대충은 예상했는데, 중첩으로 사용된 If-Else 안에서 심지어 for() 루프도  중첩해서 사용했다.

하지만 사실 이 smell들은 조금만 신경쓰면 충분히 방지할 수 있다. 여러가지 해결책들이 존재하지만 몇 가지만 알아보자면 다음과 같다.

1. Decompose Conditional

condition()에 해당하는 조건들은 최대한 간단하게 만들고, 직관적으로 만든다. 직관적이라는 부분에는 notSummer 라는 조건 대신 isSummer라는 조건을 사용하는 것이다. 얼핏 보면 비슷해 보이지만, else로 넘어갈 경우 차이를 느낄 수 있다. 전자의 경우 "여름이 아니면"의 else는 "여름이 아니면의 아니면"이 되고, 후자처럼 사용한다면 "여름이면"의 else는 "여름이 아니면"된다. 간단해 보이지만 복잡한 로직을 처리해야할 경우 큰 차이를 느낄 수 있을 것이다. Decompose Conditional 이라는 이름으로 알려져 있다.

2. Extract Method

두말할 필요도 없이 메소드를 꺼내서 코드를 읽기 쉽게 만들어야 한다. Extract Method로 이미 널리 알려져 있다. 이건 정말 꼭 해야 한다.

개인적으로는 제발 좀 자기 코드에 대해서 *고민*을 했으면 좋겠다. 당장 돌아가고 실행되는 코드가 아니라, "다음에 내가 다시 사용하게 된다면?"라는 고민을 조금만이라도 해도 이렇게 코드를 만들지는 않을텐데...