개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
팀 전체가 깨진 창문을 용납해서는 안 된다.
일상적인 작업은 모두 자동화해야 한다.
실용주의 프로그래머의 진짜 업무는 그저 코딩이 아닌 '문제 해결'이다.
TIL (Today I Learned) 날짜
2022.04.05
오늘 읽은 범위
9장. 실용주의 프로젝트
책에서 기억하고 싶은 내용을 써보세요.
실용주의 팀은 작다. 구성원이 대략 10~12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다. 모두가 서로 잘 알고, 신뢰하며, 의존 해야 한다. - 379p
팀 전체가 깨진 창문을 용납하지 않아야 한다. 사소한 결점을 아무도 고치지 않고 놔두어서는 안 되고, 반드시 제품의 품질에 책임을 져야 한다. - 379p
팀은 개인보다 더 삶은 개구리가 되기 쉽다. 사람들은 누군가가 문제를 처리하겠거니 생각하거나, 사용자가 요청한 변경 사항을 팀 리더가 이미 동의했겠거니 하고 여긴다. ...(중략)... 모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라. ...(중략)... 새 요구 사항에 대한 수치를 관리하라. - 380p
팀이 하나로 의사소통하게 도와주는 간단한 마케팅 비결이 있다. 프로젝트를 시작할 때 이름을 지어 주는 것이다. 유별난 이름이라면 더 좋겠다. ...(중략)... 바보같이 들리겠지만 팀은 정체성 확립의 기반을 얻을 것이고, 세상은 여러분의 작업과 관련해서 기억할 만한 뭔가를 얻게 될 것이다. - 383p
“잘 맞는 것”을 어떻게 알 수 있을까? 가장 근본적인 실용주의 기법을 적용하면 된다.
한번 해 보라.
작은 팀 하나나 조직 하나에서 아이디어를 시험해 보라. 잘 맞는 것 같은 좋은 부분만 유지하고 나머지는 낭비나 비용일 뿐이므로 버리면 된다. - 388p
진짜 목표는 작동하는 소프트웨어를 제공함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는 것이다. - 390p
일상적인 작업은 모두 자동화해야 한다. ...(중략)... 수작업은 일관성을 운에 맡긴다. 반복 가능성도 보장받지 못한다. - 392p
프로젝트를 빌드하는데 필요한 모든 것을 버전 관리하에 두어야 한다. - 393p
코드를 작성하자마자 테스트해야 한다. 작은 잔챙이들은 꽤 빨리 자라나 사람을 잡아먹는 거대한 상어가 되는 고약한 성질이 있다. 상어를 잡는 일은 상당히 힘들다. 그래서 우리는 단위 테스트를 작성한다. 아주 많이. - 394p
“진짜 상황 테스트”를 목표로 하는 것이 중요하다. 즉, 테스트 환경은 실제 환경과 최대한 비슷해야 한다. 두 환경의 차이에서 버그가 번식한다. - 395p
정말 진지하게 테스트해 보고 싶다면 소스 트리에서 별도의 브랜치를 하나 만든 다음 고의로 버그를 심어 놓고 테스트가 잡아내는지 검증하라. - 397p
개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다. ...(중략)... 어쨌든 소프트웨어 프로젝트 자체가 아니라 이런 성공 척도가 진짜로 의미 있는 사업 가치다. 소프트웨어는 이런 목적을 달성하기 위한 수단일 뿐이다. - 403p
여러분의 직함이 명목상으로는 “소프트웨어 개발자”나 “소프트웨어 엔지니어” 비슷한 이름일지 몰라도 진정한 여러분의 직함은 “문제 해결사”다. 이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다. - 404p
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
좋은 팀을 유지하는 데 있어 가장 중요한 것은 각자가 맡은 책임을 다하는 것이라 생각한다. 누군가 해주겠지, 혹은 누군가 했겠지라는 생각과 함께 당장 할 수 있는 일을 떠넘기는 것은 책에서 이야기했던 깨진 창문을 만드는 일이다. 항상 책임을 다하자!
각자 책임을 다하는 것만큼 좋은 팀을 유지하는 데 있어 중요한 것은 끊임없는 소통이라 생각한다. 끊임없는 소통이 가능하려면 좋은 기업 문화가 우선시 되어야 한다고 생각한다. 수평적인 커뮤니케이션, 프로젝트 단위의 업무 진행 등. 가장 중요한 것은 보여주는 것이 아닌, 실제로 하는 것이다. 책에서 언급한 애자일과 관련된 예시처럼 좋아 보이는 것을 표방한다고 하고서 기업 문화가 이를 뒷받침하지 않는 것이다. 보여지는 것에만 신경 쓰는 것이야말로 조직이 무너지기 가장 쉬운 지름길이다.
실용주의 프로그래머의 진짜 직함은 '소프트웨어 개발자'나 '소프트웨어 엔지니어'가 아닌 '문제 해결사'라는 문장이 인상적이었다. 현대 사회에서 인정 받는 개발자가 되려면 단순히 개발을 잘 하는 것을 넘어, 실제 문제를 고민하고 해결할 수 있어야 한다고 생각한다. 정확히 기억이 나지 않지만, 예전에 어떤 IT 기업 대표의 인터뷰에서 가장 뇌리에 꽂힌 문장이 있었다. 개발 능력이 좋은 프로그래머보다, 실제 비즈니스 문제에 대해 고민할 수 있는 프로그래머를 원한다고. 항상 고객, 사용자가 무엇을 원하는지를 먼저 생각하자.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
스크럼 (Scrum) : 비즈니스 요구를 충족시키기 위해 작은 목표를 짧은 주기로 실행하는 프레임워크 (참고 : https://medium.com/dtevangelist/scrum-dfc6523a3604)
스폿 인스턴스 (Spot Instance) : 클라우드 내의 남는 EC2 인스턴스를 빌려서 사용할 수 있는 기능으로, 온디맨드에 비해 저렴한 가격으로 이용할 수 있다. (참고 : 스폿 인스턴스 관련 https://data-engineer-tech.tistory.com/21 /
EC2 관련 https://buw.medium.com/aws-ec2%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B4%EB%A9%B0-%EC%99%9C-%EA%B8%B0%EC%97%85%EB%93%A4%EC%9D%B4-ec2%EB%A5%BC-%EC%84%A0%ED%83%9D%ED%95%A0%EA%B9%8C%EC%9A%94-e4c4d6b419b4 / 온디맨드와 비교 https://ssue95.tistory.com/4)
스테이징 서버 (Staging Server) : 운영 서버의 클론 서버로서, 운용 서버에 배포 전 테스트를 진행하는 서버 (참고 : https://lee-automation-lab.tistory.com/entry/IT-%EC%9A%A9%EC%96%B4-%EA%B0%9C%EB%B0%9C-%EC%84%9C%EB%B2%84Dev-%EC%8A%A4%ED%85%8C%EC%9D%B4%EC%A7%95-%EC%84%9C%EB%B2%84Stg-%EC%9A%B4%EC%98%81-%EC%84%9C%EB%B2%84Prod)
오늘 읽은 다른사람의 TIL