7대 죄악 중 나태의 죄[20221027 TIL]

서두르자, 나태하지말자

오늘 트레이너분이 오셔서 진도 점검 처럼 하고 가셨는데 그냥 무심히 툭툭 던진 말들이 알게모르게 좀 나를 불지른 것 같다. 당연히 2달이란 시간에 2달 근처에서 완성본을 내면 되겠지라고 무의식 속에 생각하고 있었는데 생각해보니 그런 작업물들은 항상 기한 오버 였거나 퀄리티가 떨어졌던 것 같다. 

그리고 완성 기간을 길게 잡다보니 뭐랄까 마지막을 쪼으는 그 조급? 마감에 임박한 그 에너지? 그게 없다. 왜 어찌할지 몰라 고민만하고 있던 학교 과제를 전날 처내려고 어떻게든 하거나 기한을 착각해 소재만 생각해두고 쓰지 않던 자소서를 하루만에 몰아쳐 쓰는 그 에너지 말이다.

 

피드백 루틴을 빠르게

그러다 보니 기획을 하는데도 시간이 많은 것 마냥 기획 하는 앱을 연구하고 있지 않은가? ( 물론 이 앱을 알려는 태도는 나쁘지 않지만 그렇게 중요도를 매기지 않고 뭐든 다 배운다라는 태도로는 에너지의 일점사가 불가능해지니 완성도가 떨어질 것 이다.) 그래서 정말 필요한가? 정말 핵심인가? 모든 컴포넌트를 반드시 다 만들어야하는가? 사진으로 대체할 수 는 없는가? 라는 질문을 던지며 빠르게 헤쳐나갔다.

그러니 정말 능률이 달랐다. 물론 기획앱을 제대로 쓰면서 안 것 도 많다. 그리고 그 동안 이 기능 저 기능 쓰며 알았기에 가능한 속도 였긴 했다.

다시 본론으로 돌아와서 내가 처음 완성한 웹은 완벽할 리가 없다. 그렇지만 피드백을 받으면 조금 더 다듬어질 것이고 또 받으면 조금 더 마치 장인가 도자기를 깍듯 그렇게 한 번 한 번 깍고 다음으면서 나은 굴곡을 가진 웹페이지가 될 것이다.

집에 가구의 높낮이를 맞출때에도 한번에 자로 깔끔하게 잰 듯 잰 후 높이를 맞추거나 평형을 맞추는 경우는 드물다. ( 그렇게 해도 삐걱거리는 경우가 많아서) 결국 대략 잰 후 다시 얇은 판지를 넣거나 보강을 하는데 개발도 그런식이어야 한다고 생각한다.

즉 완벽한 앱을 만드는 것이 아니라 규칙을 지킨 앱을 만들되 전문가의 피드백을 많이 거친 코드를 짜는 것 이 내가 추구해야할 목표이다.

그러려면? 마감기한을 보다 짧게, 더 짧게

그러려면 앱이 빨리 완성될 수록 피드백을 받을 횟수와 수정할 기회가 증가한다. 그러려면 당연히 서둘러야 하고 마감을 당겨야한다. (왜 트레이너 분이 2달 전부터 밤을 새야한다고 하는 이유를 알겠다.)

 

그렇다고 똥코드는 짤 수  없지.

그렇다고 지난 번 처럼 속도에만 급급하여 테스트 코드를 뛰어넘고 인수 테스트 코드도 뛰어넘고 당장 버튼 하나 함수 하나의 구현에만 연연한 그런 코드는 안된다.( 즉 퀄리티를 타협하고 속도를 높이라는 것이 아니란 말이다.)

그럼... 제대로 하면서 피드백을 많이 받으려면 결국 절대적 투입을 늘리는 수 밖에 없다.

 

 

액션플랜

일주일 마감 목표를 보다 더 타이트 하게 짜기. 피드백을 받을 포인트를 더 자주 만들기 

예) ~~까지 ~을 마감하여 피드백을 받겠다. ~까지 이 앱을 1차 완성하여 피드백을 받겠다 등