안녕하세요, DEVOCEAN YOUNG 1기 🌊 Dev-dive 조입니다!

DEVOCEAN YOUNG 1기에서는 지난 몇 달 간 '다독다독' 독서 스터디를 꾸준히 진행해 왔는데요,

저희 Dev-dive 팀은 주제 도서로 개발자 필독서 ‘실용주의 프로그래머’를 선정했습니다.

좋은 기회로 데보션의 도서 지원을 받아, 평소 읽어보고 싶었지만 혼자서는 완독하기 어려웠던 책을 끝까지 읽어낼 수 있었습니다.

다독다독 스터디를 마무리하는 이번 콘텐츠를 통해 ‘실용주의 프로그래머’의 주요 내용을 정리하고 팀원들의 소회를 나눠보려고 합니다.

1장부터 9장까지 빼곡하게 담겨있던 조언을 전부 담아내려다 보니 글이 조금 길어졌지만, 전체를 정독한다는 생각보다는 관심 있는 파트 위주로 범위를 확장시키며 읽으면 더 재미있게 보실 수 있겠습니다.

무려 20년 동안 수많은 개발자들의 사랑을 받아 온 ‘실용주의 프로그래머’, 바로 지금 그 첫 장을 넘깁니다.

1장 실용주의 철학

Topic 1. 당신의 인생이다

• 남 탓하지 말고 행동/실천으로 옮겨라.

• 여행을 가고 싶으면 가면 되고, 회사를 옮기고 싶다면 옮기면 된다. 공부할 기회와 시간은 없는 것이 아니라 만들지 않은 것이다.

  
  

Topic 2. 고양이가 내 소스 코드를 삼켰어요

모르겠어요, 그러니까 금방 알아볼게요.*

주인 대신 열심히 코드를 작성 중인 박고양 군(5세)

• 자신과 자신의 행동(경력 개발, 학습 및 교육, 프로젝트, 일상 업무…)의 결과에 대해 책임을 지자.

  • 팀 내 신뢰 - 내가 남에게, 남이 나에게

  • 책임지기 - 문제가 생겼을 때 그걸 고양이 탓으로 돌리지 말 것

  • 변명보다는 대안 제시가 우선

    
    

Topic 3. 소프트웨어 엔트로피

한 번 유리창이 깨지고 나면 다음 돌멩이는 더 쉽게 날아든다.

• 소프트웨어 defection은 전염된다.

• 망가진 코드, 나쁜 설계, 잘못된 결정, 구현되지 않은 기능 등이 모두 깨진 창문이다.

• 모든 프로그래머들이 ‘대충’이라는 벌레에 잠식되기 전에 깨진 창문을 보수하고, 동료들과 상의하여 덧대자. 엔트로피는 낮으면 낮을 수록 좋다.

• 창문이 제일 처음 깨졌을 때 목소리를 낼 수 있겠는가?

  
  

Topic 4. 돌멩이 수프와 삶은 개구리

나의 수프는 돌멩이 수프인가 개구리 수프인가?

• 돌멩이 수프 - 허락을 얻는 것보다 용서를 구하는 것이 더 쉽다.

  • 프로젝트 돌입 시 처음부터 동의를 얻는 것보다는 어느 정도 모양새가 갖춰진 결과물을 내밀고 ‘나도 숟가락 얹고 싶어요!’ 라는 반응이 나올 때까지 기다리는 편이 낫다.

  • 계속 되는 성공에 합류하기란 쉽다. 변화의 촉매가 되자.

• 개구리 수프 - 나는 끓는 냄비 속 익어가는 개구리가 아닐까?

  • 점진적인 변화는 알아차리기 쉽지 않다.

  • 망한 프로젝트는 서서히 죽음의 경계를 걷다 어느새 정신 차려보면 돌이킬 수 없을 정도로 악화되어 있는 경우가 대다수다.

  • 프로젝트가 어떤 국면에 도달해 있는지 늘 확인하도록 하자.

    
    

Topic 5. 적당히 괜찮은 소프트웨어

우리는 종종 뭔가 나아지게 하려다 괜찮은 것마저 망친다. - 셰익스피어, 《리어왕》 1막 4장

