개발자 원칙
덕업일치를 넘어서
좋아하는 개발을 업으로 삼은것은 좋지만, 실제로 쓸모 있는걸 만드는게 좋은 것 같다. 무조건 저레벨의 언어만 고집한다거나, 너무 신기술에만 집착하는 것은 쓸모 있는걸 만들기 위한 좋은 태도가 아니다.
신기술도 반짝 인기나 관심을 끌다가 금세 없어지는 경우가 많으므로 주의해야한다.
오류를 만날 때가 가장 성장하기 좋을 때다
오류를 만나서 해결할때가 개발자로서 성장하기 가장 좋은 때다. 오류를 만나면 너무 스택오버 플로우 같은 남들이 다 해결법을 찾아놓은 자료에만 의지하는건 옳은 습관이 아니다.
더 나아가서 소스레벨에서 버그를 파악하는 습관을 들여야한다.
소프트웨어 디자인 원칙
디자인이란 요구사항을 개발하기 위한 계획이다. 소프트웨어 분야는 역사가 짧기 때문에 명시적으로 표현할 수 있는 설계의 범위가 작다.
실제의 개발에서는 명시적 설계 외에도 암묵적 설계가 더 필요하다. 유지보수를 위한 계획이라던지, 많은 사용자와 트래픽을 감당할수 있는 서버 규모라던지가 그것이다.
궁극적으로 소프트웨어 분야도 건축분야처럼 누구나 같은 설계도를 갖고 만들면 모든 똑같은 결과물이 나올 정도의 설계가 되어야 하며. 기술이 발전하고 정형화됨에 따라 실제로 실현되고 있다.
나의 메이저 버전을 업그레이드하는 마이너 원칙들
일을 할때 항상 하던데로만 하면 발전이 없고 고인물이 되기 쉽다. 항상 두리번 거리며 나의 현재 능력과 앞으로의 방향을 확인해야 한다.
바퀴를 재발명하는 것은 나쁜습관이 아니다. 현재 범용적으로 사람들이 사용하고 있는 기술들도 재발명으로 계속 발전되는 와중에 탄생한 것이다.
이직, 분명한 이유가 필요해
이직에도 분명한 이유가 필요하다. 그냥 회사생활을 하지말고 그 회사에서 배울점이나 좋은 시스템을 보고 배우고 학습해야 한다.
목표를 달성하는 나만의 기준, GPAM
GPAM은 식상해 보이지만 우리 주변의 모든 것들에 GPAM을 적용할 수 있는 가장 확실한 방법이다.a
- G: 목표를 세우고
- P: 계획을 짜고
- A: 실행하고
- M: 평가하고 피드백을 받고
프로덕트 중심주의
스프트웨어를 서비스를 만들거나 특정 기술을 공부할때, "프로덕트 중심주의"로 생각해야 한다.
그냥 아무 목적없이 공부를 하는 것 보다. 그 기술로 실제 유용한 프로덕트를 만든다고 생각하고 공부하면 더 효과적이고 실용적이다.
제어할 수 없는 것에 의존하지 않기
모든 일이 그렇듯이 제어할수 없는 것에 의존하면 안된다.
내가 할수 있는것과, 내가 할수 없는것을 명확히 구분하고 내가 할수 있는것을 해결하는것이 정신건강에 좋다.
달리는 기차의 바퀴를 갈아 끼우기
- 일단 동작하게 만든다음 더 좋게 만들어라
- 잘못된 추상화 보다는 중복이 낫다.
- 최적화가 중요하지만 최적화가 방해가 될 수도 있다.
- 성능도 중요하지만, 읽기쉬운 코드가 더 중요하다.
- 성능을 꼭 신경써야 되는곳이 있지만 대부분은 읽기쉬운 코드가 더 필요하다.
- 소프트웨어에 기술부채를 완벽히 없애는 일은 불가능하다.
- 깨진 유리창을 즉시 바로바로 고치는것은 불가능하다. 하지만 다친 사람이 없도록 테이프로 붙여 놓은다음 차근차근 교체하는 방법이 더 효율적이다.
- 기차가 멈추지 않도록 항상 유지보수 하고 레거시나 기술부채를 줄여라,
- 기술부채가 없는 개발은 불가능하다. 기술부채를 없애겠다는 완벽주의가 더 큰 기술 부채를 만든다.
- 일단 동작하게 만드는 것은, 현재 밥값을 하는 것이고, 더 잘만드는 일은 미래의 나를 갈고 닦는 일이다.