28. 개발 노트 정리
D+2 패키징 방식 도입 D+262 ORM 구현 시작
D+4 Continuous Integration 도입 D+409 인증 플랫폼 연동
D+8 P2P 도입 ( 이후 제거 ) D+510 클라이언트 엔진 플러그인 지원
D+30 이벤트 기반 프로그래밍 모델로 전환 D+710 결제 플랫폼 연동
D+41 문서화 D+1099 관리용 REST API 추가
D+43 프레임워크 방식으로 전환 D+1427 엔진 프로파일러 추가
D+45 분산 시스템 구현 시작 D+1808 C# 지원
D+98 행동 로그 수집 시스템 구현 D+1827 데디케이트 서버 지원
D+147 TCP 지원 및 세션 계층 구현 D+1861 모니터링 대시보드 지원
D+228 UDP 지원
29. 개발 노트 정리
D+2 패키징 방식 도입 D+262 ORM 구현 시작
D+4 Continuous Integration 도입 D+409 인증 플랫폼 연동
D+8 P2P 도입 ( 이후 제거 ) D+510 클라이언트 엔진 플러그인 지원
D+30 이벤트 기반 프로그래밍 모델로 전환 D+710 결제 플랫폼 연동
D+41 문서화 D+1099 관리용 REST API 추가
D+43 프레임워크 방식으로 전환 D+1427 엔진 프로파일러 추가
D+45 분산 시스템 구현 시작 D+1808 C# 지원
D+98 행동 로그 수집 시스템 구현 D+1827 데디케이트 서버 지원
D+147 TCP 지원 및 세션 계층 구현 D+1861 모니터링 대시보드 지원
D+228 UDP 지원
배포 관련배포 관련
30. 개발 노트 정리
D+2 패키징 방식 도입 D+262 ORM 구현 시작
D+4 Continuous Integration 도입 D+409 인증 플랫폼 연동
D+8 P2P 도입 ( 이후 제거 ) D+510 클라이언트 엔진 플러그인 지원
D+30 이벤트 기반 프로그래밍 모델로 전환 D+710 결제 플랫폼 연동
D+41 문서화 D+1099 관리용 REST API 추가
D+43 프레임워크 방식으로 전환 D+1427 엔진 프로파일러 추가
D+45 분산 시스템 구현 시작 D+1808 C# 지원
D+98 행동 로그 수집 시스템 구현 D+1827 데디케이트 서버 지원
D+147 TCP 지원 및 세션 계층 구현 D+1861 모니터링 대시보드 지원
D+228 UDP 지원
배포 관련배포 관련
프로그래밍 모델 관련프로그래밍 모델 관련
31. 개발 노트 정리
D+2 패키징 방식 도입 D+262 ORM 구현 시작
D+4 Continuous Integration 도입 D+409 인증 플랫폼 연동
D+8 P2P 도입 ( 이후 제거 ) D+510 클라이언트 엔진 플러그인 지원
D+30 이벤트 기반 프로그래밍 모델로 전환 D+710 결제 플랫폼 연동
D+41 문서화 D+1099 관리용 REST API 추가
D+43 프레임워크 방식으로 전환 D+1427 엔진 프로파일러 추가
D+45 분산 시스템 구현 시작 D+1808 C# 지원
D+98 행동 로그 수집 시스템 구현 D+1827 데디케이트 서버 지원
D+147 TCP 지원 및 세션 계층 구현 D+1861 모니터링 대시보드 지원
D+228 UDP 지원
배포 관련배포 관련
프로그래밍 모델 관련프로그래밍 모델 관련
운영 및 관리 관련운영 및 관리 관련
33. 敎訓 1: 솔루션 배포 방식을 고민하라
처음부터 패키지 업그레이드 방법을 고려해야 함 .
설치 과정이 단순해야 함 . (out-of-box 방식 )
34. 敎訓 2: 버그는 치명적이다 .
패치를 내보내도 한 번 나간 버그는 사라지지 않을 수 있다 .
( 갤럭시 노트 7 의 경험 )
한 번 등을 돌린 사용자는 돌아오지 않는다 .
35. 따름 敎訓 1: Peer Code Review 의 생활화
버그 가능성을 개별 작업자의 능력이 아니라 시스템으로 풀어야
한다 .
36. 따름 敎訓 2: 빌드는 자동화 하라
빌드 자동화는 제품의 일관된 품질을 보장하는데 도움이 된다 .
작업자에 따른 결과물의 차이라는 위험을 제거할 수 있다 .
37. 敎訓 3: 문서화는 무엇보다 중요하다
“ 구슬이 서 말이라도 꿰어야 보배다 .”
“ 문서는 SW 솔루션에 있어 UI 다 .”
38. 敎訓 4: Black box 라는 것을 명심하라
블랙박스 사용자는 언제나 답답함을 느낄 수 있다 .
그러니 인터페이스는 최소화하고 , 동작은 직관적이게 한다 .
39. 敎訓 5: 서비스 운영 / 모니터링에 신경 쓰라
Black box 를 진단할 수 있는 방식을 반드시 제공해야 된다 .
40. 기타 잔소리 : Co-work 에 대해 ..
프로젝트는 내가 잘 났다는 것을 과시하기 위한 것이 아니다 .
-읽기 쉬운 코드 선호
-상세한 commit log
-관리가 용이한 개발툴로 변경 (automake -> cmake)
-“ 내 코드를 쓰면서 동료가 실수한다면 동료가 바보가
아니라 내가 나 혼자만을 위한 코드를 짠 것이다”
41. 기타 잔소리 : 서버 엔진 vs. 네트워크 엔진
서버 엔진을 네트워크 엔진으로 착각하면 안됨 .
서버 엔진은 전반적인 생산성과 확장성에 대한 많은 고려가 필요 .
42. 후회 되는 점 : 사용자 편의성 고려 늦음
인증 / 빌링 및 프로그래밍 언어에 대한 배려가 늦었음 .
43. 덤 : GitStats 로 알아보는 프로젝트 생산성
출근 직후와 점심 식사 직후의 생산성은 높지 않다 .
우리 직원들은 퇴근 직전까지도 열심히 일한다 . ( 흐믓 )
44. 요일 별 생산성에 큰 차이는 없지만 금요일이 약간 낮다 .
덤 : GitStats 로 알아보는 프로젝트 생산성
45. 건물의 냉난방이 이루어지지 않는 환절기에 생산성이 낮다 .
덤 : GitStats 로 알아보는 프로젝트 생산성