아름다운 코드에 대하여
(kciter.so)- 아름다움이란?
- 아름다움은 사람이 느끼는 가치
- 놀라움, 새로움, 안정성, 편안함, 단순성 등을 주는 것
- 놀라운 것과 자연스러운 것으로 나눌 수 있음
- 아름다움(깨달음)을 느끼기 위해선 어느정도 기본적인 지식이 필요함
- 아름다움은 생존을 위한 것. 이해할 수 없는 것을 보면 불쾌함을 느낌
- 아름다운 코드에 대한 정의
- 코드는 혼자 일하는 것이 아니기 때문에 아름다울수록 좋다
- 이상적으론 읽으며 걸리는 부분이 단 하나도 없는 코드
- 자연스러운 코드가 좋다
- 아름다운 코드를 이루는 네 가지
- 사회적, 신뢰적, 선형적, 선언적
- 사회적이고 신뢰적인 부분은 안정성을 추구
- 선형적이고 선언적인 부분은 심미성을 추구
- 사회적인 코드
- 주변 상황을 모두 고려한 코드
- 관습이나 규칙, 미션을 따르는 것
- 언어의 사회성과 유사함
- 신뢰적인 코드
- 믿고 사용할 수 있는 코드
- 믿을 수 없다면 직접 확인해야 하는 코드가 됨
- 순수 함수, 멱등성, 사이드 이펙트 등을 고려
- 사이드 이펙트가 전혀 없을 수는 없기에 문서나 예외가 있음을 알릴 수 있음
- 선형적인 코드
- 코드를 읽을 때 위에서 아래로 한 번만 읽어도 되는 것
- 선형적이면 뇌과학적으로 작업 기억 공간이 처리하기 쉬워짐
- 선언적인 코드
- 코드가 무엇을 하는지 정확히 알리는 것
- 적절한 이름을 지어주는 것이 좋음
- 뇌과학적으로 단기 기억 공간이 처리하기 쉬워짐
- 사회적, 신뢰적, 선형적, 선언적
- 현실적으로
- 아름다운 코드라는 것은 한 번에 뚝딱 나오는 게 아님
- 완벽하게 아름다운 코드라는 것은 흔하지 않음
- 따라서 점진적 개선과 코드 수식이라는 개념이 필요함
- 점진적 개선
- 리팩터링을 하는 것
- 점검과 개선을 반복하여 70~80%의 품질을 계속 유지하는 것
- 언제 점검과 개선을 해야할까?
- 코드 오너십이 흐려질 때
- 작성된 코드에 대한 지식이 흐려질 때
- 악취를 느낄 때
- 코드를 볼 때 불편함을 느낄 때
- 코드 오너십이 흐려질 때
- 코드 수식
- 코드를 아름답게 보여지도록 꾸며주는 것
- 대표적으로 테스트, 코드 리뷰, 문서화, 주석 등이 사용됨
- 테스트
- 코드를 더 신뢰할 수 있게 만들어줌
- 작동을 보장하고 테스트 자체가 문서가 될 수 있음
- 코드 리뷰
- 검증을 통해 코드를 더 신뢰할 수 있게 만들어줌
- 코드 오너십 전파를 하기 때문에 코드의 사회성도 높일 수 있음
- 무조건적인 코드 리뷰는 병목이 될 수도 있음
- 문서화
- 코드를 더 이해할 수 있게 해줌
- 문서화를 해야하는 시점은 다른 개발자가 해당 코드에 대한 맥락과 설계, 규칙을 알아야 할 때
- UML 같은 도구를 이용하면 더 좋음
- 주석
- 어쩔 수 없이 생기는 복잡한 코드 영역은 문서보다 주석으로 설명하는 것이 좋음
- 코드 품질은 중요하지만 아름다운 코드가 꼭 성공을 보장하는 것은 아님
- 오히려 설계나 업무 프로세스를 더 고려해야할 수도 있음
- 코드 품질이 꼭 제품 품질을 보장하는 것은 아니다
본인이 짠 코드에 심미적 아름다움을 느끼는 취미는 그냥 개인 관점으로 남아야지. 돈받는 프로가 회사코드를 예술적 관점으로 접근하고 주니어들에게 이상한 마인드나 주입시키는 시니어는 제발 되지 맙시다. 아니면 개발자 때려치고 그림이나 그리던가 뭔 예술타령이야...