• 내일의 완벽한 소프트웨어 - 불가능하다

  • 사용자들은 1년 뒤 만들 수 있는 (실은 없는!) 완벽한 소프트웨어보다, 내일 당장 받아 볼 수 있는 결함 있는 소프트웨어를 더 선호한다.

  • 사실, 1년 뒤의 사용자들은 또 다른 소프트웨어를 바라고 있을 가능성이 크다.

• 그럼 형편 없는 쓰레기를 출시해도 되나요? - 그렇겠습니까?

  • 내일의 완벽한 소프트웨어의 반대말은 오늘의 훌륭한 소프트웨어지, 오늘의 형편 없는 소프트웨어가 아니다.

  • 사용자의 요구 사항, 기본 성능, 개인 정보 보호, 보안 기준 등의 요구 사항들을 어느 정도 맞추어야 한다. 대신, 품질 역시 이러한 요구 사항 중 일부로 만들라는 뜻이다. (절대 기준이 아니라는 점에 유의.)

• 멈춰야 할 때를 알아야 한다

  • 다시 말하지만, 완벽한 소프트웨어는 만들 수 없다

    
    

Topic 6. 지식 포트폴리오

지식에 대한 투자가 언제나 최고의 이윤을 낸다. - 벤저민 프랭클린(Benjamain Franklin)

• 지식은 휘발성 자산이다.

  • 우리가 종사하고자 하는 직업군은 변화가 빠르다. 기술, 언어, 환경의 개발에 따라 지식은 손쉽게 옛것이 된다.

  • 우리의 가치는 꾸준히 노력하지 않으면 하향 곡선을 탈 수밖에 없으며 그 유효 기한 또한 굉장히 짧다. 끊임 없이 발전하지 않으면 안된다는 뜻이다.

• 지식 포트폴리오 만들기

  • 주기적 투자 - 소량이라도 주기적으로

  • 다각화 - 여러 가지를 알 수록 나의 가치는 높아진다

  • 리스크 관리 - 바구니 분산 법칙

  • 싸게 사서 비싸게 팔기 - 초반의 java는 인기 있는 언어가 아니었다

  • 검토 및 재조정 - 이 기술이 여전히 인기 있는가?

• 목표 세우기

  • 매년 새로운 언어 최소 하나씩

  • 한 달에 한 권씩 기술 서적 / 교양 서적 읽기 (사회 생활은 코딩순이 아니다)

  • 강의 듣기

  • 지역 사용자 단체, 모임 참여 하기 - 네트워킹 기술의 중요성

  • 다른 작업 환경(Window/Linux…) 사용해보기

  • 플로우를 놓치지 않기

  • 비판적 사고력 기르기 - ‘Why?’, ‘Who?’, ’How?’, ’What?’, ’When?’

    
    

Topic 7. 소통하라!

무엇을 가졌는지 보다 어떻게 포장하는지가 더 중요한 때도 있다.

• 최고의 아이디어, 최상의 코드, 아주 실용적인 발상이라도 소통할 수 없다면 아무 효용이 없다.

• 의사소통에 쓰는 언어도 결국은 프로그래밍 언어와 똑같다. 지켜야 할 프로토콜들이 있다.

• HOW?

  • 청중을 알라 - 각 그룹에 맞는 방식으로 접근하기

  • 말하고 싶은 내용을 알라 - 떠오르는 순서대로 말을 뱉는 건 최악이다

  • 때를 골라라

  • 멋져 보이게 하라 - 텍스트 스타일링

  • 청중을 참여시켜라

  • 경청하라

  • 응답하라

  • 문서화 - 의사소통의 주석화

2장 실용주의 접근법

Topic 8. 좋은 설계의 핵심

• ETC(Easier to Change) 원칙을 따르라

  • 좋은 설계란 바꾸기 쉬운 설계

    
    

Topic 9. DRY: 중복의 해악

스타 트렉의 외계 컴퓨터는 모순 앞에서 무력화 되었다.

• DRY(Don’t Repeat Yourself) 원칙을 따르라

• 문서화 중복

  • 코드와 주석이 같은 말을 하고 있을 때에는 함수 이름으로 함수를 설명하라.

