Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

텀 프로젝트에서 제품 프로젝트로 - 성준영님

제 6회 D2 CAMPUS SEMINAR

  • Be the first to comment

텀 프로젝트에서 제품 프로젝트로 - 성준영님

  1. 1. 텀 프로젝트에서 제품 프로젝트로 6개월간의 현업 경험담 경희대학교 성준영
  2. 2. 발표자 소개 성준영 경희대학교 컴퓨터 공학과 3학년 T.G.WinG Nomadstar 서버개발 인턴 wnsdud1861@gmail.com
  3. 3. 0_ 발표자 소개 1_ 개요 스타트업 인턴으로 맡은 포지션 거쳐간 업무들 2_ 현업 경험담 6개월의 타임라인 AWS 서버이전 > 컨퍼런스와 문서화 AWS Lambda > 코드리뷰와 리펙토링 REST API 설계 > 좋은 설계 3_ 정리 경험과 교훈의 요약 입사 전과 비교해본 나 결론 목차
  4. 4. 개요 > 스타트업 인턴으로 맡은 포지션 쓰담 (Beta) 솔직한 사용자 후기를 이용하여, 반려 동물의 특성에 딱 맞는 제품을 찾을 수 있도록 돕는 반려동물 제품 리뷰 SNS 어플리케이션 (Adroid) 1.1
  5. 5. 쓰담 서비스의 서버 관리 및 백엔드 API, 데이터베이스 작성과 설계 1.1 개요 > 스타트업 인턴으로 맡은 포지션
  6. 6. 개요 > 거쳐간 업무들 AWS Lambda Dynamodb 이미지 포맷 변경 REST API 1.2 관리자 페이지 쓰담 홈페이지 AWS 서버이전 이미지 압축 및 리사이징
  7. 7. 1.2 AWS Lambda Dynamodb 이미지 포맷 변경 REST API 관리자 페이지 쓰담 홈페이지 AWS 서버이전 이미지 압축 및 리사이징 개요 > 거쳐간 업무들
  8. 8. 1.2 가장 많은 것을 배우고 느꼈던 세가지 경험을 여러분과 공유하려 합니다. 개요 > 거쳐간 업무들 AWS 서버이전 > 컨퍼런스와 문서화 AWS Lambda > 코드리뷰와 리펙토링 REST API > 좋은 설계
  9. 9. 현업 경험담 > 6개월의 타임라인2.1 관리자 페이지 AWS 서버이전 홈페이지 이미지 압축 및 리사이징 AWS Lambda 이전 시작 ( ~ 현재 ) 이미지 포맷 변경 REST API ( ~ 현재 ) 16.09 16.12 17.02 dynamodb 버전 1.0 개발
  10. 10. 현업 경험담 > AWS 서버이전 > AWS 란?2.2 컴퓨팅 서버, 스토리지, 데이터베이스, 네트워크 등 웹 서비스에 필요한 모든 서비스를 제공하는 세계 1위 클라우드 서비스 플랫폼
  11. 11. 현업 경험담 > AWS 서버이전 > AWS Summit Seoul2.2 입사 전 (16.5.17) 참관했던 코엑스에서 열린 AWS 컨퍼런스 AWS 임직원과 전문가들의 강연 파트너 솔루션 전시 임원 초청 행사
  12. 12. 현업 경험담 > AWS 서버이전 > AWS Summit Seoul2.2 입사 전 (16.5.17) 참관했던 코엑스에서 열린 AWS 컨퍼런스 AWS 임직원과 전문가들의 강연 파트너 솔루션 전시 임원 초청 행사 멍때리며 들은 멍때리며 본 멍때리며 박수친
  13. 13. 현업 경험담 > AWS 서버이전 > 왜?2.2 국내 클라우드 서비스에서 아마존 웹 서비스로 이전 왜?
  14. 14. 2.2 SNS의 특성상 이미지가 많고, 파일이 계속 늘어남에 따라 고가용성의 이미지 서버가 필요 AWS 이전의 이유 첫번째 Image Server IMAGE FILES 현업 경험담 > AWS 서버이전 > 왜?
  15. 15. 2.2 AWS S3 무한대에 가까운 스토리지 제공 여러 물리적 저장소에 대한 중복 저장으로, 99.999999999% 내구성과 99.99%의 가용성 보장 AWS 이전의 이유 첫번째 S3 IMAGE FILES … 현업 경험담 > AWS 서버이전 > 왜?
  16. 16. 2.2 트래픽에 비해 지나친 스펙의 서버, 비용절감의 필요성 AWS 이전의 이유 두번째 트 래 픽 낭비되는 영역 Before 현업 경험담 > AWS 서버이전 > 왜?
  17. 17. 2.2 AWS 이전의 이유 두번째 간단한 절차만으로 서버를 늘렸다 줄이는 오토 스케일링이 가능 트 래 픽 절약되는 영역 Before After 인 스 턴 스 갯 수 현업 경험담 > AWS 서버이전 > 왜?
  18. 18. 2.2 단일 서버 구성으로 인해 서버 장애발생 시 모든 서비스의 마비 가능성 AWS 이전의 이유 세번째 SERVER API DATA BASE IMAGE STORAGE CLIENT 현업 경험담 > AWS 서버이전 > 왜?
  19. 19. 2.2 단일 서버 구성으로 인해 서버 장애발생 시 모든 서비스의 마비 가능성 AWS 이전의 이유 세번째 SERVER API DATA BASE IMAGE STORAGE CLIENT 현업 경험담 > AWS 서버이전 > 왜?
  20. 20. 2.2 ELB (Elastic Load Balancing) 자동 부하분산 시스템으로, 주기적인 서버 상태를 체크하여 자동 트래픽 분산 AWS 이전의 이유 세번째 SERVER API DATA BASE IMAGE STORAGE CLIENT SERVER API DATA BASE IMAGE STORAGE 현업 경험담 > AWS 서버이전 > 왜?
  21. 21. 2.2 ELB (Elastic Load Balancing) 자동 부하분산 시스템으로, 주기적인 서버 상태를 체크하여 자동 트래픽 분산 AWS 이전의 이유 세번째 SERVER API DATA BASE IMAGE STORAGE CLIENT SERVER API DATA BASE IMAGE STORAGE 현업 경험담 > AWS 서버이전 > 왜?
  22. 22. 현업 경험담 > AWS 서버이전 > API EC2 이전2.2 AWS 에 첫 발을 딛은 기존 국내 클라우드 서버에 있던 API 들을 EC2 인스턴스로 이전하는 작업 API EC2 Instance API
  23. 23. 현업 경험담 > AWS 서버이전 > API EC2 이전2.2 AWS EC2 (Amazon Elastic Compute Cloud) 가상 컴퓨터 환경을 제공하는 인스턴스, 머신 이미지를 제공하는 AMI, 스토리지 볼륨인 EBS 등을 포함하는 서비스
  24. 24. 현업 경험담 > AWS 서버이전 > API EC2 이전2.2 API를 옮기고 테스트 중, 푸시 메시지가 클라이언트로 전송 되지 않는 현상을 발견 EC2 Instance API ??? PUSH
  25. 25. 현업 경험담 > AWS 서버이전 > API EC2 이전2.2 푸시 데이터를 쌓긴 하는데… PUSH DATA
  26. 26. 현업 경험담 > AWS 서버이전 > API EC2 이전2.2 쌓아놓은 푸시를 클라이언트 기기로 보내주는 코드가 없음 ?
  27. 27. 현업 경험담 > AWS 서버이전 > API EC2 이전2.2 ?????? ?
  28. 28. 현업 경험담 > AWS 서버이전 > API EC2 이전2.2 API 1. 푸시상황이 되면 푸시 데이터를 쌓는다. 2. ? 3. 성공 후 비운다.
  29. 29. 현업 경험담 > AWS 서버이전 > API EC2 이전2.2 API 1. 푸시상황이 되면 푸시 데이터를 쌓는다. 2. Shell Script 를 cron 으로 반복한다. 3. 성공 후 비운다.
  30. 30. 현업 경험담 > AWS 서버이전 > API EC2 이전2.2 리눅스 작업 스케줄러인 cron 으로 쉘스크립트를 1분 간격으로 계속 호출하고 있었던 것 * * * * * /path/push_fcm.sh
  31. 31. 현업 경험담 > AWS 서버이전 > API EC2 이전2.2 /* * 푸시 전송 : /path/push_fcm.sh * crontab 1분에 1회 반복합니다. */ API 코드 내 주석 혹은 문서만 있었다면 크게 줄어들었을 작업시간…
  32. 32. 현업 경험담 > AWS 서버이전 > API EC2 이전2.2 다음 개발자가 이런 일로 고생할 일이 없도록 코드로는 이해못할 부분에 대한 문서화와 주석
  33. 33. 현업 경험담 > AWS 서버이전 > AWS 아키텍처2.2 EC2 로 서버도 만들어봤는데! 이왕 AWS 를 쓸거, AWS 를 최대한 활용하여 백엔드를 구축해 보자! 클라우드 데이터베이스 서비스인 RDS 활용과 AWS 아키텍처의 구성
  34. 34. 현업 경험담 > AWS 서버이전 > AWS 아키텍처2.2 그러나 너무 많은 서비스들 아키텍처는 고사하고 뭔지도 모르겠는데요..
  35. 35. 현업 경험담 > AWS 서버이전 > AWS 아키텍처2.2 그때 기억난 멍때리며 들었던 윤석찬님의 “AWS 클라우드로 천만명 웹서비스 확장하기”세션
  36. 36. 현업 경험담 > AWS 서버이전 > AWS 아키텍처2.2 당시의 발표 자료와 영상을 찾아 프레젠테이션을 참고하며 따라해보기 시작 http://www.slideshare.net/awskorea/your-first-10-million-customer-web-service-on-aws-channy-yun
  37. 37. 현업 경험담 > AWS 서버이전 > AWS 아키텍처2.2 완성된 초기 쓰담 서비스의 AWS 아키텍처
  38. 38. 현업 경험담 > AWS 서버이전 > AWS 아키텍처2.2 컨퍼런스에서 들은 내용을 바탕으로 실제 서비스의 적용까지
  39. 39. 현업 경험담 > AWS 서버이전 > 느낀 점2.2 문서화 개발자 컨퍼런스
  40. 40. 현업 경험담 > AWS 서버이전 > 느낀 점2.2 문서화 실제로 고생을 해 보고 중요성을 실감 앞으로 짜게될 코드에 대한 똑똑한 주석과 문서화의 필요성
  41. 41. 현업 경험담 > AWS 서버이전 > 느낀 점2.2 개발자 컨퍼런스 컨퍼런스를 통한 잠재 지식의 확대와 최신 트랜드 파악 나아가 프로젝트에의 적용
  42. 42. EC2 인스턴스 에서 Lambda 로 Backend API 전환 현업 경험담 > AWS Lambda > AWS Lambda 로의 이전결정2.3
  43. 43. 현업 경험담 > AWS Lambda > AWS Lambda 로의 이전결정2.3 Beta 에서 정식 버전으로 가면서 대대적인 기획안 변경
  44. 44. 현업 경험담 > AWS Lambda > AWS Lambda 로의 이전결정2.3 Beta 에서 정식 버전으로 가면서 대대적인 기획안 변경 에 따른 대대적인 백엔드 API 변경
  45. 45. 현업 경험담 > AWS Lambda > AWS Lambda 로의 이전결정2.3 백엔드, 갈아엎자! EC2 에서 Lambda 로 PHP 에서 node.js 로 RDS 에서 dynamodb 로
  46. 46. 현업 경험담 > AWS Lambda > AWS Lambda 란?2.3 AWS Lambda 2014년 발표된, 특정한 이벤트에 응답하여 실행되는, 자동으로 컴퓨팅 리소스를 관리하는 서버리스 컴퓨팅 시스템
  47. 47. API Gateway 를 통해 URI, method 와 연결하거나, S3 / Dynamodb 등 AWS 리소스의 특정 트리거와 연결해 호출가능 Lambda node.js Hello World 예제 현업 경험담 > AWS Lambda > AWS Lambda 란?2.3 exports.handler = function(event, context) { context.succeed('Hello World'); }
  48. 48. 현업 경험담 > AWS Lambda > Lambda 를 사용한 이유2.3 Lambda 사용의 이유 첫번째 초기 버전의 난항으로 인한 잦은 백엔드 변경사항 발생으로 스케일링 관리와 배포의 번거로움
  49. 49. 2.3 Lambda 사용의 이유 첫번째 > 스케일링 관리와 배포의 번거로움 오토스케일링 필요한 소프트웨어가 이미 구성되어 있는 인스턴스 템플릿인 AMI (Amazon Machine Image) 로 Launch config 를 만들고, 오토 스케일링 그룹 설정 AMI AutoScaling Launch Config AutoScaling Group V1 V1 현업 경험담 > AWS Lambda > Lambda 를 사용한 이유
  50. 50. 2.3 서버를 배포할 때, 업데이트된 인스턴스로부터 AMI 를 업데이트하고, Launch Config를 재설정하는 과정 필요 배포의 자동화가 이루어지지 않은 상태의 번거로운 작업 AutoScaling Launch Config AutoScaling Group V2 V2 V2 Lambda 사용의 이유 첫번째 > 스케일링 관리와 배포의 번거로움 현업 경험담 > AWS Lambda > Lambda 를 사용한 이유
  51. 51. 2.3 Lambda 사용의 이유 첫번째 서버의 운영과 관리 (스케일링, 모니터링, 보안, 코드배포..) 는 AWS 에서 수행해 주므로 별도의 번거로운 서버작업이 필요없어짐 현업 경험담 > AWS Lambda > Lambda 를 사용한 이유
  52. 52. 2.3 Lambda 사용의 이유 두번째 사수님 曰, “재밌겠다. 해보자, 스타트업이잖아." 현업 경험담 > AWS Lambda > Lambda 를 사용한 이유
  53. 53. 2.3 Lambda 사용의 이유 두번째 사수님 曰, “재밌겠다. 해보자, 스타트업이잖아." 현업 경험담 > AWS Lambda > Lambda 를 사용한 이유
  54. 54. 2.3 Lambda 사용의 이유 세번째 node.js 로 작성하고 API-Gateway로 묶은 이벤트 기반의 Lambda Function들은 Roopback, restify 등 REST API 프레임워크로 쉬운 이전이 가능 현업 경험담 > AWS Lambda > Lambda 를 사용한 이유
  55. 55. 2.3 Lambda 사용의 이유 세번째 Lambda 의 한정된 Timeout 과 Memory에 한계가 보인다면. 언제든지 REST 기반 프레임워크로 이전 > 부담없는 시작 현업 경험담 > AWS Lambda > Lambda 를 사용한 이유
  56. 56. 현업 경험담 > AWS Lambda > PHP to node.js2.3 Lambda function 언어 결정 부담없는 시작 npm 의 모든 패키지가 사용가능 Lambda 관련 라이브러리가 가장 활성화
  57. 57. 현업 경험담 > AWS Lambda > PHP to node.js2.3 PHP 에서 node.js로 모든 API 의 변경
  58. 58. 현업 경험담 > AWS Lambda > PHP to node.js2.3 node.js 로 API를 변경하며 겪었던 난항 진행할수록 가독성 떨어지는 코드 1. 이미지 버퍼를 받는다. 2. 원본을 저장한다. 3. 이미지를 리사이징한다. 4. 리사이징된 이미지를 저장한다. 받은 이미지를 리사이징 후 저장
  59. 59. 현업 경험담 > AWS Lambda > PHP to node.js2.3 <?php .. // 원본을 저장한다. saveOriginalImage($image); // 이미지를 리사이징해 용량을 줄인다. $resizedImage = resizeImage($image); // 리사이징한 이미지를 저장한다. saveResizedImage($resizedImage); .. ?>
  60. 60. 현업 경험담 > AWS Lambda > PHP to node.js2.3 이벤트 기반 / 비동기 / 콜백 .... 나도 대충 알아! 짤수 있다! node.js 로 API를 변경하며 겪었던 난항 진행할수록 가독성 떨어지는 코드
  61. 61. saveOriginalImage(image, function(err, savedImage) { if (err) return '원본이미지 저장 에러'; else { } }) 현업 경험담 > AWS Lambda > PHP to node.js2.3 원본 이미지의 저장이 성공하면 콜백의 결과를 받아서 이미지를 압축하고...
  62. 62. saveOriginalImage(image, function(err, savedImage) { if (err) return '원본이미지 저장 에러'; else { resizeImage(savedImage, function(err, resizedImage) { if (err) return '이미지 리사이징 에러'; else { saveResizedImage(resizedImage, result){ if (err) return ’리사이징 된 이미지 저장 에러'; else { return '성공'; } } } }) } }) 현업 경험담 > AWS Lambda > PHP to node.js2.3
  63. 63. 현업 경험담 > AWS Lambda > PHP to node.js2.3 saveOriginalImage(image, function(err, savedImage) { if (err) return '원본이미지 저장 에러'; else { resizeImage(savedImage, function(err, resizedImage) { if (err) return '이미지 리사이징 에러'; else { saveResizedImage(resizedImage, result){ if (err) return ’리사이징 된 이미지 저장 에러'; else { return '성공'; } } } }) } }) ???
  64. 64. 현업 경험담 > AWS Lambda > PHP to node.js2.3 saveOriginalImage(image, function(err, result) { if (err) return '원본이미지 저장 에러'; else { resizeImage(result, function(err, resizedImage) { if (err) return '이미지 리사이징 에러'; else { saveResizedImage(resizedImage, result){ if (err) return ’리사이징 된 이미지 저장 에러'; else { somefunction1(result, function(err, result) { if (err) return ’이런 에러'; else { somefunction2(result, function(err, result){ if (err) return ’저런 에러'; else { somefunction3(result, function(err, result){ if (err) return ’요런 에러'; else { ???????
  65. 65. 현업 경험담 > AWS Lambda > PHP to node.js2.3 점점 읽기 힘들어지는 코드들 Callback Hell node.js 로 API를 변경하며 겪었던 난항 진행할수록 가독성 떨어지는 코드
  66. 66. 현업 경험담 > AWS Lambda > PHP to node.js2.3 https://cnodejs.org/topic/570fb6a40a1e9da252f1e310 http://thecodebarbarian.com/2015/03/20/callback-hell-is-a-myth node.js 로 API를 변경하며 겪었던 난항 진행할수록 가독성 떨어지는 코드
  67. 67. 현업 경험담 > AWS Lambda > PHP to node.js2.3 그렇게 우여곡절 끝에 로그인 API 완성
  68. 68. 현업 경험담 > AWS Lambda > 코드리뷰와 리펙토링2.3 “코드리뷰 한번 해볼까요?” 네?
  69. 69. 현업 경험담 > AWS Lambda > 코드리뷰와 리펙토링2.3 “코드리뷰 한번 해볼까요?” 내 코드를 보여주는 것에 두려움과 부끄러움
  70. 70. 현업 경험담 > AWS Lambda > 코드리뷰와 리펙토링2.3 단일 Lambda 함수에 대한 코드리뷰 진행 node.js 에서 알아두면 좋을 패턴에 대한 소개 효율적인 코드를 위한 토론 좋은 라이브러리의 제안 잘못된 코드에 대한 지적
  71. 71. 현업 경험담 > AWS Lambda > 코드리뷰와 리펙토링2.3 단일 Lambda 함수에 대한 코드리뷰 진행 Callback Hell을 해결할 수 있는 Promise 라는 패턴이 있어요. Array.some 메서드를 쓰면 코드가 좀 더 간결해 지지 않을까요? 이미지를 다룰때 Imagemagick 도 좋지만, sharp 도 한번 찾아보세요! 여기서 === 연산자를 쓰지 않으면 문제 발생의 가능성이 있어요.
  72. 72. 현업 경험담 > AWS Lambda > 코드리뷰와 리펙토링2.3 수 번의 리펙토링과 리뷰 반복 코드리뷰로 얻은 결과를 통해
  73. 73. 현업 경험담 > AWS Lambda > 코드리뷰와 리펙토링2.3 코드리뷰로와 리펙토링으로 변경된 Promise 패턴과 Arrow function 의 사용 saveOriginalImage(image, function(err, savedImage) { if (err) return '원본이미지 저장 에러'; else { resizeImage(savedImage, function(err, resizedImage) { if (err) return '이미지 리사이징 에러'; else { saveResizedImage(resizedImage, result){ if (err) return ’리사이징 된 이미지 저장 에러'; else { return '성공'; } } } }) } }) 코드의 규모가 커질수록 콜백의 중첩으로 순차적인 작업 진행 시 가독성이 매우 떨어지는 코드에서,
  74. 74. 현업 경험담 > AWS Lambda > 코드리뷰와 리펙토링2.3 saveOriginalImage(image) .then(function(savedImage){ return resizeImage(savedImage); }) .then(function(resizedImage){ return saveResizedImage(resizedImage); }) .then(function(result){ return '성공'; })) .catch(function(err){ return err; }) Promise 패턴의 적용으로 한결 간결해진 코드
  75. 75. 현업 경험담 > AWS Lambda > 코드리뷰와 리펙토링2.3 ECMA 6 Arrow function 의 적용과 축약한 통용 단어의 사용으로 더욱 직관적이고 간결해진 코드 코드리뷰로와 리펙토링으로 변경된 Promise 패턴과 Arrow function 의 사용 saveOrigImg(img) .then(savedImg => resizeImg(savedImg)) .then(resizedImg => saveResizedImg(resizedImg)) .then(result => '성공') .catch(err => err);
  76. 76. 현업 경험담 > AWS Lambda > 느낀점2.3 코드 리뷰와 리펙토링 남이보는 내 코드에 대한 두려움을 버리고 동료 프로그래머와의 페어 프로그래밍 혹은 코드리뷰로 결함의 감소와 품질 향상, 나아가 성장
  77. 77. 현업 경험담 > REST API > REST API 란?2.4 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개, 웹의 장점을 최대한 활용할 수 있는 아키텍처 URI 와 HTTP Method 를 이용해 API 를 만드는 것 RESTGET / POST / PUT / DELETE
  78. 78. 현업 경험담 > REST API > REST API 란?2.4 첫 번째, URI는 Resource(자원)를 표현한다. 두 번째, Resource 에 대한 행위는 HTTP Method로 표현한다. POST : Create GET : Read PUT : Update DELETE : Delete RESTful API
  79. 79. 현업 경험담 > REST API > REST API 란?2.4 첫 번째, URI는 Resource(자원)를 표현한다. 두 번째, Resource 에 대한 행위는 HTTP Method로 표현한다. 설계 방법론에 대한 많은 책들이 존재하지만, 정해진 룰은 없음 하지만.. RESTful API
  80. 80. 현업 경험담 > REST API > 기존 API의 수정 경험2.4 리뷰, 이야기, 이벤트만 존재하던 탭 페이스북 페이지의 반려동물 팁 컨텐츠의 증가에 따라, 앱 내에서도 컨텐츠를 볼 수 있도록 매거진 탭의 추가와 댓글에 댓글을 달아달라는 많은 사용자의 요구에 따른 댓글의 댓글 기능 기능 추가 기능 추가 요청
  81. 81. 현업 경험담 > REST API > 기존 API의 수정 경험2.4 기존 API 의 URI 구성 _ Default Codeigniter 기능 추가 요청 https://Base_url/review/write CI_Controller 를 상속받는 클래스명에 대응
  82. 82. 현업 경험담 > REST API > 기존 API의 수정 경험2.4 기존 API 의 URI 구성 _ Default Codeigniter 기능 추가 요청 https://Base_url/review/write 클래스 내의 메서드명에 대응
  83. 83. 현업 경험담 > REST API > 기존 API의 수정 경험2.4 기존 API 의 URI 구성 _ Default Codeigniter 기능 추가 요청 https://Base_url/review/write 클래스 내의 메서드명에 대응
  84. 84. 현업 경험담 > REST API > 기존 API의 수정 경험2.4 기존 API 의 URI 구성 _ 리뷰 https://Base_url/review/write https://Base_url/review/update https://Base_url/review/delete https://Base_url/review/list https://Base_url/review/detail 기능 추가 요청
  85. 85. 현업 경험담 > REST API > 기존 API의 수정 경험2.4 기존 API 의 URI 구성 _ 리뷰 https://Base_url/review/write https://Base_url/review/update https://Base_url/review/delete https://Base_url/review/list https://Base_url/review/detail https://Base_url/review_comment/write https://Base_url/review_comment/update https://Base_url/review_comment/delete https://Base_url/review_comment/list 기능 추가 요청
  86. 86. 현업 경험담 > REST API > 기존 API의 수정 경험2.4 https://Base_url/story/write https://Base_url/story/update https://Base_url/story/delete https://Base_url/story/list https://Base_url/story/detail https://Base_url/story_comment/write https://Base_url/story_comment/update https://Base_url/story_comment/delete https://Base_url/story_comment/list 기존 API 의 URI 구성 _ 스토리 기능 추가 요청
  87. 87. 현업 경험담 > REST API > 기존 API의 수정 경험2.4 매거진의 추가? 기능 추가 요청 https://Base_url/magazine/write https://Base_url/magazine/update https://Base_url/magazine/delete https://Base_url/magazine/list https://Base_url/magazine/detail https://Base_url/magazine_comment/write https://Base_url/magazine_comment/update https://Base_url/magazine_comment/delete https://Base_url/magazine_comment/list 너무 많은 코드의 중복과 불필요한 작업의 증가
  88. 88. 현업 경험담 > REST API > 기존 API의 수정 경험2.4 댓글의 댓글 기능? 기능 추가 요청 많은 방법을 생각해 봤으나 구현 후 더이상의 유지보수 및 기능추가는 NAVER...
  89. 89. 현업 경험담 > REST API > API 의 재설계2.4 HTTP 는 서버와 클라이언트의 정보를 주고받기 위해 약속된 통신 규약 (프로토콜) 기존 API 설계의 문제점 파악 첫번째 POST : Create GET : Read PUT : Update DELETE : Delete
  90. 90. 현업 경험담 > REST API > API 의 재설계2.4 HTTP 프로토콜을 무시한 Method 리소스에 대한 행위를 표현하지 않고 무의미한 사용 https://Base_url/story/write https://Base_url/story/update https://Base_url/story/delete https://Base_url/story/list https://Base_url/story/detail POST POST POST GET GET 기존 API 설계의 문제점 파악 첫번째
  91. 91. 현업 경험담 > REST API > API 의 재설계2.4 HTTP 프로토콜을 준수하며 HTTP 메소드로 리소스에 대한 행위를 표현하도록 https://Base_url/story/write https://Base_url/story/update https://Base_url/story/delete https://Base_url/story/list https://Base_url/story/detail POST POST POST GET GET 스토리 작성 특정 스토리 업데이트 특정 스토리 삭제 스토리 리스트 불러오기 특정 스토리 불러오기 CREATE UPDATE DELETE READ READ 기존 API 설계의 문제점 파악 첫번째 _ 재설계
  92. 92. 현업 경험담 > REST API > API 의 재설계2.4 HTTP 프로토콜을 준수하며 HTTP 메소드로 리소스에 대한 행위를 표현하도록 https://Base_url/stories https://Base_url/stories/{story_id} https://Base_url/stories/{story_id} https://Base_url/stories https://Base_url/stories/{story_id} POST PUT DELTE GET GET 스토리 작성 특정 스토리 업데이트 특정 스토리 삭제 스토리 리스트 불러오기 특정 스토리 불러오기 CREATE UPDATE DELETE READ READ 기존 API 설계의 문제점 파악 첫번째 _ 재설계
  93. 93. 현업 경험담 > REST API > API 의 재설계2.4 리소스간의 관계가 무의미한 설계로 URL과 Method로는 API 파악의 어려움 기존 API 설계의 문제점 파악 두번째 https://Base_url/story_comment/write 댓글은 이야기의 하위 리소스이지만 분리되어 작성된 URL 어떤 스토리의 댓글을 쓰기 위한 API 인지 알기 위해서는, 서버에서 요구하는 parameter의 story_id 를 알아야 함 POST 무의미
  94. 94. 현업 경험담 > REST API > API 의 재설계2.4 리소스간의 관계파악으로 URL 과 Method 로 어떤 API 인지 파악가능하도록 기존 API 설계의 문제점 파악 두번째 _ 재설계 https://Base_url/stories/{story_id}/comments/{comment_id} {story_id} 스토리의 {comment_id} 댓글을 수정하는 API 이구나! PUT https://Base_url/stories/{story_id}/comments GET {story_id} 스토리의 모든 댓글들을 가져오는 API 이구나!
  95. 95. 현업 경험담 > REST API > API 의 재설계2.4 기존 API 설계의 문제점 파악 세번째 story review event story_comment review_comment event_comment 리소스간의 관계가 무의미한 설계로 지나친 코드의 중복으로 인한 유지보수의 어려움
  96. 96. 현업 경험담 > REST API > API 의 재설계2.4 기존 API 설계의 문제점 파악 세번째 _ 재설계 리소스간의 관계파악 후 소스코드의 설계로 유지보수가 쉽고, 확장성 있는 코드의 작성 story comment review event sub_commet
  97. 97. 현업 경험담 > REST API > 느낀 점2.4 설계와 분석 처음 피부에 와닿도록 느낀 시스템 분석에 따른 좋은 설계의 중요성
  98. 98. 정리 > 요약 >3.1 문서화 개발자 컨퍼런스 코드 리뷰와 리펙토링 설계와 분석
  99. 99. 정리 > 입사 전과 비교해본 나 >3.2 문서화 개발자 컨퍼런스 코드 리뷰와 리펙토링 설계와 분석 항상 듣던 너무 당연한,
  100. 100. 정리 > 입사 전과 비교해본 나 >3.2 문서화 개발자 컨퍼런스 코드 리뷰와 리펙토링 설계와 분석 항상 듣던 너무 당연한, 하지만 추상적이고 머리에 떠다니던 개념들
  101. 101. 정리 > 입사 전과 비교해본 나 >3.2 문서화 개발자 컨퍼런스 코드 리뷰와 리펙토링 설계와 분석 AWS 로 서버이전을 하면서,
  102. 102. 정리 > 입사 전과 비교해본 나 >3.2 문서화 개발자 컨퍼런스 설계와 분석 경험이 없었던 node.js 로 API를 옮기면서 코드 리뷰와 리펙토링
  103. 103. 정리 > 입사 전과 비교해본 나 >3.2 문서화 개발자 컨퍼런스 기존 서버의 유지보수와 새로운 API 설계를 맡으면서 코드 리뷰와 리펙토링 설계와 분석
  104. 104. 정리 > 입사 전과 비교해본 나 >3.2 현업을 겪으며 다시금 생각하게 된 ‘당연한 이야기들’
  105. 105. 정리 > 결론 >3.3 모자른 발표로나마 간접경험을 통해 함께 성장하는 개발자가 되었으면 좋겠습니다 :)
  106. 106. 경청해주셔서 감사합니다 :D

×