모과이의꿈

• Extract Method(136) - 그룹으로 함께 묶을 수 있는 코드 조각이 있으면, 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드로 뽑아낸다.
• Inline Method(144) - 메소드 몸체가 메소드의 이름 만큼이나 명확할 때는, 호출하는 곳에 메소드의 몸체를 넣고, 메소드를 삭제하라.
  
• Inline Temp(146) - 간단한 수식의 결과값을 가지는 임시변수가 있고, 그 임시변수가 다른 리팩토링을 하는데 방해가 된다면, 이 임시변수를 참조하는 부분을 모두 원래의 수식으로 바꾸라.
  
• Replace Temp with Query(147) - 어떤 수식의 결과값을 저장하기 위해서 임시변수를 사용하고 있다면, 수식을 뽑아내서 메소드로 만들고, 임시변수를 참조하는 곳을 찾아 모두 메소드 호출로 바꾼다. 새로 만든 메소드는 다른 메소드에서도 사용될 수 있다.
  
• Introduce Explaining Variable(151) - 복잡한 수식이 있는 경우에는, 수식의 결과나 또는 수식의 일부에 자신의 목적을 잘 설명하는 이름으로 된 임시변수를 사용하라.
  
• Split Temporary Variable(155) - 루프 안에 있는 변수나 collecting temporary variable도 아닌 임시변수에 값을 여러 번 대입하는 경우에는, 각각의 대입에 대해서 따로따로 임시변수를 만들어라.
  
• Remove Assignments to Parameters(159) - 파라미터에 값을 대입하는 코드가 있으면, 대신 임시변수를 사용하도록 하라.
  
• Replace Method with Method Object(163) - 긴 메소드가 있는데, 지역변수 때문에 Extract Method를 적용할 수 없는 경우에는, 메소드를 그 자신을 위한 객체로 바꿔서 모든 지역변수가 그 객체의 필드가 되도록 한다. 이렇게 하면 메소드를 같은 객체 안의 여러 메소드로 분해할 수 있다.
  
• Substitute Algorithm(167) - 알고리즘을 보다 명확한 것으로 바꾸고 싶을 때는, 메소드의 몸체를 새로운 알고리즘으로 바꾼다.
  

• Move Method(170) - 메소드가 자신이 정의된 클래스보다 다를 클래스의 기능을 더 많이 사용하고 있다면, 이 메소드를 가장 많이 사용하고 있는 클래스에 비슷한 몸체를 가진 새로운 메소드를 만들어라. 그리고 이전 메소드는 간단한 위임으로 바꾸거나 완전히 제거하라.
  
• Move Field(175) - 필드가 자신이 정의된 클래스보다 다른 클래스에 의해서 더 많이 사용되고 있다면, 타겟 클래스(target class)에 새로운 필드를 만들고 기존 필드를 사용하고 있는 모든 부분을 변경하라.
  
• Extract Class(179) - 두 개의 클래스가 해야 할 일을 하나의 클래스가 하고 있는 경우, 새로운 클래스를 만들어서 관련 있는 필드와 메소드를 예전 클래스에서 새로운 클래스로 옮겨라.
  
• Inline Class(184) - 클래스가 하는 일이 많지 않은 경우에는, 그 클래스에 있는 모든 변수와 메소드를 다른 클래스로 옮기고 그 클래스를 제거하라.
  
• Hide Delegate(187) - 클라이언트가 객체의 위임 클래스를 직접 호출하고 있는 경우, 서버에 메소드를 만들어서 대리객체(delegate)를 숨겨라.
  
• Remove Middle Man(191) - 클래스가 간단한 위임을 너무 많이 하고 있는 경우에는, 클라이언트가 대리객체(delegate)를 직접 호출하도록 하라.
  
• Introduce Foreign Method(194) - 사용하고 있는 서버 클래스에 부가적인 메소드가 필요하지만 클래스를 수정할 수 없는 경우에는, 첫 번째 인자로 서버 클래스의 인스턴스를 받는 메소드를 클라이언트에 만들어라.
  
