개발자 원칙 (테크 리더 9인이 말하는 더 나은 개발자로 살아가는 원치고가 철학)

* 원칙 준수에 도움이 되는 책

<테크니컬 리더> : 단순히 지식을 설명하는 책이 아닌, 자신과 조직을 변화시키는 능력을 갖추게 도와줍니다

<프로페셔널의 조건> : 개인이 지식 노동자로서 자각하고 준비되려면 어떻게 해야 하는지 설명한 책

 <성공하는 사람들의 7가지 습관> : 시간과 기회를 효과적으로 사용해서 성과를 내는 삶을 안내해줍니다.

<만화로 보는 댄 애리얼리 최고의 선택> : 수많은 주변의 압박에서 벗어나 현명한 선택을 하도록 도와주는 책

<학문의 즐거움> : 지속적으로 학습해야 하는 이유와 그 즐거움을 알려주는 책

<리눅스 그냥 재미로> : 리눅스를 만드는 과정도 상세하지만 제목 그대로 개발 자체의 즐거움에 대해서 이야기 합니다.

<Release it> : 성공적인 출시를 위한 소프트웨어 설계와 배치를 알려줍니다

 

* 개발에서의 설계란 

설계의 본래 의미 

1. 계획을 세움

2. 건축물 설립이나 토지 공사, 기계의 제작따위에서 그 목적에 따라 실제적인 계획을 세우고 구체적으로 도면을 그려 명시하는 일

2번이 우리가 주로 소프트웨어 제품을 개발할 때 적용해볼 수 있는 의미입니다. 그 '목적'에 따라서 '실제적인 계획'을 세우고 '구체적으로 도면'을 그려 명시하는 일이 설계 입니다.

 

* 배워야 할 지식을 저처럼 현재 업무랑 관계됟ㄴ 것에 50%, 앞으로 관련될 것에 30%, 관련 없지만 관심 있는 것에 20% 정도만 시간을 투자해보세요. 개발자에게 성장은 멈춰 있는 약속 장소가 아니라, 계속해서 움직이는 사냥감에 가깝습니다. 두리번거리며 준비하다 보면 회사 업무가 나와 상관없이 변화하더라도 기회가 될것입니다.

 

* 학습하는 과정에서 자신의 학습 방식, 이해하는 방식, 설명하는 방식, 학습 과정을 개선하는 방식까지 학습해야 합니다. v 0.1에서 설명한 속도와 방향을 인지하는 것부터 시작해보세요. 그러고 나서 의도적으로 익숙한 방식을 멀리하고, 의도적으로 낯선 방식을 선택해보세요. 프로그래밍 언어나 개발 환경에 제약사항을 추가해보세요. 익숙한 것을 반복하면 더 오래 기억할 수 있게 되지만 성장하지는 못합니다. 성장을 위한 더 효과적인 방법은 의도적으로 낯선 환경을 만들고, 제약사항을 추가해서, 도전적이면서 살짝 어렵지만 재밌는 요소를 찾아서 학습하는 겁니다.

 

* '내가 무언가를 잘합니다'라는 표현에는 다른 누군가보다 잘한다는 맥락이 숨겨져 있습니다. 숨겨진 의미는 그대로 갑춰둡시다. 자신을 다른 누군가와 비교하면 그 순간부터 괴로울 뿐입니다. 비교하는 대상을 다른 사람으로 향하지 말고, 스스로 내면을 향하도록 해야 합니다. 몇 시간 전에 몰랐던 것을 깨닫거나 하루 이틀 전에 작성한 코드를 개선할 점을 찾을 수 잇으면 조금씩 자신만의 속도로 성장한다는 증거입니다.

 

* 일희일비 하지 말고 칭찬에는 겸손하고 비난에는 나를 돌아봅시다. 하루에 조금씩만 더 나은 성장을 이끌어내면 됩니다. 그러려면 지속적으로 성취감을 느끼는 것이 중요합니다.

성취감은 성장에서 중요한 위치를 차지합니다. 크게 한 턱보다는 작은 일들의 연속으로 성취감을 느끼는 것이 중요합니다. 일을 더 작은 단위로 나누기 바랍니다. 그러면 더 자주 성취감을 쌓아 상실감을 줄일 수 있습니다. 멋진 방식에 억지로 맞추려고 하기보다는 아침에 일어나서 물 한잔 마시는 것처럼 사소한 일부터 습관을 들여 성취감으로 하루를 시작해봅시다.

 

