[우아한 테크코스 2주차] 2(주)차 전직 미션 회고록

이번 주차 미션은 위 gif와 같이 야구와 관련한 미션이었다.
2주차 미션
그리고 다음은 이번에 작성한 코드이다.
2주차미션 코드

🧐 이번 주차는 체계적으로

2주차에서는 1주차와는 달리 처음부터 무작정 코드를 작성하는 것이 아니라 최대한 설계를 우선하고 코딩을 하는 식으로 진행을 하게 되었다. 물론! 철저하게 설계한대로 계속 가지는 않고 중간 중간에 떠오르는 방식들과 예외들이 생겨서 수정을 하긴 했다!🙄🙄
그래도 이렇게 진행해서 느낀 것은 크게 다음과 같았다.

• 장점 : 체계적으로 작성을 하다보니 코딩을 진행하다 발생한 문제들에 대해서 쉽게 발견할 수 있었다(추가해야할 예외라던가, 빼먹은 기능들이라던가), 코드를 다시 보는데 명확하게 볼 수 있었다.
• 단점 : 내 속이 너무 답답해졌다.

😲 단점이 너무 간단한 거 같다.

단점이 되게 간단하게 속이 너무 답답해지는 것이었는데 -> 이는 체계적으로 명확한 의미를 가질 수 있도록 변수명을 짓고 메서드 명을 짓고 하는 과정에 있어서 기존에는 10초안에 만들었다면 이제는 만들기 위해서는 상당히 많은 시간을 투자해야 그에 대한 결과물이 나온다는 것이었다. 그저 이때까지 이상하게 가지고 있었던 나의 습관의 반항을 할려고 하기에 너무 속이 답답해진 거 같았다. 그래서 이는 그저 정상적으로 변화하기 위한 과정이라고 생각하고 꾹꾹 누르면서 최대한 체계적으로 짜보려고 했었다.

😲 장점은?

단점으로 되게 속이 답답하다고 느낀 점이었는데 물론! 이건 코드를 구성하는 과정에서 되게 답답했다는 것이었다. 이게 나중에 장점으로 바뀌게 되었는데 일단 구성하는 기능들을 완성하고 다시 코드를 보는 과정속에서 이런 답답한 것들이 다 풀린 것 같은 기분을 되게 많이 느끼게 되었다. 그제서야 이게 체계적으로 구성하는 단계속에서 나중에 유지 보수를 하거나 잘못된 것을 고쳐나가는 과정에서 아주 중요한 것이라는 것을 다시 알게 되는 과정이었다. 다시 보면 다시 볼 수록 과거에 지녔던 습관보다는 이렇게 체계적으로 과정을 설계하고 구성해나가는 것이 멀리 나아가보면 다른 사람들과 함께 공유해가면서 서비스를 유지하고 보수해나가고 코드들을 뜯어 고치는 과정들은 결론적으로 코드를 체계적으로 설계하고 의미를 명확히 부여해야만 다 같이 편해지기 위한 약속이라는 느낌을 되게 많이 받게 되었다. 그렇기에 장점으로 체계적으로 작성을 한 것에 대한 결과들에 대해 적었던 것이다.

🏸 이번 주는 찾던 것과 생각했던 것을 기록하기로 했다.

길어서 내려가셔도 됩니다 😅😅

• assertRandomNumberInRangeTest
• output().contains()
• git rebase
• 컨트롤 + 알트 + l 을 통한 코드 컨벤션 동작
• 왜 비 static 변수는 static 컨텍스트에서 참조할 수 없는지
• static 관련 discussion
• Assertj assertThatThrownBy: Assertj assertThatThrownBy
• indent depth? 어느 기준의 깊이일까?
• 간단한 조건문도 함수처리하여 알아보기 쉽게 처리하는 것이 좋다! → 근데 코드 길이가 길어지는데 어떤게 더 좋을까?
• 토론할 점:
  항상 이런 딜레마에 빠지곤 합니다.
  코드를 리팩토링을 하는 과정에 있어서 여러분께서는 다음과 같은 코드가 있다면 어떻게 리팩토링하는것이 좋다고 보이시나요?
  if(a.get(i) == b.get(j))
  if(isSame(a,b,i,j))
  이렇게 하는 대신 메서드 생성으로 인한 코드의 길이가 전체적으로 늘어나는 경우
  private static boolean isSame(List a, List b, int i, int j)
  {
  .
  .
  .
  }
  여러분들은 어떻게 생각하시나요? 보시나요?
  의견이 반반으로 나뉜다.
• Character.getNumericValue(char type)
• 깃 컨벤션
• feature : 새로운 기능 추가
• fix : 버그 수정
• docs : 문서 수정
• test : 테스트 코드 추가
• refactor : 코드 리팩토링
• style : 코드 의미에 영향을 주지 않는 변경사항
• chore : 빌드 부분 혹은 패키지 매니저 수정사항
  깃 갑자기 rebase하다가 통으로 다 날라갔을때 복구 방법 - 로컬 저장소에 커밋 기록들이 다 남겨져있음 오우 신이시여~~~ 다행이다…발견한 복구 방법
• 어떤 시점에 commit을 끼워넣고 싶다면 참고 할 것 대신 끼워넣기할때는 자신이 끼워넣고 싶은 것의 앞 위치로 rebase하여 거기에다가 넣어놓기 그리고 만약 뒤에 충돌이 생긴다면 다 skip 때리거나 해야하지만 너무 위험부담이 컷었음. 너무 어려웠다. ㅠㅠ
  깃 컨벤션: https://www.conventionalcommits.org/en/v1.0.0/