• Introduce Local Extension(196) - 사용하고 있는 서버 클래스에 여러 개의 메소드를 추가할 필요가 있지만 서버 클래스를 수정할 수 없는 경우, 필요한 추가 메소드를 포함하는 새로운 클래스를 만들어라. 이 확장 클래스를 원래 클래스의 서브클래스 또는 래퍼(wrapper) 클래스로 만들어라.
  

• Self Encapsulate Field(205) - 필드에 직접 접근하고 있는데 필드에 대한 결합이 이상해지면, 그 필드에 대한 get/set 메소드를 만들고 항상 이 메소드를 사용하여 필드에 접근하라.
  
• Replace Data Value with Object(209) - 추가적인 데이터나 동작을 필요로 하는 데이터 아이템이 있을 때는, 데이터 아이템을 객체로 바꾸어라.
  
• Change Value to Reference(213) - 동일한 인스턴스를 여러 개 가지고 있는 클래스가 있고 여러 개의 동일한 인스턴스를 하나의 객체로 바꾸고 싶으면, 그 객체를 참조 객체로 바꾸어라.
  
• Change Reference to Value(217) - 작고, 불변성(immutable)이고, 관리하기가 어려운 참조 객체(reference object)가 있는 경우, 그것을 값 객체(value object)로 바꾸어라.
  
• Replace Array with Object(220) - 배열의 특정 요소가 다른 뜻을 가지고 있다면, 배열을 각각의 요소에 대한 필드를 가지는 객체로 바꿔라.
  
• Duplicate Observed Data(224) - GUI 컨트롤에서만 사용 가능한 도메인 데이터가 있고, 도메인 메소드에서 접근이 필요한 경우, 그 데이터를 도메인 객체로 복사하고, 옵저버(observer)를 두어 두 데이터를 동기화하라.
  
• Change Unidirectional Association to Bidirectional(232) - 각각 서로의 기능을 필요로 하는 클래스가 있는데, 링크가 한쪽 방향으로만 되어 있는 경우, 반대 방향으로 포인터를 추가하고, 수정자(modifier)가 양쪽 세트(set)를 모두 업데이트 하게 변경하라.
  
• Change Bidirectional Association to Unidirectional(236) - 서로 링크를 가지는 두 개의 클래스에서 한 쪽이 다른 한쪽을 더 이상 필요로 하지 않을 때는 불필요한 링크를 제거하라.
  
• Replace Magic Number with Symbolic Constant(240) - 특별한 의미를 가지는 숫자 리터럴이 있으면, 상수를 만들고, 의미를 잘 나타내도록 이름을 지은 다음, 숫자를 상수로 바꾸어라.
  
• Encapsulate Field(242) - public 필드가 있는 경우, 그 필드를 private으로 만들고, 접근자를 제공하라.
  
• Encapsulate Collection(244) - 컬렉션(Collection)을 리턴하는 메소드가 있으면, 그 메소드가 읽기전용 뷰(read-only view)를 리턴하도록 만들고, add/remove 메소드를 제공하라.
  
• Replace Record with Data Class(254) - 전통적인 프로그래밍 환경에서의 레코드 구조에 대한 인터페이스가 필요한 경우, 그 레코드를 위한 데이터 객체를 만들어라.
  
• Replace Type Code with Class(255) - 클래스의 동작에 영향을 미치지 않는 숫자로 된 타입 코드(numeric type code)가 있으면, 숫자를 클래스로 바꾸어라.
  
• Replace Type Code with Subclass(261) - 클래스의 동작에 영향을 미치는 변경 불가능한(immutable) 타입 코드가 있다면, 타입 코드를 서브클래스로 바꾸어라.
  
