5장 영웅, 선의 그리고 프로페셔널리즘
중요하다고 생각한 내용과 나의 생각
107p
우리는 프로페셔널하지 못했다. 우리가 왜 그 일을 하는지 스스로 묻지 않았다. 고객이 실제로 무엇을 원하는지 이래하려 하지 않았고, 다른 대안을 제시하지도 않았다. 고객을 만날수도 없기는 했지만, 요구사항에 대해서 질문을 하지도, 실행할 수 없다는 이야기도 하지 않았다. 우리는 그냥 주어진 환경을 있는 그대로 두고, 무작정 일을 밀어 붙였다. 그때는 그것이 프로페셔널이라고 생각했다. 우리가 노예처럼 일할 때, 영업, 비즈니스 부서 사람들은 항상 정시에 퇴근해 가족과 시간을 보냈다.
- 그저 순응하는 것이 아닌 나 자신이 할 수 있는 정도를 파악하고 함께하는 팀원에게 이야기하는 것도 정말 중요하다는 생각이 들었습니다.
114p
개발자들이 일정이 너무 짧다고 이야기를 해도 관리자들이 그냥 흘려 들을 때가 많다. 관리자와 개발자 간에 협상이 되어야 하지만 협상 기술이나 제대로 된 근거 자료가 부족해서 개발자들이 압ㄺ에 그냥 굴복하고 말 때가 부지기수다 개발자들은 논쟁하고 싶디 않아서 또는 긍정적인 태도를 보여주고 싶어서 "최선을 다해 노력하겠다"라고 대답해버린다.
- 평소에 소통하는 능력을 어느 정도 갖추고 있다고 생각하는데 취업시장에서 이러한 점들을 강점으로 어필하면 좋을 거 같다는 생각이 들었습니다.
116p
항상 '아니오'라고만 얘기하는 것은 프로다운 태도가 아니다. 모든 '아니오'에는 반드시 하나 이상의 대안들이 따라와야 한다.
- 매우 중요하다고 생각합니다.
118p
무언가 약속은 할 수 없더라도 문제 대응이 어떻게 되고 있는지 진척 상황을 계속 공유해야한다.
122p
최대한 이른 시점에 붉은 깃발을 세워서 뭔가 잘못되고 있음을 지적하고 팀과 다른 사람들로 하여금 현실적인 다른 대안을 찾아 나설 수 있도록 해야 한다.
- 현재 진행하고 있는 밋업 프로젝트에서 애자일 방식으로 프로젝트를 진행하고 있는데 불확실성이 큰 요구사항에 대해 살짝 어려울 거 같다는 이야기는 했지만, 해보겠다고 했는데, 이런 상황에서 문제가 생긴다면 빠르게 전해야겠다고 생각이 들었습니다.
6장 동작하는 소프트웨어
중요하다고 생각한 내용과 나의 생각
126p
전통적인 관리자들과 비즈니스 컨설턴트들이 절차와 문서의 중요성을 아무리 강조하고 싶어하더라도 소프트웨어 프로젝트에는 소스 코드 그 자체만큼 중요한 것은 없다. 나머지는 모두 부차적이다.
128p 코드는 기계장치라기보다는 유기물이다. 코드는 정원처럼 지속적인 유지보수가 필요하다.
130p 나쁜 코드를 다루어야 하는 기업은 경쟁력이 떨어지게 된다.
132p
기술적 부채를 줄이는 것은 기존의 더러운 것을 청소하는 것이다. 이미 깨끗한 상태를 더럽혀서는 안된다. 즉 어떤 상황이든 추가 코드로 인해 기술적 부채가 더해져서는 안 된다. 하지만 이 개발자는 그렇게 해도 된다고 생각하고 있었다.
- 해당 개발자처럼 잘못된 이해와 지식에 확신을 가지는 것에 주의해야 겠다는 생각을 했습니다.
133p
빨리 하는 것과 허술한 것은 다르다. 우리의 결정이 어떤 의미이고 어떤 결과를 가져오는지 우리는 잘 이해하지 못할 때가 많다.
137p
테스트하지 않았다면 코드 작성을 완료했다고 할 수 없다. 단위 테스트는 코드가 제대로 구현되었는지 확인하는 가장 좋은 방법이다. 테스트 주도 개발을 접해보지 못한 보통의 개발자들은 주어진 요구사항에 맞춰 동작할 거라고 '기대만 하는' 상태로 코드를 작성하고는 바로 다음 요구사항의 구현에 들어간다. 즉 제대로 된 테스트 없이 코딩을 마무리한다. 기능 구현이 완료되었다고 할 수 있으려면 반드시 테스트까지 되어야 한다.
- 현재 TDD 방식으로 개발을 진행하고 있는데 생각보다 쉽지 않고, 함께하는 팀원은 어려울 거 같다고 해서 일단 저만 진행하고 있는데 이 글을 읽고, 다음 스프린트에서 요구사항 정의와 레드 단계의 테스트 코드를 작성하여 팀원도 같이 TDD를 할 수 있게 해야겠다는 확신이 생겼습니다.
- 그리고 필자가 작성한 것처럼 테스트 코드를 작성하는 것까지 기능구현의 단계로 생각하여 개발해야겠다는 생각 또한 들었습니다.
7장 기술적 실행 관례
중요하다고 생각한 내용과 나의 생각
152p
어떤 실행 관례를 도입한다고 해서 프로젝트의 성공을 보증하지 않는다. 사람은 우리가 원하는 대로 행동하도록 프로그램할 수 있는 기계가 아니다. 단순히 준수할 실행 관례를 공표했다고 해서 기대하는 결과가 나오지 않는다. 실행 관례는 우리가 매일 같이 습관처럼 해야 하는 것이다.
- 사람을 프로그램할 수 없다는 이야기에 깊이 공감했고, 그렇기에 실행관례를 부분적으로 하는 것이 아니라 실행관례에 대한 명확한 전략을 정의해 이를 진심으로 받아들이고 내재화해야 하기 위해 노력해야겠다는 생각이 들었습니다. 이번에도 포부있게 애자일 방식으로 해보자! 라고 했지만 이를 더 깊이 이해하지 못한 채 적용하려고 했기에 올바른 애자일 방식으로 개발을 하지 못했다는 생각이 듭니다. 상황이 바쁘더라도 애자일하게 개발을 하기위해 정한 실행 관례를 습관처럼 할 수 있도록 노력하고 더 공부해야겠다는 생각이 들었습니다.
153p
기술적 실행 관례들 그 자체를 직접적으로 실행할려고 드는 것은 아무런 의미가 없다. 그렇게 해서는 상대방을 납득시킬 수 없다. 실행 관례의 도입 자체를 관리자나 팀 구성원들에게 설득하려 하지 말고 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중을 해야한다.
155p ~ 156p
테스트 코드는 잘 정리된 요구사항의 역할도 하기 때문에 딱 필요한 만큼만 코딩되도록 유도하여 불필요하게 복잡해지거나 오버 엔지니어링을 하는 것을 줄여준다. 이러한 것들이 바로 비즈니스적인 가치다.
- 해당 문장을 읽고, 개인 프로젝트에서라도 TDD 방식을 적용해 보자는 생각이 들었습니다. 해당 방식에 빠르게 익숙해지고 추후 팀 프로젝트에서 함께하는 팀원들에게도 알려줄 수 있는 개발자가 되기 위해 노력해야 겠다는 생각이 들었습니다.
156p
TDD 이름 자체에 '테스트'가 들어 있기는 있지만 사실 TDD는 설계에 대한 실행 관례다. 테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다.
159p
같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다. 그렇게 하면 전체 시스템에 대한 이해도나 개발자의 스킬이 팀 차원에서 누적되어 올라간다. 더불어 코딩 표준을 정의하고 유지하는 데도 도움이 된다.
160p
개발자들은 이해하기 어려운 코드를 만났을 때 그것을 개선해보려 하기 보다는 그대로 내버려둔다. 괜히 수정했다가 코드를 망가뜨릴 수 있기 때문이다. 그래서 작은 워크 어라운드들과 중복 코드들을 만들면서 작업한다. 엉망인 코드가 많을수록 엉망인 코드가 늘어나는 속도도 빨라진다. 이것은 '깨진 유리창 법칙'으로도 알려져 있다. 지저분하고 엉망인 애플리케이션은 개발자들을 느리게 만들고 그로 인해 비즈니스도 느려진다.
- 저의 뼈를 때리는 문장인 것 같습니다. 이번 프로젝트를 진행하면서도 이해하기 어려운 코드들이 있었는데 그냥 넘겼고, 이번에 상호 피드백을 하면서 수정해야 하는 부분을 많이 발견했습니다. 하지만 이미 진행하고 있고, 저도 시험기간 때문에 개발을 미루어 급하게 구현하다 보니 고치지 못하고 현재 개발을 하고 있습니다..ㅠㅠ 제가 리드인데 같이하는 팀원한테 너무 미안하네요..
레거시 애플리케이션을 대상으로 일을 할 때, 전체 시스템을 한꺼번에 새로 작성하고 싶은 욕구를 조심해야 한다. 이럴 때는 수정되는 부분에 한정해서 리팩토링을 집중하는 것이 더 나은 방법이다.
실용주의적인 관념 없이 리팩토링하는 것은 대단히 위험하다. 프로페셔널로서 행동한다는 것은 트레이드오프를 이해한다는 것이다. 전체 시스템을 더 좋게 만들 수는 있겠지만, 그럴 필요 자체가 없을 수 있다. 몇년 동안 바뀐 적인 없는 부분을 리팩토링하는 것은 의미가 없다. 애당초 코드를 수정할 필요가 없다면, 리팩토링해야 할 이유도 없다. 리팩토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다.
163p
어떤 실행 관례가 다른 실행 관레보다 더 나은지 알아보는 가장 좋은 방법은 프로젝트에 어떤 가치를 주는지, 피드백 루프가 얼마나 긴지 비교해 보는 것이다. 나머지는 상관이 없다. 만약 검토 중인 실행 관례가 우리에게 어떤 가치를 주는지 판단되지 않는다면 도입을 보류해야 할 수 있다.
164p
실행 관례에 대한 도입을 이야기하기 전에, 먼저 우리가 이루려는 것이 무엇인지 논의해야 한다. 소프트웨어 개발/납품 절차 중에서 어떤 부분을 얼마만큼 개선하길 원하는가? 이러한 것이 정의되고 나면 그것을 달성하기 위해 어떤 실행 관례를 도입할지 말할 수 있다.
8장 길고 긴 여정
중요하다고 생각한 내용과 나의 생각
170p
다음은 기회를 만들어 내기 위해 할 수 있는 몇 가지 활동들이다.
- 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고 기술적 지식을 확장한다. 예를 들어 새로운 프로그래밍 언어나 기술들을 배운다.
- 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다.
- 다른 개발자, 비즈니스맨들과 교류한다.
- 새롭게 배운 것, 지금 하고 있는 것들에 대해 블로깅한다.
- 오픈 소스 프로젝트에 참여한다.
- 프로젝트를 만들고 공개한다.
- 콘퍼런스에 참석한다.
- 콘터런스에 연사로 나선다.
각자 다른 꿈과 열망이 있고 완전히 다른 상황에 있지만 커리어에 대한 열망을 실현하려 노력한다는 점에 있어서는 매우 비슷하다. 거쳐가는 모든 직장, 프로젝트들 하나 하나를 투자로 인식하는 것이 가장 중요하다. ... 소프트웨어 장인은 거치는 자리마다 끊임없이 지식과 열정에 몰입 그리고 프로페셔널로서의 태도를 키워나간다. 따라서 다른 형태의 투자로서 우리가 기대하는 보상이 어떠한 것인지 명확히 할 필요가 있다.
- 위와 같은 소프트웨어 장인으로서의 태도와 프로페셔널을 갖추기 위해 노력해야겠다는 생각이 들었습니다.
176p
성공적인 커리어는 공짜로 오지 않는다. 스스로 만들어 나가야 한다. 특정 회사 안에서의 커리어보다 개인으로서 우리 자신의 커리어가 항상 우선해야 한다.
'더 나은 개발자가 되기 위한 한걸음: 성장드루아 > 독서' 카테고리의 다른 글
| 책 소프트웨어장인 정리!! - 1~2장 (6) | 2024.10.13 |
|---|