• 데이터의 DRY 위반

  • 변하는 데이터의 값은 계산 값으로 구현하라.

• 표현상의 중복

  • API 및 데이터 저장소와의 연결 과정에서 중복이 생긴다.

    • 내부 API 중복 해결: 언어나 기술에 중립적인 형식으로 내부 API를 정의할 수 있는 도구를 찾고, 여러 팀이 공유할 수 있게 하라.

    • 외부 API 중복 해결: OpenAPI 같은 형식의 API 명세를 API 도구로 불러와 사용하라. 찾지 못했다면 하나 만들어서 공개해도 좋다.

    • 데이터 저장소와의 중복 해결: 데이터 스키마 분석 기능 또는 키-값 데이터 구조를 사용하라.

• 개발자 간의 중복

  • 의사소통을 잘 하는 팀을 만들어야 한다.

    
    

Topic 10. 직교성

• 직교적인 시스템의 장점

  • 생산성 향상: 작고 자족적인 컴포넌트는 만들기 쉽고, 타 컴포넌트와의 결합으로 더 많은 기능을 얻을 수 있다.

  • 리스크 감소: 감염 코드가 격리되어 있어 문제점이 한정될 수 있고, 특정 업체에 덜 종속된다.

• 요구사항이 변경될 때 영향받는 모듈 수를 줄이도록 계층 구조의 설계를 하라.

  
  

Topic 11. 가역성

당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다. - 에밀 오귀스트 샤르티에, 《종교론》

• 유연한 아키텍쳐를 만들라. 즉, 바꾸기 쉽게 만들어라.

  
  

Topic 12. 예광탄

준비, 발사, 조준…… - 미상

• 예광탄 코드를 써서 전체 애플리케이션의 불확실한 부분을 찾아 필요한 뼈대를 추가하라.

• 사용자가 프로그램의 작동을 일찍 볼 수 있고, 구체화된 코드 위에서 개발자가 일하기에도 용이하다.

  
  

Topic 13. 프로토타입과 포스트잇

• 정확성, 완전성, 안전성, 스타일은 무시해도 좋다.

• 프로토타입 코드를 사용해서는 안된다. 반드시 폐기해야함을 알려라.

  
  

Topic 14. 도메인 언어

언어의 한계가 곧 자기 세계의 한계다. -루트비히 비트겐슈타인

• 문제 도메인에 가깝게 프로그래밍하라.

• 도메인 언어는 원래 코드의 어휘를 진짜로 확장시킨다.

  
  

Topic 15. 추정

• 원하는 답을 제시하라. 정확도인가? 또는 단순한 큰 그림인가?

• 조건을 이해해야 한다. 조건이 답변의 일부가 되기도 한다.

3장 기본도구

Topic 17. 셸 가지고 놀기

• 개발자에겐 명령어 셸(cmd, 터미널)이 작업대이다.

• 생각보다 셸을 통해 할 수 있는 것은 상당하다.

  • 응용 프로그램, 디버거, 브라우저, 에디터, 유틸리티 실행

  • 파일 검색

  • 시스템 상태 조회

  • 출력 필터링

  • 매크로 명령 생성

• 더 편한 포인터로 클릭하면 안되나?

  • 안된다. 셸을 사용하면 보이는 것이 전부이기 때문.

• 자신만의 셸을 만들어보자!

  • 맥 사용자들은 iTerm을 잠시 밀어두고 셸을 꾸며보자.

    
    

Topic 18. 파워 에디팅

• 에디터를 유창하게 쓸 수 있게 하라.

  • 단순히 시간 절약을 하는 것 뿐만 아니라 에디터의 사용법을 생각하지 않아도 된다는 것이 큰 장점이다.

• 어떤 것이 ‘유창’한 것인가? -아래 미션을 마우스나 트랙패드 없이 수행 가능한 정도

• 마우스나 트랙패드 없이 코딩해보자

  
  

Topic 20. 디버깅

알아두면 쓸데없는 신박한 잡학사전 개발자ver.

최초의 컴퓨터 시스템 기기에 나방이 걸려 오류가 생긴 게 버그의 유래이다.

