3. Requirement & UML & Architecture & 경과

1) 요구사항에 대한 생각
기존에 내가 사용하는 시스템이 아닌, 무에서 유를 창조하는 새로운 시스템의 개발같은 경우 정확한 요구사항이란게
존재한다기 보다는, 다소 애매모호한 정도로 어떤걸 하고싶다 정도로 요구사항이 표현되는 것 같는 생각이 들었다.
아마 개인이 개발을 시도한다면 비슷한 상황일 것 같다.
이것을 보다 명확하게 하기 위해서는, 시장조사와 기존에 존재하는 내가 생각하는 것과 비슷한 다른 시스템들을 
분석함으로서 요구사항을 다소 명확하게 하는 것이 필요하다고 생각하였다.
이 과정은 도메인에 대한 추가적인 이해가 필요하므로 그에 대한 과정이 병행되어야 할 것 같다.

2) UML의 도입
OO에 대한 생각이 조금 더 명확해 진것 같다. OO는 안정적이고 변화에 대응할 수 있는 시스템을 위해서
필수적인 요소를 갖추고 있다. 이것을 도입해야함은 매우 명확하고, 이것은 프로그래밍 패러다임이라기 보다는
당연히 따라야 하는 것 같다. OO의 적용은 OO가 요구하는 몇가지 사항들을 만족시켜야 한다.
특히 재사용 가능한 구조를 가지고, 버그가 적으며, 이후의 변화에 대해 지속적으로 유지관리가 가능하기 위해서는
문서화는 필요한 것으로 보인다. 문서화에 대해 Overhead에 대한 논쟁이 있을 수 있다. 하지만, 대부분의 개인 프로그래머가
숙련된 프로그래머가 아니라는 가정하에, 초기 시스템 개발에서 문서화를 거쳐보는 것이 나은 방향이라고 생각하였다.
또한, 단순히 작동하는 시스템을 빠르게 제작하는 것이 아닌 시스템 생명주기 전체에 가져오는 효율성에 
초점을 맞추려고하기 때문에, 프로그램 디자인과정에서 UML을 이용한 문서화가 발생하게 될 것이다.
UML의 이용은 프로그래머가 일정 수준의 학습을 해야한다는 점에서, 약간의 진입장벽을 발생시킨다.
하지만, 표준화된 형태의 언어는 커뮤니케이션을 위해서는 필수적인 도구이며, 내가 무엇을 하고있고, 
무엇을 만들 것인지를 더욱 명확하게 할 수 있다. 따라서, 우리가 숙련되기 이전에는 UML을 통해 시스템을 
직접 디자인함으로서 더 많이 배울 수 있을 것으로 생각된다. 

3) Architecture 설계
처음에는 TDD를 이용한다면 빠르게 시스템을 개발 할 수 있을 것으로 생각하였다. 사실 TDD에 대한 이해가
부족한것도 있어서 처음에는 TDD를 도입한다면 굳이 아키텍처를 설계할 필요가 있을까 라고 생각하였다.
하지만, 이것은 잘못된 생각이었다. 아키텍처는 Detail은 배제한 오로지 high-level policy에만 집중해야 한다.
이미 TDD와 Kanban을 도입한다는 결정이 다소 성급한 생각이었다는 것이다. 물론 이것을 옵션으로 놓을 수 있지만
아키텍처가 확립되지 않은 상태에서 Detail을 결정하는 것은 성급한 결정이다. 
아키텍처의 설계는 development, deployment, maintenance의 단계에서 특히나 유용하며, 이것은 내가 지향하는 바이다.
High-level policy를 더 잘 이해할 수 있게하는 하나의 과정으로서도 아키텍처의 설계는 필요한 것 같다.
이것을 피할 이유는 없어보이며, 내 생각에 현 프로젝트에서 한가지 중요한 것은 사용자가 시간이 지날수록
자신의 실력이 자연스럽게 높아지며 자신의 방향을 찾을 수 있어야 한다는 것이다. 
나는 이것을 달성하기 위한 방향을 제시하기 위해 노력할 것이다.

4) 경과
시장분석 및 시스템 조사 (진행전)
O'Relly의 UML2.0 (공부중)
Clean Architecrue (공부중)

 

아무래도 주기적으로 진행상황을 올리는것도 좋을듯...