소프트웨어 엔지니어로서 뽕을 심어주는 책. 책에서 다루는 안티 패턴들이 대부분 내가 행하던 행위들이라고 느껴져 부끄러움과 한편으로 성장해나가야 할 것들이 많다는 것에서 나오는 즐거움이 교차하였다.
솔직히 개발을 어느 정도 하다보면 더 나은 소프트웨어 엔지니어링을 위한 개념들에 대해 어느정도 인지는 하고 있었다.
코드 레벨에서, 테스트 코드는 필수이며 주기적인 리팩토링을 통해 레거시 코드 + 잠재위험요소를 줄이는 일이 필요하다는 것.
또 개발자라는 한 명의 프로로서 오너십을 가지고 주어진 것만 해야 하는 것이 아닌, 본인이 주체적으로 의사결정에 참여해야 하고 거기서 나오는 모든 과정(문서화, 일정 산정, 일감 관리)도 책임을 저야 한다는 것
하지만 인지한다는 것고 행동한다는 것은 엄연히 다르다는 생각을 요새 들어 많이 느낀다. 나는 생각과 행동보다 입과 손가락이 먼저 움직이고 있었다는 것을.. 전문가이자 프로라고 하는 것에는 많은 책임감과 의식적 노력이 필요하다는 것을 깊게 느끼고 있다.
책에서 강조한 기술적 실행 관례를 잘 지키는 개발자를 실력 있는 개발자라고 부를 수 있을까? TDD, CI, PP(Pair Programming)같은 관례는 결국 더 나은 제품을 개발하기 위한 하나의 테크닉이자 도구이다. 이걸 현재 환경에서 왜 적용해야 하는지 정확히 알고 있는 것이 중요하다. 또한 이론에 입각한 이상적 결과가 아닌 어떤 사이드 이펙트가 있는지, 관례의 과정 중 포기해야할 것과 지켜야할 것을 명확하게 하는 것도 중요하다고 생각이 들었다.
결국 이론을 잘 아는 것과 실천 + 문화로 자리매김시키는 것은 완전히 다르다는 것이라는 것. 입개발은 이제 그만하고 더 잘해지고 싶다....!!
- 절차와 도구 보다는, 개성과 화합을 - 방대한 문서 작업보다는, 동작하는 소프트웨어를 - 계약 조건에 대한 협상보다는, 고객과의 협력을 - 계획을 따르는 것을 넘어서서, 변화에 대처하는 것을
20세기에는 사람들이 이해할 수 없는, 난해한 코드가 개발자 실력의 척도가 되었다(남들은 쉽게 이해할 수도 짤 수 없는 코드를 나는 짠다) 그러나 인터넷의 발전으로 지식과 오픈소스를 쉽게 접할 수 있었고 결과적으로 ‘나’만 알 수 있는 코드를 짜는 것의 가치는 떨어졌다.
애자일이 다루는 근본적인 문제는 소프트웨어 프로젝트는 변화 자체가 기본 속성 이라는 점이다. 그래서 이런 변화에 민첩하게 대응할 수 있도록 하는 방법론이자 테크닉들을 제시한다.
애자일은 문제를 드러나게 해준다
절차적 관점
회의 방식
구성원 각각의 역할
요구사항 파악 방법
작업 진척 속도 파악 법
점진적/반복적으로 일할 때 취하는 방식
진행 상황을 외부에 전달하는 방식
비즈니스 피드백 방식
기술적 관점
개발, 확장, 유지보수, 제품 출시에서 겪는 어려움에 대한 기술을 구체적으로 기술한다.
이를 통해 소프트웨어의 품질에 집중해 결과물을 올바르게 인도하고 있는지, 목표한 것을 올바르게 실행하고 있는지 안심할 수 있게 한다.
애자일을 따른다는 것이 문제를 해결한다는 행위는 아니다. 대신 .
애자일이 나타남에 따라 개인이 맡게 되는 롤은 자연스럽게 늘어났다. 코딩을 하는 것은 당연한 것이며, 이에 더불어 비즈니스와 고객 가치 창출에 개발자들이 직접 참여하는 것도 매우 중요해졌다.
계획, 요구사항 분석, 아키텍처, 제품 릴리즈, 시연, 주기적 피드백 받기(이해관계자)
애자일의 도입이 절차적 개선에만 집중되면 안 된다.
많은 기업들이 표면적으로 애자일을 도입한다고 하지만 크게 변하지 않았다고 한다. 개발 절차를 바꾸는 데 집중하고 막상 더 높은 품질의 소프트웨어를 개발하는 것에 관심을 두지 않는다고 한다. 애자일에서는 모든 절차의 개선에 앞서 기술적 탁월함이 전제되어 있다.
완전한 애자일 전환을 위해선 결국 프로페셔널한 개발자가 필요하다. 이들은 기술적 실행 관례, 기술적 전문성 그리고 관련 도구들을 마스터하고 있어서 소프트웨어의 품질을 높일 수 있어야 한다.
피드백 시스템
피드백 시스템이 제대로 동작하기 위해선 뭔가 잘못됐을 때 혹은 개선할 방법이 있다고 목소리를 당당히 내는 프로들이 있을 때 가능하다.
