리펑토링(Refuctoring)

Java 2009. 3. 5. 19:57

  • Common sense naming conventions
  • Cohesive and loosely coupled modules
  • Elegant abstractions
  • Lack of duplication
  • A close resemblance to the application domain

'고먼'이 말하는 리펙토링
- 변수, 메소드, 객체의 이름을 상식에 근거해서 붙이기
- 내부로는 강한 결합, 외부로는 유연한 모듈
- 우아한 추상화(elegant abstractions)
- 중복의 부재(lack of redundancy)
- 어플과 도메인과의 밀접한 관련성

'고먼'이 말하는 리펑토링
- '잘 설계된 코드를 작고 가역적인(reversible) 변화를 연속적으로 도입해서 자기 자신을 제외한 그 어느 누구도 관리할 수 없게 만드는 과정'
- 이름 제멋대로 붙이기
- 보물찾기(Treasure Hunt) : 코드가 간단하고 자체적으로 완결된 방식 구성이 아닌, 주로 다른 코드에 대한 참조로 이루어지는 경우.
- 객체지향적인 설계를 수행하여 상속(inheritance), 위임(delegation), 프록시(proxy)와 같은 개념 적용하다 보면 어느 객체가 수행하는 간단한 업무가 실제로 어디에서 이루어지는지 알기 어려운 경우가 생긴다.
- 객체지향의 근본사항은 코드의 관리를 쉽게 하는 것에 있지 추상 계층을 도입해 코드 이해를 어렵게 만드는 것이 아니다.
-  '자기만의 모델링 언어 사용' 워드나, 파워포인트로 그리지 말고 UML쓰자.
- 너무나 명백한 사실을 상세히 설명하지 말라. 주석은 상식선에서 쓰자.
- '비오는 날을 위한 시나리오' 일어나지도 않을 코드를 열심이 작업하지 말라.
- '모듈의 중력장(Module Gravity Well) 오만가지 잡동사니를 전부 한 곳으로 끌어들이는 객체를 만들지 말라. 모듈의 내부로는 응집력이 있어야 한다.(응집력 상승=버그 최소화)

직업 안정도(Job security index) = 1 / 코드 관리의 용이성 (Maintainability)
윗말을 고지고때로 믿지말라;; 역설적 표현이다.


refer to 
'프로그래밍은 상상이다'-임백준
저작자표시
Posted by 빈솔B
,

프로그래밍시 좋은 습관

카테고리 없음 2009. 3. 5. 19:26

If anythong can go wrong, it will (뭔가 잘못될 수 있다면 반드시 일어난다.)


1. 방어적 프로그래밍
프로그래머는 기본적으로 눈 앞에 있는 모든 것을 의심해야 한다.
자신이 작성한 메쏘드에 입력되는 인수가 혹시 null은 아닌지, 
적정한 범위를 벗어나는 값은 어닌지,
리스트에 포함된 객체가 혹시 엉뚱한 객체의 타입은 아닌지 등을 확인하고 점검하고, 검증하는 것
방어적 프로그래밍의 원리는 알고리즘의 복잡성을 최소화 하라.
Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software in spite of unforeseeable usage of said software. The idea can be viewed as reducing or eliminating the prospect of Murphy's Law having effect. Defensive programming techniques are used especially when a piece of software could be misused mischievously or inadvertently to catastrophic effect. -위키피디아

2. 성능과 확장성을 염두에 두기
일단은 요구사항대로 동작하는 프로그램을 작성하라. 성능 최적화는 제일 나중에 할일이다.
단, 성능 최적화를 신경쓰지 말라는 얘기가 아니라 개발 초기에는 소스트웨어 성능 최적화에 많은 시간을 할애하지 말라는 얘기다. 예로, '게으른 초기화(lazy initialization)', 
아무곳에서나 맘대로 쓰레드 생성 vs 쓰레드 풀 사용

3. if-else 구문 사용하지 않기
if-else 구문을 아예사용하지 말라는 얘기는 아니고, 하나의 알고리즘에 서로 다른 성격의 기능을 수행하게 강제시키기 위하 if-else를 사용하지 말라는 얘기이다.
단기적으로는 개발이 편할지 모르나 결국 코드의 복잡성을 높혀서 관리가 어려워지고, 버그 가능성도 높아지고 프로그래머 지능을 낮게 만든다.
if-else 대신 새로운 메소드나 객체를 만들라.