• Replace Type Code with State/Strategy(265) - 클래스의 동작에 영향을 미치는 타입 코드가 있지만 서브클래싱을 할 수 없을 때는, 타입 코드를 스테이트(State) 객체로 바꾸어라.
  
• Replace Subclass with Fields(270) - 상수 데이터를 리턴하는 메소드만 다른 서브클래스가 있으면, 그 메소드를 수퍼클래스의 필드로 바꾸고 서브클래스를 제거하라.
  

• Decompose Conditional(276) - 복잡한 조건문(if-then-else)이 있는 경우, 조건, then 부분, 그리고 else 부분에서 메소드를 추출하라.
  
• Consolidate Conditional Expression(278) - 같은 결과를 초래하는 일련의 조건 테스트가 있는 경우, 그것을 하나의 조건 식으로 결합하여 뽑아내라.
  
• Consolidate Duplicate Conditional Fragments(281) - 동일한 코드 조각이 조건문의 모든 분기 안에 있는 경우, 동일한 코드를 조건문 밖으로 옮겨라.
  
• Remove Control Flag(283) - 일련의 boolean 식에서 컨트롤 플래그 역할을 하는 변수가 있는 경우, break 또는 return 을 대신 사용하라.
  
• Replace Nested Conditional with Guard Clauses(288) - 메소드가 정상적인 실행 경로를 불명확하게 하는 조건 동작을 가지고 있는 경우, 모든 특별한 경우에 대해서 보호절(guard clause)을 사용하라.
  
• Replace Conditional with Polymorphism(293) - 객체의 타입에 따라 다른 동작을 선택하는 조건문을 가지고 있는 경우, 조건문의 각 부분을 서브클래스에 있는 오버라이딩 메소드로 옮겨라. 그리고 원래 메소드를 abstract로 만들어라.
  
• Introduce Null Object(298) - null 체크를 반복적으로 하고 있다면, null 값을 null 객체로 대체하라.
  
• Introduce Assertion(306) - 코드의 한 부분이 프로그램의 상태에 대하여 어떤 것을 가정하고 있으면, assertion을 써서 가정을 명시되게(explicit) 만들어라.
  

• Rename Method(313) - 메소드의 이름이 그 목적을 드러내지 못하고 있다면 메소드의 이름을 바꿔라.
  
• Add Parameter(316) - 어떤 메소드가 그 메소드를 호출하는 부분에서 더 많은 정보를 필요로 한다면, 이 정보를 넘길 수 있는 객체에 대한 파라미터를 추가하라.
  
• Remove Parameter(318) - 파라미터가 메소드 몸체에서 더 이상 사용되지 않는다면, 그 파라미터를 제거하라.
  
• Separate Query from Modifier(320) - 값을 리턴할 뿐만 아니라 객체의 상태도 변경하는 메소드를 가지고 있는 경우, 두 개의 메소드를 만들어서 하나는 값을 리턴하는 역할을 하고, 하나는 객체의 상태를 변경하는 역할을 하게 하라.
  
• Parameterize Method(325) - 몇몇 메소드가 메소드 몸체에 다른 값을 포함하고 있는 것을 제외하고는 비슷한 일을 하고 있다면, 다른 값을 파라미터로 넘겨 받는 하나의 메소드를 만들어라.
  
• Replace Parameter with Explicit Methods(327) - 파라미터의 값에 따라서 다른 코드를 실행하는 메소드가 있다면, 각각의 파라미터 값에 대한 별도의 메소드를 만들어라.
  
• Preserve Whole Object(331) - 어떤 객체에서 여러 개의 값을 얻은 다음 메소드를 호출하면서 파라미터로 넘기고 있다면, 대신 그 객체를 파라미터로 넘겨라.
  
• Replace Parameter with Method(335) - 객체가 메소드를 호출한 다음, 결과를 다른 메소드에 대한 파라미터로 넘기고 있다. 수신자(Receiver - 파라미터를 넘겨 받는 메소드) 또한 이 메소드를 호출할 수 있다면, 그 파라미터를 제거하고 수신자가 그 메소드를 호출하도록 하라.
  
