글쓰는 개발자

Stage 2030 Analysis에서는 크게 두 가지 To-Do가 있다. 하나는 외부 Actor가 시스템에 접근하기 위해 필요한 Interface 역할을 하는 Operation들을 시스템 수준에서 분석하고 찾아내는 것이고, 다른 하나는 개발에 참여하는 개발자들이 전체적인 시스템 도메인에 대해 파악하기 위한 시간을 가지는 것이다. 본격적인 시스템 해부 및 설계의 단계로 넘어가기 위한 중간 단계로써, 이 단계를 거치면서 개발의 방향성이 더욱 구체화된다. INDEX Use-Case Model Use Case System Operation Domain Model Traceability Analysis 1. Use-Case Model Use-Case Model은 사용자가 시스템에게 기대하는 행동을 Operati..

지난 포스팅 객체지향 개발 방법론(OOAD) : OOP, UP에서 OOP, UP에 대해 소개하였다. 이번 포스팅부터는 본격적으로 OOPT에 대해 소개하려 한다. OOPT의 첫 번째 단계인 Stage 1000 Planning 단계에서는 이름처럼 제작할 시스템에 대한 명칭, 전반적인 계획, 비전, 투입 금액 산정, 요구사항 정의 등의 스케치 작업들을 수행한다. 시스템 개발 측면에서 크게 할 일은 없고, 비즈니스와 관련한 내용들이 오히려 주를 이룬다. 회사 내에서는 프로젝트 착수전 보고 단계이며, UP에서는 feasibility study를 수행하는 Inception Stage로 대응될 수 있다. INDEX Activity 1001. Define a draft plan Activity 1002. Create ..

모든 일에 있어 가장 중요한 일은 개요(또는 목차)를 잡는 것이라고 생각한다. 개요를 잡고 무언가를 시작하게 되면, 큰 문제에 직면하더라도 그것을 조각내서 단순화하여 생각할 수 있고 개요 간의 관계 또한 선명하게 살필 수 있으며 전체 맥락도 빠르게 파악할 수 있는 등의 여러 가지 장점이 많다고 생각하기 때문이다. 이 개요라는 것은 비단 문장에서뿐만 아니라 어떤 영역에서든 적용될 수 있고, 각 영역에서 정의하는 그들만의 단어로 표현되는 듯하다. 소프트웨어 개발에 있어서 이러한 개요는 '설계'라는 단어로 표현할 수 있지 않을까. 무턱대고 각종 IDE를 실행하여 일단 코드를 써 내려가는 것보다는, 먼저 시스템에 대한 도메인을 파악하고, 아키텍처를 잡고 각 모듈들간의 관계에 대해 파악하는 등의 일련의 '개요 잡..

해당 주제로 포스팅을 하려고 보니 문득, 처음으로 학교에서 C언어 기반의 팀 프로젝트를 했던 시절이 기억난다. 각자 역할을 나누어 개발을 하고 다시 그 코드를 병합했을 때, 우리의 코드는 톱니바퀴처럼 맞물려 하나의 코드가 되고, 우리의 논리들은 하나의 논리가 되어 처음부터 끝까지 도미노처럼 멋지게 완성될 거란 희망을 품고 병합을 했을 때에, 우리는 우주 대폭발을 방불케 하는 코드 대폭발을 경험하였고, 코드의 엔트로피는 한없이 증가하여 손댈수록 돌아올 수 없는 강을 건너기만 할 뿐이었다. 그 덕분에 학점란에 고스란히 새겨진 C+라는 학점은 아직까지도 성적표에 남아 작성자를 괴롭히고 있다. 그때부터가 아니었을까? 코드를 나누기 전에, 어떻게 나눠야 다시 병합할 때 최소한의 에러와 논리 오류만 가져갈 수 있을..

어느덧 github을 통해 하나의 repository를 업로드하고, 그것을 다른 환경에서 동일하게 동기화하는 작업의 막바지에 다다랐다. 이전 포스팅에서, git clone 명령어를 통해 저장소를 다른 PC에 복제해보았다. 복제된 저장소는 다음과 같이 구성될 것이다. 즉 현재 맨 위의 세 개의 저장소가 모두 동일한 파일 구성을 가지게 되는 것이다. 이제 다른 PC에서도 저장소의 내용을 내려받아 수정할 수 있는 상태가 되었다. 복제된 저장소에서 한참 작업을 하여, 작업 내용을 File4.txt에 저장했다. Repository의 내용이 변경되었으므로, git status를 통해 working tree를 확인하면 File4가 untracked 상태일 것이다. 이전과 동일한 방식으로, Local Repositor..

