Dev rookie codecomplete-1
- 1. CODE COMPLETE - 1 데브루키 대영
- 2. CODE COMPLETE 주제 준비 이유 ▸추천 ▸명저 ▸실무에서는 코드를 어떻게 적용할까? ▸두꺼운 책 한번 쭉 가보자
- 3. CODE COMPLETE 발표 목차 ▸개발자에게 구현 활동이란? ▸비유의 마법 ▸아키텍처
- 4. CODE COMPLETE 책 소개 《Code Complete 2》는 소프트웨어 구현을 둘 러싼 다양한 비유부터 기초적인 프로그래밍, 시스템 구축, 소프트웨어 장인정신에 이르기까 지 소프트웨어 업계에 종사하는 분이라면 누구 나 읽어야 할 필독서입니다. 2004년에 초판이 출간된 이후로 시간이 흘러도 여전히 가치 있는 명저의 반열에 오른 책으로 서 특정 프로그래밍 언어나 플랫폼과는 무관한 내용으로 구성돼 있어 소프트웨어 업계에 종사 하는 모든 분들에게 도움될 만한 내용으로 가 득 차 있습니다. 대충 요약: 프로그래밍 기본 실무 매뉴얼 가이드
- 5. CODE COMPLETE 발표에 앞서 ▸책에서 제시하는 내용은 일종의 가이드 정답은 아니다 ▸팀의 코딩 컨벤션을 고려하여 적용해야한다 ▸저 처럼 연차가 얼마 안 되시는 주니어시라면 팀에서 정한 룰에 맞춰 프로그래밍을 해야합니다 ▸책에서 주어진 구현 방법을 암기하는게 아니라 그렇게 해야하 는 이유에 대해서 생각을 해봅시다
- 7. CODE COMPLETE 건축과 소프트웨어 건설 소프트웨어 설계 Architechure 작업 construction implementation
- 8. CODE COMPLETE 소프트웨어 개발 과정 ▸문제 정의 ▸요구사항 개발 ▸구현 계획 수립 ▸소프트웨어 아키텍처 또는 고급 수준 설계 ▸상세 설계 ▸코드 작성 및 디버깅 ▸단위 테스트 ▸통합 테스트 ▸통합 ▸시스템 테스트 ▸유지보수
- 9. CODE COMPLETE 구현 활동 문제정의 요구사항 개발 구현계획 수립 소프트웨 어 아키텍처 상세 설 계 코드 작 성 및 디 버깅 단위테스 트 통합테스 트 통합 시스템 테스트 유지보수
- 10. CODE COMPLETE 구현 활동에 속하는 구체적인 작업 ▸성공적인 구현 활동을 위한 기초 작업 검증 ▸코드에 대한 테스트 방법 결정 ▸클래스 및 루틴 설게와 작성 ▸변수와 이름 상수(named constant) ▸제어 구조 선택과 명령문 블록 구 조화 ▸코드에 대한 단위 테스트, 통합테 스트, 디버깅 ▸저수준 설계와 코드를 다른 팀원 과 교차 검토 ▸조심스럽게 코드의 포맷을 맞추 고 주석을 달아 코드를 정리 ▸개별적으로 작성한 소프트웨어 컴포넌트의 통합 ▸코드가 더 빨리 실행되고 더 적은 자원을 사용하도록 최적화
- 11. CODE COMPLETE 개발자에게 구현을 통해 중요시해야하는 것 생산성 소프트웨어 품질
- 12. CODE COMPLETE 소프트웨어 구현이 중요한 이유 ▸구현은 소프트웨어 개발에서 가장 큰 비중 차지 30% ~ 80% ▸구현은 소프트웨어 개발 과정에서 중심적인 활동 요구사항과 ▸구현에 집중함으로써 프로그래머의 생산성을 크게 향상할 수 있다. (구현은 일반적인 활동 보다 10배 ~ 20배) ▸구현의 결과물인 소스코드만이 소프트웨어를 정확하게 설명하는 경우가 많다(개발자에게 허용된 최신 문서) ▸구현은 반드시 해야하는 유일한 활동 프로젝트가 바쁘면 요구사항 및 설계 단계를 건너 뛰게되고 그에 따른 오류도 많고 테스트 시간도 부족해지지만 어떤 프로젝트를 막론 하고 구현 단계는 빠질수 없는 핵심 활동이기 때문이다
- 13. CODE COMPLETE 비유의 마법 ▸유추를 통해 종종 중대한 발전이 이뤄지기도 함.어설프게 아 는 주제를 더 잘 아는 비슷한 주제와 비교해 이해함으로써 덜 친숙한 주제를 잘 이해할 수 있다. 이렇게 사용하는것을 '모델 링’이라함 ▸일반적으로 모델은 생생하고 전체 개념의 윤곽을 잡을 수 있 다는 장점이 있고, 특성과 관계. 추가적으로 연구할 영역을 제 시해준다. ▸개인적 생각으로는 의사소통을 할 때도 올바른 비유를 하면 커뮤니케이션 할 때 더 도움이 될때가 많았던거 같습니다.
- 14. CODE COMPLETE 소프트웨어의 비유 중요성 ▸소프트웨어 비유는 지도라기보다는 탐조등이라 할 수 있고, 알고리즘보다 발견적인 학습으로 더 많은 역할 담당 ▸알고리즘은 결정적이고 바뀌지 않는다. 비유는 틀릴수도 있으며 변할수도 있다. 알고리즘은 직접적으로 방법을 알려주지만, 비유는 그 방법을 스스로 찾는 방법을 알려준다. ▸프로그래밍에 가장 어려운 것은 문제를 개념화 하는것이고, 가장 많이 발생하는 오류는 개념적인 오류이다. 프로그램은 저마다 개념적으로 고유하기 때문에 일반화 된 방법을 찾기에는 매우 어렵거나 불가능하다. 그렇기 때문에 자신이 답을 찾아가는 능력이 매우 중요하다.
- 15. CODE COMPLETE 소프트웨어의 비유 - 코드 작성하기(편지) 코드를 작성하는 것은 편지 처럼 한 페이지에 처음부터 끝까지 작성하는것 정해진 형식 없이 작성하며 말하고 싶은것을 생각해낸다. 개인 작업이나 소규모 프로젝트인 경우에는 편 지 쓰기 비유가 적절하지만 대규모 프로젝트 경우에는 해당 비유로 설명하기 어렵다. 한번 작성하면 변경하기 어려운 편지와 달리 소프트웨어는 변경하기가 어렵지 않고 완전히 완료되는 경우가 거의 없다. 하지만 소스코드의 경우 쓰고 버릴 수 없기 때문에 편지를 소프트웨어 개발 비유로 들기 어렵다.
- 16. CODE COMPLETE 소프트웨어의 비유 - 시스템 키우기(농사) 요구사항에 맞춰 설계하고 코드를 작성하고 테스트하는 일련의 과정을 단계별로 수행하여 한번에 발생하는 문제를 최소화 함으로써 소프트웨어 개발은 농사와 비슷할 수 있다. 하지만 자연에 큰 영향을 받는 농사와 달리 소프트웨어 개발은 프로그래머가 그러한 상황도 통제를 해야하기 때문에 알맞은 비유는 아니다
- 17. CODE COMPLETE 소프트웨어의 비유 - 시스템 증대(진주 양식) 증대의 사전적 의미는 점진적으로 외부에서 첨가하거나 포함해 규모가 증가하며 자라는것 점에서 키우기와 뜻이 달라진다. 점증적으로 설계학 구축하고 테스트하는 것이 활용 가능한 소프트웨어 개발 개념 중 가장 강력한 것. 점증적 개발에서는 우선 실행할 시스템을 가장 간단한 버전으로 만든다. 그것은 실제로 입력 을 안 받고 실제 출력이 안 되도 된다. 완전한 시스템이 될때까지 한번에 조금씩 코드를 추가하며 시스템 증대를 시켜야한다.
- 18. CODE COMPLETE 소프트웨어의 비유 - 소프트웨어 구축(건설) 건축가든 개발자든 일반적인 설계를 하고 승인을 받아야한다. 이 과정은 개발의 아키텍쳐 설계를 하고 그 설계를 통해 건설(구현) 시작을 하게 된다. 복잡성과 크기가 커질수록 두 활동 모두 활동(인간의 노동) 중요성이 커진다. 이미 건설된 건물을 옮기는 것이 비싼 이유는 단순 제품의 가격이 비싸서가 아니라 그 활동을 하는 노동자의 인건비를 지급해야 하기 때문에 비싸진다. 이미 다 건설된 집에 가구 등을 넣는건 기존의 라이브러리, 솔루션을 통해 개발하는것과 같으며, 고급스러운 집을 지을 때는 커스텀 제작 가구 등을 배치하는것은 자체 라이브러리 제작하는 것과 유사하다. 또한 내부벽이 칸막이보다 두꺼운 벽이 더 큰 비용이 든다. 이건 소프트웨어에서 추가,삭제 보다 변경이 더 큰 비용이 든다는점과 비슷하다.
- 19. CODE COMPLETE 준비는 철저하게 : 선행 조건 ▸앞서 건축 비유와 마찬가지로 개발은 구현활동 전 설계 수립이 매우 중요하다. ▸프로젝트가 성공할 것이냐 아니냐의 상당 부분은 구현을 시작 하기 전에 이미 결정된다. 계획을 잘못 수립했을 때 구현에서 최소 의 행동은 손해를 최소화 하는것이다. ▸최악의 소프트웨어 프로젝트는 가장 비용이 비싼 구현활동에 서 작업만 반복 시키는 경우이다. 첫 단추를 잘 끼워야한다.
- 20. CODE COMPLETE 선행 조건의 중요성 ▸품질이 좋은 소프트웨어를 개발하는 개발자들의 공통점은 자신만의 고급 실천법 있음. 시작과 중간, 끝 단계에서 품질을 중요시한다. ▸마무리 단계 중요시. ▸시스템 테스트 단계에서 품질을 강조하는 경우 잘못된 방법으로 개발하는것과 같 은 문제점 발견하기 어려움. ▸중간 단계 중요시. ▸구현 활동 단계에 중점을 두는 것이다. ▸시작단계에서 중요시. ▸계획하고 요구사항을 수집하고 설계 구현 활동 중 현재 진행 상황 판단 하는데에 큰 도움이 된다.
- 21. CODE COMPLETE 선행 조건이 최신 프로젝트에도 적용이 될까? ▸때로는 프로젝트 계획 수립 같은 성행 작업이 최신 소프트웨어 프로젝트에서 도움이 되지 않는다고 주장하는 사람도 있지만, 준비 작업의 가장 중요한 목표는 위험 축소. 가장 흔한 위험 요소는 불충분하거나 잘못된 프로젝트 계획이다.
- 22. CODE COMPLETE 불완전한 준비의 원인 ▸개발자가 자신의 작업을 수행할 수 있을 정도로 전문가적인 지식을 가지는 경우가 드물다…(뜨금) ▸대부분의 개발자가 훌륭한 아키텍처 설계하는데 필요한 기술 은 매우 중요하지만, 그러한 교육을 받는 기회가 매우 어렵다. ▸구현 활동에 급급해 준비 작업을 하지 않는 개발자도 있다. ▸관리자들이 설계하고 있으면 놀고 있는줄 안다. 까라면 까
- 23. CODE COMPLETE 만약 관리자에게 쪼일때 하는 방법! ▸효과적이지 않은 방법으로 작업할수 없다고 단호하게 거절해라! ▸상사랑 친하거나 은행 잔고가 두둑하면 그래라 ▸코드 작성하는 척하며. 설계를 한다. ▸가장 현실에서 많이 일어나는일. 하지만 좋은 아키텍처를 설계하면 그만큼 구현 시간이 줄어들 것이다. ▸관리자에게 기술 프로젝트의 미묘한 차이에 대해 설명해주자 ▸소프트웨어 개발에 좋은 환경을 구축할 수 있을 것이다. ▸다른 직장 구해라!
- 24. CODE COMPLETE 구현 전에 선행 조건을 수행하기 위한 필수적인 논의 ▸기술자는 비기술자에게 개발 프로세스에 대해 교육도 해야한다. ▸논리적 설득 ▸효과적인 프로그래밍의 핵심 큰 프로젝트일 수록 계획 수립이 필요 필요한 시간과 인력, 장비의 수를 결정하는 작업 자신이 만들고자 하는 것이 무엇인지 정확하게 이해하게 하는것 ▸비유적 설득 ▸반복적인 프로젝트를 계획하고 있다면 구현전에 핵심 요구사항과 아키텍처 요소를 규명해야한다. 트리를 세우기 전에 장식을 하지 않는 것 처럼.
- 25. CODE COMPLETE 구현 전에 선행 조건을 수행하기 위한 필수적인 논의 ▸데이터에 근거한 설득 ▸처음부터 작업을 제대로해야한다. 불필요하게 변경하는 경우 추가 비용이 든다. 초기에 결함을 고치기 위해 노력한다면 개발 비용과 일정을 두배 이상으로 줄일수 있다. 발생시기 요구사항 아키텍처 구현 시스템 테스트 출시 후 요구사항 1 3 5-10 10 10-100 아키텍처 - 1 10 15 25-100 구현 - - 1 10 10-25 요구사항과 계획이 잘 수립되어있다면 상대적으로 적은 시간과 비용이 든다.
- 26. CODE COMPLETE 소프트웨어의 비즈니스 시스템 프로젝트 계획 수 립 요구 사 항 설계 작 업 구현 시스템 테스트 유지보수 비즈니스 시스템은 반복적인 접근 방법이 좋음 안전 시스템은 요구사항이 변경되지 않아야하 때문에 순차적인 접근 방법이 좋음.
- 27. CODE COMPLETE
- 28. CODE COMPLETE 문제정의 ▸문제 정의는 개발에 근본 문제 정의를 잘못하면 일을 처음부터 시작할 수 있다 ▸문제 정의는 반드시 사용자의 사용 언어 로 작성해야한다. 컴퓨터 전문 언 어로 사용하면 안 됨 문제 정의 요구 사항 아키텍처 구현 시스템 테스트 향후 개선
- 29. CODE COMPLETE 왜 명시적인 요구사항 필요한가 ▸명시적 요구사항은 개발자 대신 사용자가 시스템의 기능을 주도 할 수 있게된다. ▸논쟁을 피할수 있게한다. ▸변경사항을 최소화 하는데 도움이된다. 새로운 오류를 발생시키 지 않는다. ▸그렇다고 완벽한 변경사항은 추구하지말자. 사용자들은 코드가 완성 될때까지 자신의 요구사항을 확실하게 설명하지 못 하는경 우가 많다. 프로젝트에서 25%가 요구 사항이 변경되지만 재작업 이유 70~80% 가 요구사항 변경때문에 일어난다는 연구조사도 있음.
- 30. CODE COMPLETE 구현 중에 요구사항 변경 다루기 ▸요구사항 변경 비용에 대해서 알게 한다 ▸요구사항 변경 절차를 구축한다 ▸변경사항을 수용하는 개발 접근법을 사용한다 ▸프로젝트를 취소한다 ▸프로젝트의 사업성을 주시한다
- 31. CODE COMPLETE 구현 중에 요구사항 변경 다루기 ▸요구사항 변경 비용에 대해서 알게 한다 ▸요구사항 변경 절차를 구축한다 ▸변경사항을 수용하는 개발 접근법을 사용한다 ▸프로젝트를 취소한다 ▸프로젝트의 사업성을 주시한다
- 32. CODE COMPLETE 아키텍쳐 ▸소프트웨어 아키텍처는 소포트웨어 설계의 상위 부분에 속하 며 설계 중에서 더 상세한 부분을 담은 틀. ▸아키텍쳐는 시스템 전반에 적용되는 설계상의 제약 사항 ▸상위수준 설계는 서브 시스템이나 여러 클래스 수준에 적용 가능하지만 시스템 전반에 적용된다는 보장은 없음 ▸아키텍쳐 변경되면 구현이나 그 후의 작업에 대해 많은 비용 이든다. 아키텍쳐 변경은 오류 수정이든 기능 향상이든 빨리 알아낼수 록 좋다.
- 33. CODE COMPLETE 좋은 아키텍쳐의 요건 ▸프로그램 구조 ▸주요 클래스 ▸데이터 설계 ▸비즈니스 규칙 ▸사용자 인터페이스 설계 ▸자원 관리 ▸보안 ▸성능 ▸확장성 ▸상호운용성 ▸국제호와 지역화 ▸입력/출력 ▸오류처리 ▸장애허용 ▸구조적인 실행 가능성 ▸과도한 엔지니어링 ▸구입과 구현결정 ▸재사용 결정 ▸변경 전략 ▸일반적인 아키텍쳐 품질
- 34. CODE COMPLETE 좋은 아키텍쳐의 요건 - 프로그램 구조 ▸프로그램 구조 ▸시스템을 일반적인 말로 기술한 개요가 필요하다 이것이 없다면 수많은 세부사항과 클래스에 대해 이해가 어려울것 ▸아키텍처에서 최종구조에 대한 대안을 고려했던 근거와 다 른 대안들 대신 지금의 구조를 선택한 이유를 찾아야한다. ▸프로그램 내의 중요한 빌딩 블록을 정의해야한다. 각 빌딩 블록이 책임져야 하는 내용은 반드시 명확하게 정 의하고, 하나의 빌딩 블록이 반드시 한 분야를 책임져야한다.
- 35. CODE COMPLETE 좋은 아키텍쳐의 요건 - 주요 클래스, 데이터 설계 ▸주요 클래스 ▸각각의 중요한 클래스가 맡은 역할과 클래스 사이의 상호 작용을 어떻게 할 것이지를 규명해야한다. ▸데이터 설계 ▸아키텍쳐는 중요한 파일고 테이블 설계를 기술해야한다 이 데이터를 구현하기위해 사용한 리스트도 사용한 이유에 대해서도 규명해야한다. 다른 프로그램과 상호연동이 가능한지도 규명해야한다.
- 36. CODE COMPLETE 좋은 아키텍쳐의 요건 - 비즈니스 규칙, 사용자 인터페 이스 설계 ▸비즈니스 규칙 ▸아키텍처가 특정한 비즈니스 규칙을 따른다면 반드시 이를 규명해야하고, 이에 따른 시스템 설계에 따른 미친 영향을 기술해야한다. ▸사용자 인터페이스 설계 ▸사용자 인터페이스는 종종 요구사항 작성 시 명시된다. 사용자 인터페이스는 비즈니스 규칙 및 프로그램 결과에 영향을 미치지 않고 다른 인터페이스로 대체할 수 있도록 모듈화 되어야한다.
- 37. CODE COMPLETE 좋은 아키텍쳐의 요건 - 자원 관리, 보안 ▸자원 관리 ▸아키텍처는 데이터베이스 연결과 스레드, 핸들과 같이 부족한 자원을 관리하기 위한 계획을 기술해야한다. 일반적인 상황과 최악의 상황에서 사용되는 자원을 측정해야 한다. ▸보안 ▸아키텍처는 설계 단계와 코드 단계의 보안에 대한 접근방법을 기술해야한다. 신뢰할수 없는 데이터(클라에서 던져주는 데이 터) 외부 인터페이스로부터 데이터 처리, 암호화, 오류 메시지 중요 데이터 보호와 같은 보안 관련 사항을 염두에 두고 작성 해야한다.
- 38. CODE COMPLETE 좋은 아키텍쳐의 요건 - 성능, 확장성 ▸성능 ▸성능을 염려한다면 요구사항에 원하는 성능을 명시해야한다. 속도, 메모리, 비용 같은 자원 사이의 우선순위를 성능 목표에 명시해야하 는 경우라면 자원 사용도 그 내용도 포함해야한다. 어떤 영역이 성능 목표를 달성하기 위해 특정 알고리즘이나 데이터 형식을 사용해야한다면 그러한 내용에 대해서 언급해야한다. ▸확장성 ▸확장성은 추후의 요구를 충족시키기 위해 시스템이 확장할 수 있는 능력이다. 사용자수, 서버수, 네트워크 노드의 수, 데이터베이스 레코드의 수, 레코드 크기, 트랜잭션 용량등의 증가를 시스템이 어떻게 처리할 것인지를 기술해야한 다.
- 39. CODE COMPLETE 좋은 아키텍쳐의 요건 - 상호운용성, 입력/출력 ▸상호운용성 ▸시스템이 다른 소프트웨어나 하드웨어와 함께 데이터나 자원을 공유할거라 예상하면 그러한 기능을 어떻게 구현할 것인지 기술 해야 한다. ▸입력/출력 ▸아키텍처에서 입력 출력도 주의 깊게 사용하고, 입력 체계가 선행인지 후행인지 아니면 상황에 따라 선택되는지 명시해야한 다. 그리고 필드나 레코드 스트림, 파일 수준에서 어떤 입출력 오류 가 검출되는지를 명시해야한다.
- 40. CODE COMPLETE 좋은 아키텍쳐의 요건 - 국제화와 지역화 ▸국제화와 지역화 ▸'국제화’는 프로그램이 여러 나라를 지원하기 위한 기술적인 준비 작업을 뜻한다. "I18n"이라고도 한다. 지역화는 특정한 언어를 지원하기 위한 번역 작업이다."L10n"이라고도 한다. 대부분 대화식 시스템은 안내 메시지, 상태 표시, 도움말 메시지, 오류 메시지가 들어있다. 문자열을 사용하는 자원들은 미리 예측해야한다. 문자열 인코딩과 문자열 종류(C Style, String) 기본적인 것과 코드를 변경하지 않고 문자열을 유지하는 방법, 그리고 코드와 사용자 인터페이스에 미치는 영향을 최소화하면서 외국어로 변환하기 위한 방법등을 고려해야한다. 직접 문자열 사용, 클래스 인터페이스가 해당 문자열을 참조, 문자열을 리소스 파일에 저장할 것인지 결정할 수 있다.
- 41. CODE COMPLETE 좋은 아키텍쳐의 요건 - 오류 처리 ▸오류처리 ▸오류 처리는 컴퓨터 과학에서 가장 어려운 문제로 인식되 고 있고 오류를 함부로 처리할 수 없다. 코드의 90% 정도가 예외적인 오류를 처리하거나 이를 정 리 하기 위해 작성하는 거고 10% 정도가 일반적인 경우를 위한 것 이라 추정된다.
- 42. CODE COMPLETE 좋은 아키텍쳐의 요건 - 오류 처리 ▸아키텍처 수준에서 다루는 오류 처리 ▸오류 처리가 오류를 수정을 해야하는가? ▸프로그램이 오류를 어떻게 전달하는가? ▸오류 처리 메시지에 관한 규약이 있는가? ▸예외를 어떻게 처리할 것인가?
- 43. CODE COMPLETE 좋은 아키텍쳐의 요건 - 장애 허용, 구조적인 실행 가 능성 ▸장애 허용 ▸예상되는 장애 허용의 종류 또한 지정해야한다. 장애 허용은 오류를 검출하고 가능한 경우에는 오류로부터 복구하고 그렇지 않은 경우에는 시스템에 미치는 영향을 최소화 시켜야한다. ▸구조적인 실행 가능성 ▸시스템이 성능 목표를 달성할 수 있는지, 자원의 한계 내에서 실행 가능한지, 멀티 플랫폼인 경우 해당 환경에서 실행이 가능한지 조사후 구현작업을 시작해야한다
- 44. CODE COMPLETE 좋은 아키텍쳐의 요건 - 구입과 구현 결정, 재사용 결 정 ▸구입과 구현 결정 ▸가장 급진적인 해결책은 모든 것을 구현하는 대신 오픈소 스를 통해 라이브러리를 사용하는 것이다. 만약 사용하지 않는다면 어떤 점을 능가할 것인지를 기술 해야한다 ▸재사용 결정 ▸기존 소프트웨어의 데이터형식, 다른 요소를 사용할 계획 이면 재사용된 소프트웨어의 아키텍쳐에 부합한지 검증해야한 다.
- 45. CODE COMPLETE 좋은 아키텍쳐의 요건 - 변경 전략 ▸변경 전략 ▸소프트웨어는 개발 내내 변경될 수 있다. 계획된 기능 향상이나 시스템의 첫 번째 버전에서 구현하 지 못했던 기능 보완을 위해 유연한 구조를 만들어야한다. ▸일반적인 아키텍처 품질 ▸아키텍처는 모든 주요 결정사항에 대한 동기를 기술해야한 다. '항상 그래왔다’라는 식으로 정당화 하면 안 된다.
- 46. CODE COMPLETE 선행 조건에 소요되는 시간 ▸문제 정의와 요구사항, 소프트웨어 아키텍처 작업은 프로젝트 의 필요에 따라 달라진다. ▸통계적으로 프로젝트 전체 시간의 20~30%로의 시간을 차지 한다 ▸만약 요구사항이 명시되지 않은 프로젝트에 있다면?
- 47. CODE COMPLETE 정리 ▸프로그래밍 실무를 원활하기 위해서는 요구사항에 대한 적극적인 커뮤니케이션이 필요하고, 구현 전에 어떻게 작성할지 미리 설계를 하고 들어가야한다. 시스템의 품질 향상을 위해 테스트 까지 잘되어있는지 책임져 야한다.
- 48. Q&A
- 49. 감사합니다