• 디버깅의 심리

  • 디버깅은 단지 문제풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.

  • 버그가 누구의 잘못인지는 중요하지 않다. 우리가 그것을 해결해야 한다는 것이 중요하다.

• 당황하지 말라.

• 코드를 고치기 전 실패하는 테스트부터.

• 그놈의 오류 메세지 좀 읽어라.

4장 실용주의 편집증

사람은 완벽한 소프트웨어를 만들 수 없다.

Topic 24. 죽은 프로그램은 거짓말을 하지 않는다

모든 오류는 정보를 준다.

• 오류가 발생할 리 없다고 자신을 설득하고 무시할 수도 있다. 하지만 실용주의 프로그래머는 오류가 발생하면 정말 나쁜일이 생길 것이라고 자신에게 이야기한다.

• 망치지 말고 멈춰라

  • 죽은 프로그램이 끼치는 피해 << 이상한 상태의 프로그램이 끼치는 피해

    
    

Topic 26. 리소스 사용의 균형

촛불 하나를 켜는 건 곧 그림자도 하나 던지는 거란다. - 어슐러 k. 르 권

• 자신이 시작한 것은 자신이 끝내라

  • 리소스를 할당하는 함수나 객체가 리소스를 해제하는 책임 역시 져야 한다. 책임지지 않을 경우 추적하기가 점점 더 복잡해진다.

5장 구부러지거나 부러지거나

Topic 28. 결합도 줄이기

결합도가 낮은 코드가 바꾸기 쉽다.

• 다리를 설계할 때는 그 형태가 바뀌지 않기를 바랄 것이다. 즉, 구조가 단단해야한다.

• 소프트웨어를 설계할 때는 언젠가 형태를 바꾸려 할 것이다. 즉, 구조가 유연해야한다.

  • 유연하려면 각각의 부품이 다른 부품에 가능한 한 조금만 연결되어야 한다.

    
    

Topic 30. 변환 프로그래밍

상태를 쌓아 놓지 말고 전달하라.

• 데이터를 거대한 강으로, 흐름으로 생각하라.

• 입력을 출력으로 바꾸어 나가는 진행 상황을 데이터로 자유롭게 표현할 수 있다.

  • 이로써 결합을 줄일 수 있다!

• 코드를 일련의 변환으로 생각하는 접근 방식은 프로그래밍을 해방시킨다.

  
  

Topic 31. 상속세

당신이 원한 것은 바나나 하나였지만, 당신이 받은 것은 바나나를 들고 있는 고릴라와 정글 전체이다. -조 암스트롱

• 객체 지향 개발자가 상속을 사용하는 이유는?

  • 타입이 싫어서

    • 입력하는 글자 수를 줄이기 위해서 상속을 쓴다.

    • 상속으로 공통 기능을 기반 클래스에서 자식 클래스로 넘긴다.

  • 타입이 좋아서

    • 상속으로 클래스 간의 관계를 표현한다. car는 vehicle의 일종이다.

• 상속의 문제

  • 상속도 일종의 결합이다.

  • 다중 상속의 문제가 발생한다.

• 상속세를 내지 말라 - 해결책

  • 인터페이스와 프로토콜

    • 다형성은 인터페이스로 표현하는 것이 좋다.

  • 위임

    • Has-A보다 Is-A관계가 더 낫다.

  • 믹스인과 트레이트

    • 믹스인으로 기능을 공유하라.

6장 동시성

동시성이란?

둘 이상의 코드 조각이 동시에 실행 중인 것’처럼’ 보이는 것

병렬성이란?

둘 이상의 코드 조각을 동시에 실행하는 것

Topic 33. 시간적 결합 깨뜨리기

작업 흐름 분석으로 동시성을 개선하라.

시간적 결합이란?

“B 동작은 A 동작의 선행이 필요하다” , “버튼 클릭은 화면 갱신이 필수적이다” → 경직된 코드

• 동시성 찾기

  • 활동 다이어그램(Activity Diagram)의 적극적 활용

  • 동시에 진행할 수 있는 작업의 색출

• 동시 작업의 기회

  • 설계의 필요성 : 실제로 병행할 수 있는 작업인가? (ex. 데이터베이스 조회, 외부 서비스 접근, 사용자의 입력 대기)

