Knowledge의 순위를 이해할 수 없어 평가센터의 말~후편을 폭로했다~

　
SC(비공식) Advent Calendar 2018의 셋째 날.
본 보도는 Knowledge의 순위를 이해할 수 없어 평가센터의 말~전편~의 계속이다.
전회의 줄거리
소속 부서 내에'KnowledgeShare 시스템'웹 투고형 지식 공유 플랫폼이 개설됐지만
이 가운데 인기 차트를 보도하는 페이지 내용은'인기'뿐만 아니라 평가 논리도 불투명하다
존재해야 할 자세와 실제 상황의 차이가 매우 크다...
의분을 품은 젠다리, wyu는 그게 OSS를 이용한 앱이라는 걸 알아요.
OSS의 대원 사이트에서 가까스로 GiitHub의 이 창고에 도착했는데 혼자서 zip을 잃어버리고 분석을 시작했어요...
　
네, 그래서 SW풍 비행 줄거리를 만들고 만족해서 바로 다시 시작했어요.
3. 조사(자료편)
머릿속
정보를 조회할 수 있는 곳에 도착하면 그 다음에 자료와 자료 출처를 볼 수 있기 때문이다.
여기까지 오면 끝까지 조사할 수밖에 없어요.
해본 일
Knowledge 첫 페이지의 화면 오른쪽 상단에 있는 "Download"링크를 따라 주체를 낮추려고 합니다.

　
GiitHub 페이지로 이동합니다.
War 파일이 포함되어 있기 때문에 Java로 개발한 것 같습니다.
또 원본 코드도 포함된 것 같아서 최악의 원본 코드에서 읽는 방법은 문제없을 것 같다.
(다행히 필자에게 자바는 개발 경험이 있는 언어이다)
그럼 Giithub의 이 창고의 첫 페이지로 이동하고 전체를 zip으로 지웁니다.
(할애)
　
네, 해동된 곳은 여기예요.
(그림1)

src 폴더에도 원본 파일이 있고 관련 문서가 포함된 문서 폴더가 있습니다.
우선 문서 폴더에서 규격과 디자인 자료가 있기를 바랍니다.
하층부로 보인다.

documentフォルダ
┗―+ databaseフォルダ
　┗― A5M2_knowledge.pdf
　┗― A5M2_web.pdf
　┗― knowledge.a5er
　┗― web.a5er
┗―+ imagesフォルダ
　┗― icon.png
　┗― startup-594090_640.jpg
　┗― startup-594090_1280.jpg
　┗― startup-594090_1920.jpg
┗―+ sampleフォルダ
　┗―+ logフォルダ
　　┗― default-logging.properties
　　┗― log4j.xml
　　┗― logging.properties

워드/excel로 쓴 설명서나 디자인서 같은 건 없는 것 같아요.
하지만 자세히 보면 데이터베이스 폴더에 a5er 파일이 포함되어 있습니다.
이른바 a5er 파일이란 A5:SQL Mk-2처럼 뛰어난 데이터 베이스 무료 도구에서 제작된 ER 그림의 파일 형식이다.
즉, 이것은 응용 프로그램의 ER 안배이다.
먼저'A5M2 knowledge.pdf'부터 살펴보자.

응, 대충 봐도'괜찮다'이런 것도 있지만,'마음'같은 문구는 없어.
이후 기고한 기사는'해설'형식으로 쓴 것으로 보인다.
따라서 한 기사에 대한 정보를 찾기 위해'해설'의 실체를 살펴본다.

수상한 게 있어.'Point'라는 속성은 항상 향기롭다.
ER 그림의 오른쪽을 보면'해설점 획득 역사(POINT KNOWLEDGE HISTORIES)'또는
이용자의 마일리지 취득 이력(POINT USER HISTORIES)이 있다.
그 외에'좋아요건수','참조건수','주석건수'등의 속성도 있다.
이 녀석은 매우 구리다.
다른 실체도 있지만 자세히 보면 끝이 없어
이 "point(POINT)"속성에 초점을 맞추어 탐색합니다.
4. 조사(소스 코드 편)
머릿속
자료가 더 이상 없는 것 같아서, 나는 DB의 KNOWLEDGE 표의 POINT 열에 초점을 맞추어 원본 파일을 보았다.
OSS인 Knowledge 애플리케이션이 어떤 Java 프레임워크에 의해 개발되었는지 모르겠지만
어떤 프레임워크든 DB에 연결된 데이터 액세스 레이어가 있어야 합니다.
따라서 SQL 및 DataAccess 계층의 컴퓨팅 포인트에서 비즈니스 로직을 포함합니다.
나의 목표는 서비스반에 도착하는 것이다.
해본 일
zip의 그림 1을 펼친 폴더에서 보듯이 src 폴더를 대상으로'POINT'을 검색 문장으로 하고 적절한 도구로 GREEP를 한다.
(이번엔 벚꽃 편집기 사용)
※ GREEP////텍스트 파일에서 정규 표현식과 일치하는 줄을 검색하고 출력하는 명령
GREEP란

