2016년 9월 19일 월요일

Apache Common IO의 BOMInputStream의 버그

Java는 BOM을 별도로 처리해주지 않는다고 한다.
http://bugs.java.com/view_bug.do?bug_id=4508058
http://bugs.java.com/view_bug.do?bug_id=6378911

유니코드에서는 UTF-8인 경우 BOM을 넣지 말도록 권장한다.
하지만 넣는다고해서 BOM규칙을 어기는 것도 아니다.
https://en.wikipedia.org/wiki/Byte_order_mark

즉, BOM은 있을 수도 있고, 없을 수도 있고, Java가 알아서 처리해주지도 않는다.
그래서 아파치에서 Common IO에 BOMInputStream을 만들어놨다.
https://commons.apache.org/proper/commons-io/javadocs/api-release/org/apache/commons/io/input/BOMInputStream.html

그런데 BOMInputStream을 사용하면서 뜻밖의 사소한 버그로 고생을 좀 했다.

첫번째 버그
BuffredReader로 감싸서 readLine()을 호출하면 파일의 마지막에서 null을 리턴하지 않고, IOException을 발생시킨다.
이건 2.0.1에서 고쳐진 버그이다.
https://issues.apache.org/jira/browse/IO-257
http://svn.apache.org/viewvc?view=revision&revision=1052095

두번째 버그
hasBOM(ByteOrderMark) 메서드가 올바른 값을 리턴하지 않는다. hasBOM()을 한번 호출하고 나면 올바른 값을 리턴한다. 이건 누군가가 아파치 JIRA에 리포팅해서 수정도 했지만, 반영되진 않은 상태이다.
https://issues.apache.org/jira/browse/IO-482


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
  • 머지 리퀘스트에서는 머 해줄거 없을까....
  • 작업 일지 남기기