• 병렬 작업의 기회

  • 좋은 설계 = 바꾸기 쉬운 설계

  • 프로세서들의 적절한 작업 분배가 필수적

    
    

Topic 34. 공유 상태는 틀린 상태

의사 선생님, 이렇게 하면 아파요. 네? 그러면 그렇게 하지 마세요. - 어느 썰렁한 농담집

한정된 자원의 현재 상태가 전체 코드에 제약 없이 공유되는 것은 바람직하지 않다. 이미 고갈 된 자원에 타 코드가 접근하면서 치명적인 시스템 오류를 발생 시킬 수 있기 때문이다.

세마포어란?

한 번에 한 사람만 가질 수 있는 Flag (ex. memory lock-wait 매커니즘)

• 자원의 트랜잭션 관리

  • 중앙 통제 알고리즘

def get_pie_if_available() //파이 가게에서 파이가 한 조각 남았을 때, 두 명의 종업원 중 
	@case_semaphore.lock() //한 사람만 실제 파이를 판매하기 위해 flag를 올릴 수 있고
try {
	if @slices.size > 0
		update_sales_data(:pie) //판매한 후
		return @slices.shift
	else
		return false
	end
}
ensure {
	@case_semaphore.unlock() //판매 완료 이후 flag를 내린다
}
end

• 둘 이상의 자원과 트랜잭션

  • 여러 자원을 하나의 모듈로 통합해 관리하는 것이 보다 실용적

slice = display_case.get_pie_if_available() //파이가 남아 있다면 판매 가능
scoop = freezer.get_ice_cream_if_available() //아이스크림이 남아 있다면 판매 가능

if slice && scoop //파이와 아이스크림이 모두 남아 있다면
	give_order_to_customer() //아이스크림을 올린 파이를 배달 가능
end

만약 한쪽의 자원이 먼저 고갈 된다면 다른 쪽의 자원도 즉시 반환

slice = display_case.get_pie_if_available() 

if slice //파이 판매가 가능하고
	try {
		scoop = freezer.get_ice_cream_available()
		if scoop //아이스크림 판매가 가능하다면
			try {
				give_order_to_customer() //아이스크림을 올린 파이를 배달 가능
			}
			rescue {
				freezer.give_back(scoop) //배달 불가 시 아이스크림 반환
			}
		end
	}
	rescue {
		display_case.give_back(slice) //배달 불가 시 파이 반환
	}
end

• 트랜잭션이 없는 갱신

  • 수정 가능한 자원을 공유하는 작업 코드는 늘 자원 관리에 주의를 기울여야 한다.

  • 병렬 처리를 하지 않을 때 작업 디렉터리를 원래 위치로 바꾸는 것도 방법 중 하나이다.

7장 코딩하는 동안

Topic 37. 파충류의 뇌에 귀 기울이기

내면의 파충류에게 귀 기울여라.

파충류의 뇌란?

프로그래밍 경험이 늘수록 뇌에는 암묵적인 지식이 쌓인다. 잘 먹히는 방법, 그렇지 않은 방법, 오류의 다양한 원인 등. 무의식 속에 잠들어 있는 이러한 경험적 지식이 ‘파충류의 뇌’다.

Q. 그렇다면 무의식 속 잠재 기억들은 어떻게 꺼낼 수 있을까?

• 파충류와의 대화

  • 하던 일 멈추기 : 뇌가 정리할 수 있는 시간과 공간 확보 (ex. 산책, 수다 등)

  • 코드를 다이어그램화하고 동료, 인형, 가족, 친구에게 설명해보기

• 타인의 코드에서 배우기

  • 메모의 습관화 : 다른 사람이 작성한 코드의 이상한 점, 패턴, 경이로운 점들을 적어두기

    
    

Topic 38. 우연에 맡기는 프로그래밍

운을 실력으로 만들어라.

• 우연에 맡기는 프로그래밍

  • 어째서 돌아가는가? - 운이 좋았기 때문에?

  • 어째서 돌아가지 않는가?

• 구현의 우연

  • 잘못된 데이터를 호출하는 루틴 : 당장 지금 잘 작동하고 있더라도 반드시 보수가 필요

  • 아주 사소한 문제로도 프로그램은 폐기된다

  • 패턴의 인과 관계를 추정하지 말고, 증명하는 습관을 길러라

