TIL (Today I Learned)

2022.02.21

1. k5946k

개념을 구분하지 않은 채 이름만 달리해서 만든 함수나 변수는 프로그래머에게 혼란을 준다.

ex) Class로 Product, ProductInfo, ProductData를 만들경우 어떤 곳에 원하는 정보가 있는지 알수가 없다..

회사 특성상 내 코드를 봐줄 사람이 없어서 내 코드가 남이보기에 지저분한 코드인지 알 길이 없었고 그저 내가 이해하기 쉽게 자기중심적인 코드를 만들었는데 이책을 보고 나서 많이 반성하게 됐다.

: 혼자서 일을 하다보면 드는 우려가 작성한 코드의 질을 판단하기 어려워 잘하고 있는 것인지 확인할 길이 많이 없다는 것이다. 혼자서 코드를 작성하는 만큼 상대방이 되어 객관적으로 바라보고 스스로 많이 고민하는 시간이 필요함을 공감한다.

2. leeq

• 자신의 기억력을 자랑하지 마라. (p.31)

: 코드 안의 클래스명이나 변수명 등을 작성할 때 추후에 봐도 기억할 수 있다는 생각으로 고민을 들이지 않고 결정할 때가 종종 있다. 그리고 코드를 수정해야할 경우 다시 보면 헷갈릴 때가 꽤 있었다. 코드란 하기 싫은 숙제를 대충 해결해나가는 것이 아닌 신중히 고민해야하는 분야임을 다시 한 번 느낀다.

3. somini

• 그동안 타 부서에서 주석을 꼭 달아서 커밋하라고 하는 분이 있었는데, 나는 그것조차 귀찮아 했었는데 주석이 필요하지 않은 코드를 작성하는게 중요하다는걸 알게되었다..

: 종종 코드를 작성한 후 주석을 달 경우가 몇번 있었다. 주석을 다는 이유는 스스로 보기에도 헷갈리거나 명확하지 않았을 경우일 것이다. 그러한 코드는 분명 나쁜 코드임이 분명한데도 작성을 했다는 것에 반성한다.