Previous
기존 NextStep에서 블로그 스터디를 진행할 적에는(20년 11월 ~ 21년 7월) 따로 양식을 가지지 않고,
내가 주간 있었던 일을 그대로 회고하는 식으로 회고록을 작성했다면, 8월~11월 코드숨 스프링 과정중에는 제시하는 3fs + Affirmation 방식을 이용해 회고록을 진행하도록 하고자 한다.
Facts
•
회사 프로젝트로 남해 출장
•
코드숨 스프링 3기 1주차 미션 시작
⇒ 순수 자바를 이용한 Rest API 구현하기
•
CJ 올리브영 코딩테스트 참가
Feelings
회사 프로젝트 남해 출장
21년 초부터 진행했던 남해 스마트시티 컨소시엄 프로젝트에서 우리 회사에서 맡은 비대면 서비스 앱을 한정적 사용자(돌봄 대상자를 관리하는 관리사, 통합플랫폼 관리자, 공무원, 타플랫폼 직원 등등 25명 가량)들에게 교육을 하게 되서 목요일 남해로 출장을 다녀왔다.
왕복 8시간정도가 걸리는 거리에 운전을 하지못하기에 순천에서 남해 교육장까지의 이동을 위해 이사님도 같이 출발을 하였다.
당일 내려가서 교육 후 다시 올라오는 일정이기에 시간적 여유가 너무 부족했고, 코드숨 1주차 미션을 진행해야 하는시점인데, 이렇게 출장을 가는게 너무 스트레스였다.
약 2시간의 기차 이동 시간을 버릴 수 없어 기차 내에서 노트북을 펼쳐놓고 코드숨 강의를 시청했다.
다행히 멀미를 하지는 않았기에 피곤했지만, 1주차 업로드된 강의들은 모두 볼 수 있었다.
여기서 내 단점이 다시 한 번 나왔는데, 나는 성격이 너무 조급하기에, 이번 강의를 모두 끝까지 보지 않고 중간정도까지만 보다가 그냥 레퍼런스 링크해준걸로 공부해야지 하면서 안 봤었는데,
그 덕에 HttpServer를 이용해서 만들어야한다는 키워드를 못봐서 혼자 열심히 구글링하는 시간낭비를 해버렸다.
코드숨 스프링 3기 1주차 미션 시작
드디어 기다리던 코드숨 과정을 시작하게 되었다.
약 2년동안 프로그래머스 - 넥스트스텝 - 코드숨까지 시간을 돈으로 산다는 생각으로 많은 코드리뷰식의 교육과정에 참가를 했다. 최근 마지막으로 넥스트스텝에서 인프라공방 2기를 마치고, F-LAB과 코드숨 과정중 고민을 많이 했는데, 너무 올라버린 F-LAB가격(약 550만원 → 700만원)도 부담되었고, 교육 후기나 리뷰,회고를 중요시한다는 코드숨의 교육방침등에 코드숨으로 결정했고, 이렇게 미션에 참가하게 되었다.
현재 1주일이 끝나는 시점에서 내가 느끼는 점은 좀 혼란스럽다는 점이다.
내 코드에 리뷰 뿐아니라 다른 분들이 제출한 미션의 리뷰, 그리고 closed된 리뷰들도 참고하면서 인사이트는 확실히 많이 얻고 있다. 듣기를 잘했다는 생각도 하게 된다.
물론, 아쉬운점도 없지않아 있다. 인단 프로그래머스에서 백엔드 스프링과정을 참가할 때는 내가 너무 초보라서 메서드내에 기능구현하나 하는것도 힘들어서 제대로 못했었고, 넥스트스텝에서 진행하던 스타일은 어노테이션, 리플렉션, 디자인패턴 등등 사용에 제한이 없어서 이런 차이점에서 약간 혼란스러운 부분도 있다.
근데, 개발자에게 필요한 덕목 중 하나는 적응력이라고 생각하기에, 이런 환경에 적응을 하고 그 환경에서 추구하는 방향을 잘 따라가서 내 개발자 역량을 한걸음 더 나아가게 하기를 노력해야겠다.
CJ 코딩테스트
아 확실히 코테는 따로 준비나 공부를 안해서 그런지 힘들었다.
그리고 컬렉션 프레임워크를 너무나 자연스럽게 쓰다가 이런 부분들도 모두 제약이 되어보니 어리버리하게 작성을 하는 나를 발견할 수 있었다.
이제 자바나 네트워크, 스프링같은 공부도 좋지만 자료구조, 코테 등등 이직 관련된 학습도 시작을 해야 할 것 같다.
Finding
네이밍의 중요성
주로 지적받은 리뷰내용은 바로 네이밍이였다. 이정도는 괜찮겠지라는 마음으로 했던 요약변수명,
직관적이지 않은 메서드명, 의도를 드러내지 못하는 메서드명들은 모두 리뷰의 대상이 되었다.
그 중에는 내가 의도한 바대로 네이밍을 했다가 차후 기획이 바뀌며 로직이 달라졌는데 네이밍은 그대로인 경우도 있었는데, 이건 내 꼼꼼함의 문제인 것 같다. 좀 더 차분하게 내 코드를 살펴 볼 수 있어야 할 것 같다.
주석에서의 의존성
/**
* SendResponseData 클래스는 HttpExchange sendResponseHeaders 메소드에 들어가는 매개변수를 담고 있는 클래스입니다.
*/
public class SendResponseData { ... }
Java
복사
같은 기수의 다른 개발자분의 코드의 주석 일부분이다.
여기서 주석의 내용을 보면 SendResponseData 라고 자기자신 객체의 이름이 들어가 있는데, 이는 주석의 내용이 클래스 이름에 의존성을 가지게 된다는 것을 의미하고, 이는 변경에 취약해질 수 있다는 점을 내포한다. 이런 불필요한 의존성을 제거하는 주석을 작성해야 한다.
/**
* HttpExchange sendResponseHeaders 메소드에 들어가는 매개변수를 담고 있는 클래스입니다.
*/
public class SendResponseData { ... }
Java
복사
그 밖에도 특정 구현에 의존하는 주석도 작성해서는 안된다. /**
* Task 객체를 Json으로 변환후 문자열로 리턴합니다.
*
* @param task 할 일 객체
* @return String Json으로 변환된 객체
* @throws IOException stream 처리 중 예외가 발생한 경우 <- 구현에 의존한다.
*/
private String taskToJson(Task task) throws IOException { ... }
Java
복사
자바 8의 옵셔널(Optional)
이 포스팅을 예전에 본 적이 있음에도 따로 포스팅도 했음에도 나 역시 Optional을 제대로 쓰고 있지 않다. NPE를 예방하기위해 Optional을 과도하게 사용하거나 컴파일러에서 에러를 내뱉지 않는다고 필드로 사용하거나 하는 행위는 성능을 떨어트릴 뿐이다. 해당 포스팅을 보고 Optional을 제대로 쓸 수 있도록 하자. 다음 정리를 보고 지키도록하자. 만약 더 자세한 내용이 궁금하다면 위북마크를 들어가서 정독해보자.
1.
isPresent()-get() 대신 orElse()/orElseGet()/orElseThrow()
2.
orElse(new ...) 대신 orElseGet(() -> new ...)
3.
단지 값을 얻을 목적이라면 Optional 대신 null 비교
4.
Optional 대신 비어있는 컬렉션 반환
5.
Optional을 필드로 사용 금지
6.
Optional을 생성자나 메서드 인자로 사용 금지
7.
Optional을 컬렉션의 원소로 사용 금지
8.
of(), ofNullable() 혼동 주의
9.
Optional<T> 대신 OptionalInt, OptionalLong, OptionalDouble
Affirmation
비싼 과정 참가했으니 여기에만 집중해야지! 라는 핑계로 하던 공부들( 네트워크, 이펙티브자바, 인프런 스프링 강의, webRTC 구현 포스팅 등)을 모두 손 놔버리고 있는 상태다.
그런데 당장 슬랙 코드숨 과정만봐도 심지어 리뷰어분들까지 포모도로학습을 같이 진행하며 공부를 하고 있다. 그런데 이런 나태한 모습을 보이다니...
내일부턴 다시 나도 열심히 병행도 할수 있는대로 하면서 리뷰어분들도 괴롭혀야겠다...
(아니 괴롭힌다는게 아니라 질문을 많이 해야겠다는 의미다 )
)
