Skip to content
This repository has been archived by the owner on Nov 12, 2022. It is now read-only.

Latest commit

 

History

History
204 lines (199 loc) · 13.4 KB

CONTRIBUTING.md

File metadata and controls

204 lines (199 loc) · 13.4 KB
Raw

Contributing Rules

코드 작성 지침

개발을 하면서 반드시 준수해야 하는 행동강령입니다.
이 원칙을 어긴 코드가 발견되는 경우 해당 코드를 반드시 수정하세요.
원칙을 지키지 않고 있는 코드를 수정하기 싫다면 이 원칙을 수정하세요.
혼자 개발을 하는 것이 아니기 때문에 같은 규칙 아래에서 코드를 작성 하는 것은 굉장히 중요합니다.
이 원칙들은 모든 상황에서 반드시 적용되어야 합니다.
불필요하게 원칙을 어겨야만 하는 경우에는 주석으로 그 사유를 적으세요.
새로운 규칙이 필요한 경우에는 이 마크다운을 수정해주세요.
서버에 영향을 주거나, 오류 발생 방지를 위한 내용은 반드시 ✅강조를 해주세요.
영역 -> 언어 -> 클래스(혹은 메소드) 순으로 정의하며, Global은 모든 상황에서 적용 되는 것을 의미합니다.

Global

Markdown

README

  • 리드미는 상세하게 기록합니다.
  • 업데이트 이력을 상세하게 기록해야 다른 팀원들이 어떤 점이 수정됐는지 확실하게 인지할 수 있습니다.
    • 잠수함(스텔스) 패치는 사용자만 혼란스러운 것이 아닌, 팀원들끼리도 황당할 수 있습니다.
    • 누가, 어떻게, 왜, 언제, 무엇을, 어떻게 했는지 상세하게 적어야 합니다. 반드시 지켜주세요.

Git

Pull

  • Merge 할 지 Rebase 할 지 미리 생각하고 누르세요.

Commit

  • 커밋 메시지는 어떤 것을 수정/추가/삭제 했는지 상세하게 적습니다.
    • 나중에 책임 소재를 가리거나, 코드를 추적할 때 굉장히 유용합니다.

Push

  • Push 하기 전에 Pull 부터 하세요
    • 충돌 나면 머리아픕니다.
  • 기능 단위(혹은 소규모 단위)로 Push 하세요.
    • 여러 기능을 붙잡고 있다가 한번에 push하면 중복 구현이 발생하기도 합니다.
    • 짧게 여러번 push 해줘야 팀원들이 새로운 코드를 보면서 피드백을 주고받기 쉽습니다.
    • push하기 전에 오류가 있는지 점검하세요. 오류가 있더라도 적어도 코드가 돌아는 가야합니다.
  • IntelliJ에서 자동으로 수정된 파일은 절대로 업로드하지 않습니다.
    • unresolved files, iml, .idea 같은 자동 수정 파일을 업로드 하지 않습니다. (이는 컴퓨터 세팅 환경마다 다를 수 밖에 없는 파일들입니다.)
    • 잘못된 push가 발생하는 경우 다른 팀원들의 프로젝트가 먹통이 되는 경우가 있습니다.
    • 특히 out 폴더를 업로드 하지 말아주세요. 절대!!

Backend

Java

Global

  • 모든 클래스의 이름은 대문자로 시작합니다.
  • 모든 메소드는 반드시 소문자로 시작합니다.
  • 메소드가 여러 개인 클래스에서는 singleton 메소드가 반드시 있어야 합니다.
    • 대표적으로 *DAO 클래스에 있는 getInstance 메소드는 싱글톤을 위한 메소드입니다. 
      • // 싱글톤 선언 예시
public class ExampleDAO {
    public static ExampleDAO it;
    public static ExampleDAO getInstance() { //인스턴스 생성
        if (it == null)
            it = new ExampleDAO();
        return it;
    }
//클래스 안에 존재하는 여러 개의 메소드
    public void method1() {}
    public void method2() {}
    public void method3() {}            
}
  • 메소드가 여러 개 들어있는 클래스에서 메소드를 한 개만 호출하는 경우에는 반드시 singleton 방식으로 호출해야 합니다.
    • singleton 방식으로 호출해야 메모리 낭비를 방지할 수 있습니다.
    • // 싱글톤 호출 예시
public class ExampleClass {
    public String exampleMethod() {
        ExampleDAO.getInstance().method2(); //이렇게 해야 method2만 메모리에 올릴 수 있습니다.
    }
}

Common Package

  • 프로젝트의 뼈대를 잡고 있는 패키지입니다. 웬만하면 수정하지 않습니다.

Handler Package

  • Action과 DAO의 역할을 확실히 분리해야 합니다.