- 버그의 '수'에 집착하지 말고 '성격'을 따져보는 습관을 가지자
- 프로그래머가 버그를 만들어내는 것은 모르고 그러는 것 보다 알고 그러는 경우가 더 많다.
- 당장의 눈앞의 기능을 만드는데 급급하기 때문에 스스로 타협하고 자신만의 규칙을 만들어낸다.
- 방어적 프로그래밍은 지금 이 순간 한줄의 코드를 작성하면서도 감각적으로 적용되어야 하며 그 순간이 지나고 나면 그 코드로 다시 돌아갈 수 있는 경우란 없다. 순간에 대한 집중력, 그것이 방어적 프로그래밍이 필요로 하는 것이다.

- 프로그래밍은 '소설가' 이다. 혼자 읽기 위한 소설은 없듯이 남이 읽기 위한 코드가 되어야 한다. 프로그래머는 현학적이면 안된다.



refer to '프로그래밍은 상상이다-임백준'

저작자표시
Posted by 빈솔B
,

Agile manifesto 애자일 선언

카테고리 없음 2009. 2. 25. 13:51
극단적 프로그래밍, 스크럼(SCRUM), DSDM, 유연한 소프트웨어 개발(Adaptive Software Development), 크리스털(Crystal), 기능중심개발(Feature-Driven Development), 실용적 프로그래밍(Pragmatic Programming) 등..
Individuals and interactions over processes and tools 
프로세스와 도구보다는 개인과의 상호작용

Working software over comprehensive documentation 
철저한 문서보다는 동작하는 소프트웨어
Customer collaboration over contract negotiation
계약 협상보다는 고객과의 협동
Responding to change over following a plan 
계획을 따르는 것보다는 변화에 응답하는 것


Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
우리의 최고의 우선순위는 유용한 소프트웨어의 쉽고 지속적인 공급을 통한 소비자 만족이다.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
심지어 개발이 늦어진다해도 요구의 변경을 환영하라. 애자일 프로세스는 사용자의 경쟁우위를 위한 변화를 이용한다.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
정상적으로 동작하는 소프트웨어를 몇 주에서 몇 달에 이르는 간격으로 자주 전달하라. 간격은 짧을 수록 좋다.

Business people and developers must work together daily throughout the project.
비즈니스와 관련된 사람과 계발자는 프로젝트 기간 동안 반드시 매일 함께 일을 해야한다. 
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
동기부여가 확실한 개인을 중심으로 프로젝트를 구축하라. 그런 개인에게 필요한 환경과 지원을 해주고 그들이 업무를 완수할 것이라는 확신을 가져라.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
개발 팀간에 또는 팀 내부에서 정보를 전달하는 가장 확실하고 효과적인 방법은 얼굴을 마주보고 나누는 대화이다.
Working software is the primary measure of progress.
정상적으로 동작하는 소프트웨어가 프로젝트의 진척을 재는 가장 정확한 척도이다.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
애자일 프로세스는 지원이 가능한 개발을 장려한다. 후원자, 개발자, 그리고 사용자는 일정한 호흡을 무한히 유지할 수 있는 능력을 갖추어야 한다.
Continuous attention to technical excellence and good design enhances agility.
기술적인 탁월함과 좋은 디자인에 대한 지속적인 관심은 민첩성을 강화한다.
Simplicity--the art of maximizing the amount of work not done--is essential.
하지않아도 되는 일의 분량을 극대화하는 기술을 의미하는 단순성을 필수이다.
The best architectures, requirements, and designs emerge from self-organizing teams.
최선의 아키텍쳐, 요구사항, 그리고 디자인은 자발적으로 조직된 팀으로부터 나온다.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
팀은 일정한 간격으로 더 효율적일 수 있는 방법을 고찰하고, 스스로의 행동을 조정하는 과정을 밟아야 한다.

refer to
번역: 프로그래밍은 상상이다-임백준

저작자표시
Posted by 빈솔B
,

Finger-Pointing(손가락질)

카테고리 없음 2009. 2. 25. 11:27
서로에게 책임전가를 위한 격렬한 논쟁

- 프로젝트 진행시 QA팀과의 원만한 관계유지는 extreme programming의 필수조건
- 비즈니스 분석가와 합의된 요구수정사항이 문서에 반영되지 않은 채 QA팀으로 넘어갈 때 테스트 시간 낭비, 코드 안정성에 대한 불필요한 소음 생김, 개발자와 QA팀간의 불신관계 형성됨.
- 위와 같은 상황에서 상세하게 설명할 책임이 있는 것은 개발자 자신이다!!!!
- 모든 것이 문서화에 치중된 프로젝트는 융통성 있는 대화를 가로 막기때문에 건강하지도 않고 빠르게 변하는 시장의 요구사항을 탄력적으로 수용할 수도 없다. so QA팀과의 관계 중요!


