Facts
- 알고리즘 문제 풀이
- <테스트 주도 개발로 배우는 객체 지향 설계와 실천> 스터디
- 휴식
Feelings & Findings
알고리즘
알고리즘 문제 풀이에서 조금이나마 진전을 보아서 좋다.
지금은 다음과 같은 방식으로 풀고 있다.
첫번째로 환경설정을 한다. 테스트가 동작하는지 린트가 걸리는지 확인하고 커밋을 한다.
혹시 안될수 있으니, 아주 간단한 내용으로라도 꼭 돌아가는걸 확인해준다.
문제를 풀기 전에 README 파일에 문제 스펙을 적는다.
구하는 것과 주어진 것 그리고 조건을 적는다.
이렇게 하면 길이가 긴 문제에서 필요한 정보에만 자연스럽게 집중하게 된다.
인지자원의 낭비를 막아주는 것 같다.
그 후에는 큼지막한 노트에 문제에 관해 간단한 모델링을 수행한다.
그리고 주요 개념어 들을 나열하고 (e.g. 조이스틱 - 상하버튼, 좌우버튼, 최소조작)
각 단어들의 관계를 그림으로 그려본다.
행렬이 나오는 문제등 예제가 복잡한 문제인 경우, 예제를 따라가면서 이해할 수 있도록 상세하게 그려본다. 패턴을 발견해서 추상화할 수 있으면 한다.
그 후에는 단계별로 테스트를 수행한다. 모델링에서 필요하다고 생각한 기능부터, 가장 단순한 형태의 테스트를 작성하고, 복잡성을 올려나간다. 그 후에 기능들을 solution 함수에서 연결하여 합친다.
전반적인 풀이 리듬은 나쁘지 않은 것 같다. 다만, 풀면서 얻게 되는 지식을 노트에 적은 모델에도 바로 업데이트를 했으면 하는 생각이 있다. 삼색펜을 활용하여 더 많이 고칠수 있도록 해보자. 테스트 주도로 하면 템포가 느려지는 감이 있으나, 일단 뭔가 풀이에 문제가 생길때부터 테스트에 진가가 발휘되어서 만족스럽다.
뭔가가 실패했을때
안정적이지 못한 개발 환경의 증상 한 가지는 뭔가가 실패했을 때 가장 먼저 어디를 살펴봐야 할지 마땅치 않다는 것이다.
다 되는 상태에서 고치세요.
잘될때는 모든게 괜찮아 보인다. 그러나 일단 안되기 시작하면, 모든게 문제였던 것처럼 보인다.
다 되는 상태에서 고치란건 참 당연한 말 같지만, 실천하는게 어렵기 때문에(진짜로 다 되는지 확신하기 위해서 필요한 일들을 생각해보자! ㅜ), 역시 실제로 하는게 의미가 있다. 실천하자.
Affirmation
나는 자신을 믿는 사람이다.
