- 추천의 글
- 법무팀은 우리 IT 팀의 답변은 믿지 않았고 세부사항까지 관리해야 마음이 놓였다.
- 그러면서도 무슨 이유에서인지 법무팁은 믿었고 세부사항까지 관리할 생각은 없었다.
- 법무팀은 어떤 식으로든 프로다운 모습을 보였고 기술팀을 그러지 못했다.
- 그 날 이후, 전문 기술자로 일하는 긴 세월 동안, 무엇을 바꿔야 프로로 대접받을지 항상 궁금했다.
- 소프트웨어 프로페셔널리즘에 관한 책
- 프로의 마음가짐
- 프로 프로그래머 - 태도, 원칙 행동이 핵심
- 테스트를 소홀히 한 이유는 재때 선적했다고 떠벌리고 싶었기 때문이다. 그게 내 체면을 세우는 일이었다.
- 고객이나 회사는 뒷전이었다. 관심을 가졌던 건 내 평판뿐이었다.
- 해를 끼치지 마라, (기능과 구조 )
- 제대로 작동하는지 아닌지 확인
- 간단하다 테스트하고 또 테스트하라
- 해결책은 테스트하기 쉽게 코드 작성
- 테스트 코드 작성 후 그 테스트를 통과하도록 코드를 작성
- 구조에 해를 끼치지 마로
- 전체 구조를 희생하면서까지 기능을 추가하는 일이 헛고
- 소프트웨어는 변한다. 이가정을 어기고 구조를 유연하게 만들지 못한다면 수익 기반인 경제 모델이 취약
- 프로가 되고 싶다면 지식을 익혀 큼지막한 덩어리를 만든다음 그 덩어리를 계속 키워야한다.
- 연습(kata)
- 아니고 말하기
- 노력한다는 약속은 지금가지는 늑장을 부렸으며 힘을 비축했다고 인정하는 셈이다.
- 노력하겠다는 약속은 계획을 바꾼다는 약속이다.
- 훌륭한 코드는 불가능한가
- 상속 구조가 안 좋은 이유는 극히 일부를 제외하면 has-a 관계가 is-a 관계보다 훨씬 낫기 때문이다.
- 좋은 코드는 확장 가능해야 한다. 운영하기 좋고, 바꾸기 편해야한다.
- 고객은 항상 완료일을 연장한다. 항상 더 많은 기능을 바란다. 항상 나중에 가서야 바꾸고 싶어한다.
- 고객은 개발자에게 들이는 비용을 절감하고, 이는 훌륭한 코드를 쓸모없게 만든다.
- 개발자 입장에서 주의를 기울이지 않으면 시간은 반으로 줄고, 코드는 두 배로 작성하라는 요청/명령/기만을 받게 된다.
- 제 시간에 일을 완료하기 위해서는 코드가 지저분해도 어쩔 수 없다는 결정을 내리지 말아야 했다.
- 예라고 말하기
- 수련간의 경험을 통해서 원칙을 깨면 느려질 뿐이라는 사실을 알게 됐다.
- "예"라고 대답할 수 있는 창으적인 방법을 찾는 데 고심해야한다.
- 프로가 "예"라고 대답할 때는 약속을 뜻하는 언어를 사용해서 내뱉은 말에 모호한 부분이 없도록 해야한다.
- 코딩
- 어떤 일에 통달하는 비버은 자신관과 오류를 느끼는 감각이라는 사실을 깨달았다.
- 준비된 자세
- 코드는 반드시 동작해야 한다.
- 코드는 고객이 제시한 문제를 반드시 풀어야 한다.
- 코드는 기존 시스템에 잘 녹아들어야 한다. SOLID 객체지향 원칙을 따라야 한다.
- 코드는 다른 프로그래머가 읽기 쉬어야 한다.
- 디버깅 시간 - 다버깅 시간을 가능한 한 0에 가깝게 줄이는 일을 프로가 짊어진 의무다.
- 테스트 주도 개발
- 단위 테스트는 문서다, 시스템의 가장 낮은 단계의 설계를 알려준다.
- 연습
- 무술과 프로그래밍 두 가지 경우 모두 속도는 연습에 달려 있다.
- 인수 테스트
- 프로그래머와 사업부 사이의 가장 흔한 의사소통 쟁접은 요구사항이다.
- '완료'라는 모호함. 개발자가 어떤 업무를 완료했다고 말할 떄, 그 의미는 무엇인가?
- 인수테스트는 자동화 되어야 한다.
- 인수 테스트는 사업부를 위해 사업부가 작성한다.
- 인수 테스트는 사업적 관점에서 시스템이 어떻게 운영되어야 하는지를 구체적으로 표시한 공식 요구사항 문서다.
- 단위 테스트는 프로그래머를 위해서 만든다.
- GUI를 통하는 것보다 실제 API를 통해서 기본 시스템의 기능을 불러오는 테스트를 작성하는 것이다. 이 API는 GUI가 사용하는 API와 같아야 한다.
- 테스트 전략
- TDD는 강력한 원칙이며, 인수테스트는 요구사항을 표현하고 강화하는 가지있는 방법니다.
- 하지만 이는 전체 테스트 전략의 일부분일 뿐디아. 'QA'는 오류를 찾지 못해야 한다'는 목표를 달정하기 위해서는 개발팀과 QA가 손잡고 단위, 컴포넌트, 통합, 시스템, 탐색 테스트의 계층을 만들어야 한다.
- 시간 관리
- 오전에는 방해가 되는 일/ 오후에는 중요한 업무
- 회의
- 프로는 회의 비용이 비싸다는 사실을 안다.
- 관리자의 가장 중요한 임무 중 하나는 직원을 회의로부터 보호하는 일이다.
- 일일 회의 / 어제는 머했다. 오늘은 뭘 할 예정인가, 방해요소는 없다. ( 참석자당 1분)
- 논쟁/의견 차이
- 어떤 논쟁이든 5분 안에 해결되지 않으면 논쟁으로는 해결할 수 없다. 논쟁이 길어지는 이유는 양쪽보두 근거가 되는 명뱁한 증거가 없기 때문이다. => 합의를 보려면 데이타를 가져와야 한다.
- 데이트는 직접 실험을 하거나, 모의실험 혹은 모델링을 하면된다.
- 추정
- 프로는 달성할 수 있다는 사실을 알지 못하면 약속하지 않든다.
- 압박
- 코드가 난장판이 되는 말든 고객 시연에 성공하면 영웅이 됐다. 이런 짓을 하면 승진했다.
- 위기 상황에서도 편하게 느겨지는 규율(ex.Tdd)을 골라라. 그 규율을 항상 따라라. 이 것이 위기상황을 피하는 최선의 방법이다.
- 어려움에 빠진 사실을 팀 동료와 상사에게 알려야 한다. 깜짝 사고는 피야햐 한다. 깜짝 사고는 압박을 열 배로 늘린다.
- 함께 일하기
- 처음으로 소프트웨어 최적화가 아주 힘들고 최적화 과정은 비직관적
- 프로그래머 VS 회사
- 자기 일에 열정적인 것은 좋은 일이다. 하지만 월급을 주는 사람들의 목표를 계속 살피는 것 또한 좋은 일이다.
- 절대 피해야 할 일은 기술더이메 파 뭍여 정신을 못 차려 주변에서 사업이 무너지고 붙타는 사실을 알아채지 못하는 것이다.
- 우리 업무는 사업이 순조롭게 나아가도록 만드는 일이다.
- 회사의 관습을 따라야 한다. 다른 사람은 정장을 입는데 나는 입지 않았다. 이유는 내가 이기적이고 자아도취에 빠진 멍청이였기 때문
- 프로는 함께 일힌다.
- 프로그래밍은 온전히 다른 사람과 함께 일하는 것에 관한 업무다. 사업부와 함께 일해야 한다. 서로 같이 일해야 한다.
- 팀과 프로젝트
- 스승과 제자 그리고 장인 정신
- 실망 시키지 않은 대학 졸업생 / 대학 입학 전에 혼자서 프로그램을 공부했고 입학 후에도 대학과 상관없이 스스로 지속적으로 공부를 했다.
- 비관습적인 멘토링
- 아주 잘 만들어진 메뉴얼
- 나를 거들떠 보지 않았던 사람들으 보면서 배웠다.
- 소프트웨어 견습기간 - 이상적
- 장인 - 한 가지 이상의 중요 소프트웨어 프로젝트를 주도/ 10년 이상으 경력 , 여러 다른 시스템, 언어 및 운영시스템 작업 , 능숙한 디자이너 건축가, 힘들지이 않고 다른 이들을 위해 코드를 처리. 또한 판독, 연구, 실행 및 가르치기를 통해 기술적 역활을 유지
- 학교에서는 컴퓨터 프로그래밍 이론을 가르치지만, 장인의 규율, 실태와 장인이 되는 기술은 가르치지 않는다.
- 도구 활용
[프로 소프트웨어 개발자 최소 사항]
1. 디자인 패텬 : 24가지 GOF 패턴을 설명할 수 있고, POSA 패턴을 실무에 적용할 수정
2. SOLID 객체지향 원칙을 알아야 한고, 컴포넌트 개념을 충분히 이해
3. 방법론 : XP, 스트럼, 린, 칸판, 폭포수, 구조적 분석, 구조적 설계 개념을 이해
4. 원칙 : 테스트 주도 개발, 객체지향 설계, 구조적 프로그래밍, 지속적 통항, 짝 프로그래밍을 실천
5. 도구 : UMD, 데이터 흐름도(DFD), Structure chart, Petri Net,
State transition diagrma dn table, flow chart, decision table을 어떻게 쓰는지
파란실버라이트
To remember the time when I started learning Silver Light!