refer to 프로그래밍은 상상이다 -임백준 지음
저작자표시
Posted by 빈솔B
,

나쁜코드가 미치는 영향

RareItem 2009. 2. 25. 11:11
두 가지 근본 문제를 내포한다. 
1. 프로그래머가 자신이 작성한 코드가 어떤 상황에도 정상 동적할 것이라는 확신을 가지지 못함
2. 해당 코드를 수정해야 될때 프로그래머는 일종의 정신적 공황상태에 빠지기 쉽다. 어떻게 코딩한지 기억이 잘 나지 않는다;;

- 버그를 논리지거은 절차에 따라 해결하지 않고 프로그램의 엔트로피와 복잡성을 기하급수적으로 중대시키는 최악의 해결책을 선택하지 말아야 한다.
- 프로시저적 접근 방식을 사용하는 프로그래머들은 대개 자신의 코드를 이미 존재하는 코드의 골격에 맞추지만, 객체지향 접근방식이 몸에 밴 프로그래머는 거꾸로 원래 존재하는 코드를 새로운 코드가 존재하는 이상적인 방식에 맞춘다.
- 리펙토링(Refactoring) : 다양한 디자인 패턴을 구사해서 객체의 관련성을 수정하고, 불필요하게 중복된 코드를 한 곳으로 모으로, 이해하기 힘든 코드를 간명한 코드로 재작성하고, 객체의 계층관계를 단순화 하는 등, 새로운 기능이 자리를 잡을 장소의 주변을 깔끔하게 청소하는 작업
- but.. 리펙토링 전에 반드시!! 유닛테스트 코드 있어야한다.

저작자표시
Posted by 빈솔B
,

코딩하기 전의 절차

RareItem 2009. 2. 25. 10:56
새로운 프로젝트 실행시

1. 요구사항 소화
- 복잡하고 까다로운 요구사항이 End User에게 미치는 영향은?
- 시스템 설계 전반에 미치는 영향은 무엇?
- 구현 가능한가?
- 요구사항에 담긴 내용은 최종목적에 부합하는가?
- 빠진 내용 없나?
- 서로 모순되는 요구사항은 없나?
- 그것으로 인한 보안, 성능, 확장가능성 등에 미치는 부정적 영향은 없나?

2. 약간의 코딩
- 필요시 새로운 코드의 얼개를 바로 코딩하는 것도 좋다.
얼개 [명사] 어떤 사물이나 조직의 전체를 이루는 짜임새나 구조. - 다음사전

3. 종이와 연필로 그림 그리기
- 전체적인 시스템 모습 스케치
- 객체를 동그란 원으로
- 관계 나타내는 선
- 기억해야 할 것은 작은 글씨로 표시

4. 인터뷰
- 새로운 기능이 다른 기존의 객체나 검포넌트를 다루고 있는 프로그래머에게 인터뷰함.
- 모르는것은 질문으로 확인, 아이디어는 동의를 구함, 더 나은 제안은 경청 및 메모
- 인터뷰를 토대로 이미 작성한 코드 개요 있으면 수정

5. 그림을 비트의 세계로 옮기기. UML을 사용하면 추가 점수.
- 객체 관련성을 도표로 표현하는데 사용하는 UML은 보조도구을 뿐임을 명심. 너무 많은 시간을 할애하지 말자.

6. 그림과 약간의 설명을 담은 문서를 작성하기
- 스케치한 걸 저장이 필요할때, 복잡하고 작업 범위가 넓은 기능 구현시에는 UML로 정리하도록 한다. 
- 마지막으로 발표(publish) 위한 자료 수집.
- 새로운 기능 구현이 갖는 개략적 방향, 방법론
- 시스템내에 영향을 받는 부분, 문제점과 해결책, 인터뷰통해 수집한 질문과 제안을 문서화
- 문서화에 또 너무 많은 시간을 투자하지 말자.

7. 공동의 검토
- 설계검토(design review) 
- 참석자들은 논의 내용을 충분히 숙지한 사람만 참여시키도록, 괜히 설명하느라 시간낭비가 될 수 있다. 


디버깅시
1. 요구사항 혹은 버거의 내용파악
2. 코딩시작

저자는 '코딩'과 '설계'를 굳이 구분할 필요가 없는 자연스러운 행위가 되어야 한다고 보고있다.


refer to 프로그래밍은 상상이다. -임백준 지음
저작자표시
Posted by 빈솔B
,

컨플루언스(confluence)

RareItem 2009. 2. 25. 10:34
'합류, 합치, 생각의 일치'라는 의미하는 위키(wiki) 기업용 소프트웨어이다.
저작자표시
Posted by 빈솔B
,

Visual Paradigm

RareItem 2009. 2. 25. 10:14
파워포인트 비지오(visio)와 같은 UML 작성 프로그램이다. 
저작자표시
Posted by 빈솔B
,

AOP(Aspect Oriented Programming)

카테고리 없음 2009. 2. 24. 13:48
저자는 AOP를 기존의 관점지향프로그래밍이라기 보단 상황중심프로그래밍으로 해석하고 있다. AOP에서 사용하는 개념은 크게 4가지가 있다. 점점(pointcut), 안내(advice), 내부타입선언(inter type declaration), 그리고 이들을 모두 묶어서 하나의 단위로 추상화하는 상황(aspect)가 있다. 

접점(pointcut)은 공통의 관심사가 여러 개의 객체나 계층을 가로지를 때 그들과 만나게 되는 지점을 의미한다.
접점을 골라낸 후 할일을 정의하는 것이 안내(advice)이다. 객체지향의 메소드라고 생각하면 된다. 접점 전후로 해야 할일을 정의하는 알고리즘이 주 내용을 이룬다. 내부타입정의(inter type declaration)는 OOP와 달리 객체에 새로운 필드를 동적으로 더하는 것을 가능하게 만든다. 마지막으로, OOP에서 클래스가 변수와 메소드를 한곳에 묶어서 하나의 객체로 추상화하듯, AOP에서 사용되는 접점, 안내, 내부타입정의를 한 곳에 묶어서 추상화한 것을 상황(aspect)라고 한다. 

저자는 AOP는 OOP를 대체할만한 방법론은 아닌 단지 '보완적' 방법론으로 보고 있다.


이클립스를 통한 예제 구현
먼저 AspectJ 플러그인이 설치 되어있지 않으면 설치합니다. Eclipse -> help -> Software Update - find and install 주소는 아래와 같습니다. (그리고 eclipse 버전별로 설치주소 차이가 있습니다. )
이클립스 3.2버전경우 : http://download.eclipse.org/tools/ajdt/32/update
3.3버전경우 : http://download.eclipse.org/tools/ajdt/33/update
3.4버전경우 : http://download.eclipse.org/tools/ajdt/34/update
* 자세한 사항은 다운로드 페이지를 참조하세요 http://www.eclipse.org/ajdt/downloads/

제경우엔 eclipse_gany3.4, AJDT1.6 으로 테스트 했습니다. 프로젝트는 AspectJ prj로 생성해야하며, GreetingAspect.aj 는 aj 클래스로 만들어야 합니다.

[GreetingAspect.aj]
public aspect GreetingAspect {
pointcut callSayMessage() : call(public static void say*(..));
before():callSayMessage() {
System.out.println("Good bye");
}
after():callSayMessage() {
System.out.println("Thank you!");
}
}
[HellowWorld.java] [HiWorld.java]
public class HelloWorld {
public static void say(String msg) {
System.out.println(msg);
}
public static void sayToPerson(String msg, String name) {
System.out.println(name + ", " + msg);
}
}


public class HiWorld {
public static void sayToYou(String msg) {
System.out.println(msg);
}
public static void sayToAnimal(String msg, String name){
System.out.println(name + ", " + msg);
}
}


[Test.java]
public class Test {
public static void main(String[] args) {
// TODO Auto-generated method stub
HelloWorld.say("Let's learn AOP");
HelloWorld.sayToPerson("Let's learn AOP", "Andrew");
HiWorld.sayToYou("Let's learn everything!");
HiWorld.sayToAnimal("Let's learn how to bark", "yoki");
}
}

저작자표시
Posted by 빈솔B
,

매달 프로그래밍 언어순위

RareItem 2009. 2. 24. 11:51
TIOBE 인덱스
순위 산출 방법은 해당 언어가 구글,msn,야후, 유투브 등의 검색엔진에서 검색되는 빈도를 측정한 값을 중심으로 순위를 매김, 검색수가 아닌 상대적인 값이다.(시작은 2001년부터)
저작자표시
Posted by 빈솔B
,

티스토리툴바