• 상황의 우연

  • 검색 사이트는 신이 아니다 : 항상 의미를 신경 쓰고, 올바른 답을 찾기

    
    

Topic 40. 리팩터링

코드는 끊임 없이 발전해야 한다.

리팩터링이란?

외부로 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법

이때 외부 동작은 유지되어야 함으로 부수적인 기능이 추가되어서는 안 된다.

• 리팩터링의 시기

  • 하단의 이유로 프로그램을 일부 변경해야만 할 때

    • 중복

    • 비직교적인 설계

    • 유효하지 않게 된 지식

    • 필요도의 변화

    • 성능 개선을 위한 코드 위치 변화

• 리팩터링의 방식

  • 리팩터링과 기능 추가를 병행하지 말 것

  • 리팩터링의 결과를 보증할 테스트의 존재 확인

  • 세분화된 단계를 밟아가며 신중하게 작업할 것

    
    

Topic 41. 테스트로 코딩하기

테스트는 단순히 버그를 찾아내기 위한 작업이 아니다.

기능 단위 테스트가 이루어지는 코드는 자연스레 결합도도 낮아진다. 코드의 근본적 이해도를 높여주는 것은 금상첨화다. 테스트는 버그를 찾아내는 작업이기 보다도, 코드 자체의 품질을 높여주는 과정이다.

• 테스트 주도 개발(TDD)

  • 기본 주기

    • 추가하고 싶은 기능 결정

    • 기능 구현 완료 시 통과해야 하는 테스트를 하나 작성

    • 테스트 실행 - 기존의 테스트는 모두 통과하고, 방금 추가한 테스트만 실패해야 성공

    • 해당 테스트가 통과될 만한 최소한의 코드 작성 - 재테스트

    • 코드 리팩터링 - 개선 부분이 있는가? 개선 이후에도 테스트를 통과하는가?

  • TDD : 목표 정하기

    • 단계 별로 세분화된 테스트를 고안하고 하나하나 확인해 나가기

    • 궁극 목표를 잊지 않을 것 : 사소한 테스트 하나의 성공보다는 핵심 로직 작성에 주목

• 단위 테스트

  • 모듈을 조각내어 살펴보는 테스트

  • 일종의 인위적인 환경을 구축하고 테스트 모듈의 루틴을 호출하는 방식

  • 반환 결과를 예상 값, 혹은 이전 결과와 비교

  • 수정 이후 재 테스트하는 과정 - 회귀 테스트 regression testing

• 임시 테스트

  • 직접 코드를 분석하는 테스트 (ex. console.log(), debugger, IDE 직접 실행 등)

  • 실행 이후 이 임시 테스트 역시 정식 테스트 형태로 보존해 놓을 것

• 테스트 접점 만들기

  • ‘완벽한’ 테스트는 없다 - 배포 이후에도 이어지는 지속적인 테스트의 필요성

  • 로그 파일을 규칙적이고 일관되게 관리할 것

    
    

Topic 44. 이름 짓기

이 변수는 무슨 이유로 작성하고 있는 거지?

• 문화를 존중하라

  • i, j, k와 같이 관례적으로 쓰이는 한 글자 변수명은 존중할 가치가 있다.

• 일관성을 유지하라

  • 변수의 뜻을 모두가 알 수 있도록 일관성 있게 사용할 것

  • 페어 프로그래밍 기법의 경우 유용하게 연습 가능

8. 프로젝트 전에

Topic 45. 요구 사항의 구렁텅이

완성은 더 이상 더할 것이 없을 때가 아니라, 더 이상 뺄 것이 없을 때 달성 되는 것이다.

• 프로그래머의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는 것이다.

  • 우리는 의뢰인의 말을 해석해서 그로 인한 영향을 다시 알려주어야 한다.

• 요구 사항은 피드백을 반복하며 알게 된다.

  • 모형이나 프로토타입을 만들어 의뢰인이 직접 다뤄볼 수 있게 하라.

• 요구 사항 문서화

  • 요구 사항 문서는 의뢰인을 위한 것이 아니다. 계획을 위한 것이다.

