우리 모두 "딸깍" 하고 싶은게 아닐까?

이번 프로젝트를 진행하면서 느낀게 있다.

 

왜 개발 책에서는 컴포넌트화를 중요시 했을까..

그건.. 일정은 고정이고 예상했던 양보다 항상 더 많이 들어와서가 아닐까..?

 

생각해보면 프로젝트 동안 겪은 일들은 사실 처음이 아니다.

이전에도 늘 겪었다.

기존 기획보다 많아지고, 계속 추가되고, 디자인도 변경되고..

개발자에 입문하는 순간 바뀌고 바뀌는건 기본이라고 생각하면 될 것 같다.

 

그럼 이게 기본이라고 생각하면,

결국 대응해야한다.

동일한 코드를 복붙해서 짜잔! 하고 만들 수 있지만

사실 컴포넌트화를 잘 해서 들어갈 파라미터만 '자 이번엔 이 파라미터 먹어봐'로 바꾸면

오히려 복붙이 더 깔끔하게 된다.

 

해당 파라미터만 변경해서 내가 원하는 UI와 데이터를 구성한다. 

책에서 자주 들은 얘기고 실행도 해왔지만 

이번 프로젝트에 뭐랄까... 몸소 겪은 것 같다.

 

컴포넌트화가 잘 된 dart파일을 보면서 '과거에 나 잘했어 고마워!' 를 외치고

해당 UI에 Bloc이 연결되서 더 이상 유연하게 못 된 코드를 보고.. 그리고 그 코드가 필요한 시점에 도달했을때

'아... 바빠 죽겠는데.. 그래도 이거 재사용가능하게 값은 밖으로 꺼내놓자.. 젠장 과거에 나 뭐한거야 ㅠㅠ' 를 외쳤다.

 

컴포넌트화를 잘 해놓으면 시간을 아낄 수 있다는 걸 몸소 체험했다.

이게 결국 '딸깍'이 아닐까?

 

이번에 프로젝트를 진행하면서

Mason 라이브러리를 이용해 해당 도메인을 자동으로 만들었고, 이 덕분에 2시간정도 아낀 것 같다.

사실 2시간을 벌었다는 생각보다, 필요는 하지만 귀찮은 보일러플레이트를 만들지 않았다는 기쁨이 더 컸던 것 같다.

 

생각해보면,

개발책에서 말한 개념과는 다른, 초보적인 코드가 만들어지는 이유를 정리해보면,

1. 만들긴 했는데, 재사용은 안할 것 같아. 그리고 이 기능은 잘 안 바뀔 것 같아 -> 미래에 바뀜

2. 기획자가 그랬는데 이거 안바뀔꺼래 -> 미래에 바뀜 

3. 너무 귀찮아 그냥 대충 할래 -> 이것도 상당히 큰 것 같다. 

 

다음부터 만들때는

'그럴일은 없을 수도 있겠지만' 일단 재사용가능하게 만들자.

라는 마인드로 해야겠다.

 

아직 내가 약한 부분은 이름 짓는 부분인데,

이게 참 여전히 어려운 것 같다.

전진해야겠다.

 

 

친구들과 먹은 설빙 새로운 메뉴. 아주 폭력적인 맛이었지만 초코링은 진짜 너무 맛있었다.