이 상품은 구매 후 지원 기기에서 예스24 eBook앱 설치 후 바로 이용 가능한 상품입니다.
|
프롤로그 인물 및 상황 설정 Chapter 1_ 〔배경〕 언어전환이 필요하다1. 레거시와 생활하기 _〔사례〕 2. 전환의 이유 찾기 _〔사례〕 _1. 이유 예시 _2. 주의사항 3. 설득하기 _〔사례〕 _1. ‘신뢰자본’을 쌓자 _2. 설득할 대상에 따른 전략을 세우자 _3. 한 번만에 설득을 완수해야 한다고 생각하지 말자 Chapter 2_ 〔준비〕 지피지기면 백전불태1. 프로젝트 로드맵 작성하기 _〔사례〕 _1. 로드맵 작성 시 이점 _2. 로드맵 도구들 2. 전환 전략 수립하기 _〔사례〕 _1. 작업 순서 결정 _2. 배포전략 수립 _3. 제약조건 설정 _4. 언어전환의 목적 확립 _5. 작업 범위 결정 _6. 작업 항목 목록화 3. 도메인 파악하기 _〔사례〕 _1. 도메인 목록 정의 _2. 행위 정의 _3. 모델 정의 4. API 정리하기 _〔사례〕 _1. REST API _2. Graphql API _3. gRPC 5. 기술 선정하기 _〔사례〕 _1. 웹 프레임워크 _2. API 프레임워크 _3. 영속 프레임워크 _4. 그 외에 고려해야 할 항목 _5. 프로토타입 작성하기 6. 패키지 구조 선정하기 _〔사례〕 _1. 패키지 구조를 선정할 때의 장점 _2. 대표 패키지 구조 7. 작업 생성하기 _〔사례〕 _1. 작업 생성 이유 _2. 작업 생성 전략 Chapter 3_ 〔과정〕 묻고 더블로 가!1. 프로젝트 환경설정 _〔사례〕 _1. 버전 관리 시스템 설정 _2. 브랜치 전략 _3. 브랜치 보호 룰 설정 _4. 프로젝트 설정 _5. 지속적 통합 및 배포 설정 _6. 인프라 설정 2. 코드 기여 규칙 설정 _〔사례〕 _1. Lint를 이용한 코드 스타일 규칙 설정 _2. 팀 내 코딩 스타일 규칙 문서화 _3. 정적 분석 도구의 활용 _4. 버전 관리 시스템 사용 규칙 3. 테스팅 전략 _〔사례〕 _1. 테스트 장점 _2. 테스트 유형 _3. 테스트 조건 _4. 테스트 전략 4. 그 외 실천항목 _〔사례〕 _1. 제약조건 실천하기 _2. 중간 점검 _3. 작업 공유 Chapter 4_ 〔이슈〕 위기를 기회로1. 운영이슈_〔사례〕 _1. 기능 개선 및 추가 개발에 대한 협의 _2. 효율적인 운영이슈 처리 방법 _3. 장애 대응 2. 기술이슈 _〔사례〕 _1. 기술이슈에 대한 대응 자세 _2. 기술이슈를 해결하기 위한 전략 3. 작업 생산성 _〔사례〕 _1. 생산성에 영향을 미치는 요인들 _2. 생산성을 높이기 위한 노력 4. 이슈 공유 _〔사례〕 _1. 협업 관리도구 활용 _2. 문서 활용 _3. 정기 회의 활용 Chapter 5_ 〔종료〕 하얗게 불태웠어1. QA 준비 _〔사례〕 _1. QA란 무엇인가 _2. QA를 위한 준비사항 2. 테스트 케이스 _〔사례〕 _1. 테스트 케이스 설계 3. 배포 _〔사례〕 _1. 배포 전 확인 항목들 Chapter 6_ 〔회고〕 회고합시다1. 회고를 위한 사전 계획 _〔사례〕 _1. 작업 관리 _2. 회고 주기 _3. 사건 기록 2. 좀 더 유익한 회고를 위하여 _〔사례〕 _1. 5F _2. KPT _3. AAR _4. YWT _5. 4L _6. 진행자의 역할 _7. 데이터 활용 _8. 피드백 Chapter 7_ 〔Q&A〕 후일담1. 언어전환 프로젝트를 시작하게된 계기가 무엇인가요 2. 진행한 언어전환 프로젝트는 성공했다고 생각하나요 3. 언어전환 프로젝트의 목표는 무엇이었나요 4. 다른 개발자들에게 언어전환 프로젝트를 추천할 건가요 5. 언어전환 프로젝트 진행 중 기억나는 에피소드가 있나요 6. 언어전환 프로젝트와 제품 개발 프로젝트의 차이를 느꼈나요 7. QA 과정에서 발생한 버그 이슈 중 기억에 남는 이슈가 있나요 8. 가장 뿌듯했던 순간이 언제인가요 9. 회사나 다른 팀에서 보는 언어전환 프로젝트는 어떤 것인가요 10. 왜 코틀린과 스프링인가요 33611. 언어전환 전후 프로젝트 진행의 차이점이 있나요 12. 만약에 프로젝트가 실패했다면 어떤 이유 때문일까요 13. 이 내용을 책으로 소개하게된 계기가 무엇인가요 찾아보기
|
|
현재 서비스 중인 코드를 바꾸고 싶은 적이 있나요?기존의 서버 코드를 대대적으로 고치고 싶을 때백엔드 서버는 어떻게 만들어지는지 알고 싶을 때대규모 프로젝트를 성공시키고자 할 때코드가 유지보수가 어려울 정도로 복잡하게 짜여 있거나 개발자가 적어 채용시장에서 개발인력 보충이 어려운 상황이거나, 자사 제품에 적합한 기능 또는 솔루션을 좀 더 손쉬운 방법으로 제공해 주는 언어가 필요할 때, 현재 서비스 중인 코드의 언어를 바꾸고 싶어합니다. 서비스 중인 코드의 언어를 바꾸고 싶은 개발자를 위해, 가상의 사례를 통해 어떻게 언어 전환을 계획하고 진행하는지 가이드를 제공해주는 책입니다.론칭한 지 2년 정도 지난 A 스타트업의 서비스. 제품의 서비스 성장을 위해 기능을 대폭 개선하고자 한다. 개발자는 10명 내외이며, 백엔드 개발자는 파트장 포함 4명 PO, PD, 프론트엔드, 안드로이드, QA 엔지니어 등이 있다. 이들은 서버 언어 전환 프로젝트를 성공할 수 있을까?_주요 내용_〔배경〕 언어전환이 필요하다 레거시와 생활하기 / 전환의 이유 찾기 / 설득하기_〔준비〕 지피지기면 백전불태 프로젝트 로드맵 작성하기 / 전환 전략 수립과 도메인 파악 API 정리와 기술 선정 / 패키지 구조 선정과 작업 생성_〔과정〕 묻고 더블로 가! 프로젝트 환경설정 / 코드 기여 규칙 설정 및 테스팅 전략 그외 실천항목_〔이슈〕 위기를 기회로 운영 이유, 기술 이슈 / 작업 생산성과 이슈 공유_〔종료〕 하얗게 불태웠어 QA 준비 / 테스트케이스 및 배포_〔회고〕 회고합시다_대상 독자개발자들은 언제나 크든 작든 필요에 의해 수많은 프로젝트를 진행한다. 팀의 결정으로 때론 개발자가 능동적으로 적극 설득(?)하여 프로젝트를 만들고 완수해야 하는 게 모든 개발자들의 숙명이자 업(일)이다. 이 책은 “서비스 중인 코드를 바꿔보자”라는 미션으로 시작된 프로젝트이기는 하지만, 개발 현장에서 일어나는 모든 프로젝트의 진행 방식과 크게 다르지 않다. 그래서, 이 책의 독자는 적어도 주니어의 티(?)를 벗은 개발자가 보면 많은 도움을 받을 것이다.
|