수행 내용

• 프로그래밍 디자인 패턴 활동 학습
• 쥬스메이커 프로젝트 팀 배정 및 팀 그라운드룰 작성
• 쥬스메이커 프로젝트 Step 1 구현

학습 내용

활동학습 중 일반적 내용

• 코드를 작성하기 전에 미리 설계를 해보고 구현 해볼 것 (큰 삽질을 예방해준다)
• 코드의 재사용성에 대해 생각해볼 것 (메서드를 기능 단위로 분할했을 때 느낀 점, 묵찌빠 프로젝트 Step 1, Step 2에서 유사한 내용을 구현할 때 생각했던 점 회고)
• 프로젝트 기간이 지나면 프로젝트 회고, TWL, 고민했던 점, 어려웠던 점, 해결 방법, 사용한 문법, 시행착오 등을 README에 작성한다.
• 리뷰어 피드백, 코드와 관련되지 않은 것은 현직자가 무엇을 중요하게 생각하는지가 담겨있으므로 꼭 새겨들을 것
• 어떤 용어를 한 문장으로 설명하는 것은 어렵다. 이야기하기 위해 공부해야하는 양이 굉장히 많으니 항상 어떤 용어에 대해 간략하게 설명할 방법을 찾기 위해 스스로 공부해볼 것
• 지금 코드는 발전 폭을 보여줄 수 있는 지표이므로 보관 잘 해두고 이후에 다시 들여다보며 어떻게 개선할 수 있을지 고민해볼 것

프로그래밍 디자인 패턴

• 객체지향 소프트웨어에서 재사용 가능한 요소들을 설계하기 위한 설계 템플릿
• 천재 선배들의 삽질 기록물
• 주객전도 조심! 수단이 되어야하지 목적이 되면 안됨.

적절히 잘 사용하면,

• 객체 지향 프로그래밍의 다양한 문제상황에 대한 예방
• 프로그래머 사이의 협업효율 향상
• 프로그래머 사이의 의사소통 증진
• 코드의 안정화 및 최적화
• 코드의 재사용성 증가

예시
스타크래프트에 익숙한 사람이면 4드론이라는 이야기만 들어도 어떻게 전개될지 알 수 있다.
템플릿대로 똑같이 하지 않아도 됨. 템플릿 안에서 조금씩 변형해서 사용해도 된다.

현재 시점 충고사항

아직은 패턴에 따라 직접 만들어보려 애쓰지 말고 사용 중인 프레임워크(라이브러리)에서 찾아볼 것

디자인 패턴 VS 아키텍처

• 아키텍처 (Architecture): 소프트웨어 전체 설계에 적용할 양식 (건축 양식과 유사)
• 디자인 패턴 (Design Pattern): 세세한 문제를 해결할 수 있는 해결 방식 (아키텍처에서 발생하는 자그마한 문제를 해결)

iOS 아키텍처

애플은 MVC (Model-View-Controller) 아키텍처 사용한다고 표현

어떤 요소들을 패턴으로 만들어두었을까? 어떤 기준으로 나눌까?

source: https://commons.wikimedia.org/wiki/File:ModeleMVC.png

• 이 친구들이 데이터들을 다룰 친구들이냐 (Model),
• 화면을 다룰 친구들이냐 (View),
• 중간 다리를 담당할 친구들이냐 (Controller)

• Model, View, Controller는 모두 객체이며 구조체, 클래스와 같은 타입으로 표현한다.

정적 웹과 동적웹

유튜브 얄팍한 코딩사전 채널 "정적 웹은 뭐고 동적 웹은 뭔가요?" 컨텐츠를 보고 작성하였습니다.
https://www.youtube.com/watch?v=C06xRvXIAUk

정적 웹

source: https://commons.wikimedia.org/wiki/File:Scheme_static_page_en.svg
움직이지 않는, 언제 접속해도 같은 리소스를 건네주는 웹사이트. 정적 웹사이트에 접속하면 서버는 마치 진열대에 놓인 상품처럼 이미 프로그래머가 작성해 놓은 파일들을 그대로 클라이언트의 브라우저에 전달한다. 그렇다고 접속할 때마다 같은 화면을 보여주는 것이 정적 웹은 아닌데, 현재 날짜와 시간을 표시하는 페이지, 랜덤 함수로 매 번 다양한 화면을 보여주는 페이지, 서버에 직접 추가적인 내용을 요청해서 받아오는 페이지 등이 있을 수 있기 때문이다. 정적 웹의 기준은 접속할 때마다 받게 되는 HTML, CSS , JavaScript, 이미지, 동영상 파일들의 동일 여부이다. 서버에서 가공해서 제공하는 것이 아니라 프로그래머가 작성한 제품들이 진열되어 있는 것을 그대로 가져가게 하는지 여부이다. 접속할 때마다 내용이 변할 필요가 없는 사이트들인 회사, 학교 소개 페이지, 댓글 기능이 없는 블로그를 예시로 들 수 있다.

