Top 9 of 97 Things every programmer should know라는 글과 Top 7 of 97 Things Every Software Architect Should Know라는 블로그 글이 올라왔다.
이 두 글은 97 Things Every Programmer Should Know라는 책과 97 Things Every Software Architect Should Know라는 책에서 블로그 작성자가 생각한 최고들만 뽑아서 정리한 것이다.
내가 공감하는 내용이 많아 간략히 정리한다. 원문 글 내용을 두서 없이 요약한다. 다시말해 제대로 읽으려면 원문과 책을 읽으라.
먼저 프로그래머가 알아야 할 것 중 최고 9가지 부터..
다음은 아키텍트가 알아야할 것들 중 최고 7가지...
먼저 책의 첫 챕터에 나온 "요구사항보다 내 이력서에 쓸 것을 우선시 하지 말라"(즉, 요구사항을 구현하는테 별로 필요도 없는 것을 이력서에 넣을 경력꺼리를 만들려고 신기술을 도입하거나 하지 말라)에 대해 말하자면 블로그 글쓴이는 이 내용에 찬성하고, 신기술을 도입할 때는 매우 조심스러워야 하지만, 그렇다고 신기술을 무조건 배척하지 말자한다.
그런데 이래 저래 개발 하다 보면 이런 경우를 매우 많이 본다. 과잉 기능과 과잉 설계로 시작했다가 버그와 논리적 뒤틀림만 양산하다 끝나는 프로젝트들. 결국 핵심 기능은 뒷전이 되고 만다.
이 두 글은 97 Things Every Programmer Should Know라는 책과 97 Things Every Software Architect Should Know라는 책에서 블로그 작성자가 생각한 최고들만 뽑아서 정리한 것이다.
내가 공감하는 내용이 많아 간략히 정리한다. 원문 글 내용을 두서 없이 요약한다. 다시말해 제대로 읽으려면 원문과 책을 읽으라.
먼저 프로그래머가 알아야 할 것 중 최고 9가지 부터..
- 보이스카웃 규칙 - "내가 머문 자리를 머물기 전보다 깨끗하게 하고 떠나라."라는 규칙인데, 다시 말해서 처음부터 완벽한 코드를 커밋할 필요는 없다. 다만, 코드를 커밋할 때마다 항상 이전보다 낫게 개선하도록 하라. 작은 개선이라도 좋다. 사용하지 않는 코드를 삭제하거나 단위 테스트를 하나라도 더 추가하거나..
- 아름다움은 간결함에 있다. - 오버 엔지니어링 하지말라. 과도한 추상화, 패턴을 위한 패턴, 인터페이스를 위한 인터페이스.. 완벽하진 않더라도 간결하게 일을 수행하는 코드를 짜라.
- 잠깐! 자동화하고 자동화하며 또 자동화하라. - 빌드, 배포, 코드분석, 단위테스트, 기능 테스트, 통합테스트. 자동화는 해도해도 부족하다.
- 끊임없이 학습하라. - 지속적으로 발전하고 변화하는 분야에서 일하는 프로그래머는 끊임없이 학습해야 한다. 책을 읽고, 관련 분야 RSS를 구독하고, 블로깅을 해서 나의 코드와 지식을 공유하라. 1~2주에 한번씩 블로그에 글로 쓸 내용을 공부하도록 자신을 독려하라. 오픈소스에 참여하라. 회사에서는 최신 기술을 충분히 적용해볼 수 없다.
- 다른 이를 비난하기 전에 내 코드먼저 살펴라. 특히 서로 다른 팀간의 인터페이스를 할 때 서로 비난할 시간에 문제를 해결하라.
- 야근한다고 월급 안오른다. - 적게 일할 수록 더 많이 이룩할 수 있다.
- 코드 스스로 말할 수 없을 때만 주석을 달라. - 가장 중요한 것은 주석이 없어도 잘 이해되는 코드를 짜는 것.
- 자신의 IDE를 알라. - 단축키와 각종 기능들을 익혀서 IDE가 가진 모든 능력을 이끌어내라.
- 개발 시간을 추정하는 법을 배우라. - 자신의 기능별 개발 시간이 얼마나 걸리는지 측정하라.
다음은 아키텍트가 알아야할 것들 중 최고 7가지...
먼저 책의 첫 챕터에 나온 "요구사항보다 내 이력서에 쓸 것을 우선시 하지 말라"(즉, 요구사항을 구현하는테 별로 필요도 없는 것을 이력서에 넣을 경력꺼리를 만들려고 신기술을 도입하거나 하지 말라)에 대해 말하자면 블로그 글쓴이는 이 내용에 찬성하고, 신기술을 도입할 때는 매우 조심스러워야 하지만, 그렇다고 신기술을 무조건 배척하지 말자한다.
- 비즈니스 도메인을 이해하라. - 기술 뿐만아니라 개발하는 비즈니스(보험, 재무, 마케팅 등?)에 대한 지식을 갖추고 있어야 훌륭한 아키텍트가 될 수 있다.
- 무엇보다도, 아키텍트는 프로그래머이다. - 니가 설계했다면 니가 코드로 구현할 수도 있어야 한다. 코딩할 줄 모르는 아키텍트는 과잉 설계하여 불행한 개발자들이 엉망으로 구현하게 만들수도 있다.
- 개발자들을 다루기 - 과도한 제약은 개발자를 불행하게 만들고, 제약을 너무 적게하면 고객을 불행하게 만든다. 개발자 혹은 고객이 불행해지면 그것은 실패한 프로젝트가 된다.
- 성능 - 성능은 가능한 일찍 고려하라. 애플리케이션 아키텍처가 성능을 좌우한다.
- 결정을 하게 된 근본적 이유를 기록하라. - 문제가 없을 때는 어떤 결정에 대한 근본적 이유를 몰라도 그냥 넘어가게 되지만, 문제가 생겼을 때는 왜 그런 결정을 했는지 기록해둔 것이 당신을 살릴 것이다.
- 일어서라! - 다른 사람과 효율적으로 커뮤니케이션 하고 싶다면, 일어서라!
- 위대한 소프트웨어는 한번에 만들어지는 것이 아니라 성장하는 것이다. - 거대한 시스템 설계는 거의 득될게 없다. 비전은 크게 가지나 설계는 크지 않게하라. 기본적이고 작고 단단한 시스템으로부터 시작하여 프로젝트 기간동안 성장하도록 하라.
그런데 이래 저래 개발 하다 보면 이런 경우를 매우 많이 본다. 과잉 기능과 과잉 설계로 시작했다가 버그와 논리적 뒤틀림만 양산하다 끝나는 프로젝트들. 결국 핵심 기능은 뒷전이 되고 만다.
덧글
제 경험상으로는 아키텍트의 7번 오버스펙에 관한 내용은 개발자로 부터의 문제라기보다 그 윗선에서 부터의 문제인 경우가 많았던것 같아요.
우리 제품의 핵심 포인에 집중하기 보다는 남이 하는거 다하고보 자라는 생각이 문제라고 생각합니다.
헌데, 제가 마지막에 넣은 예는 저의 주관적인 생각일 뿐입니다. 원문은 사실 거의 기술위주의 경고입니다. 아키텍처도 처음에는 작게 가져갔다가 프로젝트의 성장에 따라 키워가라는 그런 의미 같네요. 하지만 어쨌든 과대 아키텍처를 가져가게 만드는 이유가 기능 과다인 경우가 많다는 생각은 (저도 또한) 변함없습니다.