일을 하는 것 만큼 중요한 것은 일을 어떻게 하느냐 이다.
작가가 이 책을 통해 전하려는 핵심메시지는 저 문장이 아닐수도 있지만, 나를 변화시켜주는 문장은 바로 위 문장이다.
이 책에서 하나의 문장만 고르라고 하면 저 문장을 고르고 싶다(아직 중간까지밖에 안읽음 ㅋㅋ..)
애자일
(초보자가 쓴 글이라, 애자일에 대해 틀리거나 부족한 내용이 있을 수 있습니다. 그렇다면 댓글로 달아주시기 바랍니다.)
애자일 방법론은 폭포수 모델과 반대되는 모델이다.
due date 안에 '기획 -> 개발 -> 시연 -> 배포' 라는 과정을 모두 끝내고 제품을 내놓아야 하는 방식이 폭포수모델이다.
반면 애자일 방법론은 처음부터 초기 제품을 내놓고(배포) 고객의 요구에 맞추어 계속 가치를 창출해내는 방식이다.
즉 변화에 민감하게 대응할 수 있는 방법론이다.
애자일은 모든 공정을 투명하게 공개함으로써 문제를 빨리 인식할 수 있게 하고, 잦은 배포로 변화에 민감하게 대응할 수 있게 한다.
문제는 이러한 절차개선으로 결과가 좋아질 것이라고 착각하는 것이다.
능숙하게 정교하게 제품을 개발함은 물론, 비즈니스적인 이슈에 대해서도 건설적인 피드백을 고류 할 수 있어야 한다. <-> 책상에 박혀서 불러주는 동작만 구현하는 것은 공장 노동자와 다를 바 없다.
절차개선을 최상으로 하더라도 공정 취급을 당하거나, 스스로를 '개발 공정' 이라고 생각하는 개발자들과 일한다면 여전히 제품은 좋아지지 않는다.
비즈니스 자체에 관심을 갖고 일하는 개발자들과 고객의 의견이 교류가 될 때(혹은 관리자가 스스로를 공정이라 생각하지 않는 적극적인 개발자들과 교류할때) 품질이 개선된다.
나는 현재 회사의 랜딩페이지를 개선하는 업무를 맡고 있는데, 마케팅팀과 교류가 활발하게 이루어지며 거의 매주 배포를 하고 있다.
실제로 SEO 관련된 피드백을 받은적도 있고, title태그에 대한 의견을 제시한 적도 있었다.
개발자와 관리자(마케팅팀은 협업자지만 여튼)의 교류만 생각했을 때, 내가 일하는 팀은 애자일하다고 할 수 있는것 같다.
소프트웨어 장인 정신
동작하는 것은 당연하다. 동작하는 것 이상의 코드를 작성해야 한다.
예측 가능하고 유지보수 될 수 있는 코드를 작성해야 한다.
변경사항의 영향력은 기능 모듈을 벗어나지 않아야 한다.
가치를 더한다는 것은 단순 기능 추가, 버그 수정에 국한되는 것이 아니다. 코드를 깔끔히 하고 구조를 개선하고 확장성을 높히는 등 쉽게 유지보수가 가능하도록 해야 한다. -> 내가 4주프로젝트때 작성했던 코드는 가치가 엉망이었다. 작동은 하지만 하나를 수정하기 위해 여러가지를 손봐야 하는, 나말고는 누구도 건들 수 없는 코드가 되었기 때문..
프로페셔널 커뮤니티 조성
장인정신은 엘리트 주의가 아니다.
소프트웨어 장인은 항상 다른 사람에게 배우려는 겸손함이 있어야 하고 경험이 적은 개발자와의 지식을 공유하는데 주저함이 없어야 한다.
업계 혹은 개인의 발전을 위해 블로깅, 오픈소스 기여, 코드 공개, 커뮤니티 참가, 페어프로그래밍 등을 할 수 있다.
나는 코드스테이츠 알럼나이, '이름은 없지만 20명이 조금 안되는 개발자 커뮤니티' 에 가입되어 있는데, 조금 더 활발히 활동하기로 하자!
코드스테이츠는 커뮤니티를 활발하게 하려고 노력하고, 교육과정에는 페어프로그래밍을 매주 2~3회씩 페어를 바꿔가며 실시하는데 그 뒷 배경에는 프로페셔널 커뮤니티 조성을 통한 업계, 개인의 발전을 도모하려는 생각이 있는것같다.(뇌피셜)
협업을 넘어선 동반자 관계
- 책상에 파묻혀 지시사항만 해내는 이는 프로가 아니다.
- 요구사항에 질문하고, 비즈니스를 이해하고, 개선사항을 제안하며 고객 또는 고용주와 생산자적인 동반자 관계를 맺어야 한다
코딩만이 나의 일이라 한다면 소프트웨어 장인이라 할 수 없다.
소프트웨어 장인의 태도
고객은 기술자의 지식과 실력에 돈을 지불한다.
소프트웨어 프로페셔널로 대우받기 원하면 스스로 발전에 돈과 시간을 들여야 한다.
자신이 커리어의 주체로서 언제, 무엇을 배울 수 있을지를 스스로 결정해야 한다. 회사에서 자신을 교육시켜주지 않는다고 불평하면 이는 프로페셔널이 아니다.
고객은 당신의 교육에 돈을 지불하는 것이아니라, 당신의 실력에 돈을 지불한다.
당신은 스스로 그에 걸맞는 가치를 갖고 있는가 스스로 질문해야 한다. 그렇지 않는다면 도태 될 것이다.
훈련
급여를 받는 대가는 문제 해결이기에 '문제를 해결하는 것'이 중요하다.
하지만 훈련을 할 때는 '어떻게 해결했는지'가 중요하다.
훈련을 할 때는 시간이 걸려도 가능한 최상의 코드를 만드는데 노력해야 한다.
일과 삶의 균형 :
낭비시간 줄이기
프로페셔널리즘
고객이 실제로 무엇을 원하는지 이해하려 하지 않았다. 요구사항에 대해 질문을 하지도, 실행할 수 없다는 이야기도 하지 않았다. 우린 그냥 무작정 일을 밀어 붙혔다. 그때는 그것이 프로페셔널이라고 생각했다. 마음속에서는 인정과 명예를 원했다. 불가능한 일을 해낸 사람으로 보이고 싶었다. 결국 그 노력은 헛고생으로 끝났다. 일정이 늦춰졌고 부서의 그 누구도 우리가 얼마나 노력했는지 알아주지 않았다.
....(생략)...
우리의 행동이 프로답지 못했음을 지금은 이해한다. 실제 어떤 문제가 있는지 한번도 질문하지 않았다. 대안을 제시하려 노력하지도 않았다. 우리를 노예처럼 취급하도록 내버려 두고 즐기기 까지 했다.
..(생략)..
우리는 전혀 프로답지 못했다. 한번도 '아니오' 라고 말하지 않았기 때문이다.
- 프로답게 행동하기 : 불명확하거나 불편한 사실들, 걱정되는 사항들을 최대한 빨리 문제제기 해야 한다. 고객의 요구사항을 그냥 받아들이지 않고 스스로 판단해서 의견을 낼 수 있어야 한다.('기간 내 완성 불가' 혹은 '업계에서 불리한 모델이다.' 등등)
그저 실망시키지 않기 위해 말하는 '네'는 거짓말에 지나지 않는다. 그냥 거짓말이 아니라 중독적이고 파괴적인 습관이다. 양의 탈을 쓴 나쁜 습관이다.
고객은 문제를 들고 프로페셔널을 찾아 간다. 프로페셔널이 경험과 지식을 활용해 그 문제를 다룰 방법, 장단점을 알려주길 기대한다.
프로페셔널이 생각하기에 올바르지 않은 결정을 고객이 밀어붙이려 한다면 당연히 프로페셔널은 거부한다. 우리도 그래야 한다.
- 대안 제시 : 모든 '아니오' 에는 반드시 하나 이상의 대안이 따라와야 한다. '아니오'라고 대답하기 전에 문제를 분석한 대안이 있어야 한다. 항상 실용적인 대안을 찾지는 못할 수 있다. 하지만 무턱대고 안된다고 하지 마라.
- 깨어있는 관리자 : 관리자와 개발자 사이에 갑 을 관계는 없다. 좋은 관리자는 외부의 압력으로부터 개발자를 보호하고 팀이 가진 장애요소들을 제거한다. 팀원들이 편안한 마음으로 자신감을 갖고 일할 수 있도록 한다. 팀을 행복하게 하는 것이 관리자의 직무다.
우리 회사는 '심리적 안전감'을 최우선으로 한다. 심리적 안전감이 있으면 '욕먹을 걱정'을 하지 않는다.
우리는 말로만 '심리적 안전감'을 외치는게 아닌, 모두가 '심리적 안전감'을 조성하기 위해 노력하고 있고 그것이 눈에 보인다.
이를 보았을 때 나는 깨어있는 관리자와 일하고 있다고 생각한다.
동작하는 소프트웨어 - 코드의 품질
소프트웨어는 동작하는 것만으로 부족하다.
소프트웨어 프로젝트에서 소스 코드 보다 중요한 것은 없다.
레거시 코드도 동작하는 소프트웨어라고 볼 수 있다. 새로운 기능을 추가할 때 마다 의존성을 파악해야 하고, 해당 기능 뿐 아니라 의존되어 있는 다른 모듈들도 수정해야 한다. 이러한 소프트웨어도 동작하는 소프트웨어긴 하다.
코드의 품질이 낮아질수록 새로운 기능을 추가하거나 버그 수정이 점점 더 어려워진다.
평범한 개발자가 아닌, 프로페셔널는 시간적인 제약이나 요구 사항의 변경을 나쁜 코드를 위한 변명으로 삼지 않는다.
코드의 품질이 프로젝트의 성공을 보증하지는 못하지만 실패의 핵심요인이 될 수 있다는 것을 알아야 한다.
빨리 끝내는 것이 개발자로서의 미덕이 아니다. 빨리하는 것과 허술한 것은 다르다.
기술적 실행 관례 - 테스트 주도 개발(TDD)
테스트 주도 개발은 실행 관례가 되어야 한다.
어떤때는 하고 어떤때는 하지 않는 것이 아니다.
시간이 없다며 테스트 주도 개발을 하지 않아 결국에는 더 많은 시간 낭비를 하게 된다.
소프트웨어 장인정신은 더 많은 애자일 방법론들과 마찬가지로 고객에게 가치를 전달하기 위한 내용으로 채워져있다.
더 짧은 시간에 , 비즈니스적 우선순위가 매겨진 기능들로, 비즈니스적 가치로 측정되는 진척도로 고객에게 가치를 전달한다.
그렇다면 테스트 주도 개발은 어떤 비즈니스적 가치가 있을까??
테스트먼저
테스트를 먼저 작성하면 아이디어 생각에도 도움이 되고 한번에 하나씩만 집중할 수 있다.
코드 작성 후 실제 환경에서 기대한 대로 동작할 것이라 강하게 확신할 수 있다.
테스트 코드는 요구사항의 역할도 하기 때문에, 딱 필요한 만큼만 코딩하도록 유도한다.
이는 오버 엔지니어링하는 것을 줄여준다.
테스트 주도 개발(TDD)
'테스트 먼저 작성하는 것'의 진화된 버전이다.
테스트가 코딩 방향을 주도 하면 복잡한 코드를 작성하는 것 자체가 어려워진다.
- 정확히 요구사항만큼만 만족시키는 것, 즉 테스트로 규정된 부분만 작성하게 되기 때문
- 확대해석하여 미래에 있을 부가 조건들을 추가하는 일을 막는다.
또한 TDD에 의한 피드백은 정규 리뷰 미팅보다 훨씬 빠르고 객관적이다.(근거들이 책에 적혀있지만 생략함)
지속적 통합
팀원들이 각각 다른 기능을 구현하고 모든 기능을 통합했을때, 애플리케이션에서 문제를 일으키지 않을지 어떻게 확신 할 수 있을까?
매 통합 때마다 테스트하는 방법이 있다. 개발자가 코드를 올리면 전체 테스트 슈트가 실행되고 테스트가 실패하면 팀에 실패메시지가 전달된다.
이러한 실행관례는 '일단 멈추고 버그부터 수정' 이라는 태도가 필요하다.
이는 항상 배포 가능한 상태로 유지되고 버그가 누적되지 않는다는 점에서 효율이 높다.
이러한 방식은 QA검증 기간을 줄여 몇일~몇주의 시간을 벌어준다.
버그를 양산하고 뒷수습에 드는 시간을 줄일 수 있다.
이것이 테스트 주도 개발의 비즈니스적 가치이다.
'독서' 카테고리의 다른 글
| 도메인 주도 설계란 무엇인가? (Domain Driven Design Quickly) (0) | 2023.10.10 |
|---|---|
| 샘 올트먼의 생각들 (0) | 2023.08.25 |