• Introduce Parameter Object(339) - 자연스럽게 몰려다니는 파라미터 그룹을 가지고 있다면, 그것들을 객체로 바꾸어라.
  
• Remove Setting Method(344) - 어떤 필드가 객체 생성시에 값이 정해지고 그 이후에는 변경되지 않아야 한다면, 그 필드 값을 설정하는 모든 메소드를 제거하라.
  
• Hide Method(348) - 메소드가 다른 클래스에서 사용되지 않는다면, 그 메소드를 private으로 만들어라.
  
• Replace Constructor with Factory Method(350) - 객체를 생성할 때 단순히 생성하는 것 이외에 다른 작업도 하고 있다면, 생성자를 팩토리 메소드로 대체하라.
  
• Encapsulate Downcast(355) - 메소드가 그 호출부에서 다운캐스트(downcast) 될 필요가 있는 객체를 리턴하고 있다면, 다운캐스트 하는 것을 메소드 안으로 옮겨라.
  
• Replace Error Code with Exception(357) - 메소드가 에러를 나타내는 특별한 코드를 가지고 있다면, 대신 예외를 던져라.
  
• Replace Exception with Test(363) - 호출부에서 먼저 검사할 수 있는 조건에 대해 예외를 던지고 있다면, 호출부가 먼저 검사하도록 바꿔라.
  

• Pull Up Field(368) - 두 서브클래스가 동일한 필드를 가지고 있다면, 그 필드를 수퍼클래스로 옮겨라.
  
• Pull Up Method(370) - 동일한 일을 하는 메소드를 여러 서브클래스에서 가지고 있다면, 이 메소드를 수퍼클래스로 옮겨라.
  
• Pull Up Constructor Body(373) - 서브클래스들이 대부분 동일한 몸체를 가진 생성자를 가지고 있다면, 수퍼클래스에 생성자를 만들고 서브클래스 메소드에서 이것을 호출하라.
  
• Push Down Method(376) - 수퍼클래스에 있는 동작이 서브클래스 중 일부에만 관련되어 있다면, 그 동작을 관련된 서브클래스로 옮겨라.
  
• Push Down Field(377) - 어떤 필드가 일부 서브클래스에 의해서만 사용되고 있다면, 그 필드를 관련된 서브클래스로 옮겨라.
  
• Extract Subclass(378) - 어떤 클래스가 일부 인스턴스에 의해서만 사용되는 기능을 가지고 있다면, 기능의 부분집합을 담당하는 서브클래스를 만들어라.
  
• Extract Superclass(384) - 비슷한 메소드와 필드를 가진 두 개의 클래스가 있다면, 수퍼클래스를 만들어서 공통된 메소드와 필드를 수퍼클래스로 옮겨라.
  
• Extract Interface(389) - 여러 클라이언트가 한 클래스 인터페이스의 동일한 부분 집합을 사용하고 있거나, 두 클래스가 공통된 인터페이스를 가지는 부분이 있다면, 그 부분 집합을 인터페이스로 뽑아내라.
  
• Collapse Hierarchy(392) - 수퍼클래스와 서브클래스가 별로 다르지 않다면, 그것들을 하나로 합쳐라.
  
• Form Template Method(393) - 각각의 서브클래스에, 동일한 순서로 비슷한 단계를 행하지만 단계가 완전히 같지는 않은 두 메소드가 있다면, 그 단계를 동일한 시그니처를 가진 메소드로 만들어라. 이렇게 하면 원래의 두 메소드는 서로 같아지므로, 수퍼클래스로 올릴 수 있다.
  
• Replace Inheritance with Delegation(401) - 서브클래스가 수퍼클래스 인터페이스의 일부분만 사용하거나 또는 데이터를 상속 받고 싶지 않은 경우, 수퍼클래스를 위한 필드를 만들고 메소드들이 수퍼클래스에 위임하도록 변경한 후 상속 관계를 제거한다.
  
