애자일 프랙티스

애자일 프랙티스
애자일 프랙티스 2009. 06. 24 Practices of an Agile Developer
I. 애자일 소프트웨어 개발 II. 애자일 시작하기 III. 애자일 기르기 IV. 사용자가 원하는 내용을 제공하기 목 차 V. 애자일 피드백 VI. 애자일 코딩 VII. 애자일 디버깅 VIII.애자일 협력
1. 애자일 소프트웨어 개발 소프트웨어 개발은 서핑(surfing)과 비슷하다. 한마디로 동적이고 늘 변하는 환경이다. 바다 자체는 예측할 수 없고, 위험하고, 물속에는 상어가 있을지도 모른다. 애자일 소프트웨어 개발선언문 •‘프로세스와 도구’보다는 ‘개인상호작용’을 •‘포괄적인 문서화’보다는 ‘동작하는 소프트웨어’를 •‘계약 협상’보다는 ‘고객과의 협력’을 •‘계획 준수’보다는 ‘변화에 대응’을 + 일시적이 아닌 지속적인 개발 •프로젝트 전 생애 주기 동안 지속 •기술/요구수집/사용자 훈련 포함 에너지를 주입하라 •위기에 바로 대응하라 •사고, 코딩실천방법, 팀워크 재정비 애자일 정의 애자일 개발은 고도의 협력적인 환경에서 지속적인 조정을 위해 피드백을 사용한다. 위키사용 버젼관리 시스템 단위테스트 애자일 툴킷
I. 애자일 소프트웨어 개발 II. 애자일 시작하기 III. 애자일 기르기 IV. 사용자가 원하는 내용을 제공하기 2.1 결과를 위해 일하라 2.2 땜질은 늪을 만든다 2.3 사람이 아니라 생각을 비판하라 2.4 위험을 무릅쓰고, 앞으로 나아가라
2.1 결과를 위해 일하라 손가락질 하는 대신, 가능한 해결책을 제시하라. 중요한 것은 긍정적인 결과다. “문제에 대처하는 첫 번째이자 가장 중요한 단계는 그 문제가 누구 때문에 일어났는지 판단하는 거야. 그 바보 를 찾아! 일단 잘못을 시인하게 하면 그 문제가 다시는 일어나지 않도록 할 수 있어. 영원히!” 문제가 생겼을 때 보이는 반응 •일을 더 복잡하게 하는 말을 한다. •비난을 퍼붓는다. •사람들을 방어적으로 만든다. 프로세스 준수가 결과는 아니다 애자일은 프로세스보다 결과에 가치를 둔다. 균형 유지하기 비난은 버그를 수정하지 못한다 •감정적으로 반응하는 사람과 일하는 것 •문제 해결에는 관심이 없고 뒷담화를 즐긴다. •손가락질하고 누구를 비난할지 토의한다. •문제의 근원파악보다 해결 하는 게 더 빠르다. •실수를 하지 않는 건 충분히 일하지 않는 것이다. •팀원이 반복해서 잘못된 행동을 한다면 그 사람을 팀에서 제외해야 한다. •팀원 대부분이 프로다운 방식으로 행동하지 않고, 관심도 없다면 다른 곳에서 성공을 추구 해야 한 다.
2.2 땜질은 늪을 만든다 깔끔하고 모든 것이 드러나도록 코드에 정력을 쏟아라 “그 코드부분은 이해할 필요가 없어. 그대로도 잘 동작하는 것 같잖아. 그래, 하긴 조금 고칠 필요가 있겠네. 그냥 그 결과에 한 줄 더 붙여 봐, 그럼 동작하잖아. 계속해서 그렇게 끼워 넣어. 아마 괜찮을 거야.” 실천방법 •지뢰를 조심하라 - 땜질식 수정은 지뢰를 밟게 된다. •따로 코딩 하지 말라. - 코드 리뷰가 좋은 방법. •단위테스트를 사용하라 •코드의 동작을 이해하지만 전문가가 될 필요는 없 다. •이해하지 않은 상태에서 코드를 고치지 마라. •팀원이 이해하고 유지보수를 할 수 있도록 코드를 단순화하라. G A P서투른 해커 좋은 프로그래머 • 코드를 그대로 남겨두고 다음 문제로 재빨리 넘어간다. • 다음 단계로 가서 하나를 더하는 일이 왜 필요한지, 다른 무언가에 영향을 받는지 이해하려고 노력한다. 균형 유지하기
2.3 사람이 아니라 생각을 비판하라 누구 아이디어가 더 나은지를 입증하는 것이 아니라 해결책에 도달하는데 자부심을 가져라. “설계에 공을 많이 들였잖아. 온몸과 정성을 다 바쳤지. 다른 누가 만든 것보다 낫다는 걸 잘 알잖아. 귀찮게 그 사람들 생각을 들을 필요 없어. 그래 봤자 쟁점을 혼란하게 할 뿐이야.” 마감을 정하라 상대방과 논의하라 중재자를 둬라 •점심시간이나 하루의 끝 •최선의 답이 아니라 더 적합한 답 • 항상 트레이드 오프가 존재 • 장단점을 최대한 모으기 위해서 • 발언권과 회의 시간에 중점 • 여러 측면에서 생각과 의견의 기회를 줌 1. 다른 사람생각에 군더더기를 넣지 마라 2. 현실 가능성을 생각하라 3. 최선책은 모두에게 적합해야 한다 4. 절대적인 최선책은 없다. 더 나은 것 일뿐 균형 유지하기
2.4 위험을 무릅쓰고, 앞으로 나아가라 정직하라. 그리고 진실을 얘기할 용기를 가져라. 때로 이렇게 한다는 것이 어려울 수도 있지만, 그렇기 때문에 용기가 필요한 것이다. “다른 사람의 코드에서 문제를 발견하더라도 그냥 혼자 알고 있어. 그 사람들 기분을 사하게 하거나, 문제를 일 으키길 원하는 게 아니잖아. 그리고 그 사람이 네 상사이기라도 하면 특히 조심해야지.” 고양이 목에 방울을 달자 근데 누가 달지? 균형 유지하기 1. 옳다는 근거를 충분히 설명하라. 2. 상대방이 이해하지 못하면 용어를 바꿔라. 3. 충분한 시간을 갖고 이해를 해라.
I. 애자일 소프트웨어 개발 II. 애자일 시작하기 III. 애자일 기르기 IV. 사용자가 원하는 내용을 제공하기 3.1 변화에 뒤처지지 말라 3.2 팀에 투자하라 3.3 버려야 할 때가 언제인지 알자 3.4 이해할 때까지 질문하라
3.1 변화에 뒤처지지 말라 모든 분야에서 전문가가 될 필요는 없지만, 업계가 어디로 가는지 알고 있어야 하고, 그에 맞춰서 경력과 프로젝트 계획을 세워야 한다. “기술이란 게 정신 없이 빨리 변하잖아. 하긴 기술이란 그런 거지. 네가 아는 프로그램 언어를 써서 옛날 방식 대로 해. 넌 따라 잡을 수 없어” Java Swing, servlets, JSP, Struts, JSF,Tapestry, JDBC, JDO, Hibernate, JMS, EJB, Lucene, Spring 등 Microsoft VB, Visual C++, MFC, COM, ATL, .NET, C#, VB.NET, ASP.NET, ADO, WinForms, Biztalk 등 반복해서 조금씩 배우자 •매일 일정시간을 확보하자. •공부시간이 길 필요는 없지만, 규칙적이어야 한다. 최신 소식을 얻자 •포럼의 토론, 블로그, 메일링 리스트를 구독하자. 워크숍이나 세미나에 참석하자 •유명한 전문가의 강좌나 세미나에 참석하자. 열심히 읽자 •개발, 비 기술적 주제, 경제 잡지 등 다양하게 읽자.
3.2 팀에 투자하라 도시락 회의를 통하여 모든 사람의 지식과 숙련도를 올리고 사람들이 화합하게 하자. 즉, 팀이 흥미를 보 이는 기술이나 프로젝트를 이롭게 할 기술을 도입하자. “알고 있는 걸 공유하지 마. 혼자 간직해. 팀에서 똑똑한 사람이 되는 게 유리해. 네가 똑똑하다면 다른 멍청이 는 신경 쓰지 않아도 돼.” 도시락 회의 •일주일 중 하루, 예를 들어 수요일 •참석자들과 같이 점심식사(도시락) •팀원 한 명이 회의를 이끌게 함 •회의 주관자가 15분 정도 얘기하는 것으로 시작 •팀원 모두가 자신의 아이디어를 제안 •팀 내로 회의를 한정하라. •규칙적인 일정을 지켜라. •순수하게 기술적인 책이나 주제 너머로 확장하자. •도시락 회의는 설계 회의가 아니다. 균형 유지하기
3.3 버려야 할 때가 언제인지 알자 새 기술을 배울 때, 여러분을 방해할 낡은 습관을 버려라. 결국 구형 차보다는 새 차가 훨씬 낫다. “항상 이렇게 해 왔고, 그렇게 한 이유도 충분하잖아. 보통 그렇게 하면 잘 동작했었지. 처음 시작할 때 배운 방법이 최선이야. 사실 그 이후에 별로 바뀐 게 없어.” 힘들게 만든 건데 버려야 하나? J2EE 프로젝트 / 1년 PHP 프로젝트 / 1달VS 대가를 많이 치른 사고방식은 쉽게 버릴 수 없다 •오래된 습관은 바꾸기 힘들다. •버리는 일의 첫 단계는 그 사실을 깨닫는 것이다. •예전 지식은 쓸 수 있는 상황에서 다시 사용하자. •오래된 습관을 단지 습관적으로 끌지 말라. •새 환경으로 바꿀 때는 가능한 철저히 바꿔라. •새 기술을 배울 때 겁이 난다. •낡은 습관을 유지하는 것은 여러분의 경력에 해가 된다.
3.4 이해할 때까지 질문하라 여러분이 들은 얘기들을 액면 그대로 받아들이지 마라. 쟁점이 되는 내용의 핵심을 이해할 때까지 계속 질문하라. “네가 들은 설명을 받아 들여. 문제가 있다고 얘기 들은 곳만 찾아보면 돼. 뜬구름 잡느라 시간 낭비하지 마” 몸이 안 좋아요 어디가 아파요? 의사는 진료를 위해 환자에게 물어본다. 습관이 뭐고, 뭘 먹었고, 어디가 아프고, 무슨 약을 먹 고 있는지? •핵심에서 벗어나 무관한 질문을 할 수도 있다. •“왜 그래요?”라고 물어볼 때, 질문의 타당성을 항상 간직 하라. •피상적인 답을 받아들이지 마라. “그건 전부터 그렇게 해 왔기 때문에…”과 같은 답은 대부분 답이 아니다. •“이런, 모르겠는걸”과 같은 얘기는 끝이 아니라 더 연구 하기 좋은 출발점이다. 균형 유지하기
I. 애자일 소프트웨어 개발 II. 애자일 시작하기 III. 애자일 기르기 IV. 사용자가 원하는 내용을 제공하기 4.1 고객이 결정하도록 하라 4.2 설계가 강요하는 대신 안내하도록 하라 4.3 기술사용을 정당화하라 4.4 짧은 반복을 사용하여, 점진적으로 배포하라
4.1 고객이 결정하도록 하라 개발자, 관리자, 비즈니스 애널리스트가 비즈니스에 치명적인 결정을 내려서는 안 된다. 사업주가 이해할 수 있는 언어로 세부 내용을 설명하고 사업주가 결정하도록 하라. “개발자들은 창의적이고 지적이고 프로그램의 대부분을 알잖아. 그러니 중요한 결정을 개발자가 내리는 게 맞지. 고객이 참견할 때마다 일이 엉망이 될 뿐이야. 고객은 구현하는 로직을 이해하지 못하잖아.” 고객이 결정 •자신의 권한 밖인지 정하고 그 이슈를 고객이 결정하도록 하자. •지금 이슈가 시스템에 영향을 준다면 고객에게 넘기자. •고객과 얘기할 때 가능한 선택 사항을 준비해 둬라. •장단점을 제시하고 선택 사항의 영향을 논의하라. •결정과 그 근거에 대한 기록을 남겨라. •기억은 신뢰할 수 없다. 로그, 이메일 이력, 이슈추적 등 사용. •모든 문제로 고객을 귀찮게 하지 마라. 업무에 영향이 없으면 하찮 은 것이다. •“나는 몰라요”라는 말은 고객에게 듣기 쉬운 말이다. 할 수 있는 최선의 방법을 제안하자.
4.2 설계가 강요하는 대신 안내하도록 하라 설계는 바른 방향으로 인도한다. 그것은 허물 수 없는 경계가 아니다. 특정한 방식을 강요해서는 안 된다. 여러분이 설계(혹은 설계자)에게 인질로 잡혀서는 안 된다. “설계 문서를 아주 자세하게 작성해서 아무리 낮은 수준의 코더라도 그냥 코딩하게 해. 객체 간 상호작용에 대 한 낮은 수준의 세부 내용뿐만 아니라 객체가 어떻게 연관되는지 높은 수준의 세부내용까지 명시해. 메서드 구 현에 대한 정보와 메서드 매개변수에 대한 설명을 꼭 넣고 클래스의 모든 필드도 잊지마.” 애자일 개발방법론 전통적 개발방법론 계획 수준 반복적인 주기를 설정하고 다음 주기에 대해서만 상세계획 수립 각 단계별 세부 계획 수립 요구사항 초기 요구사항에 대한 BaseLine(기준선)을 설정하고 요구사항 변경 시 정의된 절차에 따른 변경과 형상관리 요구사항에 대한 변경 및 추가가 비교적 자유 시스템 개발 실제 구현된 기능을 통해 시스템의 각 구조의 실현가능성과 효과를 증명하고 구현 분석 및 설계 단계에서 세부적이고 구체적인 시스템을 설계하고 설계에 따른 개발 구현 테스트 작은 단위의 기능별로 개발과 테스트를 반복하여 검증 특정 모듈의 구현 후에 단위 테스트와 통합 테스트, 시스템 테스트 순으로 시스템의 완전성을 보장
4.3 기술 사용을 정당화하라 먼저 무엇이 필요한지 정하라. 그러고 나서 그 특정한 문제에 기술 사용 여부를 판단하라. 어떤 기술의 사용에 결정적인 질문을 하고 진실하게 답해 보라. “넌 새 프로젝트를 막 시작하려 하지. 그리고 새로운 기술과 애플리케이션 프레임워크의 상세 목록이 네 앞에 있어. 모두 대단한 기술이고 다 써 필요가 있지. 이런 훌륭한 최신 프레임워크를 쓰면 네 이력서가 얼마나 화려 해지는지, 또 새 애플리케이션이 얼마나 첨단 기술로 무장될지 생각해 봐.” 개발자 새로운 기술이 문제를 정말 해결할까? 이 새로운 기술에 얽매이게 되는가? 유지보수 비용은 어떤가? 균형 유지하기 •기술적 요구를 평가하기 너무 이르면 기술을 결정하려고 달 려들지 말라. •모든 기술에는 장단점이 있다. (오픈소스 vs 상용제품) •즉시 다운로드할 수 있는 것을 새로 만들지 마라.
4.4 짧은 반복을 사용하여, 점진적으로 배포하라 최소의 유용한 기능 단위로 묶어서 제품을 릴리즈하라. 각 추가기능의 개발에 1~4주 정도의 반복 주기 를 사용하라. “우리에겐 향후 3년 동안의 작업과 산출물이 예정된 멋진 프로젝트 계획이 있어. 3년 후에 제품을 릴리즈하면 시장을 장악할 거야.” 하루에 여러 번 로컬 빌드 체크 인 데모 및 연습 릴리즈 기능추가 1~6개월 반복 1~4주 중첩된 애자일 개발 사이클 •적절한 반복 주기를 정하는 일의 균형에 결정적이다. •반복마다 충분한 시간이 없다면, 업무가 너무 많거나 반복이 너무 짧은 것이다. •사용자 요구와 릴리즈 할 기능 사이에 단절이 있다면 그건 아마 반복이 길기 때문이다. •점진적인 릴리즈는 사용할 수 있어야 하고 고객에게 가 치를 제공해야 한다. 균형 유지하기
V. 애자일 피드백 V. 애자일 코딩 VI. 애자일 디버깅 VII.애자일 협력 5.1 수호천사를 곁에 두기 5.2 만들기 전에 사용하라 5.3 차이는 다른 결과를 만든다 5.4 실제 진척상황을 측정하라
5.1 수호천사를 곁에 두기 좋은 단위테스트는 문제를 즉시 경고한다. 견고한 단위테스트가 자리 잡지 않았다면 설계나 코드 변경을 하지 말자. “단위 테스트를 작성하느라고 들인 시간과 노력이 쓸모 있다고 합리화 할 순 없어. 단위테스트는 프로젝트를 지 연시킬 거야. 그래 넌 정말 잘난 프로그래머야. 어쨌든 단위테스트는 시간 낭비일 뿐이지.” •단위테스트로 즉각 피드백을 받는다. •단위테스트는 코드를 강건하게 한다. •단위테스트는 유용한 디자인 툴이 될 수 있다. •단위테스트는 자신감을 증진시킨다. •단위테스트는 프로브(probe) 역할을 할 수 있다. •단위테스트는 믿을만한 문서다. •단위테스트는 학습 도우미다. 단위테스트를 해야 하는 이유
5.2 만들기 전에 사용하라 테스트 주도 개발을 설계 툴로써 사용하자. 테스트 주도 개발은 여러분을 더 실용적이고 더 간단한 설계 로 인도할 것이다. “라이브러리 코드를 어서 완성해. 사람들이 라이브러리에 대해서 무슨 생각을 하는지 들을 시간은 뒤에도 많아. 지금 당장은 코드를 옆으로 치워둬. 그래도 괜찮아.” 코드를 작성하기 전에 테스트를 작성하라 좋은 디자인이 더 많은 클래스를 뜻하지는 않는다 균형 유지하기 •테스트주도 개발은 작성하려는 코드에 실패하는 단위테스트를 만든 다음 코드를 작성한다. •테스트를 먼저 하면 개발자 관점이 아닌 사용자 관점에서 코드를 살펴볼 수 있다. •객체지향 시스템을 설계할 때, 더 많은 객체의 클래스를 만들도록 강요하는 경향이 있다. •클래스가 진짜로 필요하지 않은 경우에도 쓸데없는 코드를 추가한다. •테스트 우선이냐, 코드작성 후 테스트냐 사로잡히지 말자. •모든 설계는 향상될 수 있다. •단위테스트만으로는 더 나은 디자인을 보장하지 못하지만, 더 쉬운 디자인을 만들 수 있다.
5.3 차이는 다른 결과를 만든다 지속적 통합 툴을 사용해서, 지원하는 플랫폼과 환경의 조합마다 단위테스트를 실행하자. 문제가 여러분 을 부르기 전에 능동적으로 문제를 찾자. “네 머신에서만 코드가 작동하면, 괜찮아. 어느 플랫폼에서 작동하든 누가 신경 쓰겠어? 어차피 네겐 그게 없는 데.” •하드웨어는 개발자 작업 시간보다 더 저렴하다. •모든 플랫폼에 존재하는 버그가 스택 레이아웃의 차이, 캐릭터셋의 차이 때문에 발생할 수 있다. •솔라리스보다 리눅스 사용자가 많아도 여전히 양쪽 테 스트는 하는 것이 필요하다. •필요하다면 Vmware나 가상 PC를 사용해라. 균형 유지하기
5.4 실제 진척 상황을 측정하라 현실성이 떨어지는 측정 기준으로 자신이나 팀을 기만하지 말자. 해야 할 작업의 백로그를 측정하자. “제발, 진척 상황을 보고할 때 근무시간 기록표를 사용해. 우린 근무시간 기록표를 프로젝트 계획 수립에도 사 용할 거거든. 그러니까 매 주 40시간을 항상 채워. 네가 진짜로 얼마큼 일했는지 관계없이 말이야.” •근무시간 기록표는 현실을 좀처럼 반영하지 못하여 프로젝트 계획수립, 예측, 성과측정에 도움이 안 된다. •80퍼센트 완료했다고 하기 보다는 몇 퍼센트 남았는지 판단하려고 노력하자. •예측한 작업을 정말로 끝냈을 때, 이 작업이 진짜로 얼마나 오래 걸렸는지 기록하자. •예측해야 하는 다음 작업의 경우, 이러한 경험을 기초로 조정해야 한다. •진척 상황을 측정하는 가장 좋은 방법은 백로그(backlog)를 사용하는 것이다. •달력이 아니라 중요한 것은 기능이다.
V. 애자일 피드백 VI. 애자일 코딩 V. 애자일 디버깅 VI. 애자일 협력 6.1 의도적이고, 의미 있게 프로그램 하라 6.2 코드로 대화하기 6.3 능동적으로 트레이드 오프 평가하기 6.4 계약에 의해서 교체하기
6.1 의도적이고, 의미 있게 프로그램 하라 코드를 읽는 사람에게 의도를 명확하게 표현하자. 읽기 쉽지 않은 코드는 독창적이지도 않다 “작동하고 이해할 수 있는 코드도 멋지지만, 더 중요한 것은 독창적인 거야. 너는 똑똑하기 때문에 월급을 받잖 아. 그러니까 네가 얼마나 훌륭한지 보여줘” coffeeShop.placeOrder(2) worst coffeeShop.placeOrder(2 /* 큰컵 */) coffeeShop.placeOrder (CoffeeCupSize.Large) PIE 원칙 작성하는 코드는 의도를 명확하게 반드시 의미가 있 어야 한다. PIE – Program Intently and Expressively 균형 유지하기 •지금은 명백해도 일 년 후 명백하지 않을 수 있 다. •다음이란 없다. 지금 할 수 없으면 다음에도 할 수 없다. •상황에 맞는 결합을 사용하자. 밀접하게 결합된 컴포넌트의 경우 해쉬테이블을 쓰지 말자. best better
6.2 코드로 대화하기 잘 고르고, 의미 있는 이름을 사용해서 코드를 문서화하라. 메서드의 목적과 제한 조건을 설명하는 주석 을 사용하라. 좋은 코드를 대신하려고 주석을 사용하지 말자. “코드가 너무나 난해해서 읽기 어려울 때 주석이 도움이 될 거야. 줄마다 코드가 무엇을 하는지 정확하게 설명 해 둬. 이유는 고민하지 말고 왜냐면 코드가 무슨 일을 하는지 주석이 알려줄 테니까.” 1. 코드 자체로 표현 2. 코드로 표현할 수 없는 부분에 주석처리 코드의 문서화 주석 •목적 : 이 메서드는 왜 존재하는가? •필요조건(선행조건) : 이 메서드를 작동하기 위해서 어떤 입력이 필요한가? •계약 사항(후행조건) : 이 메서드가 성공적으로 완 료되었을 때 객체 내부의 상태는 어떻고, 어떤값을 돌려주는가? •예외 : 무엇이 잘못될 수 있고, 어떤 예외를 던지는 가? •인덱스 색인변수 : i(루프), s(문자열) •// 생성자 : 의미없는 변수 •passthrough() // 통과하게한다 : 의미없는 주석 균형 유지하기 •짧게 표현하기 힘들면 길게 사용하라. •실제코드가 의도를 전달할 수 있을 때 주석을 사용하지 마라. •코드가 무슨 일을 하는지 주석을 다는 것은 유용하지 않 다. 그러나 왜 그렇게 하는지 주석을 다는 것은 유용하 다. •매서드를 재정의할 때, 원래 메서드의 목적과 제한 조건 을 설명하는 의도와 주석을 보존하자.
6.3 능동적으로 트레이드오프(trace-off) 평가하기 성능, 편의성, 생산성, 비용, 적시 릴리스를 고려하자. 성능이 적당하면, 다른 요소를 향상시키는데 집중 하자. 하찮거나 미미한 성능이나 우아함을 위해서 디자인을 복잡하게 하지 말자. “소프트웨어 개발에서 성능, 생산성, 우아함(elegance), 비용, 적시 릴리스는 매우 중요하고 결정적인 이슈 지. 너는 이 모든 것을 만족시켜야 해.” 성능 성능프로젝트 성공 생산성비용 편의성 적시 릴리즈 •모든 환경을 만족시키는 최선의 해결책은 없다. •가까이서 문제를 평가하고 가장 적당한 해결책 에 도달해야 한다. •과거에 사용했던 해결책이나 접근 방식이 현재 문제에 적합하지 않을 수 있다. •최후의 밀리세컨드를 줄이는데 시간을 보내는 것보다 더 낮은 가격으로 일찍 릴리즈하는 것 이 더 중요할 지 모른다.
6.4 계약에 의해서 교체하기 인터페이스 계약을 존중하는 클래스를 교체해서 기능을 추가하거나 강화하자. 위임은 언제나 상속보다 바 람직하다. “상속에 상속을 받는 상속계층은 너무나 멋져. 다른 클래스에서 기능이 필요하면, 그 클래스를 상속해. 새로운 클래스가 약속을 어겨도, 호출자가 자신의 코드를 바꿀 수 있지.” •is-a는 상속을 사용하고, has-a나 uses-a에는 위임 을 사용하자. •상속이 잘못된 것은 아니다. 단지 잘못 사용되는 것이다. •인터페이스는 실제로 무엇을 제공하는지 확실히 알지 못 하면 제대로 구현하기 힘들다. 상속 위임 •상속 – 새로운 클래스를 기존의 클래스 자리에서 사용할 수 있고 이들 관계가 is-a로 표현되면 상속을 사용 •위임 - 새로운 클래스는 단순하게 기존의 클래스를 사용해 야 하고 관계가 has-a나 uses-a로 표현 할 수 있으면 위 임을 사용하자. 균형 유지하기
V. 애자일 피드백 VI. 애자일 코딩 VII.애자일 디버깅 V. 애자일 협력 7.1 해결책 로그를 기록하자 7.2 모든 예외를 보고하라 7.3 유용한 에러 메시지를 제공하라
7.1 해결책 로그를 기록하자 문제를 해결하는 일의 일부는 나중에 해결책을 찾고 적용할 수 있도록 해결책의 상세 내용을 보존하는 것 이다. “개발하면서 데자뷰 느낌이 자주 들지 않나? 괜찮아. 한번 느낀 건데. 다시 느낄 수도 있지.” 데이로그 •문제발생일 •문제나 쟁점의 간단한 설명 •해결책의 상세한 설명 •더 많은 상세 내용과 관련된 정보를 담은 가사나 URL의 참조 •해결책의 일부나, 상세 내용을 깊게 이해하는데 도움이 될 만한 코드 일부, 설정, 다이얼로그 스 냅샷 균형 유지하기 •문제를 문서화 하는 것 보다 해결에 시간투자 •이전 해결책을 찾는 게 중요하다 •문제가 생긴 애플리케이션 버전, 프레임워크, 플 랫폼의 버전을 추적 •웹 검색을 올바르게 활용하자 •무슨 이유로 그런 결정을 내렸는지 기록하자
7.2 모든 예외를 보고하라 예외를 덮어 두지 말자. 임시로라도 말이다. 코드가 실패할 수 있다고 생각하며 작성하자 “이상한 예외로부터 호출자를 보호해. 예외를 다루는 것은 네 일이야. 네가 호출하는 모든 것을 감싸버려. 너만 의 예외를 보내. 아니면 예외를 삼켜 버리든지.” 처리할 수 없을 때는 넘기자 구체적으로 표시하자 에러를 처리하자 try { … } catch (Exception e) { xxx } try { … } catch (Exception e) { logger.error(e); } try { … } catch (Exception e) { … } try { … } catch (Exception e) { System.out.println(“null”); } try { … } catch(Exception e) {} try { … } catch (Exception e) { throw e; }
7.3 유용한 에러 메시지를 제공하라 에러의 상세내용을 알아내기 쉬운 방법을 제공하자. 문제가 생겼을 때 할 수 있는 한 많은 지원과 관련된 상세 정보를 제공하라. 그렇지만 이 정보와 함께 사용자를 파묻지는 말자. “사용자를 겁주지 마. 다른 프로그래머들조차도, 사용자에게 멋지고 정제된 에러 메시지를 줘. ‘사용자 에러. 복귀됨. 계속함’ 같은 편안한 걸 사용해.” •사용자는 메시지를 알 수 없다. •빠른 해결이 불가능하다. •원인파악하기가 힘들다. •사용자에게 메시지를 제공한다. •기술 지원 시 활용 할 수 있다. •세부적인 정보를 제공한다. •사용자로 하여금 혼란을 준다.
V. 애자일 피드백 VI. 애자일 코딩 VII.애자일 디버깅 VIII.애자일 협력 8.1 정규 대면회의 시간을 가져라 8.2 아키텍트는 코드를 작성해야 한다 8.3 공동소유를 실천하라 8.4 멘토가 되자 8.5 준비되었을 때만 코드를 공유하라
8.1 정규 대면회의 시간을 가져라 스탠드 업 미팅은 팀을 같은 곳에 둔다. 회의를 열성적이면서 짧고, 집중적으로 유지하자. “너는 회의를 열어야 해. 아주 많은 회의 말이야. 사실 우리는 일이 왜 끝나지 않는지 알아낼 때까지 더 많은 회의를 할 거야” 스탠드 업 미팅 •어제 내가 달성한 일은 무엇인가? •오늘 계획한 일은 무엇인가? •문제나 어려운 점은 무엇인가? 장점 •집중 - 집중하는 방식으로 하루를 시작하게 한다. •이슈해결 - 이슈를 공개적으로 만들고 도움을 구할 기회를 얻는다. •인력관리 - 도움이 필요한 분야를 관리자가 인력 재할당한다. •공유 - 타 분야에서 무엇이 진행되는지 팀원이 인식하게 한다. •빠른 처리 - 다른 사람의 해결책을 빨리 파악하도록 해준다.
8.2 아키텍트는 코드를 작성해야 한다 진짜 통찰력은 활동적인 코딩 작업에서 나온다. 코드를 작성하지 않는 아키텍트를 기용하지 말자. 시스템 의 현실을 알지 못하는 아키텍트는 설계를 할 수 없다. “우리의 노련한 아키텍트 프레드가 코드를 작성할 설계를 넘겨 줄 거야. 프레드는 경험 많고 무척 비싸니까, 멍 청한 질문이나 구현 문제 따위로 프레드가 시간을 허비하게 하지마.” 가역성 여러분이 내리는 어떤 결정도 돌에 새겨서는 안 된다. 대신에 중요한 결정마다 해변에 있는 모래성만큼만 유지된다고 생각 하고, 변화를 향해 당당히 계획을 세우자. 균형 유지하기 •시스템의 핵심적인 상세 내용을 이해하지 않고는 제대로 된 설 계를 할 수 없다. •지도만 보고 수마일 떨어진 곳에서 전투를 지휘하는 격. •설계하기를 거부하는 프로그래머는 생각하기 거부하는 사람이 다.
8.3 공동 소유를 실천하라 개발자들을 순환시켜 전체 시스템의 다른 영역에 있는 서로 다른 모듈이나 태스크를 교차해서 개발시키자. “그 치명적인 버그는 걱정하지 마. 조이가 다음 주에 휴가에서 돌아오면 버그를 고칠 거야. 그때까지만 버그를 피해서 일해.” 코드 공동 소유를 강조하자 개발자들을 순환시켜 전체 시스템의 다른 영역에 있 는 서로 다른 모듈이나 태스크를 교차해서 개발시키 자. 균형 유지하기 •뜻하지 않게 팀에서 전문가를 잃지 말자. 특정 분야에 노련하 다면 그를 해당 분야에 전문가로 두자. •모든 것을 공동소유 한다면 무척 혼란스러울 수 있다. •프로젝트의 모든 부분을 상세하게 알아야 할 필요는 없다. •전문적이고 특정문제 영역은 공동 소유를 할 필요 없다. •지식을 공유하지 않는다면 지식을 잃어버릴 각오를 해야 한다 – 팀원을 잃는 경우
8.4 멘토가 되자 아는 것을 공유하는 데 즐거움이 있다. 얻은 만큼 베풀어라. 더 나은 목표를 달성하기 위해서 다른 사람 을 자극하자. 팀의 전체적인 역량을 향상시키자 “네가 있는 곳에 도달하려고 오랜 기간 동안 무척 힘들었겠지. 더 멋져 보이도록 너만의 것으로 간직해. 팀 동 료를 겁주기 위해서 발군의 기술을 사용하라고.” •지식은 나누면 커진다 - 돈은 나눌수록 줄지만 누군가를 교육하면 둘 다 더 많은 지식은 얻는다. •멘토링은 손을 잡고 숟가락으로 정보를 떠먹여 주는데 시간을 쓰라는 것은 아니다. •테두리 안에 갇히지 마라 - 블로그나 코드 관련 사이트에 글을 올리자. •짝 프로그래밍은 훌륭한 멘토링을 위한 환경이다. •팀원이 도움을 요청하기 전에 얼마나 매달려야 하는지 제한 시 간을 설정하자.
8.5 준비되었을 때만 코드를 공유하라 다른 사람이 쓸 수 있도록 준비되지 않은 코드는 체크인하지 마라. 컴파일이 안 되었거나 단위테스트를 통과하지 못한 코드를 체크인하는 것은 프로젝트의 범죄적인 태만 행위로 간주해야 한다. “사용자를 겁주지 마. 다른 프로그래머들조차도, 사용자에게 멋지고 정제된 에러 메시지를 줘. ‘사용자 에러. 복귀됨. 계속함’ 같은 편안한 걸 사용해.” 버전 관리 시스템을 사용하지 않는 것보다 더 나쁜 것은 무엇일까? 답은 버전 관리 시스템을 잘못 사용하는 것이다 •코드를 얼마나 자주 체크인 하느냐가 생산성, 제품 안정성, 품질, 일정에 영향을 미친다. •작업이 끝나기도 전에 체크인 하는 것은 다른 개발자에게 영향을 줄 수가 있다. •파일 전부를 체크인 하는 데 어떤 파일이 변경되었으며 의미 있는 로그 메시지를 덧붙여야 한다. •작업이 끝나기도 전에 코드를 체크인하는 경우는 회사에서 체크인하고 집에 와서 체크아웃 하는 것이다.
에필로그 – 애자일로 이동하기 1. 새로운 실천방법 하나 2. 실패하는 프로젝트 구출하기 4. 애자일 도입하기 : 프로그래머 지침 •스탠드 업 미팅을 사용하라 •팀이 뭉치고 응집력이 높은 단위로 형성 •오래 걸리지 않으며, 많은 노력을 들이지도 않음 •회의를 지키는 규율이 필요하지만 곧 습관이 됨 •단지 새로운 실천방법 한 가지였지만 팀에 커다란 차 이를 만들었다. •한번에 모든 개발 실천방법을 바꾸는 것은 프로젝트 를 죽이는 최선의 방법 •모든 것을 한꺼번에 고치려고 노력하지 마라 •상황이 급박하지 않는다면, 애자일 실천방법을 도입 하기 위해 더 신중한 접근 방법을 택해라 3. 애자일 도입하기 : 관리자 지침 •관리자라면 팀 전체를 하나로 모으는 데서 시작해야 한다 •천천히 진행하자 •스탠드 업 회의로 시작하자 •개발 기반 환경을 차례로 도입해야 한다 •팀에서 피드백을 받자 •애자일 실천방법을 모두 완수해야 한다 •팀을 납득시키기 위해서 싸우는 대신에, 이제 그들이 최선의 실천방법을 습득하길 열망한다 •지금 당장 할 수 있는 실천방법부터 시작하자

Check these out next

애자일 프랙티스

Recomendados

Mais conteúdo relacionado

Apresentações para você(20)

Similar a 애자일 프랙티스(20)

Mais de 한 경만(12)

Último(20)

애자일 프랙티스