@@ -88,12 +91,11 @@ intro:
### 단축키 시스템
![]()
-단축키가 서비스 전반에 다양한 곳에 적용되어 있다. 그래서 아래와 같이 구분을 했다.
-- Global (모드 변경을 위한 키)
-- Local (모드의 기능을 사용하기 위한 키)
-- 예외 (input 태그에 입력중일 때 등)
+단축키를 설정하는 것이 쉽지 않았다.
+키 중복이나 잘못된 키 인식 문제가 발생했다. 그래서 여러 방법을 고려하였다.
+flag 변수를 사용해 시스템을 제어하고, 빠른 검색 모드에서는 단축키 사용을 최대로 줄였다.
+또한, 입력받는 키 값의 범위를 ASCII 코드상의 알파벳으로 제한하기로 결정했다.
-중복으로 인식하는 일을 막기 위해 모드에 맞게 키 연결이 대체되거나 일시적으로 작동이 멈추는 상황이 필요했다. 각 범위에 논리타입의 변수와 조건문으로 Handling하는 로직을 추가했다. 서비스에서 사용되지는 않지만 모든 키 입력에 대응하던 부분을 ASCII 코드상의 범위를 알파벳 범위로 제한하고 각 키에 대응하는 입력값 연결로 구현했다.
```javascript
/*
* 0 : off, 1: on
@@ -125,33 +127,51 @@ function modeChange() {
}
```
-즐겨찾기 모드는 데이터 관리 편의를 위해 배열단위로 값들을 서버에서 응답 받는데 처음에는 리스트로 제공을 해서 문제가 없었지만, 단축키라는 특징을 직관적으로 사용자에게 전달하는 경험을 추가하기 위해 화면에서 현실의 키보드 배치로 제공하기로 변경되었다. 이 부분의 코드와 과정을 줄이기 위해 줄 간 키 개수의 패턴이 10, 9, 7로 (n-i)같이 떨어지는 것을 이용했고, 처리과정에서 객체의 개수를 줄여 코드를 많이 줄일 수 있었다.
-
---
-### 웹 로그
-
![]()
+### 코드 최적화
+즐겨찾기 값은 데이터 관리 편의를 위해 배열단위로 값들을 서버에서 응답 받았다.
+단축키 UI를 적용되고 나서 불필요하게 코드가 많이 늘어나게 되었다.
+반복적인 패턴을 찾았지만 2뎁스 배열의 길이가 일정하지 않아 문제였다.
+다행히도 길이가 10, 9, 7로 (n-i)같이 떨어지는 규칙성을 발견했고 반복 횟수로 적용할 수 있었다.
+한 루프 안에서 처리하고 나니 개별 코드들이 정리되었고 객체의 개수를 많이 줄일 수 있었다.
+---
-이 서비스는 TOMCAT 서버 호스팅을 이용했는데 Server의 Console과 Log에 접근하기 위해서는 ftp를 이용해야만 했다. 서버를 중단해야했던 적도 있었다. 그래서 모바일로도 접근이 가능한 웹로그를 개발했다. 웹 로그 컨트롤러를 따로 두고 일부 Joinpoint에서 메소드 호출했고, 전체검색/날짜별검색/상세검색(날짜, 태그별)으로 3가지 쿼리를 이용해 화면의 유연한 요청을 처리하게끔 구현했다.
+## 배운 점
+### 네이밍 컨벤션
+프로젝트 중 네이밍 컨벤션의 필요성을 다시금 깨달았다.
+특별히 팀 내에서 설정하지 않았더라도 개발자 사이에서 대체로 사용되는 네이밍 컨벤션이 존재하는 것을 간과하였다.
+팀원에게도 안내를 하지 못 했고, 그로인해 불필요한 에러에 시달려야했다.
+다음에는 프로젝트를 시작할때 미리 꼭 논의를 하고 넘어가야겠다.
---
-## Problem & Try
-### 개발 표준을 정하자
-프로젝트를 시작할때 명명법이나 구조적인 부분에 대해 회의와 규칙을 정하지 못 했다. 그래서 잔 에러나 소통 실수가 생겨났다. 그리고 중반부에 알게된 것이 컨트롤러에 기능적인 로직을 최대한 줄이고 서비스 단계에서 마무리를 하는게 더 좋았을 것이라는 생각이 들었다. 그 부분이 찝찝한 아쉬움으로 남는다.
+### 컨트롤러의 역할
+이론을 공부 했을때 컨트롤러 본연의 역할은 최종 전달자였다. 가공된 값을 전달하는 임무를 수행한다.
+하지만 나는 편하다는 이유로 간단한 로직들을 컨트롤러에서 그냥 처리하고 있었다.
+프로젝트 후반부에 피드백을 통해 알게되었다. 서비스 레이어를 잘 활용하지 못 했다.
----
+## 결과 및 성과
+
+### 웹 로그
+
![]()
-### 익숙한 것 벗어나기
-사용자 편의성을 고려하는데 분석을 많이 했고 그것을 반영한 설계로 기능들의 로직흐름이 변화했다. 그리고 나에게 익숙했던 Server 단계가 아닌 기술 트렌드에 맞춰 스크립트로 기능들을 최대한 구현하려고 신경썼다. 그 결과, 빠른 처리 속도와 서버의 부하를 줄일 수 있어서 적은 비용으로 더 많은 사용자들을 수용할 수 있게 되었다.
+TOMCAT 서버를 호스팅했는데 서버의 콘솔과 로그에 접근하기 위해서는 FTP를 이용해야 했다.
+웹 로그 컨트롤러를 따로 두고 일부 Joinpoint에서 메소드 호출하여 모바일로도 접근이 가능한 웹 로그 시스템을 개발했다.
+전체검색, 날짜별검색, 상세검색(날짜, 태그별)으로 쉽게 확인하도록 구현했다.
---
-### 기간을 위해 보류
-중간중간 좋은 아이디어들이 많이 나왔다. 중요도가 높거나 시간이 별로 소모되지 않는 경우 반영되기도 했지만 보통 보류된 것들이 많다. Social기능을 강화한 하이퍼 공유, 즐겨찾는 하이퍼, 추천 url 기능과 비즈니스 목적으로도 사용가능한 Hyper 플러스, iframe을 이용한 위젯형태의 모바일 사이트 연동, 플러그인 형태의 사용자 위젯 마켓 등 욕심이 나는 것들이 참 많았다. 만약 2.0 프로젝트를 기획하게 된다면 꼭 해보고 싶다.
+### 스케일 조절
+생각보다 좋은 아이디어가 많았지만, 중요하거나 시간적 여유가 있는 것들만 먼저 구현했다.
+취지에 가까운 소셜 기능인 하이퍼 공유, 즐겨찾는 하이퍼, 추천 url 기능은 반영되었다.
+비즈니스 목적에 가까운 기능인 Hyper 플러스, iframe을 이용한 위젯형태의 모바일 사이트 연동, 플러그인 형태의 사용자 위젯 마켓은 보류되었다.
+2.0 프로젝트를 기획하게 된다면 꼭 해보고 싶다.
---
## 마치며
-결과적으로 담당 기능도 잘 나누어졌고 나름 예측 범위 안에서 흘러가서 프로젝트 기간이 길어지지 않았고, 퀄리티도 괜찮은 수준으로 개발되었다. 아무래도 요새 PC보다는 스마트폰을 사용하다보니 일반인 지인들에게는 피드백을 받지 못 했지만, 개발자 지인들의 반응이 뜨거웠고 과정, 결과 모두 뿌듯할 수 있었다.
\ No newline at end of file
+아무래도 PC보다는 스마트폰을 더 사용하다보니 일반인 지인들에게는 피드백을 받지 못 했지만, 개발자 지인들의 반응은 뜨거웠다.
+프로젝트 담당 기능도 잘 나누어졌고, 예측 범위 안에서 흘러가서 프로젝트 기간도 길어지지 않았다.
+만족스러운 프로젝트였다.