top-down/bottom-up 방식 채택에 관해

 

to do list 📋

✅ 프로그래머스 커밋하기

✅ 개인 프로젝트 회고하기

✅ 깃허브 관리

✅ java 쓰레드 공부하기

 

총 순공부시간

 

Today I Learned 👨‍💻

📕 기획 단계에서..

order-system을 만들어보고 있는 와중에 screendata를 kiosk화면에 println으로 다 출력하고 싶지 않기도 하고 현업에서 가시성 좋게 package와 class로 세분화하고 알맞는 데이터끼리 분류될 수 있게 만들어보고 싶었다 (괜히 덤볐다가 큰 코를 다치게 된다..)

나는 객체지향적인 설계 중에 bottom-up방식인 큰 틀을 먼저 만들고 하나하나 구현해나가는 것이 나에게 더 맞다고 생각하고 이어나가봤는데 여기저기서 예상치 못할 구현해야 할 메소드들이 터져나가는 것을 보았다. 나는 아직 잘 하는 개발자가 아니기에 필요한 작은 클래스부터 하나하나 키워나가야 하는데 현업에서 class를 상속하는 것보다 interface를 implements를 하는게 맞다느니, println으로 메뉴판을 그냥 출력하면 될걸 나중에 객체지향적으로 개발하기 위해 나중에 추가될 애들을 위해ㅋㅋ enum으로 묶어주느니.. 나중에는 이렇게 만들어봐야하는 것은 분명 맞는 말이지만 이렇게 만들어보자라는 욕심이 리빌딩을 해야하는 지경까지 이르게 되어 계획했던 기간에서 시간이 많이 촉박해졌다.

 

📗 top-down방식 bottom-up방식의 개념 및 채택 방식에 대해

top-down의 경우 높은 추상화 수준에서 시작한다. 예를 들어 냉장고의 문을 열어 음식을 집는다고 가정했을 때, 문을 열면 음식 리스트가 나온다!를 시작으로 설계를 시작하는 것이고 bottom-up은 구체적인 것부터 시작해서 일반적인 쪽으로 작업하는 것을 말한다.

top-down은 설계가 쉽지만 세부 사항 구현을 미루어 혼란스러워지고 최하위 부분에 있는 클래스를 구현하기 까다롭다는 것이다. 시작은 간단하지만 복잡성이 필요이상으로 복잡해질 수 있다는 점이다. bottom-up은 초기에 필요한 기능을 파악할 수 있어서 간결하고 잘 구성된 설계가 만들어질 수 있을 가능성이 크지만 내가 오늘 느낀 것처럼 초보개발자일수록 더더욱.. 구현하기 빡셀 수가 있다. 둘 다 프로젝트를 하면서 여러 방식으로 써봐야 성장할 수 있는데 둘 중 어느 하나가 좋다고 말할 수 없고 상호보안적인 개념이니 설계를 함에 있어서 어떤 것이 나의 상황에 좋은지 생각을 해야하며, 많은 시행착오가 필요하다는 것을 느꼈다.

 

다음 계획 

order-system을 다시 top-down 방식으로 처음부터 리팩토링하기