TIL 양식

Facts (사실, 객관)

• 네이버에서 NDTI라는 맞춤 채용 제안을 확인할 수 있었다. 재미있고 좋은 아이디어인 것 같다.

• 지도 서비스를 구축하는데 도움이 되는 라이브러리 및 도구를 발견하였다. 토이 프로젝트를 하는데 많은 도움이 될 것 같다. OPEN STREET MAP으로 나만의 지도시스템 만들기

• TDD를 하는 이유 중에, 테스트를 하면서 미리 설계를 같이 하고 이를 검증해볼 수 있다는 점도 있지만 무엇보다 좋은 점은 구현을 먼저하면 테스트 코드를 귀찮아서 작성하지 않는다는 점이다. 또한 문서화도 마찬가지인데 메서드를 설명하는 코드나 클래스를 설명하는 코드를 작성할 때, 미리 클래스나 메서드를 설명하는 주석을 먼저 작성하면 나중에 귀찮아서 작성하지 않아도 되는 장점이 있고 메서드 주석을 작성하면서 내가 작성하려는 메서드의 목적과 좋은 메서드 이름을 지을 수 있는 장점이 있다.

Feelings (느낌, 주관)

• 이전에 계획을 먼저 세우고 코딩을 하려고 하였지만, 구현하면서 계획이 자주 바뀌어 결국에는 원래대로 돌아가고 말았다. 하지만, 기능 구현은 기능 구현을 하면서 언제든지 바뀔 수 있다는 점을 간과한 것 같다. 또한 처음부터 모든 기능 목록을 완벽하게 정리해야한다는 것도 부담을 가지게 된 것 중에 하나인 것 같다. 따라서 처음부터 모든 기능 목록을 정리해야하는다는 부담을 가지기 보다는 기능을 구현하면서 문서를 계속 업데이트하는 방향으로 가자. 너무 학교 과제물을 제출하던 습관이 들어, 회사에서도 한번 만들면 끝이라고 생각하는데 이러한 생각은 학교에서까지만 가지고, 현실에서는 계속 꾸준하게 고쳐가는 것이 중요하다고 생각을 하자.

• 구조 개선을 해야한다고 외치기만 하면서, 구체적으로 어떤 부분을 어떻게 고쳐야겠다고 정리하여 PM에게 구체적으로 말해본 적이 없었던 것 같다. 따라서, 제안을 하기 위해서는 구현하면서 개선해야할 점이 보이면, 틈틈히 정리를 해두고 구체적으로 어필을 해야겠다. 여태까지 구체적인 방향을 제시하지도 않으면서 불평만 하지 않았는지 되돌아봐야겠다.

Learning (배운점)

• 계획을 세우고 코딩을 하되, 이 계획은 언제든지 바뀔 수 있다는 것을 명심하자. 죽어있는 계획 보다는 계속해서 살아있는 문서를 만들려고 노력하자. 또한 기능 목록을 메서드 설계나 구현과 같이 너무 상세하게 적으려고 하지 않는다. 따라서 정상적인 부부도 중요하지만, 예외적인 상황도 기능 목록에 정의한다. 특히 예외사항은 시작하는 단계에서 모두 찾기 힘들기 때문에, 기능을 구현하면서 계속해서 추가해나가도록 한다.

Bad (개선할 점)

• 프로젝트를 진행하면서 개선할 점이 보이면, 틈틈히 정리를 해두고 다음 이관에 처리할 일감화를 시켜서 PM 분들에게 나의 의견을 제시하자.

• 계획을 먼저 세우고 코딩을 할 때, 계획은 항상 변화한다는 것을 명심하면서 이를 수정하면서 코딩을 해야겠다. 죽은 계획이 아니라, 살아있는 계획을 세우는 것을 목표로 하자. 참고로 이 부분은 PULL REQUEST를 할 때, 토의를 할 텐데 이 부분에서 논의를 같이 하면 될 것 같다.

Affimation (자기 선언)

• 나중에, 테스트 코드를 지우더라도, 먼저 테스틑 코드를 작성하고 이를 구현하는 연습을 하자, 그리고 메서드를 작성하기 전에 메서드 주석을 먼저 작성하고 이로부터 메서드의 목적과 좋은 이름을 도출해내자.

회고 작성법

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