DAO

  • 메소드 개수가 넘쳐 흐르므로 싱글톤 처리가 필수입니다.
  • 메소드가 아주 많으므로 이름을 명확하게 합니다. 메소드의 이름만 보고도 이 메소드가 무엇을 하는지 감이 와야합니다.
    • 일반적으로 다음과 같은 접두사를 포함합니다. (이 항목은 지켜지지 않은 경우가 많습니다. 추후 통일 바람.)
    • 가져오는 메소드 : get
    • 추가하는 메소드 : set, insert, add, register
    • 수정하는 메소드 : update, modify
    • 삭제하는 메소드 : delete,
    • 확인하는 메소드 : check

DTO

  • 변수는 public으로 선언합니다.
  • getter와 setter는 사용하지 않는 경우가 많으나, 코드 호환을 위해 만들어줍니다.
    • 이 항목은 추후 개발팀의 판단에 따라서 수정될 여지가 있습니다.
    • 기존 프로젝트에서는 변수를 privite으로 하고, getter와 setter를 적극 활용해왔습니다만, 이 프로젝트에서는 굳이 그렇게 하지 않고 구현하고자 했습니다.

MariaDB

Global

  • 서비스 개시 이후에는 *.sql 파일은 반드시 서버 컴퓨터 -> 로컬 컴퓨터로 이동해야 합니다.
  • 사용자의 db는 github에 커밋 혹은 푸쉬하지 않습니다.
    • 이 프로젝트는 오픈소스로 운영되고 있으므로 db는 구글 드라이브나 별도의 디스크에서 관리합니다.
    • 실수로 업로드 하는 경우에는 git 명령어를 통해 수정 이력을 모조리 지웁니다.

Table

  • 테이블 이름에는 대문자를 사용하지 않습니다.
    • MariaDB는 운영체제에 따라서 대소문자가 예민하게 적용됩니다.
    • Windows 환경에서 잘 돌아가더라도, 리눅스 환경에서는 오류가 발생하기도 합니다.
  • 테이블 이름을 작성할 때 여러 단어가 결합된 형태라면 '_'(언더바)를 활용하여 구분합니다.
  • 테이블의 이름은 어디에 쓰이는지 추정이 가능하도록 명확하게 작성합니다.

Column

  • 컬럼의 길이 제한을 유연하게 적용합니다.
  • 되도록이면 컬럼을 추가하지 않습니다.
    • 기능 추가로 인해 컬럼을 추가하는 것은 신중하게 검토해야고, 가능하면 테이블을 추가 하는 것이 낫습니다.
    • 팀에 DB를 자유롭게 사용이 가능하고, 복구에도 능한 팀원이 있다면 서비스 도중에 컬럼을 추가해도 좋습니다.
  • 데이터 값은 되도록 '글자화' 합니다. ex) 상태를 숫자로 나타내는 것 보다 변수화 하는 것이 가독성이 훨씬 좋습니다.

Frontend

JSP

Global

  • 변수명을 중복하지 않습니다.
    • JSP 안에 같은 변수가 등장하는 경우 치명적인 오류를 발생시킵니다.
    • JSP를 include 하다 보면 변수가 중복되는 경우가 있습니다. 같은 JSP 내의 변수가 아니더라도 include 하는 경우에는 주변 파일들과도 변수가 중복되면 안됩니다.
    • 여기에서 오류가 발생 하는 경우, 일반적으로는 duplicated됐다고 알리지만, 제대로 된 오류 메세지를 출력하지 않는 경우가 많으므로 주의합니다.
  • 공통된 디자인을 활용 하는 경우에는 taglib를 활용하여 jsp를 끼워 맞추듯 설계합니다.
    • 대표적인 경우가 아래 Layout 설명에 있습니다.
  • 코드가 너무 길어지는 경우, taglib를 활용하여 jsp를 분리하여 중앙 jsp에 include 합니다.
    • 대표적으로 admin_main 페이지가 이런 식으로 분리 설계 되어있으며, bbs나 reg의 경우에도 과도한 Action 클래스 생성을 막기 위해 중앙 jsp를 만들어서 include하는 방식으로 설계되었습니다.

Layout

  • 몇몇 페이지는 JSP를 효율적으로 다루기 위해 레이아웃을 돌려씁니다. 이 프로젝트에서 사용되는 레이아웃은 다음에 등장하는 규격에 맞춰 강제로 끼워넣습니다.
    • 이렇게 처리하면 디자인을 하나만 수정 해도 여러 곳에서 적용됩니다.
    • 단점으로는, 디자인을 강제한다는 것입니다. 페이지마다 여백을 강제로 지정해야하므로 문제가 발생할 수도 있습니다.
  • main 레이아웃
    • 메인 레이아웃은 메인 페이지에서만 사용됩니다. 즉, 돌려쓰지 않습니다.
  • page 레이아웃
    • page 레이아웃은 기존 홈페이지의 페이지 레이아웃과 동일하게 배치되어 있습니다.
    • 홈페이지 구현 초기에는 이 레이아웃으로 제작을 시도하였으나, 이후 aside 개념이 등장하면서 특정 페이지(마이페이지, 관리페이지)에서만 등장하게 되었습니다.
  • page_stand_alone 레이아웃
    • page 레이아웃은 기존 홈페이지의 페이지 레이아웃에서 side_menu 파트가 사라진 디자인 입니다.
    • 홈페이지 구현 초기에는 이 레이아웃은 주변 jsp들과 유기적으로 사용되지 않고 독립적으로 활동하는 페이지들에서만 사용되었으나, 지금은 aisde가 도입되면서 주류 디자인이 되었습니다.
    • 초창기에 독립적으로 활동하던 페이지들을 stand alone 레이아웃으로 부르기 시작하면서 이 이름이 굳어졌습니다.
  • login 레이아웃
    • 로그인 레이아웃은 로그인 화면에서만 사용됩니다. 즉, 돌려쓰지 않습니다.
    • 아래 register.jsp와 동일한 레이아웃을 사용중이기 때문에 추후 통합 가능성이 매우 높습니다.
  • register 레이아웃
    • 회원가입 레이아웃은 회원가입 화면에서만 사용됩니다. 즉, 돌려쓰지 않습니다.
    • 위 login.jsp와 동일한 레이아웃을 사용중이기 때문에 추후 통합 가능성이 매우 높습니다.

