소프트웨어 장인 : 프로페셔널리즘/실용주의/자부심

BOOKS

소프트웨어 장인 : 프로페셔널리즘/실용주의/자부심

파란실버라이트 2017. 9. 28. 11:44

21세기 소프트웨어 개발
- 오버엔지니어링 - 코드 작성 전에 대응책을 추상화 하고 , 요소마다 디자인 패턴 적용 / 애자일 방식으로 변경
- 커리어 패스를 정할 때 - 내가 열정이 있는 것, 진정 즐겁게 할 수 있는 것을 따라야한다.
- 고참 개발자, 신참 개발자라는 것은 없다.
- 개발자들은 다음과 같은 일을 할 수 있어야 한다. (사진 1)
- 소프트 웨어를 빠르게 바꾸면서도 품질 유지가 가능하다면 높은 경쟁 우위를 차지할 수 있다. 소프트웨어를 비즈니스의 핵심 자산으로 둔 회사 (아마존, 구글, 트위터, 페이스북 등)가 이러한 경쟁 우위가 있다면 시장에서 메이저 업체로 빨리 성장할 수 있다.
- 기민하고 정교하게 잘 만들어진 소프트웨엉[ 대한 요구가 그 어느 때보다 높다.
애자일
- 절차적인 부분 : 팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중한다. 올바른 목표를 향해 진행 중인지 확인할 수 있다.
  - 회의방식
  - 구성원 각각의 역활
  - 요구사항 파악 방법
  - 작업 진척 속도 파악 방법
  - 점진적/반복적으로 일할 때 취하는 방식
  - 진행 상황을 개발팀 밖의 관계자(고객, 영업 등)에게 전달하는 방식
  - 비즈니스 피드백 방식
- 기술적인 관점 : 테스트 주도 개발, 페어 프로그ㅐ밍, 지속적인 통합, 단순한 다자인 원칙. 목표한 것을 올바르게 실행하고 있는지 안심할 수 있게 한다.
- '애자일을 따른 다'는 것은 새로운 환경에 성공적으로 적응하고 있다는 의미다 - 톰 길브
- 민첩(Agile)하다고 해서 애자일을 실행하고 있는 것은 아니다. 애자일 방법론들은 모두 빠르고 짧은 피드백 루프에 대한 것이다.

- 미리 세운 계획에 따라 기계적으로 코딩만 하는 것이 아니라, 계획, 일정 및 예산 드의 추산, 요구사항 분석, 팀 구성, 분석, 아키텍처, 제품 리리즈, 우선순위 조정, 시연 그리고 사용자와 프로젝트 이해관계자에게 정긱적으로 피드백을 받는 단계까지 개발자가 수행하기 시작.
- 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다. 그에 더해 테스트, 분석, 비즈니스에 대한 이해, 커뮤니케이션 능력, 보자 외향적인 성격을 소프트웨어 프로페셔널에게 요구한다.
- 애자일 메니페스토(선언문)
  - 우리는 스스로 행하고 다른 이들도 이를 행할 수 있도록 도움을 줌으로써 소프트웨어 개발의 더 나은 방법을 전파한다. 이러한 작업을 통해 우리는 아래와 같은 가치에 도달하게 되었다.
    - 절차와 도구를넘어선 개성과 화합
    - 종합적인 문서화를 넘어선 동작하는 소프트웨어
    - 계약과 협상을 넘어선 고객과의 협력
    - 계획 준수를 넘어서 변화에의 대응
  - 이들의 앞선 가치들을 인정하면서도 뒤에 오는 가치들에 보다 큰 무게를 둔다.

- 애자일 12가지 원칙
  - 1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
  - 2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
  - 3. 작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더 짧은 기간을 선호하라.
  - 4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
  - 5. 동기가 부여된 사람들을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
  - 6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
  - 7. 작동하는 소프트웨어가 진척의 주된 척도이다.
  - 8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
  - 9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
  - 10. 단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.
  - 11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
  - 12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

- 애자일 스럽지 못한 프로젝트 - 기술적 탁월함보다 절차가 더 중요해졌다. 애자일의 모든 절차들에게는 기술적 탁월함이 전재되어 있다.
- 절차에감 집중하고 소프트웨어 개발을 공장 라인처럼 취급하면, 그저 시키는 일만 하고 출퇴근하는 공장 노동자와 다를 바 없는 개발자들만 생긴다. 이렇게 되면 비효율적인 피드백 시스템이 되어 전체 프로젝트에 해를 끼친다.
- 고참 관리자에게 새로운 절차를 파는 것은 쉽지만 많은 노력과 어려움이 수반되는 기술역량 향상에 투자하도록 설득하기는 꽤 어렵다. 그들은 개발자들이 작성하는 코드 자체의 품질에 관심을 기울여야 한다는 것도 모른다. 그들은 그져 코드가 동작하기만 하면 그냥 만족할 뿐이다.
- 요약
소프트웨어 장신 정신
- 여기저기를 유랑하며 새로운 장인에게 새로운 기술과 도구의 사용법을 익힌다.

- 매니페스토 - 프로페셔널 소프트웨어 개발의 수준을 높인다.
  - 동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨있게 만들어진 작품을
    - 코드를 수정할 때 어떤 일이 일어날지 개발자가 알 수 있어야 하고,
    - 수정 자체가 두려운 상황에 처하지 않도록 해야한다.
    - 변경 사항이 있더라도 그 영향이 해당 기능 모듈에만 국소적으로 제한되며 애플리케이션의 다른 부분에 파급 효과가 없어야
    - 몇 분 또는 몇 초 만에 전체 애플리케이션에 대한 자동화 테스트가 구동되어 잘못된 부분이 있는지 파악 가능해야한다.
  - 변화에 애응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을
    - 신규 기능을 추가하거나 버그 수정만을 뜻하지는 않는다. 코드를 깔끔하게 정리하고 구조를 개선하며 확장성을 높이고
    - 테스트를 가능하게 하고, 쉽게 유지보수할 수 있게 하는 것을 포함
    - 캠핑 장소를 처음 발견했을 때보다 더 깨끗하게 남겨두라 - 로버트 마틴
  - 개별젹으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을
    - 멘토링과 공유
  - 고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를
    - 고용자*피고용자 형태의 관계를 믿지 않는다.
    - 파트너쉽과 프로페셔널한 행동을 계약관계보다 상위에 둔다.
    - 장인을 공장 노동자가 아니다. 적극적으로 프로젝트의 성공에 기여해야 한다.
    - 요구사항에 질문하고 , 비즈니스를 이해하고 , 개선사항을 제안하면, 고객 또는 고용주와 생산적인 동반자 관계를 맺어야 한다.

소프트웨어 장인의 태도
- 오래 전에 작성했던 코드를 지금에 와서도 고칠 부분이 없어 보인다면 , 그것은 그동안 배운 것이 없다는 뜻
- 독서, 낳은 독서, 블로그 , 기술 웹사이트, 트위터 사용법
- 카타
  - codingkata.org
  - codekata.pragprog.com
  - kate.softwarecraftsmanship.org
- 펫 프로젝트 - 최고의 자가 학습, 자가 훈련 방법
  - 펫 프로젝트는 비즈니스 프로젝트가 아니다.
  - 비즈니스을 원한다면, 코드를 작성하고 새로운 기술들은 배운는 것은 최우선 순위가 될 수 없다. 애신 코드를 한 줄이라도 작성하기 전에 먼저 린 스타트업 개념에 대한 자료를 찾아보고 익숙해지를 권한다.
  - 팻 프로젝트를 비스니스화 하고 싶다면 비즈니스 자체에 집중하고, 작성된 코드들을 시작이 원하는 방향이 아니라면 얼마든지 버릴 준비가 되어 있어야한다. 즉 코드에 대한 애착을 버리고 비즈니스 요구에 맞는 최소한의 것만 남기고 깨끗이 정리할 수 있어야 한다.
- 오픈 소스, 페어 프로그래밍
- 다른 개발자들과 어울리기
- 나는 아테네에서 가장 똑쪽한 사람임에 틀림없다. 왜냐하면 나는 내가 아무것도 모른다는 사실을 알기 때문이다. - 소크라테스.
영웅, 선의 그리고 프로페셔널리즘
- 우리는 프로페셔널하지 못했다. 우리가 왜 그 일을 하는지 스스로 묻지 않았다. 고객이 실제로 무엇을 원하는지 이해하려 하지 않았고 다른 대안을 제시하지도 않았다.
- 빡빡한 일정을 다루는 가장좋은 밥업은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것이다.
- 항상 '아니오'라고만 얘기하는 것은 프로다운 태도가 아니다. 모든 '아니오'에는 반드시 하나 이상의 대안들이 따라와야 한다.
- 백로그(해야 할 일 목록) 또한 전체 팀에 공유되고 있었다. 일의 진척도와 해야 할 일을 시작적으로 보여 줌으로써 비즈니스 팀이 우리가 처한 상황을 정확하게 이해할 수 있게 .
동작하는 소프트웨어
- 동작하는 소프트웨어만으로는 부족하다 / 고품질의 동작하는 소프트웨어 옮겨감
- 프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 가깝다. - 실용중의 프로그래머
- 자신이 만든 소프트웨에어 인질이 되는 상황 => 기존 코드에 손을 대는 것을 두려워한다면 지체 없이 대응
- 장인을 전체 애플리케이션을 몇 분만에 테스트할 수 있는 자동화 테스트를 구축하고 활용할 줄 안다.
- 왜 단위 테스트 코드를 애당초 작성하지 않고 반복해서 디버깅하고 있는 건지??
- 자동화된 테스트를 만들고 활용하는 데 능숙한 개발자라면 코드 디버깅을 해야 하는 상황이 매우 드물다.
- 태도는 큰 차이를 가져올 수 있는 작은 요소다. - 윈스턴 처칠
- 무언가 마음에 들지 않는다면 바꾸어라. 그것을 바꿀 수 없다면, 그에 대한 당신의 생각을 바꾸어라 - 마리 엥겔브레이트
- 요약 - 회사와 개발자들은 정기적으로 도끼날을 가는 시간이 낭비가 아니라는 사실을 이해해야 한다. 바로 그것이 시간을 절약하고 끊임없이 빨리 움직일 수 있는 최선의 방법이다.
기술적 실행 관례
- 애자일 방법론은 변화와 싸우는 것이 아니라 변화 자체를 내재화한다.
- 테스트 코드를 먼저 작성
  - 아이디어를 생각 해내는 데도 도움
  - 한 번에 하나에 집중
  - 모듈 , 클래스 , 함수를 구체적으로 정의하도록 강제하여 점진적으로 진행
  - 코드 작성 완료 후 실제 환경에서 기대한 대로 동작할 것이라고 강하게 확신
- TDD에 '테스트가 들어있지만 사실 TDD는 설계에 대한 실행 관례다.
- 테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다.
  - 테스트로 규정된 부분만 작성 되기 때문. 오버 엔지니어링을 막는다.
  - 코드가 복잡하고 방대하면 테스트 자체가 어렵기 때문이다.
- TDD가 주는 비즈니스적 가치
  - TDD에서 주어지는 피드백은 정규적인 설계 리뷰 미팅보다 훨씬 빠르고 객관적
  - 설계 리뷰가 너무 잦으면 무엇이라고 기여하픈 참여자의 욕구로 인해 객관성을 읽고 오버 엔지니어링.
  - TDD는 코드의 설계, 단순성, 유지보수 용이성에 대해 피드백이 빠르다.
  - 코드에 대한 살아 움직이는 문서 역활을 한다.
  - 긍정적인 부가 효과로 회귀 테스트 역할도 한다.
- 지속적인 통합 - 피드백 루프를 줄인다. 코드를 올릴 때마다 전체 테스트 슈트가 실행되고 테트스가 실해하면 이메일이 모든 팀에 전달 , '일단 멈추고 버그부터 수정한다.'
- 리펙토링 - 몇 년동안 바뀐 적이 없는 부분을 리펙토링하는 것은 의미가 없다. 리펙토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다.
- 우리는 지속적으로 일하는 더 나은 방법을 찾고 고객을 만족시켜야 한다.
- 특정 실행관례가 더 이상 우리에게 가치를 주치 못한다면 그 실행관례를 버려야한다. 우리의 일에 항상 최선의 기술, 도구, 절차, 방법론 그리고 실행관례를 선택할 수 있도록 개방적인 사고 방식을 가져야 한다.
길고 긴 여정
- 편한다고 익숙한 상태에서 벗어나 나를 발전시키고 배울 수 있는 기회를 지속적으로 찾아야하만 한다. 나의 인생이고 커리어이고, 내가 주인이어야 했다.
- 원동력 - 동기부여의 원칙 / 돈은 충족되어야 할 기본 조건, 노동자를 움직이는 것은 자율성, 통달, 목적의식.
- 대규모 조직에서 그 회사를 위해 최선의 것이 무엇인지 집중 < 프로페셔널이 되기 위해 노력하는 대신 주어진 규칙과 질서를 지키는 데 에너지를 는 쏟는다. 사내 정치 게임을 위해서 스스로의 가치는 제처둔다. 자신의 승진에 영향력이 있는 사람들과 다툼를 피하기 위해 정직한 의견을 말하지 않고 회사에 해가 되더라도 승진에 도움이 되는 일이라면 기꺼이 한다. => 이런 태도로 일하지 말자.
인재 채용
- 항상 배우기를 우너하고 더 나은 일하는 방법을 찾는 사람은 자신보다 훌륭한 사람과 함께 일하기를 원하고 최소한 자신과 비슷한 역량의 사람이라도 채용되기를 희망한다.
- 열정은 기술적인 역량이나 프로그래밍 언어에 대한 이해보다도 더 중요한 조건이었다. 나는 항상 새로운 것을 시도하고, 배우고, 지식을 공유하고 , 커뮤니티 확동에 적극적인 사람을 원했다.
  - Github account
  - blog
  - open source activity
  - technical community activity
  - pet project
  - Twitter
  - favorite technical books
  - conference to be joined or do presentation
소프트웨어 장인 면접하기
- 면접을 볼 때, 일자리를 구걸하는 입장이 아니라는 것을 기억해야한다.
- 항상 질문을 많이 하는 지원자를 우선시하는 것이 좋다.
- 면접관의 질문들은 대개 면접관이 중요하게 생각하는 것들을 반영한다.
- 어떤 도구를 선호하느지? 프로젝트를 금장 시작할 수 있는지? 테스팅/목업 프레임워크를 이미 모두가지고 사용하고 설정? 업무시간 외에도 코딩을 하는 개발자.
- 좋은 개발자는 나쁜 개발자를 채용하지 않는다.
잘못된 면접 방식
- 금전적 보상 수준보다도 자율성, 배움, 목적, 생산적 파트너쉽, 열정적인 사람들, 좋은 업무 환경과 같은 것을 우선
낮은 사기의 대가
- 장인은 다른 사람에게 무엇을 하라고 명령하는 대신 다른 개발자들과 함께 앉아
- 페어 프로그래밍을 하면서 그들의 지식과 경험 열정을 나눈다.
- 다른 개발자들의 멘토로서 행동하는데 주의를 기울인다.
- 항상 소프트웨어 대해서 이야기하고 자신의 자기 계발 황동을 다른 사람들과 공유하려한다.
배움의 문화
기술적 변화의 실행
실용주의 장인정신
- 리펙토링 - 새로운 기능을 추가할 때마다 코드를 분석하고 필요한 경우 리펙토링을 하여 레거시 코드가 새로운 기능을 자연스럽게 반아들일 수 있도록 해야한다.
- 잘 작성된 코드는 단순하고, 작고, 테스트 가능하며 이해하기 쉽다. 가장 중요한 부분으로 코드가 해야 할 일을 한다.
- 코드는 더 적게 작성할수록 좋다.
- 단순한 설계
  - 모든 테스트의 통과
  - 중복의 최소화
  - 명료성의 최대화
  - 구성요소의 최소화
- TDD에 능숙한 개발자는 개발 초기부터 디자인 패턴을 적용하는 일이 극히 드물다.
- 패턴이 먼저가 아니다. 문제에 적합한 리펙토링을 단순한 설계와 SOLID원칙을 따라서 먼저 시도해야 한다.
소프트웨어 장신으로서의 커리어
- 열정, 이 단어 하나가 모든 것을 요약한다.
- 장인은 소프트웨어 개발과 자신의 직무에 열정적이다.
소프트웨어 장신정신에 대한 오해와 설명

저작자표시 비영리