• Replace Delegation with Inheritance(404) - 위임을 사용하고 있는데, 전체 인터페이스에 대해 간단한 위임을 자주 작성하고 있다면, 위임하는 클래스를 대리객체의 서브클래스로 만들어라.
  

• Tease Apart Inheritance(410) - 두 가지 작업을 한번에 처리하는 상속 구조가 있는 경우, 두개의 상속 구조를 만들고 하나가 다른 하나를 호출하도록 위임을 사용하라.
  
• Convert Procedural Design To Objects(416) - 절차적 스타일로 작성된 코드가 있다면, 데이터 레코드를 객체로 바꾸고, 동작을 쪼개서 객체로 옮겨라.
  
• Separate Domain from Presentation(418) - 도메인 로직을 포함하고 있는 GUI 클래스를 가지고 있다면, 도메인 로직을 분리하여 도메인 클래스를 만들어라.
  
• Extract Hierarchy(423) - 너무 많은 작업을 하거나 또는 부분적으로라도 많은 조건문이 있는 클래스에 대해서는, 각각의 서브클래스가 특정 작업을 담당하도록 클래스의 상속 구조를 만들어라.

추상 팩토리 패턴
서로 연관된 또는 의존적인 객체들로 이루어진 제품군을 생성하기 위한
인터페이스를 제공한다. 구상 클래스는 서브 클래스에 의해 만들어진다.

추상 팩토리 패턴 예제
#include <iostream>
#include <fstream>
#include <string>
#include <vector>

using namespace::std;

class CAudio
{
public:
 virtual void Run() = 0;
};

class CWindowAudio : public CAudio
{
public:
 virtual void Run()
 {
  cout << "Window Audio Run" << endl;
 }
};

class CUnixAudio : public CAudio
{
public:
 virtual void Run()
 {
  cout << "Unix Audio Run" << endl;
 }
};

class CVideo
{
public:
 virtual void Run() = 0;
};

class CWindowVideo : public CVideo
{
public:
 virtual void Run()
 {
  cout << "Window Video Run" << endl;
 }
};

class CUnixVideo : public CVideo
{
public:
 virtual void Run()
 {
  cout << "Unix Video Run" << endl;
 }
};

class COSFactory
{
public:
 virtual CAudio* CreateAudio() = 0;
 virtual CVideo* CreateVideo() = 0;
};

class CWindowFactory : public COSFactory
{
public:
 virtual CAudio* CreateAudio(){ return new CWindowAudio; }
 virtual CVideo* CreateVideo(){ return new CWindowVideo; }
};

class CUnixFactory : public COSFactory
{
public:
 virtual CAudio* CreateAudio(){ return new CUnixAudio; }
 virtual CVideo* CreateVideo(){ return new CUnixVideo; }
};

void main()
{
 COSFactory* pOSFactory = new CWindowFactory;

 CVideo* pVideo = pOSFactory->CreateVideo();
 CAudio* pAudio = pOSFactory->CreateAudio();

 pVideo->Run();
 pAudio->Run();

 delete pVideo;
 delete pAudio;

 delete pOSFactory;
}

==========================================================================================================

코딩 스타일의 상식을 박살 내라

서두

엔지니어 여러분은 평상시 다양한 상식에 사로 잡히고 있지 않습니까? 그러한 상식의 상당수는 믿음이며 당신의 능력이나 생산성을 방해하는 요인이 되고 있습니다. 이 연재에서는 고정 관념을 깨어, 유저 시점에서 고품질의 일을 해내는 「리얼 엔지니어」으로 한 걸음을 내디디는 아이디어 여러 가지를 소개합니다.

빠져 나가라! 영문법의 속박

베테랑일수록 「그래, 이러한 것」적인 미를 고집하는 것 같습니다.

