generated from muhandojeon/study-template
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[황동준] 15장 16장 : 실용주의 장인 정신, 소프트웨어 장인으로서의 커리어
- Loading branch information
Showing
2 changed files
with
113 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,75 @@ | ||
## 15장 실용주의 장인 정신 | ||
|
||
### 중요하다고 생각한 내용과 나의 생각 | ||
|
||
286p - 288p | ||
품질은 선택사항이 아니다 | ||
|
||
가장 근본적인 문제는 싸고 그저 그런 코드로도 충분하다는 매우 잘못된 가정을 할 때가 많다는 것이다. 단기적으로는 그럴 수도 있다 하지만 중장기적으로는 절대 그렇지 않다. 보통 품질의 코드를 목표로 하는 회사들은 형편없는 코드를 결과물로 내놓는 경우가 대부분이다. | ||
|
||
당신은 부자도 아니고 공사 기간 동안 생활할 수 있는 다른 집도 없는 보통 사람이라고 가정하자. 인테리어 업자가 품질 확보를 위해서 돈을 많이 지불해야 하거나 공사기간을 두세 배 늘려야 한다고 하면 어떤 선택을 할것인가? **돈을 많이 써서 품질을 확보하든, 돈을 적게 써서 하자가 생기든 두 경우 모두 문제다.** | ||
|
||
289p | ||
소프트웨어 장인은 지속적인 통합과 프로젝트 초기부터의 제품 딜리버리를 목표로 하기 때문에 소프트웨어 품질로 인해 상용 릴리즈가 지연되는 일은 가정에 없는 상황이다. | ||
|
||
어떤 코드이든 몇 줄이 넘어가는 복잡도를 가졌다면 소프트웨어 장인은 테스트 코드를 함께 작성하며, 다른 보통의 개발자가 테스트 코드 작성 없이 작업하는 것보다 더 느려지지 않는다. | ||
|
||
- 저도 이렇게 TDD와 애자일하게 개발하는 것에 능숙해지고 싶다는 생각이 드네요 | ||
|
||
290p | ||
소프트웨어 장인이 작성한 자동화 테스트는 몇 초 안에 , 늦어도 몇 분안에 완료된다. 이를 통해 테스트를 위한 별도의 절차가 있는 경우와 비교하여 기능의 딜리버리 속도가 훨씬 더 빠르다. | ||
|
||
291p | ||
유능한 개발자라면 TDD 때문에 개발 일정이 지연되지 않는다. 그것이 진실이다. | ||
|
||
292p | ||
레거시 코드를 대상으로 작업할 때는 최소한 수정한 부분만큼은 원래 보다 깨끗하게 만들어 놓아야 한다. | ||
|
||
- 소프트웨어 장인 정신을 가진 개발자의 자세를 알려주는 중요한 문장들을 작성했습니다. | ||
|
||
294p | ||
장인이라면, TDDㅇ허 같은 XP 실행 관례들을 절대 불변의 진리라고 믿어서는 안 된다. 지금 당장 우리가 XP를 추구한다고 해서 더 나은 다른 방법을 찾아보는 것을 멈춰서는 안 된다. 소프트웨어를 개발하는 방법이 하나밖에 없다고 생각하는 순간, 다시 말해 우리가 활용해야 할 실행 관례들이 정해져 있다고 믿는 순간 우리는 진화를 멈추게 된다. | ||
|
||
- 매우 중요한 문장이라는 생각이 들었습니다. 저는 위에서 언급했던 것 같이 TDD와 같은 XP 실행 관례들이 진리라고 생각했던 것 같습니다. 이러한 저의 생각을 망치로 때리는 문장이어서 인상깊었습니다. 계속해서 서비스의 품질을, 사용자와 개발자의 경험을 높일 수 있는 좋은 방법들을 생각하고 연구해 봐야 겠다는 생각이 들었습니다. 우선은 현재 소프트웨어 장인이라면 갖추어야 할 능력을 기르는 것에 집중하고 이후에 더 좋은 방법들을 찾아볼 예정입니다. | ||
|
||
295p | ||
특정 실행 관례를 사용하지 않는다는 이유로 누군가를 프로페셔널하지 않다고 성급하게 폄하해서는 안 된다. 그들이 사용 중인 실행 관례가 무엇인지 물어보고 당신이 사용하고자 하는 실행 관례와 비교해서 그들의 것이 어떤 점에서 더 나은지 찾아보아야 한다. | ||
|
||
299p | ||
소프트웨어 프로젝트에서 예측 못한 변경의 양 자체는 문제가 아니다. 문제는 그러한 변화를 따라갈 수 있는 역량의 부족이다. 잘 작성된 소프트웨어는 고객에게 가치를 제공하기 위한 수단이다. 어느 정도 이상 규모의 프로젝트라면 잘 작성된 소프트웨어를 통해 더 높은 품질과 더 빠른 진척도를 얻을 수 있다. | ||
|
||
- 기술적 역량을 키워 예측 못한 변경량이 있더라도 그러한 변화를 따라갈 수 있는 개발자로 성장하기 위해 노력해야 겠다는 생각이 들었습니다. | ||
- 또한 저번에도 이야기 했던 내용인거 같은데 해당 책에서는 TDD가 정말 중요하고 빠르게 개발을 할 수 있다고 하는데 실제로 해보신 분이 있다면 그런 점을 체감했는지 궁금합니다. | ||
|
||
300p | ||
프로젝트를 수행한 사람들이 떠나간 후 그것을 유지보수할 사람들을 고려해야만 한다. | ||
|
||
그 어떤 바보 같은 개발자도 뭔가를 동작하게 만들 수는 있다. 비범한 개발자와 평범한 개발자를 기르는 기준은 어떤 방식으로 그것을 동작하게 만드느냐이다. | ||
|
||
301p | ||
비범한 개발자들은 심지어 단순하고 짧은 솔루션 이상의 것을 추구한다. 그들은 코드 한 줄 짜지 않고 문제를 해결할 방법을 찾는다. 가장 훌륭한 코드는 작성할 필요가 없는 코드이다. | ||
|
||
- 매우 인상 깊은 문장이었습니다. 동시에 단순히 개발과 코드만 바라보는 것이 아닌 사용자를 위한 솔루션 자체에 집중하는 것이 중요하다는 생각이 들었습니다. | ||
|
||
단순한 설계를 위한 네가지 원칙 | ||
|
||
1. 모든 테스트의 통과 | ||
2. 중복의 최소화 | ||
3. 명료성의 최대화 | ||
4. 구성 요소의 최소화 (메서드, 클래스, 모듈의 수는 가능한 적어야 한다.)\\\\\ | ||
|
||
- 책에서는 위 4가지에서 TDD를 일상적으로 실천한다고 가정하면 첫 번째는 무시 가능하면 중복을 최소화 하다보면 구성 요소가 줄어들기에 네 번째 원칙도 무시할 수 있다고 했습니다. | ||
- 그리고 필자는 중복 제거 보다는 명료함을 항상 우선시하고, 단순한 설계를 위한 가이드 라인으로 좋은 네이밍과 비즈니스 콘셉트를 잘 추영한 추상화에 집중한다고 했습니다. | ||
- 그 다음에 중복을 제거하면서 코드의 응집성과 독립성을 높이고 해당 과정에서 새로운 구조를 적용하며 명료성을 또 높인다고 합니다. | ||
- 이러한 책의 의견에서 스터디원들의 생각은 어떤지 궁금합니다. 코드를 작성함에 있어서 제일 중요시 하는 요소는 무엇인가요?? | ||
|
||
303p | ||
사실 상아탑 아키텍트의 말 중에 맞는 내용도 있다. 초기부터 큰 설계를 해야 한다는 것은 잘못되었지만 수십년에 걸쳐 구축한 지식을 버려서는 안된다는 부분은 맞는 말이다. | ||
|
||
304p | ||
**당장의 합당한 이유 없이 단지 '미래를 대비해야 한다'는 모호한 전제로, 초기부터 추상화를 하면 애플리케이션은 엉망이 된다.** 미래에 어느 부분에서 수정이 필요할 지 모르기 때문에 모든 부분에서 추상화(복잡도 증대)를 적용해버린다. **애플리케이션이 진화 및 변경할 수 있도록 모든 가능성에 대비하는 것을 똑똑한 대응이라고 생각할 수 있다. 진실은 반대로 매우 바보같은 짓이다.** | ||
|
||
- 최근까지 가능성을 대비하여 탄탄한 기초 설계를 하는 것이 중요하다고 생각했는데 이 글을 읽으며 꼭 그런 것만은 아니라는 생각도 드네요 프로젝트 초기 단계에서 적절한 설계는 어느 정도일까요..?? | ||
|
||
305p | ||
내가 좋아하는 패턴에 문제를 끼워맞추기 전에 문제에 적합한 리팩토링을 단순한 설계와 SOLID 원칙에 따라서 먼저 시도해야 한다. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
## 16장 소프트웨어 장인으로서의 커리어 | ||
|
||
### 중요하다고 생각한 내용과 나의 생각 | ||
|
||
310p | ||
장인은 특정 도구, 개발 언어, 프레임워크에 독단적인 고집을 부리지 않는다. 항상 주어진 문제에 적합한 도구를 찾고 단순한 해결책을 추구한다. 특정 도구를 종료적으로 신봉하지는 않더라도 최선이라고 알려진 몇몇 조합들에 대해서는 완전하게 마스터하고 있어야 한다. **마스터한 도구들이 없다면 장인이라고 할 수 없다.** | ||
|
||
진정한 소프트웨어 장인 가장 먼저, 코드 작성이 아니라 문제 해결에 집중한다. | ||
|
||
- 위의 문장이 제가 생각하는 소프트웨어 장인의 핵심이라고 생각합니다. | ||
|
||
311p | ||
여기서 말하는 정직과 용기란 필요한 상황에서 고객에게 '아니오'라고 말할 수 있는 것을 의미한다. | ||
|
||
그저 '아니오'라고 답하는 것만이 장인으로서의 태도는 아니다. 모든 '아니오'에는 항상 대안을 제시해야 한다. | ||
|
||
315p | ||
커리어 전반에 걸쳐, 항상 신중하게 다음 직장을 찾았다. 낚시하듯이 여러 회사에 맹복적으로 이력서를 보내는 일은 하지 않았다. 그 대신 집중했다. 내가 일하고 싶은 회사의 형태가 어떠해야 하는지 항상 생각했다. 현실에 부딪혀, 내가 아직 그런 일을 하기에는 부족하다는 이야기를 드렁ㅆ을 떄에도 나느 시간을 두고 다시 준비하고 도전했다. | ||
|
||
316p | ||
커리어 만들어 나가기 | ||
|
||
- 나의 커리어로부터 나는 무엇을 원하는가? | ||
- 그것을 성취하기 위한 다음 단계는 무엇인가? | ||
- 이 일은 나의 커리어 방향과 합치하는가? | ||
- 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가? | ||
- 그러한 투자에 대한 이익은 무엇인가? | ||
- 그러한 투자는 대략적으로 얼마 동안 지속되어야 하는가? | ||
- 내가 되고자 하는 프로패셔널에 이르는 데 이 일은 어떻게 도움이 되는가? | ||
- 이 일에서 나는 자율성, 통달, 목적의식을 가질 수 있나? | ||
- 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치 얻고 행복할 수 있나? | ||
|
||
이 모든 질문에 대한 대답을 고용계약서에 서명하기 전에 파악하기는 거의 불가능하다. 실제 일을 시작하고 나서야 일부 질문들에 대한 답을 알 수 있을 뿐이다. | ||
|
||
319p | ||
원하는 바를 모른다면 어떻게 해야 할까 | ||
|
||
그런 상황에 빠졌을 때 항 수 있는 것은 한 가지 밖에 없다. 마음을 열고 사람들을 만나는 것이다. 껍질을 벗고 뛰쳐 나와 할 수 있는한 최대한 많은 문들을 열어 보아야 한다. |