주석의 양면성

주석이 많다는 것은, 그만큼 비지니스 요구사항을 코드에 잘 못 녹였다는 이야기

좋은 주석이란 → 우리가 가진 모든 코딩 표현 방법을 총동원해 코드에 의도를 녹여내고, 그럼에도 불구하고 전달해야 할 정보가 남았을 때 사용하는 주석

변수와 메서드의 나열 순서

변수는 사용하는 순서대로 나열한다. (인지적 경제성을 위해)
메서드의 순서는 공개메서드를 상단에 배치하고 private 메서드를 후순위로 둔다. 이때 각 메서드 그룹(public, private) 안에서는 상태변경 > 판별 >= 조회 메서드 순으로 배치시키는 것이 좋다.

메서드를 만들거나 추출할 때마다 2가지 생각을 할 줄 알아야한다. 1. 어? 이 메서드를 어디쯤 둬야하지 2. 어?이게 private 인가 public인가? 외부에서 내부로 쓰임새가 변경되었는지까지 한번 더 확인

패키지 나누기

패키지는 문맥으로써의 정보를 제공할 수 있다.
하지만 멋대로 바꾸면 안된다. 협업 안에서의 안정성과 팀원을 배려함을 확보하면서 작업해야한다.

알고리즘 최적화

스택오버플로우? 재귀? dfs? 스택 ? 데큐? 더 좋은 성능이 무엇일까

특정 알고리즘의 성격을 띄는 비지니스 로직이 있을 수 있다. 이는 기본적인 자료구조와 알고리즘에 대한 이해를 기반으로 최적화 해나갈 수 있다. 강의에서는 dfs라는 배경지식을 기반으로 재귀를 스택자료구조로 표현했고 이후 데큐를 통해 성능을 최적화했다.

ide의 도움받기

코드 포맷 정렬, Sonarlint, editorconfig

발전하는 it의 특성상 여러가지 툴도 동시에 발전해나가고 있다. 툴의 도움을 꺼려하지말자. 더 많은 것을 배울 수 있다.

능동적 읽기

뒤가 있어 우리에겐 " git reset --hard"

코드를 읽고 이해하려고 할 때, 공백으로 단락을 구분하고 의미와 책임으로 추상화를 해보고, 주석을 직접 달아가면서 해석을 해보자. 도메인의 지식을 늘리면 코드의 추상화가 더 쉬워진다. 도전을 두려워하지마 우리게엔 git reset --hard가 있다.

오버엔지니어링

정말 필요한 코드 구조인가?

도메인의 지식에 벗어난 과한 추상화, 과한 인터페이스는 오히려 오버엔지니어링일 수 있다.

은탄환은 없다.

정답은 없다.

클린코드는 모든 방법의 핵심이 아니다. 클린코드는 미래의 일어날 수 있는 변화에 대하여 잘 대응할 능력을 제공해준다. 이러한 사고법을 기반으로 언제 적재적소에 알맞게 클린코드가 필요한지 파악할 수 있다.

모든 기술의 방법록은 정적 기술의 범위 내에서 적용되어야 좋은 기술이다.

1주차 회고

Keep (만족했고, 앞으로도 지속하고 싶은 부분)
추상화와 조금 더 친해질 수 있었다. 클린코드를 배우다보면 초창기에는 모든 코드가 불편하게 보이게 되는 경향이 있다. 하지만 이번 차수를 마치면서 은탄환은 없다. 적재적소에 맞는 기술과 코드를 쓰는 것이 중요하다라고 느꼈고 이 점을 회사에 적용해보니 더 많은 사람들이 나의 생각을 이해하고 따라와주는 것에 고마움과 만족감을 느꼈다. 앞으로 더 넓은 객체의 세계를 배워 더 좋은 설계를 해보고 싶다.

.
Problem (아쉬웠던 점)
알고리즘과 자료구조에 대한 깊은 이해가 부족하다는 생각이 들었다. 알고리즘을 겉햝기 식으로 풀어는 왔지만 막상 코딩테스트 문제를 통해 접근하는 알고리즘과 실제 비지니스 도메인로직에 알고리즘을 녹이는 것은 차원이 다르다는 생각이 들었다. 우선 원초적인 기본부터 지켜나가면서 공부를 더 해야함을 느꼈다.
Try (다음에 시도해볼 점)
주석을 쓴다는 것은, 내 코드를 다른 사람들이 읽기 쉽게 해준다고 생각했었다. 예를 들어 회사에서 잘 쓰지 않는 신규 api나 메서드를 가지고 코딩을 하면 그 코드에 대한 해석이 어려운 부분이 있을 거라 생각해서 그랬던 거 같다. 하지만 이번 강의를 통해 더 친절한 코딩을 하면 주석따위는 필요없다고 생각이 들었다. 앞으로 코딩을 할 때 과연 내가 후손에게 친절한 코드를 작성하고 있는가 에 데한 고민을 수시로 해봐야겠다.