예를 들면 프로그램 언어는 영어를 기조로 하고 있습니다.「영문법을 의식하는 것이 아름답다. 왜냐하면 그러한 것이니까」라고 하는 것은 그 대표 예입니다.

우선 이 예를 봐 주세요. 직감적으로 어느 쪽이 아름다운지 아이와 같은 깨끗한 마음으로 봐 주세요.

예 A

1. TopMargin = 10;

2. BottomMargin = 10;

3. LeftMargin = 20;

4. RightMargin = 20;

예 B

1. MarginTop = 10;

2. MarginBottom = 10;

3. MarginLeft = 20;

4. MarginRight =20;

예 A는 영문법에 따른 기술, 예 B는 Margin을 앞으로 기술했습니다.

어떻습니까?

영문법을 무시한 예 B쪽이 「Margin」이 깨끗하게 갖추어져 있어 아름답지 않습니까. 여기까지 깨끗하게 모이면 대입 부분 「
= 10;
」도 정리하고 싶어집니다.

예 C

1. MarginTop    = 10;

2. MarginBottom = 10;

3. MarginLeft   = 20;

4. MarginRight  = 20;

한층 더 아름다워졌습니다. 소스의 시인성(視認性)이 올라서 유지보수도 편하게 되겠죠.

보충

최근에는 클래스로 설계하므로,

Margin->Top = 10;

라고 기술하는 것이 많습니다만 네이밍이라고 하는 시점에서 읽어 주세요.

상식에 속박 되고 있지 않습니까? 「있어야 아름다운 모습」이라고 생각하고 있는 것은 정말로 아름답습니까?

훌륭한 멀티 스테이트먼트의 세계!

「멀티 스테이트먼트」. 이 단어를 알고 있는 분, 기억하고 있는 분, 어느 정도 계십니까?  80년대 전반 주로 interpreter 언어에 있어서 유행된 기술 방법입니다.

멀티 스테이트먼트란

지금은

1. a=10;

2. b=20;

3. c=a+b;

4.  

이라고 쓰는 것을

1. a=10; b=20; c=a+b;

와 같이 쓰는 것이 멀티 스테이트먼트입니다. 1행에  복수의 명령을 기술하는 매우 기분 나쁜 기술 방법입니다.

그렇지만 옛날에는 제대로 의미가 있었습니다. 아직 컴퓨터가 빈약했던 시대 멀티 스테이트먼트로 기술하는 것으로

  조금 메모리가 절약

  좀 더 처리 스피드가 오른

닙다.

그 후 컴퓨터 기술의 발달에 의해 멀티 스테이트먼트는 그 의미를 잃었습니다…….

부활! 현대풍 멀티 스테이트먼트!

우선 다음의 소스를 봐 주세요. 월 마다 대입 문자열을 바꾸는 처리로 비교적 알기 쉬운 소스입니다.

1. switch(month){

2.     case 1:

3.        tsuki="1월";

4.        koyomi="1월";

5.        break;

6. 
   

7.     case 2:

8.        tsuki="2월";

9.        koyomi="2월";

10.        break;

11. 
    

12.     case 3:

13.        tsuki="3월";

14.        koyomi="3월";

15.        break;

16. 
    

17.     case 4:

18.        tsuki="4월";

19.        koyomi="4월";

20.        break;

21. 
    

22.     case 5:

23.        tsuki="5월";

24.        koyomi="5월";

25.        break;

26. 
    

27.     case 6:

28.        tsuki="6월";

29.        koyomi="6월";

30.        break;

31. 
    

32.     case 7:

33.        tsuki="7월";

34.        koyomi="7월";

35.        break;

36. 
    

37.     case 8:

38.        tsuki="8월";

39.        koyomi="8월";

40.        break;

41. 
    

42.     case 9:

43.        tsuki="9월";

44.        koyomi="9월";

45.        break;

46. 
    

47.     case 10:

48.        tsuki="10월";

49.        koyomi="10월";

50.        break;

51. 
    

52.     case 11:

53.        tsuki="11월";

54.        koyomi="11월";

55.        break;

56. 
    

57.     case 12:

58.        tsuki="12월";

59.        koyomi="12월";

60.        break;

61. 
    

62.     default:

63.        tsuki="";

64.        koyomi="";

65.        break;

66. }

