부스트코스 개발일지 TODO앱 만들기 - 7~8일차(완성)

한 이틀내내 CSS만 짰는데, 예상보다 CSS에서 레이아웃을 잘 짜는 게 엄청 어려워서 애먹었다.

 

처음에는 아예 todo, doing, DONE을 따로 구성하고 그걸 왼쪽 가운데 오른쪽 이런식으로 카드들을 쌓는 방식으로 할려했는데  그방식은 애초에 구현하기가 어려워서 (여기서 한 4시간씀)

 

그래서  보드화 시켜서 구현하는 방식을 택했다. 그 안에 카드를 따로따로 구현하는걸로. ㅋㅋ; 그래야지 한 화면에 3개가 있을 수 있을 것 같아서, 그렇게 구현하니까 재대로 됨.

 

원래는 버튼을 div로 따로 구현했는데 이걸 화살표로 만들수 없다는 사실에 좌절하고 7일차를 때려쳤던걸로 기억하고 8일차에 이걸 a태그로 한다음에 get으로 값전달을 하면 된다는 걸 그때 알아버려서 허탈함을 얻었다.

 

막상 AJAX에서 엄청 고생한 부분의 JS코드도 없이 잘 작동하는 거 보고 몇일동안 뻘짓한건지 고민하면서 다시 태그 정렬했다.

 

대략적으로 float를 다루는 거랑 같은 선상에 있게 할려고 마진이랑 padding 다루는거 때문에 일일히 고생하면서 직접 비교해보면서 했다.

 

이상한게 내 Eclipse에서는 webclipse가 설치가 안되서 JS코드를 작성하는데도 엄청 애먹었고, 

해결방안으로 크롬에서 console에서 써보고 그게 되는지 확인해보고 그걸 바탕으로 복사 붙혀넣기 방식으로 코드를 썼다. 이럴거면 intelliJ로 넘어갈까 생각도 했다.

 

물론, 서버때문에 무서워서 못넘어갔다. 서버설정을 할 수 있을지 명확하지 않아서 그걸 다시 배우다가 내머리통이 터지지 않을까 싶어서 포기하고 다시 이클립스에서 코드작성.

 

심지어 CSS작동도 바로바로 안되서 그거 고친다고 애먹었고, 그래서 그거 해결하려고 그냥 css자체를 크롬에서 바꿔보고 맞춘다음에 그걸 내 로컬 CSS에 적용하는 걸 택했다. 

 

대충, 그런식으로 레이아웃 완벽하게 똑같이 짜는것을 도전해보려다가 그게 쉽게 되지는 않아서 ㅠㅠ 80%정도 구현하는 걸로 만족했다.

그래도 짜잘하게 다른 구석이 있어도 거의 대부분은 같은 모양이다.

 

그래서 좀 아쉽기도 하지만, 이 플젝에 너무 시간을 많이 소비하면, 나중에 인강 들을 시간이 부족할 것 같아서 일단 이정도로 접었다.

 

거의 1주반을 이 프로젝트에 매달리면 얻은 생각을 적어놔야지 나중에 실수를 면할 것 같은데, 일단 경험적으로 얻은 지식을 적어본다.

 

1. 기획서가 엄청 중요하다.

 

기획서를 꼼꼼하게 적을수록 개발할때 내가 어떻게 구현해야할지 감이 온다. 특히 기획서를 안보고 내가 삽질한 경우가 많다. 그래서 그걸 찾아보다가 날린시간을 생각해보면 차라리 기획서를 꼼꼼히 읽어서 내가 오류를 줄이고, 시간을 투자하는 데 있어서 이 방법이 훨씬 좋다.

부스트코스만 국한된 거긴한데, 아무리 생각해도 기획서와 그 기획동영상과 평가제출표만 봐도 내가 얻을 수 있는 힌트들이 꽤많다. 그러니까 기획서랑 기획동영상 평가지표들을 꼭 명심하면서 잘 볼것.

 

2. 이 기술이 안되면 다른 방법을 찾아봐야한다.

 

이게 내가 구현한 방법이 안되면 다른 방법을 빠르게 찾는것도 중요한것 같다. 특히, 어? 이거 왜 안됨? 이거 맞는데? 이생각이 아주 개발시간을 연장시키는 중요한 요소인 것 같다.

특히 이런 방법으로 1~3일차를 한 문제에만 너무 매달려서 완성했지만, 심지어는 안됬다고 착각해버린 병크를 만들었다. 사실상 3일을 날려버린 격. 그래서 빠르게 이 기술이 맞는지를 체크해보는 과정이 필요하다. 아니면 빠르게 다른 기술로 갈아탈 마음가짐이 필요하다.

 

 

3. 비슷한 맥락으로 컴파일러에서 몇번째 코드가 안되는 지 그걸 확인해서 뭐가 안되는 지를 파악해서 수정하는 과정도 중요하다.

 

개발 초기 1~2일차에는 그냥 빨간 코드가 뜨면 왜 안되는지 생각도 안해보고 이게 안되는 것에만 걍 오류만 해결할 방법을 내스스로 찾아서 해결 했는데 그게 그렇게 좋은건 아니다. 

덕분에 2일쯤을 막힌 쪽에서 진척없이 앞으로 제자리걸음하면서 다녔고,  3일차쯤됬을땐가 몇번째줄에서 오류가 발생하고 그 오류가 무엇이고, 왜 값을 전달 받지 못했는지에 대해서 생각해보면서 코드를 짜기 시작했다.

그러면 이 함수가 재대로 작동하는지 혹은 이 함수가 상황에 맞게 쓴건지 확인해볼 수 있는 결과를 만들어줬다. 

정말 중요한 것 같으니 다음부터 이런 과정을 통해 수정하는 과정을 택해야한다. 

 

4. 그냥 기술을 알고 있는거랑 프로젝트를 해보는건 차원이 다름.

 

이 기술을 압니다.랑 이 기술을 써먹을 수 있습니다는 완전 차원이 다른 문제. 플젝해보면서 인강으로 듣고 기술만 잡고 넘어 가는게 별 도움이 안된다는 사실을 처절하게 깨닳았음. 내가 기술을 아는 거랑, 그 기술을 적용할 수 있는건 엄청 다른 문제임. 처음에 프로젝트 할때는 그런생각 잘 안했는데 프로젝트 하고 난 다음부터는 엄청 많이 생각남.

한 기술에서 파생되서 발생하는 문제들이 엄청나게 많고 한문제를 해결하는 방식도 엄청나게 많아서 그걸 해결하는 방식마저도 너무 다르고 적용방식도 엄청 달라서 그걸 직접 경험해보지 않는 이상 기술의 폭이든 깊이든 차이가 엄청나게 많이 발생한다.

결국 프로젝트를 해본 것과 안해본 것의 차이의 간격은 엄청나다는 것을 느꼈다.

 

 

이번 플젝도 어찌됬든 끝을 내보긴했으니까. 스스로 고생했습니다. 짝짝짝~ 또 고생합시다.