원격 저장소를 생성하고, 원격 저장소에 push 하는 과정까지 지나왔다. 원격 저장소에 지역 저장소의 커밋 내용을 업로드했다면, 다른 곳에서 원격 저장소에 저장된 내용을 다시 끌어와서 사용할 수 있어야 진정한 Back-Up의 의미가 완성되겠다. 그러기 이전에 위의 사진처럼, 우리의 커밋을 불러오기 위해서 똑같은 저장소를 다른 PC에도 설치하여야 commit을 내려받을 수 있는 상태가 된다. 그러려면 우선 directory를 하나 생성한 후에, 그 directory를 git init으로 초기화하고 git remote로 원격 저장소와 해당 directory를 연결한 후 내려받아주면 된다. 그런데 이런 과정 하나하나를 매번 다 해주긴 너무 귀찮다. 예상했겠지만, 위와 같은 복제 기능을 하나의 작업으로 퉁칠 수..

원격 저장소를 지역 저장소와 연결하는 작업을 마쳤다. 서로를 연결하는 통로가 생겼으니, 이제 데이터를 주고받을 수 있는 단계가 된 것이다. git을 사용하는데 있어서 가장 중요하고 기본적인 기능이다. 지역 저장소에서 commit을 하고 github에 업로드해보자. ./gitStudy$ git log --oneline --all daa63a3 (HEAD -> master, origin/master) commit without File3 fea7dc5 Revert "Version2" a23df4a Version2 bd66197 Version1 ./gitStudy$ ls -al total 24 drwxrwsr-x 3 cabox www-data 4096 Apr 29 07:13 . drwxrwsr-x 11 cab..

원격 저장소를 생성하였으니, 지역 저장소와 연결하여 두 저장소 간 동기화하는 작업이 필요하다. 위 화면은 원격 저장소와 다른 저장소를 연결하는 여러가지 선택지를 주고 있다. 파일을 내려받는 방법, 새로운 지역 저장소를 생성하여 연결하는 방법, 기존에 존재하던 지역 저장소를 연결하는 방법, 기존에 존재하던 다른 원격 저장소를 내 원격 저장소로 복제해오는 방법이 존재한다. CLI 버전관리에서 이미 만들어오던 지역 저장소가 존재하므로, 빨간 네모 박스 부분의 방법으로 진행하겠다. #git 브랜치 상황 확인하기 ./gitStudy$ git log --oneline --all daa63a3 (HEAD -> master) commit without File3 fea7dc5 Revert "Version2" a23df..

오늘날 대부분의 개인들은 스마트폰을 포함한 최소 1대 이상의 PC를 소유하고 있다. PC를 많이 소유할수록, 개인의 정보를 일관성있게 유지하기 위해 반드시 필요해지는 것이 PC간의 동기화인데 이러한 역할을 톡톡히 수행해주고 있는 것이 바로 클라우드 시스템이다. 클라우드 시스템은 PC에 종속되지 않고, 개인의 이동성을 보장하고 정보의 동기화 시스템을 빠른 속도로 구축해나갈 수 있게 하기에 이제는 더 이상 선택이 아니라 필수라고 생각한다. 개발을 하는 과정에서도 여러 사람들과 소통하고, 그들간의 소스 코드를 동기화하는 것은 프로젝트의 크기가 커질수록 반드시 필요한데 이 또한 클라우드 시스템을 이용한 서비스를 통해 해결할 수 있다. 개발을 목적으로 둔, 가장 널리 쓰이는 클라우드 시스템이 바로 git remo..

작업을 마무리하고 git을 이용하여 commit을 하는 상황에서, 파일을 빼먹고 올리거나 commit 내용을 잘못 작성하여 저장하게 되는 경우가 있다. 이런 경우 빼먹은 파일을 따로 업로드하면 버전으로써의 의미가 사라지고, 그렇다고 commit을 지워버리고 다시 업로드하자니 그동안의 작업 내용을 날려버리게 되니 참으로 난감한 상황이 아닐 수 없다. 당연하게도 이런 상황을 해결할 수 있도록, git에는 commit 내용을 수정할 수 있는 기능이 있다. test directory에서 작업을 진행해보도록 하자. ./test$ ls -al total 12 drwxrwsr-x 3 cabox www-data 4096 Jun 3 06:13 . drwxrwsr-x 6 cabox www-data 4096 Jun 3 06..