• 클래스로 각 기능 분류해보기 - domain, game, main부분
• 예외처리 알파벳 기능 - check
• 코드 depth 3 이 되는 것 확인하기
• 요구사항 다시 한 번 더 확인하기
• 출력형식 수정 (0볼 0스트라이크 이런건 없음) 하나가 0이면 그냥 없애고 볼 이나 스트라이크만 출력해야함.
• 테스트 명 수정 정리하기
• static 뗄 수 있는건 다 떼보기
• stream 활용하여서 이중 포문 없애보기

for (int i = 0; i < 3; i++) {
     for (int j = 0; j < 3; j++) {
         overlapCheckProcess(userNumber, i, j);
     }
 }
private void overlapCheckProcess(String userNumber, int i, int j) {
        if (i == j) {
            return;
        }
        char nowIndexUserNumber = userNumber.charAt(i);
        char otherIndexUserNumber = userNumber.charAt(j); // 여기 depth 3
        inputOverlapCheck(nowIndexUserNumber, otherIndexUserNumber);
    }
public void inputOverlapCheck(char nowIndexUserNumber,
        char otherIndexUserNumber) {  // test 입력시오류경우_확인
        if (nowIndexUserNumber == otherIndexUserNumber) {
            throw new IllegalArgumentException("입력 숫자중 중복");
        }
    }
  // 위 코드가 아래 코드로 바뀌게 된다.
Stream<String> overlapCheck = Arrays.stream(userNumber.split(""));
long count_exceptDuplicate = overlapCheck.distinct().count();
if (isDuplicate(userNumber, count_exceptDuplicate)) {
    throw new IllegalArgumentException("입력 숫자 중복");
}

• stream 관련 아고라 토론
• https://github.com/orgs/woowacourse-precourse/discussions/381
• stream 관련 영상
• https://www.youtube.com/watch?v=7Kyf4mMjbTQ&ab_channel=남궁성의정석코딩
• 스트림은 데이터 소스를 표준화된 방법으로 다루기 위하여 나오게 된 것이다.

1. 스트림 만들고 2. 중간연산 3. 최종연산 3단계로 작업을 처리하게 됨.
2. 중간연산의 과정은 총 n번 진행이가능하다.
3. 최종 연산의 과정은 1번만 진행이 가능하다.
4. intstream, doublestream, longstream 을 통하여서 오토박싱, 언박싱 비효율이 제거된다.
   기존에는 Stream여서 Integer로 변환을 해줘야하는데 큰 데이터들의 경우 너무 효율이 좋지 않다.
5. 연산만 할 뿐 실제 컬렉션을 변경시키지 않는다.
6. 최종 연산 이후 stream은 닫히기 때문에 다시 부를 수 없다.(일회용이다.)
   제출 전까지 한번 리팩토링 계속 확인해보기
   리드미 요구사항 다시 확인하면서 체크하기 ✔
   • Java 코드 컨벤션 가이드를 준수하며 프로그래밍한다. ✔
   indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다. ✔

• 좀 실망스러운 부분: getball에서의 인수 - 너무 많이 들어감. ㅠㅠㅠ 이거 줄여보려고 햇는데 이게 코드끼리 엮이다 보니 줄이질 못함.

😂 아무튼 이렇게 많이 찾고 고민을 했다.

이렇게 작성하면서 느끼게 된 것이 생각보다 이 2주차를 위해서 많이 검색하고 했다는 것에 있어서 이 프리코스 과정을 통해서 성장을 위해 되게 발버둥친다고 해야할까? 라는 느낌을 되게 많이 받았다. 하면 할 수록 이 과정 자체가 살이되고 양분이 되어간다는 느낌일까? 그리고 일단 필독서라 사놓긴 했지만 잘 읽진 않고 있었던 Clean Code책도 읽게 되고 참 신기한 현상이다 😂😂

😅 그럼 지금의 코드에 대해서 만족하나?

원래 자신을 만족시키는게 가장 어렵다고 했던 것처럼 아직은 아니다. 그치만 과정을 거치면 거칠수록 점점 깨끗해지려고 하는 것과 함께 개선해나갈 점도 하나씩 보여가는 것 같다. 점수를 매기고 싶다면 한 55점 정도 되는 거 같다. 아직 제대로 이해하지 못하는 부분도 있고 말이다. 남은 점수들은 계속해서 이어져가는 뒤에 주차의 내용에서 계속해서 얻어갈 수 있도록 해야겠다.

❗ 결론

이렇게 위에 작성했던 것들을 보며 진짜 검색도 많이 하는 과정을 통해서 성장이라는 경험을 하게 되는 거 같다. 이를 빗대어 설명하면 1주차 1주차가 뭔가 전직퀘스트를 하는것처럼 매주마다 퀘스트가 나오고 쉽지는 않지만 해결하게 된다면 여러 가지 skill과 새로운 능력치들을 얻어가게 된다. 물론 이제 1차 2차 전직했으니 나머지 3차 4차 전직 퀘스트를 수행해야 하는데 이는 더 어려울 수밖에 없을 것이다. 그렇지만 이것을 수행하고 성공하게 되었을 때 얻게 되는 skill과 능력치들은 그 어려움에 비례할 만큼 높은 보상임을 알고 있기에 다음 주차에도 더욱더 고민해보고 힘든 1주를 버텨나갈 수 있도록 열심히 해야겠다!