• 프로젝트 용어 사전을 사용하라.

  • 프로젝트에 참가하는 모든 사람이 동일한 용어를 사용해야 한다.

완벽한 소프트웨어를 만들고 싶다는 꿈은 시간과 노력만을 낭비하게 할 것이다.

Topic 46. 불가능한 퍼즐 풀기

늘 보이는 것만큼 어렵지는 않다.

• 생각의 틀을 벗어나지 말고, 틀을 찾아라.

  • 자신에게 주어진 자유도를 파악하라.

• 자신만의 방법에서 빠져나오라

  • 안 풀리는 문제를 붙잡고 있기보다, 잠시 의식을 환기하라.

• 행운은 준비된 사람에게 찾아온다.

  • 뇌의 무의식 영역에 원료를 주입하라.

    • 일상적인 작업을 할 때 무엇은 잘되고 무엇은 안되는지 피드백 하라.

      
      

Topic 47. 함께 일하기

코드에 혼자 들어가지 말라.

• 사용자는 여러분 팀의 일원이다.

• 코딩 도중 질문과 토론을 하라.

• 짝 프로그래밍

  • 한 명은 코드를 입력하고, 다른 한 명은 문제만 푼다.

  • 입력 담당이 아닌 개발자는 더 넓은 범위에서 고민을 할 수 있다.

  • 입력 담당 개발자는 두 번째 사람에게 받는 압력을 원동력으로 보다 좋은 품질의 소프트웨어를 만들 수 있다.

• 몹 프로그래밍 : 셋 이상 참여하는 짝 프로그래밍의 확장판

  • 사용자, 프로젝트 후원자, 테스터 등 개발 팀 일부로 여겨지지 않는 사람도 쉽게 끌어들일 수 있다.

• 코드에 혼자 들어가지 말라.

  • 누가 가장 똑똑한지 겨루지 말라.

  • 소규모로 시작하라.

  • 코드만 비판하고 사람을 비판하지 말라.

  • 다른 사람의 관점을 듣고 이해하려고 노력하라. 다른 것은 틀린 것이 아니다.

  • 자주 회고하라. 다음 번에 시도하거나 개선할 점을 찾아라.

    
    

Topic 48. 애자일의 핵심

과정이 설계를 주도한다.

• 애자일은 방식이다.

  • 애자일 선언은 고정불변의 문서가 아닌 만들어 가는 과정에 대한 제안

  • 애자일 선언에서 언급한 가치를 기억하라.

    • 공정과 도구보다 개인과 상호작용

    • 포괄적인 문서보다 작동하는 소프트웨어

    • 계약 협상보다 고객과의 협력

    • 계획을 따르기보다 변화에 대응하기

• 애자일 프로세스는 있을 수 없다.

  • 피드백 수집과 대응으로 불확실성을 헤쳐 나가는 것이 애자일의 전부

  • 좋은 설계로 무언가를 바꾸기 쉬울 때, 애자일이 전반적으로 작동할 수 있다.

    
    

9. 실용주의 프로젝트

Topic 49. 실용주의 팀

실용주의 프로그래머를 실용주의 프로젝트로”

• 깨진 창문 없애기

  • 제품의 품질에 책임지기(품질 관리 담당자의 책임이 아니라!)

• 삶은 개구리

  • 모두 적극적으로 환경 변화(범위 확장, 일정 단축, 추가 기능, 요구 사항의 변경) 감시

• 지식 포트폴리오 계획

  • 자신들의 지식과 기술에 투자할 것Now or Never!

    • 구형 시스템 보수

    • 프로세스 회고와 개선 - 무엇이 잘되고 있는가? 무엇이 잘못되고 있는가?

    • 새로운 기술 탐험 - 후보 기술의 프로토 타입, 새로운 시도, 결과 분석

    • 학습 및 기술 갈고 닦기 - 팀원들과 함께

• 소통

  • 개발자/개발자, 팀/세상 → 원활한 의사소통은 중복을 줄인다

• 팀 예광탄

  • 모든 기능을 갖춘 팀을 조직하라

• 자동화

  • 개발과 서비스 배포 과정을 전부 자동으로

    
    