957개...좀 많아요.
굴러갔는데 중간에 신경 쓰이는 게 있어요.

 (アドレス割愛)\src\main\java\org\support\project\knowledge\logic\KnowledgeLogic.java(253,32)  [UTF-8]:
                   data.getKnowledge().setPoint(db.getPoint()); // ポイントもDBの値を引き継ぐ

예의 바르게 일본어로 댓글을 남겨주세요.
GiitHub에 기고한 OSS에 일본어 댓글이 없는 것 같아요.
Knowledge에 관해서는 아직 개발 당시의 평어가 남아 있는 것 같습니다.
(친근감이 솟구친다)
　
그러니까 "Point"로 원본의 댓글을 검색하는 게 좋을 것 같은데...!?

196개!좋은 느낌으로 줄었어!
그리고 방법을 명확하게 써서 설명!이것은 이미 승리의 보증이다.
　
　
그리고 훑어보는 과정에서 찾은 답은
src\main\java\org\support\project\knowledge\logic\activity\Activity.java
처음 반의 설명으로 설명되어 잘 기술되었습니다!!
　
　
이것이 바로

/**
 * ポイントが増減するアクティビティの種類
 * 
 * 種類  | ターゲット文字列 | イベントの内容
 * 1    | knowledge_id  | 記事を登録(使わない）
 * 2    | knowledge_id  | 記事参照
 * 3    | knowledge_id  | 記事へイイネを登録
 * 4    | knowledge_id  | 記事をストック
 * 5    | knowledge_id  | アンケート回答
 * 6    | knowledge_id  | イベント参加
 * 10   | knowledge_id  | 記事を「公開」で投稿（登録／更新時）→増える
 * 11   | knowledge_id  | 記事を「保護」で投稿（登録／更新時）→前が非公開であれば増える、前が公開であれば減る
 * 12   | knowledge_id  | 記事を「非公開」で投稿（登録／更新時）→前が「公開」「保護」の場合減る（前が「公開」「保護」で無い場合登録しない/非公開の記事ではポイント増えない）
 * 101  | comment_no    | コメント登録
 * 103  | comment_no    | コメントにイイネ登録
 * -6   | knowledge_id  | イベント参加の取り消し
 * 
 * ---------------------------------------------------------------------------
 * 
 * ポイント操作
 * 
 * 種類  | 獲得のタイプ  | ポイント付与先 | ポイント    | 獲得タイプの意味
 * 1    | 11          | 記事登録者    | 50       | 記事を投稿したら投稿者にポイント追加(使わない）
 * 1    | 13          | 記事         | 50       | 登録された記事のポイント初期値(使わない）
 * 2    | 21          | 参照者       | 1        | 記事を参照するアクションを行うと、参照者にポイント追加（一つの記事に付き1回のみ）
 * 2    | 22          | 記事登録者    | 1        | 自分が登録された記事が参照されたら、登録者にポイント追加（一つの記事に対し、参照者毎に1回のみ）
 * 2    | 23          | 記事         | 1        | 記事が参照されると、その記事のポイントが追加（一つの記事に対し、参照者毎に1回のみ）
 * 3    | 31          | 参照者       | 2        | 記事にイイネのアクションを行うと、参照者にポイント追加（一つの記事に付き1回のみ）
 * 3    | 32          | 記事登録者    | 10       | 自分が登録された記事にイイネがついたら、登録者にポイント追加（一つの記事に対し、参照者毎に1回のみ）
 * 3    | 33          | 記事         | 10       | 記事が参照されると、その記事のポイントが追加（一つの記事に対し、参照者毎に1回のみ）
 * 4    | 41          | 参照者       | 0        | ストックした場合、ストックした人にポイントは付与しない
 * 4    | 42          | 記事登録者    | 2       | 記事の登録者にポイント追加（一つの記事に対し、参照者毎に1回のみ）
 * 4    | 43          | 記事         | 2       | 記事のポイントが追加（一つの記事に対し、参照者毎に1回のみ）
 * 5    | 51          | 参照者       | 3        | アンケート回答者にポイント付与
 * 5    | 52          | 記事登録者    | 3       | 記事の登録者にポイント追加（一つの記事に対し、参照者毎に1回のみ）
 * 5    | 53          | 記事         | 3       | 記事のポイントが追加（一つの記事に対し、参照者毎に1回のみ）
 * 6    | 61          | 参照者       | 5        | イベント参加者にポイント付与
 * 6    | 62          | 記事登録者    | 5       | 記事の登録者にポイント追加（一つの記事に対し、参照者毎に1回のみ）
 * 6    | 63          | 記事         | 5       | 記事のポイントが追加（一つの記事に対し、参照者毎に1回のみ）
 * 10   | 101         | 記事登録者    | 50       | 公開になった時点でトータル50になるように
 * 10   | 103         | 記事         | 50       | 
 * 11   | 111         | 記事登録者    | 30       | 
 * 11   | 113         | 記事         | 30       | 
 * 12   | 121         | 記事登録者    | 0        | このアクティビティの前に、投稿のアクティビティがあった場合、それを打ち消す（マイナスのポイント）
 * 12   | 123         | 記事         | 0        | 
 * 101  | 1011        | 登録者       | 20       | コメントを投稿すると、投稿者にポイント追加
 * 101  | 1013        | 記事         | 20       | 記事にコメントが付くと、その記事に対しポイント追加
 * 103  | 1031        | 参照者       | 2       | イイネを押すと、押した人にポイント追加
 * 103  | 1032        | 登録者       | 10       | コメントにイイネが付くと、そのコメントを登録したユーザにポイントが付く
 * 103  | 1033        | 記事         | 10       | コメントにイイネがつくと、そのコメントの記事に対しポイント追加
 * -6   | -61         | 参照者       | 5        | イベント参加者にポイント付与（取り消しなのでマイナス）
 * -6   | -62         | 記事登録者    | 5       | 記事の登録者にポイント追加（取り消しなのでマイナス）
 * -6   | -63         | 記事         | 5       | 記事のポイントが追加（取り消しなのでマイナス）
 * 
 * ユーザのポイントは、USER_CONFIGSテーブルへ格納する
 * ポイントはランダムで少し増減した方が面白い？？
 * ポイントは、だいたいの定義で、各実装の処理内で拡張する（例えば、イイネは、件数が増える毎に、ナレッジに付くポイントは増加するとか）

　
생각보다 얇아요.
이것은 중점에 관한 수첩을 만들지 않아도 이해할 수 있다.
나는 아마도 이 계산점들을 종합한 총계의 논리가 있을 것이라고 생각한다
이거 보면 상관없어.
결론적으로'인기'로 판단되는 이유는 참고 기사, 희소식, 리뷰, 보도의 재고 등과 관련이 있다.
자사가 펼치는 시스템에서 의사록 같은 게'인기 처리'로 바뀐 것도 이해할 만하다.
(특히 20점짜리 평론은 후급 점수로 매우 높다)
그리고 상술한 디자인을 보면 기본적으로 많은 디테일을 고려했다.
당사에서 전개되는 제품도 더 가공될 수 있지만
차라리 문제가 있으면 개인의 보도, 의사록, 규격의 기록 등 업무 문서를
동일한 장소에서 투고/관리하는 통일된 사용 방법이 있을 수 있습니다...
　
・・・
　
　
그래서 왠지 불쾌한 느낌이 든다
회사 내부 시스템이라는 출발점에서 회사 내부 관계가 없는 OSS의 출처를 보는 여행이 됐지만 이런 목적은 달성되었다!
(투고자에게 동력을 주는 아이디어를 냈는데 순위가 이상하게 나왔다.)
5.끝
어때?
체계적인 방법론은 전혀 아니지만 대체로 이해가 안 가는 문제에 부딪혔어요
이런 느낌으로 문제를 해결하기 위해 전자 해양에서 수영을 한다.
그리고 쓰고 생각해 봤는데 이것도 두 번으로 나뉘는 양이 아니죠.
(달력의 테두리가 망가져서 죄송합니다)
한 마디로 하면, 이 글을 읽은 젊은이들은 번역의 조사 임무가 실제 업무에 분배되는 것을 몰랐을 때
조금이라도 해결하거나 그 목적을 위한 방법에 대한 힌트는 행운이다.