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.

웹 Front-End 실무 이야기

41,121 views

Published on

프론트엔드와 실무 경험담을 위주로 설명한 프레젠테이션입니다.

Published in: Internet

웹 Front-End 실무 이야기

  1. 1. 웹 FRONT-END 
 실무 이야기 NAVER
 이진권 lee.jinkwon@navercorp.com
  2. 2. 짧게나마, 
 실무 이야기 전에 FE에 대한 이야기를 
 먼저 할까 합니다.
  3. 3. 대부분이 생각하시는
 FRONT-END 개발은, CSS 를 작성하고,
 HTML 을 작성하고,
 Javascript를 작성해서, 
 사용자 웹페이지를 만듭니다.
  4. 4. FRONT-END?
  5. 5. 이런 일을 하는 
 사람들이 맞습니다. 난이도가 어렵지 않다고 생각하는 사람들도 많구요.
 
 그리고,
  6. 6. 대다수의 프로젝트에는,
 FE 개발자가 필요하지 않습니다.
  7. 7. 페이지에 넣을 인라인 스크립트 작성
 (파일 분리 필요 없는 정적 페이지 개발) 폼 유효성 검사 재사용이 필요 없는 View 코드 작성 공통 모듈 (jindo/query)로만 페이지 개발 이 가능할 때
  8. 8. 서버 개발자 분들이 하셔도 되요 대부분의 스펙은 서버 개발자가 개발해도 충분
 (더불어 엄청 잘하세요) 화면 동작만 잘 하면 됩니다 View 단은 금방 고칠 수 있어요
  9. 9. 모바일은 JMC만 있으면 
 거의 다 구현 됩니다. 플리킹 스크롤
  10. 10. 요새 풀스택 개발자들은 
 다 할 수 있어요 연봉 1억짜리 풀스택 개발자를 고용했으니, 
 다 잘 할 수 있을꺼에요. 일정은 변경할 수 없으니 2달 안에 끝내죠. 아마 다 잘 될꺼에요.
 근데 최신 브라우저에서만.
  11. 11. 사실, 우리에게 FE 개발자가 
 필요한 이유는,
 저희가 주로 받는 요청 사항에 들어 있습니다.
  12. 12. 크로스 브라우저 대응 아래 브라우저에서 모두 잘 동작하게 해주세요. 
 IE6, 7은 동작은 다 안되도 화면 깨지지 않게 해주세요. Internet Explorer (6, 7) 8, 9, 10, 11
 Firefox
 Chrome
 Safari
 Another Browser coming soon (Spartan)
  13. 13. 멀티 모바일 디바이스 대응 모바일의 아래 브라우저에서는 당연히 잘 동작해야 해요.
 4층에 테스트 실이 있으니까 거기 가서 테스트 하고 오세요. iOS Safari iOS Naver App Browser Android OS Version 2.3, 3, 4, 5 Samsung, App Browser, Mobile Chrome Android Mobile Chrome + System WebKit
  14. 14. 기획/디자인과 합의점 찾기 웹으로 다 구현 가능한거 아니에요?
 어떤 사이트 보니까 잘 되던데. 우리 최소 대응 스펙은 진저브레드 인데요, 
 정말 멋진 UX를 구현하고 싶어요. 
 근데 오픈 일은 2주 남았어요. 될까요? 이 스펙으로 전체 커버리지는 이런 문제가 있어요. 
 성능 최대한 고려해서, 이 커버리지로 구현하겠습니다.
 IE 8~, Android 2.3~, Chrome, Firefox
  15. 15. 프로토타이핑도 합니다. 이런 서비스를 개발하려고 하는데요,
 기술적으로 웹에서 구현이 가능할까요? 이 스펙 빠르게 프로토타이핑 해주세요. (*화면 보여주면서) 이거 될까요?
  16. 16. 성능 최적화 기능 구현은 잘 됐는데, 느려요. 네이버 메인은 빠르던데 모바일에서 더 부드럽게 구현이 안될까요? 인스타그램 앱에서 스르륵 효과가 멋지던데 
 우리 웹은 뚝뚝 끊겨서 이상해요. 제 폰은 갤럭시 s3 인데 우리 서비스가 너무 느려요. 메뉴를 누를 때마다 왜 이렇게 깜박거리죠?
  17. 17. 유지보수가 가능한 JS 개발 이 프로젝트 일단 기능만 추가하죠. 
 리펙토링(채무청산)은 나중에 하고요. JS코드는 유연하니 편할대로 작성하세요.
 다음에 누군가 잘 유지보수 해주시겠죠. 유연하다는 말은, 
 다른 말로 “플젝마다 구조가 다르다” 입니다.
  18. 18. 유지보수가 가능한 JS 개발 다른 FE개발자가 작성한 걸 유지보수 하더라도 
 한참은 헤매야 합니다. 일관성이 있다면, 유지보수가 한결 편리합니다. 기존 프로젝트에 접근하여, 
 기본적인 코딩 컨벤션 정립 및 FE 개발 환경 
 구축을 합니다.
  19. 19. 웹 트렌드는 아직도 변화중 새로운 웹기술, 새로운 스펙은 계속 발전하고, 
 변화를 감지하고 스위칭 할 Follower 필요합니다.
 이런 것들과 함께요. ECMA Script 6 (Babel, traceur) Web Components React, Angular 2, Polymer And more.
  20. 20. 정리 해 보면,
  21. 21. FE개발자들의 일은, CSS, HTML, JS 을 이용하여,
 
 화면 로직을 설계, 구현하고, 
 프로토타이핑을 하여 가능성을 확인한 다음,
 테스트를 해서,
 UI 컴포넌트 작성, 통신 API를 작성합니다.
 개발/기획/디자인 소통 창구 역할을 수행하기도 하구요,
 성능 최적화를 하여 
 
 좀 더 빠르고 나은 웹 어플리케이션을 위해 노력합니다.
 물론 최신 웹 스펙과 함께요.
  22. 22. 그렇다면 요샌 
 어떻게 개발을 할까요?
  23. 23. 고도화 된 프론트엔드 개발 1. 디자인 패턴 유입 2. MVC 구조에 따른 웹 어플리케이션 개발 3. Framework/Library 의 다양화
 (jQuery 하나로 끝나는게 아닌) 4. 프론트엔드 도구의 다양화 5. 차기 JS 스펙은 계속 발전 중 (ES 6, ES 7)
  24. 24. (요새) 하고 있는 개발 프로세스
  25. 25. 1. 요구 사항 분석 (스펙 회의) 1) 서버개발에서 된다고 했다가 
 브라우저 커버리지 때문에 FE 개발자에게 HELP! 
 IE에서 안되요!! (실제로 이런 경우 많습니다) 2) 애초에 서비스 기획/설계 당시부터 
 프론트엔드 개발자가 포함되는게 좋습니다. 3) 이번 서비스에 이 스펙을 꼭 넣어야 해요. 
 (구현 가능성 판단 및 일정 산정. 
 프로토타이핑 일정이 포함되곤 합니다)
  26. 26. 2. 프레임워크/라이브러리 선정
  27. 27. 프레임워크/라이브러리 선정 JQUERY/JINDO 하나면 다 되는거 아니야? 일반적인 상황에서는 충분하지만, 
 좀 더 고차원의 어플리케이션 개발은 
 부족합니다. 유지보수가 용이한 프로젝트를 위해선 
 적절한 라이브러리 선정이 매우 중요합니다.
  28. 28. 3. 환경 세팅 ANT YUI빌드 정도면 되는거 아니야? 충분합니다. 
 하지만, 더 좋은 툴들이 너무 많이 있습니다. 다양한 종류의 프론트엔드 개발을 도와주는 
 도구들이 오픈소스로 공개 되어 있습니다. 그리고,
 Minification 만으로는 부족하죠.
  29. 29. 자바스크립트 개발 환경 고도화 JS 개발 환경은 node.js로 인해 정말 많은 
 발전을 했고, 주로 아래와 같은 툴들이 있습니다. grunt, grunt-init
 gulp
 yeoman
 bower
 karma
 browser-sync
  30. 30. FE BUILD TOOLS JS 최적화 (Min & Uglify) JS 코드 품질 검증 (JS Lint, flow) JS 테스트 수행 (test code run with browser) JS Code Templating CSS 최적화 (Min) CSS Image sprite 자동화 HTML, CSS 리소스를 js로 변환
 tmpl[‘index.html’] = ‘<html>n<body></body></html>’; ALL FILE CONCAT to THE_ONE.js
  31. 31. 이걸 합쳐서, BUILD TASK JS 최적화 (Min & Uglify), JS 코드 품질 검증 (JS Lint), JS 테스트 수행 (test code run with browser), CSS 최적화 (Min), CSS Image sprite 자동화, HTML, CSS 리소스를 js로 변환, ALL FILE CONCAT to THE_ONE.js, checkout Flash file BUILD 태스크를 수행 하면
 3초만에 우리가 원하는,
 result.min.js 산출물 파일 생성
  32. 32. 여러가지 귀찮은 작업을 
 커맨드 한번에.
  33. 33. 4. 개발/테스트
  34. 34. 여러 브라우저에서 
 테스트하기 여러가지 솔루션이 있습니다. BrowserSync
 Browser Stack SauceLabs
 Many Virtual Machines
  35. 35. 테스트 방식 선택 •무료로 할려면, (로컬에 세팅하기) •BrowserSync •VM 환경 세팅 •돈내고 편하게 하려면, (그냥 서비스 이용하기) •SauceLabs •Browser Stack
  36. 36. 가상 머신 테스트 준비 modern.ie : IE test VM 이미지 무료로 받기 Genymotion : Android VM Xcode : iOS VM (Simulator)

  37. 37. VM 기본 셋 필요에 따라 
 더 설치 하기도 합니다.
 Genymotion VirtualBox 브라우저 삼총사
  38. 38. BROWSER-SYNC 테스트 환경을 (극적으로) 도와주는 도구입니다.
 태스크 러너(grunt/gulp) 를 통해 
 쉽게 run 할 수도 있습니다. weinre 자동 세팅 (Remote Debugging) Click & Scroll position &Form action 동기 화 자동 화면 갱신 (리소스/코드 변경시)
  39. 39. 우리 개발 환경엔 
 이렇게 쓰고 있습니다. 폴더서 gulp bs 를 하면 자동으로 서버가 뜹니다.
  40. 40. BROWSER STACK 웹 베이스 가상 머신 테스트 (설치 없이)
  41. 41. SAUCELABS https://saucelabs.com/
  42. 42. SAUCELABS 앞서 본 브라우저 스택과 유사
 셀레니움이나 remote test 환경 지원이 
 좋습니다. 멀티 브라우저에서 테스트를 자동화 시킬 수 있습니 다. 서비스를 사용해서요. 우리 파트에서도 직접 사용할 수 있을지 고민중인 서비스입니다.
  43. 43. CI와 함께 UI 테스트
  44. 44. FRONT-END PACKAGING MANAGER 프론트엔드 패키징 매니저, bower
 기존엔 jquery를 받으려면 jquery사이트를 들 어가서 봐야 했습니다. 이제 커맨드 만으로 간단히 받아올 수 있어요. command 유틸로 설치하는 jquery는,
 bower install jquery
  45. 45. 마지막, 5. 성능 최적화
  46. 46. 성능 최적화는, 조금만 그리고(draw), 조금만 연산하기 Repaint / Reflow 최소화 리소스 로컬 캐싱 활용 (Local Storage) UI 인터페이스 응답성 최대한 보장 빌드를 이용한 파일 크기 최적화
  47. 47. BACK-END, FRONT-END 한 집 생활 기존/신규 프로젝트에 프론트엔드 집짓기
  48. 48. 실무 프로젝트 1. 어떤 공통 모듈 공통으로 사용하는 어떤 모듈 개발 모든 리소스(image, html)는 
 리퀘스트 수를 줄이기 위해 
 js 파일 하나로 패키징 해야 합니다.
  49. 49. AS-IS 파일 하나에 5000줄이 넘었습니다.
 앞으로 고통스러운 유지보수가 될 게 뻔해요.
  50. 50. 집짓기 시작 기존 현황은,
 loc 5000 짜리 단일 파일 1개로 관리
 공통 라이브러리인 특성상 유지보수 업무가 많았습니다. 진입 방식?
 프론트엔드 프로젝트 폴더 생성과 동시에, 
 기능 단위로 파일을 분리
 Markup / CSS 리소스 파일 분리 (유지 보수성)
 프론트엔드 빌드 환경 세팅
  51. 51. TO-BE JS파일 안에 있던 리소스 분리 유틸리티 함수 추출 기능 단위 파일 분리 gulp를 이용한 빌드 환경 세팅
  52. 52. 변환 결과 굳이, 여러 파일로 나눌 필요가 있을까요? 네. 꼭 필요해요.
 
 5000 줄짜리 클래스 파일을 
 유지 보수 하는 건
 정말 고통스러운 일입니다.
  53. 53. 얻은 것과 잃은 것 프론트엔드 개발 관점에서 유지 보수가 
 편리해졌습니다. 피쳐 개발 중간에 HOTFIX나 
 긴급 수정이 생겨도 문제 없어요. 빌드시, 패키지 내부에 자동으로 빌드 날짜가 
 추가 되니까 서비스의 배포 상태 점검이 용이해요.
  54. 54. 하지만, 
 기존 개발자 분들이 
 쓰시기가 어려워 졌습니다.
  55. 55. 그렇게 복잡하지 않습니다. 몇가지만 기억하신다면요.
  56. 56. 세팅된 환경은 사용은 쉽습니다. 1.node.js 설치를 하고, 2.해당 폴더로 가서, 3.npm install 만 해주면, 빌드 준비 끝 4.app/src 안에 변경이 필요한 파일 수정후, 5. 마지막으로, gulp publish 커맨드로 산출물 생성 6. 코드 커밋
  57. 57. /app/resources
 리소스를 저장할 폴더 /app/src
 플레이어 소스 코드 저장 폴더 /coverage
 코드 커버리지 산출 폴더 /dist
 최종 산출물 저장 폴더 /test
 테스트 관련 파일 기타 환경 세팅 관련 파일들
  58. 58. 환경 세팅 후 얻은 또다른 것 CI 연동을 통한 빌드/테스트 자동화
  59. 59. NODE 덕분에 서버에서 브라우저를 띄울 수가 있습니다. 커맨드로,
 웹페이지 캡쳐
 (리눅스 에서도 가능)
  60. 60. 이걸로, UI 테스트도 가능합니다.
  61. 61. 실무 프로젝트2. 플러그인 구현이 이미 잘 되어 있어요. 동작도 잘 하고요. 하지만 조금 개선해서 다른 서비스에서도 
 쓸 수 있게 하면 좋겠어요. 이번에 다른 스펙을 구현할껀데 한 페이지에 
 이 모듈을 여러개 붙일 수 있나요?
  62. 62. 개선 포인트 접근 기존 구조 파악 단일 페이지에서 한개의 모듈만 초기화 가능
 (인스턴스 기반이 아님)
 신규 피쳐 개발과 함께 구조 개선 필요 개선 방향 jQuery 플러그인(모듈)으로 개발을 하고, 
 인스턴스 기반으로 여러개를 
 만들 수 있게 하기 위해 파일 구조 전면 변경
  63. 63. AS-IS 모든 코드는 window scope 에 있었습니다. 
 초기화는 한개의 업로더만 가능.
  64. 64. TO-BE 신규 컴포넌트는, 
 원하는 갯수만큼 초기화 할 수 있습니다.
 API는 jQuery를 따르기 때문에 간단합니다.
  65. 65. 디렉토리 구조 bower_components
 외부 라이브러리 coverage
 코드 커버리지 측정 산출물
 
 jsdoc
 api 문서 spec
 test 관련 코드
 
 src
 실제 소스 코드
 
 기타 환경 관련 파일들
  66. 66. 사실 이 프로젝트 디렉토리를 
 서버 저장소에 놓을 필요는 없습니다. command util인 bower를 이용해 특정 디렉 토리에 라이브러리 설치도 가능합니다.
  67. 67. 실무 프로젝트 3.
 동적인 인터렉션의 프로젝트 프론트 개발 분량이 매우 많고, 
 동적인 인터렉션이 많아요. 개발 기간도 짧고요. 프로젝트 변화가 잦습니다. 
 개발 시간을 최대한 줄이고 싶어요.
  68. 68. 그렇다면, 서버와 프론트 역할을 
 완전히 분리하는게 어떨까요? 프론트엔드의 빌드 주체는, 프론트엔드 개발에서. 서버 프로젝트 디렉토리의 static 폴더에 전체 빌 드 산출물을 빌드 (html, css, js) FE에서 수행한 빌드 산출물은 곧 실제 서비스까지
  69. 69. 장단점이 있을까? 장점?
 파일 히스토리 관리, 머지 부탁 필요 없음.
 (공유 메일 작성 안해도 됨)
 FE to Server 통합 요청 프로세스의 간소화
 (산출물 공유가 전혀 불필요. 시간 절약이 많이 되었어요) 단점?
 FE에서 기존에 서버 개발자의 view레이어에 대한 
 책임을 일부 가져가야 해요. (jsp 코드 적용, 등)
  70. 70. 그래도 문제는 있었습니다. 매번 서버 저장소에 최종 산출물 코드를 커밋해야 하는 번거로움이 있습니다. 빌드를 하는 주체가 다른 사람이 되면, 
 저장소의 산출물 파일에 Conflict가 발생합니다.
  71. 71. 그래서, 이런 생각이 들었습니다.
  72. 72. 프론트엔드 빌드 도구들도 
 서버 빌드 타임에 실행하면 어떨까요?
  73. 73. MAVEN-FRONTEND front-end 역할을 위임하는 대신,
 FE 빌드를 서버에서 자동으로 실행해 주는 방식입니다. Front-End에서 개발과 환경 세팅을 하고, 빌드 요청은 maven 플러그인을 사용해 실행만 해주면, 빌드 서버에서 빌드시 자동으로 product js 코드가 
 생성됩니다.
 
 https://github.com/eirslett/frontend-maven-plugin
  74. 74. 물론 의존 모듈은, 자동으로 설치됩니다.
 (Node.js, NPM) 개발하던 모듈이 들어있는 서비스 서버는 
 maven 기반이 아니라서, 다른 모듈에 테스트를 해 보았습니다.
  75. 75. POM.XML
 frontend-maven-plugin추가 환경 세팅은, 프론트엔드 개발자가 원하는대로 가능함 bower, npm, 
 karma, gulp, 
 grunt
 모두 사용 가능
  76. 76. NPM INSTALL만 가능해도, package.json의 scripts 옵션으로 
 할 수 있는 것들이 이미 열려 있음.
 
 "scripts": {
 "preinstall": “bower install",
 "test": "gulp test",
 "build": "gulp build",
 "deploy": "gulp build"
 }
 https://docs.npmjs.com/misc/scripts
  77. 77. MAVEN INSTALL node.js 자동 설치 의존 모듈 자동 설치
 
 자동으로 프론트엔드 빌드
  78. 78. 결과, 배포용 코드 생성 완료
  79. 79. 개발 환경을 잘 몰라도, 빌드서버에서 자동으로 빌드 시킬 수 있습니다.
  80. 80. 더 나은 개발 환경을 위해, 지금도 계속 고민하고 있습니다.
 
 제가 편하고,
 제 동료들이 편하게 할 수 있게.
  81. 81. FIN. THANKS
  82. 82. APPENDIX
  83. 83. BASELINE FOR FRONT-END DEVELOPERS: 2015 http://rmurphey.com/blog/2015/03/23/a-baseline-for-front-end- developers-2015/ 1. ES6 2. Modules 3. Build Tools 4. Testing 5. Process Automation 6. Code Quality 7. Client-Side Templating 8. node.js

×