3 minute read

오늘 작성 할 키워드


  1. 놓친 예외 사항
  2. code review, left -> right, right -> left
  3. static, final, constant(Hard coding)
  4. test

놓친 예외 사항


가장 아쉬워서 기억에 남는 것 같다.
자동차 경주 게임인데 상대가 없는 경우를 생각을 못했다.
빈 문자열이나 null 값, 음수 등 당연한 것들을 생각했고…
기본적인 게임, 경주가 있고 우승자가 있는데 그것을 생각을 못했다.
그 이유는 테스트 케이스 부족과 내 프로그램을 가지고 놀면서 런 해보고 직접 입력을 해보고 즉각적인 결과를 보면서 놀았다면…
떠올랐을 것 같다는 생각이 들면서 여러 각도에서 바라보는 것이 중요하다는 것을 깨달았고 무엇보다 협업도 중요하다고 생각이 들었다.
왜냐하면 여러 사람들의 시선으로 사각을 줄이는 것이 예외 사항을 다루는데 좋을 것이라는 생각이 들었기 때문이다.
또한 앞으로의 변동 사항 예측 불가능한 사항들에 스트레스 받기보단 즐거움으로 받아들여야겠다고 생각도 한편으로 든다.
결론 에러를 즐기자, 놓쳐버렸지만 덕분에 이 또한 나의 기억에 오랫동안 강렬하게 남을 수 있기 때문이다 하하..

두 번째 code review를 하면서..


솔직하게 말하자면 첫 시작에는 너무 설레었고 시작하자마자 괴로웠다.
다른 사람의 코드를 읽는다는 건 다른 사람의 사고를 이해할 수 있고 따라갈 수 있어야하는 것 같다.
나와 비슷한 건 너무 잘 읽히고 낯선 코드는 봐도봐도 모르겠고 너무 힘들었다.
1주 차때는 그럴 때 전체적으로 보면서 넘겼던 것 같다.
정확히 모르면서 아는 척, 그랬기때문에 토론적 리뷰를 못했던 것 같다.
그 댓가가 이번 2주차때 더 강하게 온 것 같다.
그래서 내가 한 도피처는 바로 왼쪽에서 오른쪽으로 읽고 오른쪽에서 왼쪽이다.
정확히 무엇이 어디에서 호출되고 생성되고 무엇이 입력으로 들어가서 무엇이 반환되고 그러한 것들을 정말 세세히 보려고 했다.
시간은 평소보다 5배는 더 걸린 것 같다.
대신 오늘 하루지만 배우고 느낀 것이 정말 정~~~말 많은 것 같다.
modifier에 대해서 자세히 생각하게 되고 모르는 문법이 나오면 찾아 보게되고 인터페이스 등 동료들이 사용하는 것들을 모두 이해할 수 있는 과정을 거치는 것 같다.
완전 책이 필요없다고 느낄 정도였다.
좋은 코드인지 나쁜 코드인지 지금의 나로선 알 수 없고 많이 읽으면서 나만의 기준과 판단력을 높이는 것이 우선이라고 생각한다.
이번 코드 리뷰를 통해서 느낀 것이 앞으로의 길에 있어서 너무 크다고 생각한다.
앞으로 보게 될 코드들이 즐겁게 느껴진다, 다만 시간이… 시간아.. 시간을 멈추고 싶다 ㅎㅎ 일주일이 하루였다면!!

static, final, 하드코딩


static과 final은 public과 private와 다른 것들인 줄 알았다.
자세하게 접근을 안했던 것이 이번 기회로 들어났다.
modifier에 대해서 알게 되니깐 좀 더 쉽게 느껴졌다.
우선 이게 무엇인지 인지를 하고 나니깐 더 기억하기 쉬워진 것 처럼?

생각나는 대로 가지고 놀아봤다 예를 들면)

  • modifier public static final 모두 제어자, static은 클래스==설계도 안에서 살아 움직이는 NPC처럼 static 멤버들은 클래스 자체에 속해 있어 객체 없이도 독립적으로 동작할 수 있습니다. 객체는 설계도를 따라 생성된 캐릭터라면, static설계도에 항상 존재하는 공통된 기능을 의미한다고 볼 수 있습니다.

    ### 핵심 정리

    1. final 참조와 상태 변경:
      • final은 참조(변수가 가리키는 대상)를 고정합니다. 즉, final이 붙은 변수는 다른 객체를 가리킬 수 없습니다.
      • 하지만, 참조된 객체의 내부 상태(필드 값)는 자유롭게 변경할 수 있습니다. 예를 들어, final Mode mode는 다른 Mode 객체로 바꿀 수 없지만, mode가 가리키는 객체의 속성은 변경할 수 있습니다.
    2. 참조된 객체의 상태 접근 방법:
      • 객체의 상태나 속성을 변경하려면 해당 객체에 메서드가 필요합니다.
      • 메서드가 없다면 외부에서 객체의 상태에 접근하거나 변경할 방법이 없습니다.
    3. 정리된 비유:
      • *팔(참조)은 고정되어 다른 대상을 가리킬 수 없지만, **그 팔이 가리키는 대상의 속성은 바꿀 수 있습니다.
      • 상태를 변경하려면 대상이 메서드를 제공해야 합니다. 메서드가 없으면 외부에서 상태를 조작할 수 없습니다.

이런 식으로 작성을 해봤다.
또 조금 전에 하드 코딩 관련된 2차 공통 피드백을 보고 static과 final에 대해서 또 알아갔다.
가비지 컬렉터와 스택과 힙 new를 이용한 생성했을 때 힙, static을 선언했을 때 스택에서 등
이런 것들을 쌓아가며 정식 회고에서 정리를 싸악 해봐야겠다. (너 정식 회고 언제할거니?..)
크흠.. 핑계를 달자면 하루를 너무 열심히 살다보니 논리정연한 멋진 회고를 쓰기가 정신적으로 부담된다.
이렇게 글 쓰는 건 하루종일 시켜도 쓸 수 있는데 말이다.
상수에 대해서 처음엔 변수 사용을 하지 않았다.
1주차 다른 분들과 코드 리뷰를 하며 따라하게되었다.
그 이유는 멋져보였나보다.
사실 사용하면서도 오히려 위로 갔다가 다시 봤다가 불편하다고 생각했기도 했다.
상수 그 자체로 이해를 쉽게 하는 면도 있다고 생각했기때문이다.
재활용되거나 자주 값이 변경되는 목적이 아닌 경우에는 상수화 안하도록 해야겠다.
이것을 하드코딩이라고 하는건가?? 메세지에 대해서는 어떤 대처를 해야할까? 고민을 해봐야겠다.

test


사실 지금 체력이 다 빠져서 무슨 정신으로 작성하고 있는지 모르겠다.
이래서 정신은 육체가 지배한다고 하나보다, 체력을 키우자 체력이 곧 국력!..아니 자산이다!! 이번 과정에서 또 드는 아쉬움은 테스트이다.
테스트에 대한 스터디를 줬는데 열심히 참여해보고 테스트 라이브러리도 하나씩 잘 까봐야겠다.
까볼 것이 너무 많아서 행복하다.
오늘은 여기까지!

Updated: