'소스코드'에 해당되는 글 1건

  1. 2007.01.05 소스 코딩시 주의하여할 몇가지
웹개발(JSP&Servlet)2007.01.05 19:01

1. 만들지 않은 소스 코드에 버그는 없다.
  당연히 소스 코드를 만들지 않으면 버그를 발생하지 않는다. 그러나
  소스코드를 만들면 버그가 발생할 가능성이 생긴다.
  따라서, 이미 사용하고 있는 버그없는 소스 코드가 있다면
  그것을 이용하는것이 가장 좋다.
  <소스코드를 만들기 전에 이전 코드를 조사할것. 그리하여
  비슷한것이 있다면 재사용을 고려하여야 한다>

2. 같은 소스 코드는 메소드화하고, 나서 클래스화 한다.

3. 너무 깊은 인덴트 부분은 메소드화 한다.
  <인덴트가 깊으면 알아보기 어렵다. 이런 떄는 메소드화 하여 인덴트계층을
  낮춘다>

4. 큰 클래스는 분할을 검토한다.
  파일 용량이 큰 클래스는 가독성이 떨어진다.
  <1000행을 넘는 클래스는 파일 분할을 검토한다>

5. '한 개의 파일에 클래스 한 개' 정책
  한 개의 파일에 한 개의 클래스를 기본 원칙으로 두지 않으면,
  나중에 클래스를 검색하는 경우에 파일명으로 검색할수 없게 되어
  가독성이 극단적으로 저하된다.

6. 클래스의 책임(responsibility)를 생각한다.
  어느 객체에 어떤 메소드를 배치해야 하는 것인가? 그 클래스가 책임을
  가지고 관리해야 하는 데이타는 무엇인가를 생각하지 않으면,
  여기저기의 데이타가 항상 필요하게 되거나, 그 클래스 자체는 필요도
  없는 큰 배열을 갖디 않으면 안되게 된다. 또한 클래스간의 관계를
  잘 알수가 없어 작동은 되지만, 의미를 알수없는 코드등이 만들어지게되어
  독립성과 재사용성이 낮아진다.
  <클래스 설계는 이렇게 하는것이다란 강한 지침이 필요>

7. 글로벌 데이타를 한곳에 모으지 않는다.
  상수값 정보를 한곳으로 모으는 방법은 클래스 책임에 대한 사고방식에
  위배됨. 정말로 필요한 클래스에 이 상수값을 분산 배치 시킨다.


8. 에러의 복잡한 처리를 피한다.
  try/catch를 활용 에러처리의 복잡함과 이중성을 피할수 있다.
  너무 많은 try/catch는 성능저하를 야기. if로 간단 처리 할수있는것은
  try/catch를 사용하는것을 자제한다.

9. 클래스명과 메소드명에 번호를 사용하지 않는다.
  가독성이 극단적으로 낮아진다. 어쩔수 없이 사용한다면 '3'을 넘지
  않도록한다.

10. '데이터가 대부분인 소스 코드'는 쓰지 않는다.
  파일에서 이름을 지어 디자인 패턴과 소스 코드를 분리하는 편이
  다소 어렵지만 수정하기 쉽다.

Anti Design-Pattern중 맨 단락~에서

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 영겁회귀

티스토리 툴바