Topic 50. 코코넛만으로는 부족하다

특정 개발 방법이나 프레임워크, 테스트 기법을 굳이 사용하는 이유가 무엇인가?

• 맥락의 중요성

  • 시장, 제약 조건, 전문성, 조직 크기, 경영진, 문화, 사용자 층, 요구 사항…

• 쓸모 없는 만병 통치약

  • 규칙을 넘나들며 좋은 부분만 떼어내 적용하기

• 올바른 방향

  • 필요한 시점의 지속적 배포, ‘기능 스위치’

    
    

Topic 51. 실용주의 시작 도구

생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다. - Alfred North Whitehead-

• 버전 관리 - 빌드, 테스트, 릴리스

• 테스트 일찍, 자주, 자동으로

  (1) 단위 테스트 - 하나의 모듈, 모든 테스트의 근간

  (2) 통합 테스트 - 서브 시스템 간의 협업

  (3) 유효성 평가 및 검증 - 정말 필요한 성능인가? 요구사항을 만족하고 있는가?

  (4) 성능 테스트 - 스트레스 테스트

  (5) 테스트의 테스트

• 전체 자동화

  
  

Topic 52. 사용자를 기쁘게 하라

프로젝트의 성공 여부는 어떻게 알 수 있을까?

모든 팀 구성원이 사용자가 기대하는 바를 완전히 이해하고,

매 순간 그것을 의식하며 개발에 임해야 한다.

자발적으로 요구 사항을 분석하고, 고객과 적극적으로 소통하자.

우리는 문제 해결사다.

Topic 53. 오만과 편견

내가 이걸 만들었고, 내 작품의 품질은 내가 보증합니다.

맺으며

바쁘게 돌아가는 현대사회에서 책 한 권을 온전히 읽어내기란 사실 꽤 어려운 일이 되었습니다.

쏟아지는 일과 일상 때문에 여유 시간이 없다는 것도 하나의 핑계가 될 수 있겠지만, 우리가 어느 순간부터 텍스트보다는 영상에 더 익숙해 져버린 세대이기 때문일지도 모르겠네요.

그런 면에서 함께 독서 스터디를 진행한 모든 팀원들이 입을 모아 이번 <다독다독> 컨텐츠가 정말 좋은 기회였다는 감상을 남긴 것 그렇게 이상한 일은 아니겠죠.

“늘 미뤄오던”, “거들떠도 보지 않았을”, “표지만 겨우 들추어봤을 것 같은” 책을 함께 읽으니 어느덧 완주할 수 있었습니다. 우선은 이것이 제일 값진 경험입니다.

또 그 유명세를 증명하듯 유려한 필력으로 쓰인 본문 역시 4명의 팀원 모두에게 무척 긍정적인 영향을 주었다고 생각합니다.

우선 개발 서적임에도 불구하고 특정 개발 분야에 국한되지 않고 ‘개발자’가 알아두면 좋을 전반적인 개발 팁들, 가져야 하는 소양, 태도, 자세 등을 두루두루 다루고 있어 각자 관심사가 다른 팀원들이지만 모두 부담 없이 읽을 수 있었어요.

가끔은 ‘내가 이런 것들에 소홀했구나’, 하고 반성할 수 있는 부분도 있었고, 학부에서 배운 지식과 그렇지 않은 지식을 비교해가며 발전할 수 있는 부분도 있었습니다.

결론적으로는 모두가 ‘언젠가 이 책에서 배운 조언들을 현장에서 자연스럽게 써 먹을 수 있는 프로 개발자가 되고 싶다’ 는 소감을 나누며 마무리 할 수 있었네요.

좋은 개발자를 꿈꾸는 사람부터 현직에서 일하고 있는 사람에 이르기까지 다양한 사람에게 도움이 될 만한 책, 「실용주의 프로그래머」.

단순히 일회성 독서 스터디 용 책이 아닌, 앞으로도 책장에 꽂아두고 필요할 때마다 두고두고 꺼내 읽을 것만 같은 책이었습니다.

다시 한 번 좋은 기회 제공해주신 SK DEVOCEAN께 감사의 말씀 드리며 글 마치도록 하겠습니다.

긴 글 읽어주셔서 감사합니다!