HTML

Global

  • 여러 페이지에 중복되어 등장 하는 코드는 common_settings.jsp에 넣습니다.
    • 중복된 외부 파일 삽입 등이 이에 해당합니다.
    • 대표적으로 헤더의 경우에도 여기저기서 똑같이 동일하게 사용되므로 위 jsp 파일로 처리합니다.
  • class와 id의 역할을 정확하게 숙지하며, 이름이 헷갈리지 않게 명명합니다.
    • 일반적으로 카멜 형식이 아닌 하이픈이나 언더바로 단어를 구분지어 명명합니다.
    • ex) userId (❌) -> user_id (⭕)
  • 한 줄로 표현이 가능한 코드는 되도록 한줄로 씁니다. 
    • <div>⭕ 올바른 예 ⭕</div>
<div>
    ❌ 올바르지 못한 예 ❌
</div>
  • 코드 통일을 위해 form 태그 사용은 권장하지 않습니다. (단, 구 로그인 버전에서는 제한적으로 사용함.)

CSS

Global

  • dd

Bootstrap

  • 부트스트랩은 cdn으로 받지 않고 assets에 있는 부트스트랩으로 적용합니다.
    • 공식 부트스트랩css를 적용하는 경우 테마가 해제됩니다.
  • 잘 모르면 부트스트랩 공식 문서를 참조합니다.
    • 사람들이 일반적으로 겪는 문제의 거의 모든 답이 문서에 잘 나와있습니다.

Custom CSS

  • 가독성을 위해 css 파일을 외부로 생성하지 않습니다.
    • 기존 코드는 css가 외부 파일로 import 되는 경우가 종종 있었지만, 되도록이면 jsp 파일 안에서 정의합니다.
    • css 파일을 따로 만드는 경우 크롬에서 캐시 메모리화 시켜서 수정사항이 제때 반영이 되지 않는 문제가 발생합니다.

Javascript

Global

  • 가독성을 위해 js 파일을 외부로 생성하지 않습니다.
    • 어떤 jsp 파일에서만 조작해야하는 js 코드가 있다면, 외부로 분리하지 않고 해당 jsp 파일 안에 스크립트문을 작성합니다.
    • js 파일을 따로 만들어서 import 하는 경우, 코드 오류 원인 파악이 어렵고 가독성이 매우 떨어집니다.
    • js 파일을 따로 만드는 경우 크롬에서 캐시 메모리화 시켜서 수정사항이 제때 반영이 되지 않는 문제가 발생합니다.
  • 여러 함수에서 공통적으로 여러번 사용해야 하는 변수는 global 변수로 선언하세요
  • 여러 페이지에서 공통적으로 사용되어야 하는 js코드는 main.js에 넣는 것을 추천합니다.
    • 공통적으로 특정 역할을 하는 코드라면 새로운 js를 만들어서 import해도 좋습니다.
  • 함수 명을 알아보기 쉽게 작성합니다.
    • 일반적으로 다음과 같은 접두사를 포함합니다.
    • html을 만드는 메소드 : make
    • 수정하는 메소드 : modify, update
    • 추가하는 메소드 : insert, add, register
    • 삭제하는 메소드 : delete
  • DOM을 조작할 때에는 되도록이면 JQuery를 사용합니다.
    • DOM을 조작하는 코드의 99%가 JQuery를 기반으로 작업되어 있습니다.
    • 가독성을 위해 JQuery 사용을 권장합니다.

Ajax

  • ajax를 요청할 때 변수명을 알아보기 쉽게 합니다.
  • 요청 받고 나서 alert가 필요한 경우, sweetalert 라이브러리를 적용합니다.
  • ajax는 jQuery를 이용하여 사용합니다.

JQuery

  • ㅇㅇ

Ubuntu Server

Tomcat

  • 서버를 중지하고 WAR 파일을 날립니다.
  • 날리기 전에 첨부파일 백업은 필수입니다.

MariaDB

  • 절대로 DB를 날리지 않습니다.
  • 주기적으로 dump 파일을 백업합니다.