TIL 양식

Facts (사실, 객관)

• 오늘 회사에서 구현하다가 설계가 잘못되었다는 사실을 발견하고, 이를 고치기 위해서 다시 설계를 하고 여태까지 작업한 내용을 거의 다 버리게 되었다.

• 오늘 회사에서 새로운 테이블 설계를 하였다.

• 내가 오늘 생각하고 배운 것들을 코드숨에서 의견을 나누어 보았다.

Feelings (느낌, 주관)

• 다시 설계를 할 때, 뭔가 시간을 많이 사용하지 못하는 것 같다. 어색하기도 하고 막상 동료랑 같이 이야기를 하다보니까 뽀죡한 수가 떠오르지 않았다.

• 동료들과 해결책을 생각할 때, 그냥 말로만 하고 흘러가니까 나중에 남는 것이 없었다. 따라서, 이야기만 할 것이 아니라 말했던 내용들을 글로 남기고 이를 기록하도록 해야겠다.

• 일을 할 때, 동료와 신뢰를 쌓는 것이 굉장히 중요하다는 것을 느끼게 되었다.

• 일도 훨씬 잘되고, 내가 진행 한 것을 공유하는 것이 편했다.

• 새로운 테이블을 설계할 때, 이름을 짓는 것이 굉장히 어려웠다. 따라서 일단 이 테이블을 만들게 된 이유 및 이 테이블의 역할이 무엇인지를 생각했다.

• 결론적으로는 문제가 무엇인지 명확하게 이해하지 못해서 발생한 것들이 많다.

• 버스에서 그냥 시간을 보내는게 아까웠는데, 코딩 테스트 문제의 해결책을 생각하면서 가는 것이 좋을 것 같다.

Findings (배운 점)

• 설계를 꼼꼼히 검증하고, 유연한 설계를 하도록 해야겠다.
• 동료들에게 신뢰를 쌓으려면, 내가 노력해야한다.
• 변수명, 함수명, 클래스 명을 짓을 때 어려운 이유는 역할과 필요한 목적을 잘 정의하지 못했기 때문이다. 따라서 어떤 클래스, 메서드의 역할에 대해서 정의를 해보고 이름을 짓는 방법을 사용하는 것이 어떨까 하고 생각을 해보았다.
• 나의 문제는 문제를 제대로 이해하지 못하는 것에서 온다. 어떻게 하면 문제를 더 잘 이해할 수 있을지를 고민하자.
• 출 퇴근 시간에 코딩 테스트 문제를 정하고 이를 구글 킵에 메모를 하는 것이다. 그렇게 한 후에 내가 생각한 문제 풀이를 적어두고 구현은 시간이 날 때하는 것이다.
• 내가 정말로 어떤 것을 알고 있다면, 그것을 말로 누군가에게 설명할 수 있을 정도가 되어야겠다고 생각했다.
• 오늘 주간 보고를 하는데, 내가 한주동안 진행한 일도 제대로 설명하지 못했다. 따라서 주간보고 때 내가 진행한 일들을 논리정연하게 설명할 수 있도록 해야겠다.

• 현실적으로 설계가 완벽하게 되기는 힘들다는 의견이 있었고, 미쳐 생각하지 못하는 부분은 필연적으로 나타나게 된다. 따라서 피드백 주기를 짧게 하고, 공유를 자주하는 문화가 필요하다.

피드백 주기를 짧게 하고, 공유를 어떻게 하면 잘 할 수 있을지 고민을 해봐야겠다.

• 따라서 실험을 자주하되, 실험은 비용을 동반하기에 유연한 설계를 통해서 변경이 쉽도록 만드는 것이 최선이다.

• 잦은 공유, 회고를 통한 개선, 코드숨에서 실천하는 것을 팀에서 하나씩 실천해보도록 노력해봐야겠다.

• 문제를 막는 것보다 최대한 빨리 문제를 발견해서 적은 비용으로 새로 만드려고 한다. 테스트를 먼저 작성하는 것도 구현 전에 문제점을 찾아내서 수정하려는 노력의 일환이다.

• 수정하기 좋은 코드는 작성하지 않은 코드이다. 그리고 변경은 피할 수 없는 숙명이라고 생각하면 좋은 설계 = 쉽게 변경할 수 있는 구조라는 접근이 가능하다.

• 불확실성이 높고 변화가 빠른 요즘은 적응할 수 있는 능력이 중요하다.

• “후회"는 사람마다 조직마다 기준이 다르다. 따라서 “우리는 언제 후회할까?“를 놓고 함게 논의를 해보면 좋은 방법이 나올 것이다.

• 일하는 방법을 조직 내에서 찾아서 합의를 이루는 게 중요하다.

• 불분명한 BEST 대신에 명확한 Better을 추구하자.

• 한번에 답을 내지 말고 계속 개선하려고 하는 것이 방법이 될 수 있다. (일일신 우일신)

Bad (개선할 점)

• 동료들에게 신뢰를 쌓기 위해서는 솔직해지고, 실수를 인정하자.
• 동료들에게 신뢰를 쌓기 위해서는 동료에게 관심을 가지고 동료의 일을 남일 처럼 여기지 말고 내일처럼 여기자.
• 문제를 명확하게 이해하고 내가 정확히 이해하고 있는지 스스로 검증하는 프로세스가 필요하다.
• 코드가 복잡해 질때, 문제를 정의하지 못하는 것 같다.

Affimation (자기 선언)

• 동료들에게 신뢰를 쌓을 수 있도록 노력하자.
• 클래스, 메서드, 변수의 역할에 대해서 글로 정리 해보자. 그렇다면 이름을 명확하게 작성할 수 있을 것이다.
• 문제를 정확히 이해하고 있는지 스스로에게 물어보고 테스트를 해보자.
• 출퇴근 시간에 코딩 테스트를 정하고 해결책을 생각해보자!
• 내가 배운 것들을 남에게 말로 설명할 수 있는지 스스로 테스트해보자.
• 나는 알고 있다고 스스로 착각하고 있는 일들이 많은 것 같다. 따라서 스스로를 테스트해보자. 또한 어떻게 테스트 할 수 있는지 생각해보자.
• 문제 해결의 시작은 명확히 어떤점이 문제인지를 정의하는 것이다. 따라서 코딩을 하면서 부딪치는 문제들을 마주치면 어떤 점이 문제인지를 명확히 정의하고 이를 풀어가려고 노력해보자.
• 한번에 좋은 방법을 선택하려고 하지 말고, 계속 개선하려는 마음을 가지고, 유연한 설계를 하려고 노력하는 것이 방법이다.

회고 작성법

1. Facts(사실, 객관) 회사에서 실제로 내가 했던 일이나 겪었던 일의 사실을 적는다.
2. Feelings(느낌, 주관) 내가 했던 일을 하면서 느꼈던 감정이나 느낌을 적는다.
3. Findings(배운 점) 내가 했던 일을 통해서 새롭게 배운 점이나 알게 된 점을 적는다.
4. Affirmation (자기 선언) 내가 했던 일을 통해 배운 점과 아쉬운 점을 어떻게 유지 하고 개선할지를 적는다.