이것을 현대풍 멀티 스테이트먼트로 기술해 봅시다!

1. switch(month){

2. case 1: tsuki= "1월"; koyomi= "1월"; break;

3. case 2: tsuki= "2월"; koyomi= "2월"; break;

4. case 3: tsuki= "3월"; koyomi= "3월"; break;

5. case 4: tsuki= "4월"; koyomi= "4월"; break;

6. case 5: tsuki= "5월"; koyomi= "5월"; break;

7. case 6: tsuki= "6월"; koyomi="6월"; break;

8. case 7: tsuki= "7월"; koyomi= "7월"; break;

9. case 8: tsuki= "8월"; koyomi= "8월"; break;

10. case 9: tsuki= "9월"; koyomi= "9월"; break;

11. case 10: tsuki= "10월"; koyomi="10월"; break;

12. case 11: tsuki="11월"; koyomi= "11월"; break;

13. case 12: tsuki="12월"; koyomi= "12월"; break;

14. default: tsuki= ""; koyomi= ""; break;

15. }

이렇게 되었습니다. 실로 컴팩트하고 시인성 좋게 되었습니다.

필자가 이것을 실천했을 때 「 어째서 멀티 스테이트먼트야!」라고 많은 물의를 일으킵니다. 이미 먼 과거의 것으로 여겨진 기술법을 꺼냈으니까 비판되는 것도 당연하다고 말하면 당연합니다. 그러나 한 번 이것에 익숙한 사람은 그만둘 수 없게 됩니다.

한번 더, 잘 봐 주세요.

각 case에 대응하는 처리가 세로에 깨끗이 줄서 한눈에 확인할 수 있습니다. 부주의 BUG 혼입을 막을 수 있기 때문에 유지보수 성이 올르고 또 소스도 컴팩트하게 되기 때문에 좋습니다.

만약 「아니! 그것은 이상하다!」라고 반론하고 싶어졌다고 하면 그것은 당신이 열중한 상식에 붙잡혀 있는 탓인지도 모릅니다.

"박살 내라 상식! 리얼 엔지니어의 길" 이만 마칩니다.

주

　예의 단순한 반복이 계속 되는 경우에 유효합니다. 복잡한 처리를 무리하게 멀티 스테이트먼트로 하는 것은 전혀 추천하지 않습니다.

“소프트웨어 개발이라는 긴 여로의 시작, 생각하는 프로그래머의 길은 어떻게 가야 하는가.” 

『실용주의 프로그래머』가 숙련된 프로그래머에서 마스터로 가는 깊은 통찰을 전해줬다면 이 책은 견습 프로그래머가 숙련 프로그래머로 성장하는 길을 안내하는 지침서다. 
흔히 프로그래밍을 공부하면서 진지한 고민 없이 인기 있는 언어를 선택하고, 개발에 몸담은 햇수를 기준으로 앞길을 결정하고는 한다. 
『프로그래머의 길, 멘토에게 묻다』는 당신이 소프트웨어 개발 분야에서 경력의 시작을 설계하고 이 분야에서 탁월한 개발자가 될 수 있도록 자기 자신을 세우는 일에 관한 책이다. 
프로그래밍을 생업으로 삼으며 견습이라고 부를 만한 시기에 어떻게 행동해야 이상적인 길을 걸을 수 있을지, 정말로 제대로 배우려면 어떤 마음가짐이어야 하는지, 커뮤니티를 어떻게 활용해야 내게 도움이 되는지 등 구체적인 상황과 해결책을 멘토의 조언을 빌어 제시한다.

