라라벨 과제 코드리뷰 후기 / 라라벨 과제 최종 리뷰

라라벨 과제 코드리뷰 후기

- 코드 리뷰 진행 시 반드시 예행 연습과 세팅을 완료해놓을 것. 화면 공유, 마우스 세팅. 그때 그때 해당 파일을 보여달라고 할 때 바로 보여줄 수 있어야 함. (기본 예의)

데모서버, vscode, db툴(테이블 출력해볼 수 있도록 할 것)

- 이번 라라벨 과제 결과를 볼 때 중요한 기준은 3가지.

1. 1:n 구조의 db를 잘 설계했는지

2. datepicker를 썼는지 (필수는 아니지만, 프론트 쪽 센스를 보려는 것)

3. 데이터 조회 시에 join 을 적절히 잘 활용했는지

- 데이터 형식을 맞추는 작업이 필요하다면, mvc 중 어느 단에서 처리하는 게 맞나?

=> 정답은 없고 상황에 따라 다름. control 단이 정석. model 에서는 db 관련 작업만, view 단에서는 데이터를 뿌려주는 작업만. 그러나 너무 많아지면 서버 부하가 커지기 때문에 간단한 작업이라면 view 단에서 해줄 수 있을 것. 만약 데이터 형식을 맞추고 공통적으로 지속적으로 쓴다면 모델 단에서 해줄 수도 있을 것.

- 라라벨 블레이드와 php 문법을 혼용하는 것이 괜찮나?

=> 이왕이면 하나로 맞추는 게 나음. 근데 어쩔 수 없는 경우에는 같이 써도 됨.

- php 파일 내에서 js 를 쓰는 건 괜찮나?

=> 각자 역할이 다르므로 같이 써도 되고 같이 쓸 수 밖에 없음. js 코드는 script 태그로 파일 내에서 불러오는 경우도 있고 따로 분리해서 import 해오는 방법이 있는데 각자 상황에 맞게 쓰면 됨. 

- where 조건을 걸 것은 없으나, 걸지 않으면 오류가 나는 경우에는 where 1+1 실무에서는 이런 식으로 씀. 이게 정석은 아니지만 어쨌든. 무조건 true 가 나오게끔 하는 것. 준형매는 where ~ not null 뭐 이런 식으로 걸었는데, 이 경우에는 어쨌든 db에서 실제로 not null 인지 확인하는 과정을 거치게 되므로 좋지 않음.

- 스크립트 쪽이 재밌었는지, db 쪽이 재밌었는지?

=> 사실 이번 db는 테이블 하나 만들어본 게 전부라 db를 했다고 말하기도 좀 애매하다. 물론 둘다 재밌지만 스크립트 쪽이 더 재밌고 아직 db는 미지의 영역.

- 만약 여기서 개선되서 name으로 테이블을 join 한다고 치면, 그것도 좋은 건 아님. name 을 잘못 입력할 수도 있고, name이 바뀔 수도 있고. 그러므로 name 같은 걸 key 로 잡는다기보다는 변하지 않는 idx 같은 걸로 하는 게 좋음

=> 근데 사용자 입장에서는 name은 입력할 수 있어도 member idx는 모르지 않나?

=> 그러므로 사용자가 name으로 검색해서 idx를 알 수 있게끔 하고, 그 idx를 입력으로 할 수 있도록 하면 됨.

- 실무에 들어가면 사실상 만들어진 것들 내에서 데이터를 뿌려주는 정도만 하게 될 것, db도 웬만한 건 건들지 못함. 일부만 다루게 될 거고 하던 것만 하게 될 것. 그러나 분명 그 구조를 이해하고 각 부분을 할 수 있으면서 일부만 하는 것과 아예 다른 부분은 모르고 못하면서 일부만 할 줄 아는 것과는 다름. 우리는 성장과 양성을 목적으로 데려온 것이지 바로 실무에 투입하려고 데려온 인력이 아니기 때문에 이 시기에 좀더 재밌는 걸 하는 걸 추천함. 리액트 같이 실제 우리 플랫폼에서는 안 쓰지만 쓰고 싶었던 기술이라든지. 지금은 있는 코드를 복붙해서 만드는 느낌이라면 아예 처음부터 본인이 만드는 프로젝트를 해보는 것도 추천.

