2주차 회고

2주차 공통 피드백을 봤는데 찔리는 내용이 너무 많았다.. 그래서 한 번 첫 회고록을 작성해보고자 한다.

이번 일주일 동안 있었던 일

이번 일주일은 우태코 2주차 미션을 마치고 딱히 한 게 없었다. 처음에는 백엔드 공부에 대한 열정이 강했지만 요즘은 뭘 할지 헷갈리기도 하고 전체적으로 열정이 떨어진 거 같다... 중간고사 마치고 수업도 딱히 열심히 듣지 않았다. 미션은 열심히 했지만 다른 것들은 꾸준히 열심히 하지 않았다. 프리코스는 단순 경험이라고만 생각하니까 꾸준히 뭘 하고 싶은 것도 사라졌다. 아무튼 그런 일주일이었다.

느낀것

1. 이번에 처음으로 docs를 자세히 작성한 것 같다. 간단한 로직이지만 readme파일에 정리하고 구현하나 안 하나 차이가 크다고 느꼈다.
2. 메서드에 하나의 기능만 부여해달라는 공동 피드백을 보고 그러려고 노력했는데 막상 해보니 코드 가독성도 좋고 의미가 컸던 것 같다.

   배운점

   클래스 작성 순서

   static, fianl 같은 상수나 클래스 변수 -> 인스턴스 변수 -> 생성자-> 메서드 순으로 작성한다.변수 이름에 자료형은 사용하지 않는다. ❌변수 이름에 자료형이나 자료구조를 사용하지 않는 점이다.

   String carNameList; 

   이런식으로 List라는 자료구조를 사용하지 않는다. 이유는 모르겠지만 난 알아보기 쉽게 하려고 그랬는데 실천해봐야겠다...

   함수가 한 가지 기능을 하는지 확인하는 기준을 세운다.

   여러 함수에서 중복되어 사용하는 코드가 있다면 함수 분리를 고민한다.
   한 메서드가 15줄 이상을 넘기는지 가이드라인을 세워본다.

   Readme 파일 기능 목록을 계속해서 업데이트 한다.

   기능 목록은 구현을 하며 변경될 수 있기 때문에 계속해서 업데이트 한다.

   Readme 파일은 자세히 작성하지 않는다.

   ⭐️ 기능 목록을 클래스 설계와 구현, 함수 설계와 같이 너무 상세하게 작성하지 않는다. ⭐️

   이 부분이 내가 크게 깨달았던 점이다. 내 전 docs 파일을 보면 엄청나게 자세히 써둔걸 볼 수 있다.. 왜그랬지 자세히 쓸수록 좋다고 생각한 거 같다 하하하!!
   이유는 클래스 이름과 함수 시그니처, 반환 값은 언제든지 변경이 될 수 있기 때문이다. 너무 세세한 부분까지 정리하기 보다는 구현해야할 기능 목록을 정리하는데 집중한다.

앞으로

공통 피드백에 테스트 코드 구현하는 게 있었는데 한 번도 사용해보지 않았던 기능이다...테스트 하는 법을 공부하면 좋을 것 같다.
지금은 열정이 많이 죽어서 놀고 먹고 그냥 일주일 중에 5일은 자빠져있는데 (당연하지않음...난 4일 학교가는 학생임....) 좀 정신을 체렸으면 좋겠다
티스토리를 네이버 블로그처럼 쓰네 나