동적 웹

source: https://commons.wikimedia.org/wiki/File:Scheme_dynamic_page_en.svg
데이터베이스의 정보를 읽어서 접속할 때마다 최신 정보들을 보여주는 웹페이지

MVC 웹 프레임워크

유튜브 얄팍한 코딩사전 채널 "MVC 웹 프레임워크가 뭔가요?" 컨텐츠를 보고 작성하였습니다.
https://www.youtube.com/watch?v=AERY1ZGoYc8

source: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

요소와 기능들이 많아지고 구조가 이것저것 얽힐 수록 코드가 길어지고 난해해진다. 거대해지고 복잡해질 때는 특정 기준으로 분리, 모듈화해서 접근하곤 한다. 웹사이트를 비롯한 소프트웨어는 Model, View, Controller (MVC) 접근법이 많이 사용된다.

• Model: 데이터에 관련된 것. 예시를 확인하자.
• View: 눈에 보이는 것. 웹의 경우 HTML, CSS
• Controller: 무언가를 제어하는 것. 프로그래밍이 이 부분에서 많이 이루어진다.

게시판 예시

• 게시판에 쓰이고 읽히고 수정되는 글들은 데이터베이스의 데이터로 저장된다. 이 데이터의 형식을 지정하고 저장하고 불러오는 작업들에 관련된 코드들이 Model 파트에서 이루어진다.
• 사용자들이 목록과 글, 입력화면 등으로 시각적으로 볼 수 있게 해주는 HTML, CSS 등의 요소가 View 파트에 작성된다.
• 이 둘을 연결해주는 부분, Model의 데이터를 View에 연결해서 사용자가 GUI 화면을 통해 데이터를 읽고 쓰고 지울 수 있도록 전반적 제어를 하는 파트가 Controller 파트이다.

레스토랑 예시

• Model: 식료품 창고를 관리하고 음식을 요리하는 주방장
• View: 주방장이 내온 음식을 플레이팅 하는 직원
• Controller: 주문도 받고 서빙도 하는 매니저

문제점 / 고민한 점

쥬스메이커 프로젝트에서의 MVC 요소

기능 명세서를 통해 MVC 요소들을 어떻게 나눌 수 있을지 고민해보았다. 앱 개발은 처음이라 정석대로 분리하기는 어렵지만 프로젝트 진입 전에 전체적인 설계와 같이 고민해볼 요소들은 미리 하면 할수록 실제 구현에 드는 시간이 절감되는 효과가 있는듯하다.

하나의 메서드로 모든 +, - 버튼에 대응할 수 있을까?

과일 재고의 관리버튼이 과일별로 존재하는데 하나의 메서드로 대응할 수 있는 방식에 대해 고민해보았다.

코드를 어떻게 작성하면 유지보수가 용이할까?

계속 해야할 고민이지만, 가독성 (이해의 편리함)과 절대적인 코드량과는 현재 시점에서는 상반되는 관계처럼 느껴져서 어느정도 절충이 필요해보인다.

해결 방법

• 아직까지 해결된 고민은 없다. 앞으로 지속적으로 해야할 고민이거나 프로젝트 중 해결될 고민도 있다.
• 나름대로 나누어본 MVC 요소
  • Model: 과일 재고
  • View: 화면 UI요소 (제목 레이블, 과일 이미지, 현재 재고, 각 주문버튼, 재고 수정버튼, 재고 추가제거 레이블 및 버튼, Alert 화면 (애매함))
  • Controller: 각 주문, 재고 수정, +/- 버튼, Alert와 같은 상호작용에 따라 구현할 기능
• 연산프로퍼티를 활용해 메서드의 파라미터로 활용한다면 가능해보인다.
• 로직이 아무리 뛰어나도 다른 개발자가 이해하기 어렵다면 유지보수가 어려울 것이다.
• 현재 하는 생각은,
  • 최대한 이해하기 쉽도록 풀어쓰고, 의미없는 정수와 같은 요소들의 사용을 지양하자.
  • 향후 기능 명세 변경, 유지보수 시 최대한 기존에 작성한 코드를 수정하지 않게끔 설계하자.