5장 영웅, 선의 그리고 프로페셔널리즘
-
일정 안에 모두 완료하는 것이 거의 불가능한 상황이라는 것을 분명히 알면서도 상사에게 노력해보겠다라는 말을 어떻게 할 수가 있나? 노력해 본다는 것의 의미가 무엇인가? 그저 실망시키지 않기 위해 말하는 ‘네’는 거짓말에 지나지 않는다고 한다.
-
어떤 때는 단지 문제를 어떻게 풀어야 할지 방법을 모를 수도 있다. 이때는 최대한 이른 시점에 그 사실을 정직하게 알려야 한다. 그리고 문제 해결을 위해서 최선의 노력을 다하고 있음을 보여주어야 한다.
- 나는 주어진 일을 해내지 못해 상사를 실망시키게 만드는 게 너무 두려웠고 지금도 그렇다. 😞😞 그래서 뒤늦게 말을 하는 경우가 많았는데 이 말을 꼭 기억해야 되겠다.
-
코드의 품질 수준을 낮추고 야근과 휴일 근무를 연이어 하게 되면 모두가 지쳐 쓰러지고 프로젝트 전체가 위태로워진다.
- 정말 공감되는 말이었다. 프로젝트가 긴박해 가끔 야근을 하거나 오버해서 근무할 때가 있었는데 정말 삶의 질은 떨어지고 그로 인해 코딩은 더더욱 안되고 악순환만 반복 되었다.
-
관리자는 팀의 한 부분이다. 관리자도 팀과 동고동락해야 한다. 좋은 관리자는 외부의 압력으로부터 개발자를 보호하고 팀이 가진 장애요소들을 제거한다. 팀원들이 편안한 마음으로 자신감을 갖고 일할 수 있도록 해준다.
- 팀원들이 편안한 마음으로 자신감을 갖고 일할 수 있도록 하는 관리자가 몇이나 있을까 ..?
-
의도한 대로 동작할 수 없거나, 실행 불가능한 무리한 일정에 대해서 “아니오”라고 답하는 것은 우리의 의무이다.
- 아니오라고 답하는 힘을 기르자! 특히 무리한 일정, 몸소 너무 느끼는 바!
6장 동작하는 소프트웨어
태도의 변화, 무언가가 마음에 들지 않는다면 바꾸어라. 그것을 바꿀 수 없다면, 그에 대한 당신의 생각을 바꾸어라.
-
프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 더 가깝다.
-
소프트웨어 개발자의 삶에 있어 압박은 피할 수 없다. 우리는 압박을 받는다고 느낄 때 중심을 잃고 고만고만해진다. 게으른 탓이 아니다. 더 빨리 해야 한다고 느끼기 때문에 그렇게 한다.
- 나는 '압박'이라는 것에 매우 취약한 사람이다. 몇개월 간 일을 해보면서 느꼈다. 압박이 없을 때는 오히려 더 창의적인데, 압박이라고 느끼는 순간 식은땀이 나고..너무 부담스럽고 불편한 마음이 든다.
-
테스터가 버그를 발견하는 것은 개발자로서 대단히 수치스러운 일이다.
- 회사 내에 따로 테스트 업무를 맏고 있는 팀이 없다. 따라서 개발자가 최대한 단위테스트로 테스트를 진행하고 있다. 이번에 나는 처음으로 맡은 프로젝트에 대한 테스트 시나리오와 테스트 케이스를 작성해보았는데 여간 힘든 게 아니였다. 얼마나 구체적이게 해야할지, 어디까지 해야할지 감이 오지 않았다. 버그도 많이 있었고 ..ㅜㅜ
- 아무튼 테스트 케이스를 다 작성하고 테스트 했다. 그 중 팀원이 개발했던 기능에 대해 오류가 있었는데 비슷한 페이지를 여러번 개발해본 탓에 내가 오류를 수정하고 커밋을 했다. 하지만 상사분은 그 기능을 개발한 개발자가 수정해야 하는 부분이지 다른 개발자가 그 기능을 건들이다가 오히려 연쇄적으로 시스템 내에서 문제가 생길 수도 있다고 주의를 주셨다. 지금 개발하고 있는 소프트웨어가 정말 규모가 컸더라면?.. 정말 큰 문제가 되었을 것이다. 🤯 🤯
-
테스트 주도 개발을 접해보지 못한 보통의 개발자들은 주어진 요구사항에 맞춰 동작할 거라고 '기대만 하는' 상태로 코드를 작성하고는 바로 다음 요구사항의 구현에 들어간다. 즉 제대로 된 테스트 없이 코딩을 마무리한다. 기능 구현이 완료되었다고 할 수 있으려면 반드시 테스트까지 되어야 한다.
- 나는 보통의 개발자이다. 이 문장을 읽으니 굉장히 부끄러워졌다. 하하.. 다음 프로젝트 부터 테스트 코드를 작성하는 것도 활용한다고는 했지만....
-
항상 프로젝트에 다른 사람들도 있다는 사실을 인식하고 전체 프로젝트에 미치는 영향을 감안하여 책임있게 행동해야 한다.
-
레거시 코드는 우리가 다른 방식으로 생각하도록 강제한다는 특징이 있다.
-
회사와 개발자들은 정기적으로 도끼날을 가는 시간이 낭비가 아니라는 사실을 이해해야 한다. 바로 그것이 시간을 절약하고 끊임없이 빨리 움직일 수 있는 최선의 방법이다.
07장 기술적 실행 관례
-
코드가 망가지고 있는지를 비지니스 담당이 눈치채기는 대단히 어렵다. 반면에 개발자가 그것을 숨기는 것은 너무나 쉽다.
-
XP 실행 관례들은 소프트웨어의 품질, 즉 일을 올바르게 수행하는 관점에서 피드백 루프를 단축시킬 수 있는 여러 방법들을 제공한다. XP 실행 관례들은 단순히 도입한다고 해서 일이 갑자기 저절로 되지는 않는다.
-
실행 관례가 효율적이라면 반드시 모든 팀 구성원들에 의해서 그 가치가 납득되어야 한다. 예를 들어 모든 팀 구성원들은 원활한 정보 소통, 빠른 피드백, 빠른 결과물 생성, 실수 예방, 고객 만족, 최선을 다하지 못하거나 배우지 못하는 것에 대한 부끄러움을 느낄 줄 아는 것, 이러한 것들에 가치를 느껴야 한다.
- 원활한 정보 소통, 빠른 피드백 .. 정말 중요한 가치인데 .. 느껴본 적이 별로 없는 것 같다. 물론 내가 먼저 노력해야 하는 일이긴 하지만 ....
-
테스트 주도 개발 (TDD)는 단위 테스트와 다르다. TDD는 테스트 단위가 어느 정도로 작아야 하는지 강제하지 않는다.
-
TDD에 의해서 주어지는 피드백은 정규적인 설계 리뷰 미팅보다 훨씬 빠르고 객관적이다. 코드의 설계, 단순성, 유지보수 용이성에 대해 피드백이 빠르다.
-
전체 시스템을 더 좋게 만들 수는 잇겠지만 그럴 필요 자체가 없을 수도 있다. 몇년 동안 바뀐 적이 없는 부분을 리펙토링하는 것은 의미가 없다. 애당초 코드를 수정할 필요가 없다면, 리팩토링해야 할 이유도 없다.
08장 길고 긴 여정
-
어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다. 소프트웨어 장인으로서 스스로의 커리어를 가치있게 여기고 아끼고 보살펴야 한다. 커리어가 개인의 삶 전체에 이어지는 긴 여정이며 각자의 선택에 따라 마스터가 될 수 있음을 이해해야 한다.
-
어디로 가기를 원하는지 커리어의 방향을 정하는 것이 중요하다. 이것은 장기적인 목표이고 중간이 많은 것이 바뀔 수 있다.
- 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고 기술적 지식 확장
- 커뮤니티 참여
- 새롭게 배운 것, 하고 있는 것들에 대해 블로깅
- 오픈 소스 프로젝트
- 프로젝트를 만들고 공개
- 컨퍼런스 참석
-
거쳐가는 모든 직장, 프로젝트 하나 하나를 투자로 인식하는 것이 가장 중요하다. 직장은 단순히 돈을 버는 곳이 아니라 큰 목표를 향해 다가가는 단계 중 하나다.
- 지금 진행 중인 프로젝트가 힘들다고 느껴져도 이게 다 미래의 나를 위한 투자라고 생각하자 🙌
-
커리어에서 옳고 그른 것은 없다. 지식은 영원하고 돈과 안정은 영원할 수 없다는 것만은 마음에 새기고 있어야 한다. 어떤 이유에서든 직장을 떠날 때 남은 것은 오로지 지식과 경험 뿐이다. 항상 배우고 더 나은 소프트웨어 장인이 되는 것에 집중한다면, 단순히 돈만 좇을 때보다 좋은 직장을 얻기가 오히려 더 수월하다.
-
역량이 부족한 사람들만이 일자리 걱정을 한다. 소프트웨어 장인은 직업을 잃은 것에 대해 걱정하지 않는다. 소프트웨어 장인은 자신의 커리어 방향과 일치하는 경우에만 회사 안의 커리어를 수용한다.
- 역량을 키우자 키우자 키우자 💘 💘
-
자율성 : 무엇을, 어떻게, 언제할지 통제할 수 있는 상태를 뜻한다. 제대로 된 애자일 개발 환경이라면 이러한 것들이 보장되어야 한다.
-
통달 : 더 나은 프로페셔널, 더 나은 인간이 되기 위해 계속 배우고 진화하는 것
-
목적의식 : 지금 하고 있는 일이 중요하고 무언가를 더 나아지게 하고 있다고 느끼는 것
-
일은 단지 돈을 벌기 위해 참아야 할 고통이 아니다. 일을 선택할 때는 자율성, 통달, 목적의식을 쫓아야 한다. 역량이 더 높아질수록, 스스로에게 기쁨을 주는 일을 찾기가 쉬워진다. 좋은 일감을 얻을 수 있는 위치에 도달하려면 커리어의 개발 과정 중에 많은 집중과 결단력이 필요하다.
- 출근하기 싫다고 찡찡거리지 마자. 스스로에게 기쁘는 주는 일을 찾아가도록, 찾을 수 있도록 😎
위 글은 산드로 만쿠소의 소프트웨어 장인을 읽고 정리한 내용입니다.