<프로그래머의 길 멘토에게 묻다>

프로그래밍에 대한 최고의 실무적인 지침서로 널리 알려진 스티브 맥코넬의 CODE COMPLETE 제2판. 이번 책은 소프트웨어 개발 단계 중 "구현" 부분에 초점을 맞추고, 소프트웨어 구현에 대한 예술과 과학을 설명하기 위해서 최신의 기법들과 수백 개의 새로운 예제 코드가 포함되어 개정되었다. 

맥코넬은 연구와 학계, 그리고 상업적인 기법들에 있는 지식들을 바탕으로, 가장 효율적인 기법과 반드시 알아야 하는 원칙들을 이 실용적인 지침서에서 종합적으로 다루었다. 

스티브 맥코넬(Steve McConnell)은 개발 분야에 있어서 가장 뛰어난 저자이자 대변인 중 한 명으로 인정받고 있다. 그는 Construx Software의 수석 소프트웨어 엔지니어이며, Software Development 잡지의 Jolt Award를 수상한 Code Complete과 Rapid Development, 그리고 Software Project Survival Guide와 Professional Software Development의 저자이다.

<CODE COMPLETE 2>

이 책은 기존에 존재하는 소프트웨어의 성능과 구조적인 무결성을 개선하기 위한 방법을 소개하는 책으로, 갈수록 복잡해지는 개발환경에 맞춰서 어떻게 해야 보다 효율적이고, 재사용이 가능한 소프트웨어를 개발할 수 있는지에 대해서 집중적으로 논의하고 있다. 여기서는 좋지 못한 코드로 재 작업하여 잘된 코드로 변환하는 적절한 방법을 소개하며, 그와 함께 "Refactoring"의 개념에 대해서 제대로 이해할 수 있는 기회를 제공한다. 

이러한 Refactoring을 통해서 실무자들은 소프트웨어의 결점을 보완할 수 있으며, 잘못된 코드로 인한 시간과 비용의 낭비라는 딜레마에서 헤어날 수 있을 것이다. Refactoring에 관한 한 이 책은 관련 기술 모두와 방대하고도 자세한 세부명세를 제공하고 있으며, 그것을 적용하기 위한 조언도 아끼지 않고 있다. 이러한 조언들은 단계적인 접근에 의해 보다 쉽게 익힐 수 있도록 하였다. 이 책에서 제공되는 모든 예제들은 Java라는 객체 지향언어로 작성 되었고, 객체 지향을 지원하는 어떠한 언어에서도 그 개념이 적용 가능하도록 작성하였다.

저자들

Martin Fowler는 컨설턴트로 10년 이상 객체를 주요한 기업 문제에 적용해왔다. 그는 의료, 금융, 회계 등의 분야에서 사용되는 시스템을 컨설팅했고, 그의 고객으로는 크라이슬러, 씨티뱅크, UK 내셔널 헬스 서비스, 앤더슨 컨설팅, 넷스케이프 커뮤니케이션 등이 있다. 또한 Fowler는 객체와 UML, 패턴에 관련된 정기 강연자이고, Analysis Pattern와 UML Distilled 등의 저자 이기도 하다.

Kent Beck은 저명한 프로그래머이자, 테스터, 리팩토링 전문가, 저자 그리고 밴조 연주자이다.

John Brant와 Don Roberts는 스몰토크에서 사용할 수 있는 리팩토링 브라우저(http://st-www.cs.uiuc.edut/~brant/RefactoringBrowser)를 개발했다. 이들은 또한 6년 동안 리팩토링의 실용적 측면과 이론적 측면을 연구한 컨설턴트이기도 하다.

William Opdyke는 객체지향 프레임워크에서의 리팩토링에 대한 연구로 이 분야의 중요한 업적을 남겼다. 그는 현재 Lucent Technologies/Bell Laboratories의 기술위원으로 있다.

<Refactoring (한글판)>