2016년 9월 7일 수요일

git repo로 구성된 소스코드의 Tab과 Space 일괄 통일 작업 계획

소스코드의 들여쓰기를 Tab과 Space 중에 무엇으로 하는가에 대한 이야기가 있다. 설문조사도 있고, github의 현황을 통계낸 자료도 있다. 업무로 개발중인 소스코드에서는 표준없이 마구 개발하다보니 통일되어 있지 않은데, 관련해서 생각을 정리해본다.

왜 통일하려고 하는가?

  • 머지 리퀘스트 diff 중에 공백문자로 인한 불필요한 diff를 보기 싫어서
  • 에디터 설정에 따라서 인덴트가 둘쑥날쑥하면 소스 보기 어려워서
  • 마음속 깊은 곳의 불편함을 없에고 싶어서
  • 그냥 해보고 싶어서

통일작업시 고려할 것은?

  • Tab과 Space중 무엇으로 할 것인가? (개발팀의 의견 중요)
  • Space로 하면 몇 칸으로 할 것인가? (2 or 4)
  • Space를 Tab으로 바꾸면 Space 몇 칸을 Tab 1개로 할 것인지?
  • Space 나머지는 어떻게 할 것인지? (ex: Space 4이 Tab1개인데, Space가 14칸일때 Tab은 몇개?)
  • 바꾸고 나면 인덴트가 틀어지는데, 파일 전체의 자동 인덴트를 할 수 있을지?

통일작업 이외에 고려할 것은?

  • 언제 BigBang 날짜를 잡을 것인가?
  • 작업중인 feature 들은 어떻게 할지? (머지 리퀘스트 할때 conflict 날텐데 ㅠㅠ)
  • 하는 김에 줄끝의 공백문자도 같이 지워주면 좋다.
  • 하는 김에 줄바꿈 문자도 통일하면 좋다.
  • 공백문자만 변경된 머지 리퀘스트는 공백문자만 바뀌었는지를 어떻게 보장할지?
  • development에서 작업하고나서, 다음 master 머지전까지 master에서 변경되는 hotfix는 develoment로 어떻게 (자동으로) 머지할지?

통일작업 완료되면 할일은?

  • 개발표준 문서/위키 변경 및 공지
  • 모든 개발자의 에디터의 Save Action 설정 통일
  • 커밋 훅 추가해서 안지켜진 소스는 reject
  • 머지 리퀘스트에서는 머 해줄거 없을까....
  • 작업 일지 남기기

댓글 없음:

댓글 쓰기