* 물론 소프트웨어 코드가 항상 실수투성이어야 한다는 의미는 아닙니다. 학습할 때도, 일을 할 때도 실수를 두려워하지 말라는 의미입니다. 실수가 전혀 없을 수는 없겠지만, 소프트웨어 설계부터 테스트까지 개발 과정에서 실수를 빠르게 찾아낼 수 있어야 합니다. 실수한 사람을 질책하기보다는 누구나 실수할 수 있다고 가정하고 최종 릴리즈가 되기 전에 실수를 찾아낼 수 있는 안정적인 흐름을 만들어야 합니다. 테스트는 의도한 대로 소프트웨어가 제대로 동작하는지 확인하는 과정이며 실수를 찾아내는 과정입니다. 개발 과정에서 버그만 실수가 아니라, 기획 과정이나 설계 과정에서도 실수가 반영될 수 있습니다. 개발 과정에서 버그를 발견해서 수정하는 것도 개선이고, 협업 과정에서 개발 프로세스 병목 지점을 찾는 것도 개선입니다.

 

* 성장에 대한 분명한 기준과 이유로 다양한 이직 과정을 거쳐왔습니다. 하지만 분명한 이유가 있다고 항상 이직을 하라는 말은 아닙니다. 저는 새로운 회사를 모색하기 전에 항상 기존 조직에서 내 성장을 위한 변화를 시도할 수 있는지 찾고, 선배 혹은 상위 리더와 고민을 나누는 시간을 충분히 가졌습니다. 그렇게 방법을 함께 찾다 보면 가시적인 계획이 보일 때도 그렇지 않을 때도 있습니다. 내 성장을 위한 계획이 뚜렷하게 그려지지 않을 때, 그때는 새로운 회사와 환경을 찾을 결심을 했습니다.

 

* 대부분은 목표만 정하고 끝나는데 이렇게 실천 계획까지, 그리고 실천까지 이어진다면 90%는 성공한 겁니다. 그런데 여기서 멈추면 안됩니다. GPAM(Goal, Plan, Action, Measure) 퍼즐의 마지막 조각인 평가를 꼭 진행해야 합니다. 주기적으로 평가를 해서 목표와 계획과 실천을 계속 점검해야 합니다. 평가를 하면 '목표 대비 조금만 더 하면 되겠어, 드디어 목표를 달성했어' 처럼 도전의식과  성취감을 얻을 수 있습니다. 지속적으로 무언가를 해나가는데 이런 감정은 순풍이 되어줍니다. 사람에게 감정은 무언가를 달성하는 힘이 되기도 포기하게 되는 짐이 되기도 합니다. 의욕을 가지고 지속적으로 실천하려면 꼭 평가를 수행해야 합니다.

 

* 제어할 수 없는 것에 의존하지 않기 원칙

1. 제어할 수 없는 값에 의존하는 코드들을 최대한 멀리한다.

2. 주요 비즈니스 로직은 모두 제어할 수 있는 값만 의존하게 해 테스트 코드 작성이 쉬운 형태로 구성한다.

 

// 주문일이 일요일이면 주문 금액의 10%를 할인하는 메서드
export default class Order {
  ...
  discount() {
    const now = LocalDateTime.now(); // 현재 시간을 반환하는 메서드
    
    if (now.dayOfWeek() == DayOfWeek.SUNDAY) {
      this._amount = this._amount * 0.9
    }
  }
}

if ('일요일에는 주문 금액이 10% 할인된다', () => {
	const sut = Order.of(10_000, OrderStatus.APPROVL);
    sut.disount();
    expect(sut.amount).toBe(9_000);
})



위의 코드는 일요일에만 테스트 코드가 통과됨
따라서 변경이 필요

export default class Order {
	...
    // 현재 시간 메서드(now를 밖에서 주입받음)
    discountWith(now: LocalDateTime) {
    	if(now.dayOfWeek() == DayOfWeek.SUNDAY){
        	this._amount = this._amount * 0.9
        }
    }
}

it ('일요일에는 주문 금액이 10% 할인된다', () => {
	const sut = Order.of(10_000, OrderStatus.APPROVAL);
    const now = LocalDateTime.of(2022,8,14,10,15,0);
    sut.discountWith(now);
    
    expect(sut.amount).toBe(9_000);
})

메서드/함수가 제어할 수 없는 값에 의존하지 않을수록 항상 같은 결과를 반환하는 부수효과가 적은 메서드/함수가 됩니다. 아직가지 코드를 작성할 때 제어할 수 없는 값에 의존하는 코드를 작성한다면 한 번 적용해 보시길 바랍니다. 그간 답답했던 문제를 해결하게 될 겁니다

 

 

* 행동강령

1. "Make it work, then make it better" => 일단 동작하게 만든 다음 더 좋게 만들어라

2. "Always leave the campground cleaner than you fount it" => 언제나 발견했을 때보다 깨끗하게 해놓고 캠핑장을 떠나라

3. "The good thing about reinventing the wheel is that you can get a round one" => 바퀴를 새로 발명하는 일의 좋은 점은 둥근 바퀴를 얻을 수 있다는 점입니다.