안녕하세요. bsidesoft의 신입사원 dimanche입니다. summer의 [초보자들 pilot]에서 잠깐 나왔었지만, 모르시는 분들을 위해 존재 어필을 할게요. 저도 summer와 같이 레벨 테스트에서 멘붕을 겪었습니다. 그 후 정신차리고 미션을 통해 코드뿐만아니라 개발자로써 좋지 못했던 제 생각들도 뜯어 고치고 있습니다.
그럼 이제 첫 번째 미션에서 제가 어떻게 씹고 뜯고 맛보고 즐겼는지 보여드리겠습니다.
2시간의 코딩 욕심이 부른 충격적인 결과물.. 그리고 쓰나미처럼 밀려 온 고쳐야 할 코드들… 엄청난 멘붕 상태의 dimanche와 summer는 이를 잘 극복할 것 인가아아?!!
미션 임파서블??
레벨 테스트를 한 날로부터 열흘 후 저희는 또 다른 미션을 받았습니다. 미션의 주제는 수정 내역을 확인 할 수 있는 텍스트 편집기를 만드는 것이었습니다.
이건.. dimanche의 레벨 테스트 코드?
두근거렸습니다. 레벨 테스트 때처럼 못난 코드가 되지 않을까라는 걱정 반, 이번엔 제대로 단계를 밟아가면 잘 할 수 있지 않을까라는 기대 반이 심장을 쫄깃쫄깃하게 만들었습니다.
심호흡을 하며 진정을 시키고 요구사항을 열심히 적었습니다.
- 구성 요소 중에는 텍스트 입력 창 하나와 버튼 3개, ‘현재 위치/전체 개수’를 나타내는 박스가 있다.
- 버튼은 각각 뒤로가기, 앞으로가기, 저장을 한다.
- 저장버튼을 누를 때 마다 텍스트 입력 창의 내용을 저장한다. 그리고 전체 개수가 +1되고 현재위치는 마지막 저장한 내용으로 점프한다.
- 뒤로가기, 앞으로가기 버튼을 누르면 현재 위치가 -1, +1되고 그 위치의 저장한 내용으로 점프한다.
똑같은 실수를 반복하지 않도록 이렇게 몇 자 적은 요구사항으로는 무엇도 만들 수 없다고 생각했습니다. 좀 더 예뻐진 코드로 미션을 성공하기 위해 첫단계를 시작합니다.
이렇게 저렇게 설계
개발의 첫 단계는 요구사항을 정리한 설계문서를 작성하는 것입니다. 문서는 메모지에 볼펜으로 끄적여 놓는다면 그 것은 얼마가지 않아 쓰레기가 될 것 입니다. 그래서 디지털화된 문서가 필요하고, 그런 문서를 작성하는 것은 파워포인트를 이용합니다.
오~ 파워포인트! 본 적있다고 익숙하다고 그래서 ‘잘 할 수 있겠는데?’라고 생각했습니다. 하지만 파워포인트를 켜고 멍해졌습니다.
어이가 없네?
전 또 만만하게 생각했습니다. 슬롯머신도! 파워포인트도! 파워포인트는 고등학생 때도 대학생 때도 사용해 본 적 있는 문서 도구입니다. 익숙하고 쉬운 듯 했습니다. 이 때 저희의 구세주이신 실장님이 친절하게 파워포인트를 활용하는 법(자주 쓰는 단축키와 간격조정, 여백조정, 색 배제 등의 팁 등)을 알려주셨습니다. 이젠 저의 파워포인트는 초딩수준인 것을 인정하고 이도 연습을 하고 있습니다.
설계문서의 내용엔 ‘다함께 프로그래밍’에서 배운 것을 적용해보았습니다. 테마를 정하고, 줄거리를 정하고, 시나리오를 작성하는 단계로 생각을 했습니다.
1. 테마 정하기
테마를 정하고 요구사항을 한번 정리하고 화면구성도 생각해보았습니다.
2. 줄거리, 시나리오 작성하기
줄거리에 맞게 시나리오도 작성해 보고, flowchart도 그려보았습니다.
3. 전체 flowchart
마지막으로 시나리오의 flowchart를 합쳐 전체 flowchart도 만들어보았구요.
이렇게 문서를 작성해보니 코드 작성도 술~술~ 잘 풀릴 것 같았습니다. 그 기분 그대로 신나게 드림위버를 켰습니다. 그리고 설계 문서를 토대로 스크립트에 주석을 달았고, 그 내용이 반영되도록 코드를 작성했습니다.
4. 코드 작성
static save(){
//내용이 없으면 저장되지 않는다
//내용에 공백만 있으면 저장되지 않는다
//내용이 마지막에 저장된 내용과 동일하면 저장되지 않는다
var contents = document.getElementById('contents').value.trim();
//textarea에 내용이 있으면,
if(contents) {
//textarea의 텍스트를 contents에 저장한다
//총 contents 개수가 1 증가된다
//현재 위치가 마지막 content로 이동한다
storage.push(contents);
curPage = storage.length;
TextEditor.render();
}
else if(contents==storage[storage.length-1]){
alert("내용이 수정되지 않았습니다.");
return;
}
else{
//그렇지 않으면, 내용이 없다고 경고 메시지를 띄운다
alert("내용이 없습니다.");
return;
}
}
설계 문서를 토대로 스크립트에 주석을 달았고, 그 내용이 반영되도록 코드를 작성했습니다. 레벨 테스트 때와는 달리 작동은 하고 있는 타임머신 에디터였습니다.
진화하는 설계 문서
위의 이미지와 내용들은 언뜻보면 그럴 듯한 문서로 보일지도 모르겠습니다. 하지만 요구사항부터 모든 내용이 굉장히 허술합니다.
너무 많은 허술한 부분들 중 한가지를 짚어보겠습니다.
‘저장하기’ 시나리오
작성한 시나리오의 중 하나입니다. 노란색 박스로 표시한 것들이 전부 하나를 가리키는 용어들입니다. 쟤들이 전부 타임머신 에디터에서 입력된 값을 말하는 거에요….단어의 일관성이 없어서 무엇을 가리키는지 불분명하고 의사전달이 모호해집니다.
빨리 빨리만 일을 진행하려는 마음으로 문서를 치밀하게 구성하지않는다면, 문서를 작성한 사람이 아닌 이상 어떻게 공유할 수 있을까요?
일정한 규칙없이, 모호한 표현으로 기록되어 있는 문서를 읽을 때 누가 읽느냐에 따라 해석이 달라질 것입니다. 그래서 모든 문서에 작은 오타 하나, 문서를 정리하는 규칙 하나에도 신경을 써야합니다.
그래서 제 설계문서를 진화시켜보았습니다. 일단 설계 시 사용하는 이름은 역할을 나타내는 최대한 고유한 이름을 부여해야하고 정의를 명확하게 해야합니다. 이를 저의 허접한 문서에도 적용해 용어집을 정리했습니다.
첫 번째 진화 – 용어집
타임머신 에디터 용어집
두 번째 진화 – 설계문서
와우! 진화된 설계문서
자, 이제 설계문서의 시나리오도 진화되었습니다. 물론 용어들이 좀 더 적절하게 변경해야 하지만, 그 전에 하나의 뜻에 여러 용어를 사용하던 문제를 일관성 있는 하나의 용어로 정의했습니다.
세 번째 진화 – 코드
static save(){
var contents = document.getElementById('contents').value;
//1. 입력값을 검증한다
//1. 입력값을 변환한다
//1. trim()으로 공백을 제거한다
contents.trim();
//2. replace()로 개행문자를 제거한다
contents.replace(/\n/g, '');
//2.입력값이 없으면 empty_content 오류를 출력한다
if(!contents){
showError('empty_content');
return;
}
//3.입력값이 입력값 배열의 마지막 값과 동일하면 equal_content 오류를 출력한다
if(contents===storage[storage.length-1]){
showError('equal_content');
return;
}
//2. 입력값을 입력값 배열에 push()로 추가한다
storage.push(contents);
//3. 입력값 번호를 입력값 배열의 length 값으로 갱신한다
curContentNum = storage.length;
//4. 화면을 갱신한다
TextEditor.render();
}
문서 진!!!!!화!!!!
제 멋대로 쓴 용어로 내용을 제대로 읽을 수 없던 문서가 읽을 수 있는 문서로 진화했습니다. 문서가 정리되니 코드도 많이 깔끔해진 것 같습니다. 저는 그 전에 설계 문서와 주석을 다는 것을 무시해왔습니다. 하지만 요구사항이 무엇인지, 무엇을 어떻게 만들어야하는지를 잘 알고 있지 않으면 오히려 시간이 오래걸리고 결과가 좋지 않다는 것을 경험했습니다.
초보개발자에게 설계문서를 작성해보는 것, 주석을 사용하여 차근차근 코드를 작성해보는 것이 무시되지않고 꼭 필요한 것임을 알았습니다.
미션 완료
최초 문서 작업없이 머릿속으로만 프로그램의 구조를 떠올리고 한 번에 코딩해 내는 프로그래밍의 천재와 같은 사람들도 있습니다. 저도 그런 사람이고 싶지만, 아쉽게도 저는 전혀 그렇지 않습니다. 오히려 기억력이 나쁜 편이기 때문에 몇 줄되지 않는 코드를 작성하더라도 최소한의 순서도 정도는 그려야 프로그램을 작성할 수 있는 것 같습니다. 그리고 지금 보다 더 큰 규모의 프로그램을 작성해야한다면 더 자세하게 기술된 문서가 있어야 안정적으로 프로그래밍 작업을 할 수 있을 것입니다.
또한, 최초에 작업한 문서만으로 프로그램을 완벽하게 만들수 있을까요? 제가 설계문서를 처음으로 작성을 시작할 때 완벽할 수 있을 줄 알았습니다. 그래서 2시부터 7시까지 작업했습니다. 나중에는 다 수정된 설계문서와 코드들이 총 5시간동안의 결과물이었습니다.
한번 더 말하지만 저는 천재가 아닙니다. 그렇기 때문에 최초로 설계한 프로그램의 문서는 100%로 수정되어야할 것입니다. 그 수정 사항이 작은 범위라면, 빈도가 적다면 문제가 크지 않을 수있습니다. 하지만 어떤 경우에는 코드 작성도중에 광범위하고 자주 수정되어야 할 수도 있습니다. 그런경우에는 아마 코드를 고치느라 설계문서의 수정은 뒷전으로 밀려버릴 수 있습니다. 아마도 저는 ‘일단 코드부터 마무리하자. 얼마되지않아 또 수정해야할 수도 있잖아.’라는 생각을 할 것입니다. 그 순간 설계문서는 실제 프로그램과 일치하지 않게됩니다.
저는 프로그램을 만들 때 설계문서를 작성하는 것이 오히려 시간낭비라고 생각했습니다. 그리고 모든 내용을 알고 있고, 다 기억할 수 있을 것이라는 자만이 문제였습니다.
이번 미션에서도 레벨 테스트 때와 같이 제가 배워야할 것들, 고쳐야할 것들이 많았습니다. 그 중에서 가장 크게 배우게 된 것은 문서에 대한 제 생각일 것입니다. 설계문서라는 것이 기본적인 것임을, 기본적인 것이 중요한 것임을, 등한시 했을 때의 여파를.
부끄럽지만, 완성된 저의 타임머신 에디터를 보여드리겠습니다.
dimanche의 타임머신 에디터!
dimanche | bsidesoft 신입사원
좋은 개발자가 뭔지도 모르고 좋은 개발자가 되고 싶은 초보 개발자입니다.
회사에서는 열심히 교육받고 발전하는 운 좋은 개발자로 일하고 있습니다.
recent comment