- 프론트가 백에 요청하는 서버라는 건 api 서버임. 웹 서버를 띄우는 건 사실 프론트의 영역이고. 프론트는 여기까지다, 라고 본인 스스로 한정 지으면서 능력을 제한시키는 것은 좋지 않음. 

- 본인 로컬에서 테이블 만들어서 이것저것 해보길 추천.

- 리액트는 틈틈히 공부해둘 것. 무엇보다 기본에 충실할 것. 결국 기본 위에 쌓는 것이므로,,,

- 우리 회사 css는 기본적으로 부트스트랩을 쓰고 있으므로 부트스트랩 클래스명들에 익숙해지면 편할 것. sm-4 뭐 이런 것들 (디바이스 화면 사이즈별 클래스)

- 점심, 저녁을 따로 컬럼을 만드는 방법도 있지만, 하나의 컬럼에 두 개의 데이터를 넣는 방법도 있음. 식단이라는 컬럼 안에 배열 형식으로 점심, 저녁을 넣는다든지, 아니면 json 형식으로 넣는다든지 (이건 키 값을 가지므로, 나는 이 방법이 더 나아보였음)

- 이번 과제는 여기서 끝인가?

=> 여기서 더 딥하게 파고들 필요는 없음. 다음 과제로 넘어가게 될 것임.

다만, 이번 과제에 개선사항들이 조금 있음. 테이블을 새로 만들 수는 없을 것 같고. datepicker 혹은 validation을 주는 방법도 있을 듯. pagination 을 주는 방법도 있을 듯. (데이터를 일단 왕창 넣어서 페이지네이션 되는지 볼 것. 라라벨 자체 기능)

 

<준형매와 함께 개선시키기로 한 사항들>

1. pagination 코드 리뷰 및 구현 => pagination 코드 살펴보았고 기능 추가까지 완료

2. datepicker => input form 을 date로 바꿔서 나오는 기본 datepicker까지 했음. customizing 은 안 했음.

3. list를 불러오고 거기서 선택하면 그게 입력폼으로 들어가도록 구현 => 하려고 했는데 더 이상 기능 추가하지 말고 다음 과제로 넘어가는 게 낫겠다는 조언

 

라라벨 과제 최종 리뷰 

Questions

1. 라우팅에서 store, update의 경우에는 사실 post 만 받아도 될 것 같은데, get을 같이 안 받아주면 오류가 나서 get과 post를 둘다 받아줬다. 오류가 나는 이유는..?

2. 사실상 store와 update는 하나의 함수로 합칠 수 있을 것 같기도 하다. 이 둘을 합치는 것이 좋은 선택인지 궁금하고, 만약 그렇다면 합치는 방법도 궁금함. (처음에 ismethod 사용해서 post면 store, patch면 update로 하는 방법을 했었는데 안 됐음)

3. 엑셀비드 .env 에 있는 계정으로 db 접속하면 제대로 안 뜸. 어떤 문제인지?

 

Comment

- 이미 만들어진 프로젝트 안에서 구성품을 추가하는 거라, 참고할 자료가 많았고 복붙과 적절한 응용력만 있으면 할 수 있었으므로, 라라벨을 완벽히 이해했다고 보기엔 무리가 있다. 한편으로는 이미 만들어진 프로젝트인만큼 기존의 코드 스타일에 맞추어야 하고 구글링으로 나오지 않는 부분들도 많았으므로 오히려 0부터 100까지 나 혼자 만드는 프로젝트보다 어려운 점도 많았고 배우는 점도 많았다. 실제로 하게 될 일도 이런 부분에서의 능력이 필요하기도 하다. 하지만 여전히 기본이 부실한 느낌이 들고 있기 때문에 시작부터 끝까지 스스로 만들어보는 라라벨 프로젝트를 사이드로 진행해야 할 것 같다.

- db 설계가 이번 과제에서 사실 가장 의미있는 부분이라고 할 수 있다. 그리고 정답이 정해져있는 게 아니다보니 오히려 개발자로서의 센스, db 에 대한 이해가 필요한 부분이었다. 하지만 내 결과물은 오답이었으므로,,, 다시 한번 db 에 얼마나 무지했었는지 깨닫고... 정말 좁은 시야로 개발을 해왔구나 다시 한번 느꼈다. 그러니.. 공부나 열심히 해야겠다. 양질전화는 커녕,,, 그냥 양적으로 턱없이 모자라다. 일단은 열심히 많이 다양하게 공부하자.