서론
2021년11월27일 클린 코드에 대하여
2021년11월28일 애자일 정신에 대하여
결론
배우기
역시나 정답은 배우기이다.
넓게 배우고 그 중 필요한 것을 깊게 배우기.
이 말의 의미는 내가 할 수 있는 것을 찾고 해야 할일을 해라! 의.. 원점이 되는 것 같다.
2021년 11월 29일의 나는
Git , Notion, Selenium 을 사이드로 배워봐야겠다.
앞의 두 개는 현재 조장을 맡게 된 스터디를 조금 더 효율적으로 이끌고 대화를 나눠보고 싶어서인데, 과연 이 애자일에 대한 생각이 다른 분들은 어떨지가 궁금하고, 기왕 스터디를 하는거 제대로 해보고 싶다. 물론 다른 분들도 이에 대해서 긍정적이여야 하지만 말이다.
Selenium 은 내가 예전부터 많이 궁금했던,
단위테스트? 그게 뭔데?? 라는 것의 답이 되지 않을까 싶다.
나도 많이 많이 테스트 하고 많이 많이 에러 만나고 싶다.
그 후에 더이상 내 코드에서 에러가 나오지 않은 순간이 (드물게) 마주하면 기분이 너무너무 좋기 때문이다.
내용
애자일이란?
출처 : https://pmnagile.tistory.com/27
애자일 도구
- 소스 코드 저장소 도구 | 깃
- 지속적 통합/빌드 도구 | 젠킨스 팀시티 GoCD 등
- 배포/서버 관리 도구 | 도커 쿠버네티스 앤서블 셰프 퍼핏 등
- 의사소통 도구 | 이메일 슬랙 국어
- 테스트 도구 | 단위 테스트 프레임워크, 큐컴버, 셀레늄 등
비즈니스 실천방법
계획 세우기
스토리
- 스토리는 독립적이다.
- 최소 단위의 스토리를 정할 것
- 최소 단위의 스토리 별로 크기를 구분할 것
- 해당 스토리를 완벽히 처리할 것
- 스토리의 처리에는 작은 릴리즈 && 인수테스트 && 유닛테스트 를 포함하고 있다.
반복주기 와 속도
- 반복주기는 목표치가 아닌 상황 판단을 할 수 있는 지표일 뿐이다.
- 반복주기를 기록하며 속도 그래프와 번아웃 그래프를 작성한다.
2-1. 속도가 오른다면, 단순히 구성원이 압박을 느끼고 있을 확률이 높다.
2-2. 속도가 느려진다면, 이전까지의 코드의 품질이 낮을 확률이 높다.
인수테스트
- 구현,수정,리펙토링 이전에 테스트 코드부터 작성한다.
- QA 단계에서가 아닌, 개발자 단계에서 인수 테스트를 선행해야 한다.
유닛테스트
- 구현,수정,리펙토링 이전에 테스트 코드부터 작성한다.
- 모든 유닛들은 테스트 코드가 작성되며 이가 그룹화 되어 있어야 한다.
작은 릴리즈
- 스토리 별로 작
팀 실천방법
스탠드업 미팅
- 지난 스탠드업 미팅 이후 무엇을 했는가?
- 다음 스탠드업 미팅까지 무엇을 할 것인가?
- 어떤 장애물이 있는가?
기술 실천방법
테스트 주도 개발
- 제품 코드를 쓰기 전에 테스트 코드를 먼저 써야 한다는 것
- 해당 코드가 없어서 실패하는 테스트 코드를 쓰기 전에 제품 코드를 먼저 쓰면 안된다.
- 테스트 코드를 쓸 때는 실패하도록 만들기 위해 필요한 것보다 더 많이 쓰면 안된다. 컴파일 실패도 실패로 간주한다.
- 실패하는 테스트를 통과시키기 위해 필요한 코드보다 더 많이 제품 코드를 쓰면 안된다.
문서화
- 위의 세 가지 규칙을 따르다 보면 만들어지는 테스트는 전체 시스템의 코드 예제가 된다.
- API 함수를 어떻게 부르는지 알고 싶다면 테스트를 보면 된다.
- 테스트는 이 함수를 호출하는 모든 방법을 보여주고 이 함수가 던지는 모든 예외를 처리하는 방법을 보여줄 것이다.
- 객체를 어떻게 만드는지 알고 싶을 떄는 마찬가지로 테스트를 보면 객체를 만들 수 있는 모든 방법을 살펴 볼 수 있을 것이다.
- 각 테스트는 시스템 중 작은 부분의 동작을 설명하는 독립적인 코드 조각일 뿐이다.
디버깅
- 디버거를 사용하자.
- 언제나 1분만 거슬러 올라가면 모든 겅시 작동한다는 것은 어떤 의미일까?
리팩터링
- 실패하는 테스트를 만든다
- 그리고 이 테스트를 통과하게 만든다.
- 그리고 코드를 정리한다.
- 1단계로 돌아간다.
단순한 설계
- 모든 테스트를 통과할 것
- 의도를 드러낼 것
- 중복을 없앨 것
- 구성 요소를 줄일 것
짝 프로그래밍
Ref : 애자일 선언문
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
Ref : 애자일 선언 이면의 원칙
우리는 다음 원칙을 따른다:
우리의 최우선 순위는, 가치 있는 소프트웨어를
일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.비록 개발의 후반부일지라도 요구사항 변경을 환영하라.
애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이
되게 한다.작동하는 소프트웨어를 자주 전달하라. 두어 주에서
두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에
걸쳐 날마다 함께 일해야 한다.동기가 부여된 개인들 중심으로 프로젝트를 구성하라.
그들이 필요로 하는 환경과 지원을 주고 그들이 일을
끝내리라고 신뢰하라.개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장
효율적이고 효과적인 방법은 면대면 대화이다.작동하는 소프트웨어가 진척의 주된 척도이다.
애자일 프로세스들은 지속 가능한 개발을 장려한다.
스폰서, 개발자, 사용자는 일정한 속도를 계속 유지
할 수 있어야 한다.기술적 탁월성과 좋은 설계에 대한
지속적 관심이 기민함을 높인다.단순성이 -- 안 하는 일의 양을
최대화하는 기술이 -- 필수적이다.최고의 아키텍처, 요구사항, 설계는
자기 조직적인 팀에서 창발한다.팀은 정기적으로 어떻게 더 효과적이 될지
숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
