기술 블로그

처음 설계를 시작할 때는 클래스 수를 늘리는 것보다, 무엇이 책임이고 무엇이 자주 바뀌는지 먼저 묻는 편이 훨씬 안전하다. 입문자가 바로 적용할 수 있는 5가지 질문으로 정리한다.

소프트웨어 개발은 분석-설계-구현-테스트가 한 번 직선으로 끝나는 공정이 아니다. 작은 단위를 반복하며 스코프를 줄이고 피드백을 되감는 순환 구조로 보는 편이 실제에 가깝다.

소프트웨어 설계 입문에서 중요한 것은 다이어그램 도구를 많이 아는 것이 아니라, 시스템의 경계와 책임을 설명하는 습관을 익히는 것이다. UML과 C4 모델은 그 다음에 붙이는 도구에 가깝다.

Erich Gamma 외 3인의 『Design Patterns』는 23개 패턴 목록보다도, 반복되는 설계 문제를 이름 붙이고 토론하게 만든 공통 언어로서 영향력이 컸다.

Google C++ Style Guide, PEP 8·257, Javadoc, Go 문서 주석 가이드를 바탕으로, 어떤 주석은 지우고 어떤 주석은 남겨야 하는지 정리한다.

Dan North, Martin Fowler, Cucumber 문서를 기준으로, 행동 주도 개발이 단순한 '주어진 상황-행동-결과' 문법이 아니라 요구사항과 테스트를 같은 언어로 연결하려는 시도였다는 점을 다시 정리한다.

좋은 프로그램의 기준은 성능 하나로 정해지지 않는다. 이름, 함수 크기, 주석, 일관성, 리팩토링 가능성처럼 다른 사람이 읽고 고칠 수 있는 코드의 조건을 다시 정리한다.

출시 직전에 터지는 버그, 기능 추가할 때마다 무너지는 구조. 게임 프로젝트에서 리팩토링을 미루면 어떤 일이 벌어지는지, 그리고 실전에서 리팩토링을 언제, 어떻게 해야 하는지를 경험을 바탕으로 정리한다.

UML, 디자인 패턴, 개방-폐쇄 원칙 같은 개념을 게임 개발 맥락에서 어떻게 익히고 적용할지 정리한다.