본문 바로가기

Architect

모래상자(Sandbox) 안에서 개발하기 -- Ship IT --

모래상자 안에서 개발하기란.
모든 개발 단계를 Atomic하게 분리시키라는 말로 이해된다.

그렇다.
개발을 위한 도구를 이용하는 단계는 나누어 져 있다.
보통 IDE --> Build --> Release를 하는 일반적인 단계를 한다.

이러한 일반적인 단계를 거쳐갈때 이전, 다음 단계가 서로 독립적으로 유지될 수 있도록 할 수있도록 하기 위해서
다음과 같이

개발자 컴퓨터 <--> SCM(소스코드 저장소) <--> Build <--> 릴리즈

사용자 삽입 이미지


의 각 단계를 구분하고 별도 관리하는 것이다.
각 단계가 이전, 다음 단계에 영향을 최소화 할 수 있게 된다.

-------------------------------------------------------------------------------------
책에서 기술하는 내용을 간단하게 좀더 웹 개발에 맞게 변경해 보았다.

여기서 핵심은 각 개발 인프라의 담당 영역을 분리하는 것이다.

보통 내가 개발을 할 경우 위와 같이 인프라를 나누지 않았었다.
이러한 각 단계를 나누는 것에는 통일된 개발을 위한 인프라에 대한 지식에 대해 통일을 위해서 지원하는 것일 것이다.

이런 인프라를 구현하여 개발하는것이 상당히 바람직하다는 생각을 많이한다.
책에서는 각 개발자들이 서로다른 IDE를 이용하든, 단순히 메모장을 이용하여 개발하든 영향을 받지 않아야 한다고 말한다.

아직 내공이 부족해서인지 모르겠지만, 나는 개발할때 나와 같이 개발하는 모든 사람들이 동일한 IDE(eclipse주로 이용)를 이용하여 개발 환경에서 부터, 프로그램 코딩, 포매팅까지 통일화 시키기를 원한다.

이러한 작업은 매우 멋진 생각이다. 그러나 반면 어느정도 번거로움은 있었다.
그것을 몇가지 기술해보면
1. 개발자의 각자 코딩 규칙을 가지고 있다. 이러한 경우 소스를 처음 보는 사람의 경우 이해하기가 어렵다.
(내가 알기로는 사람이 코드를 이해하기 어려워 하는 이유는 띄워쓰기, 인덴트, 그리고 변수이름과 같은 것에 상당히 민감해서 그러는 경우가 많다는 것이다.)
즉, 코딩 규격화를 맞추기 힘들다는 것이다.

2. 그리고 SCM을 이용하여 코드 관리를 수행할때, 메인 관리자가 필요하다는 것이다.
각기 개발을 하려고 소스를 SCM에서 당겨썼을때, Commit하는 과정에서 충돌이 발생한다. 이러한 충돌을 해결하기 위해서는 소스 관리를 해주는 중재자가 필요하거나, 당사자들끼리 검토를 하는데 상당한 시간이 필요로 하게 된다.
(이럴 경우 IDE툴은 어느정도 소스코드에 대해서 미리 문제점을 밝혀준다. 그리고 그러한 문제점이 있을때 즉각적으로 반응하여, 이해 당사자들과 논의할 수 있다.)