11. Coding

11. Coding

코딩시 주의사항

코딩시 주의사항은 굳이 소프트웨어 공학론이 아니더라도 많이 찾아볼 수 있다. 그리고 에러의 종류가 워낙 방대하다보니 그때그대 상황에 맞추어 학습하는 편이 훨씬 도움될 것이다. 일단 코드컨벤션에 맞추어 코딩하는 것을 우선하자.

UML 보고 코딩하기

요구사항 분석 → 모델링 → 설계를 마치고 드디어 구현까지 왔다. UML의 대표적인 다이어그램 3개를 보고 어떻게 실제 코드로 구현할지 알아보자.

Class Diagram 보고 코딩

Modeling -2(UML)에서도 설명했던 부분이다.

• 접근제한자는 +, -, #를 보고 판단한다.
• 반환 형식은 : 뒤에 나오는 것으로 판단한다. 없으면 void 형식이다.
• 가운데 칸은 변수를, 아래 칸은 함수를 선언한다.

• 밑줄은 static을 의미한다.

  

• 상속은 화살표를 받는 쪽이 부모이다.

• 다른 클래스 형식을 멤버변수로 가질 때는 그 수나 이름을 표기한다.

  

• Aggregation은 인자를 받지만, 인자가 없다고 사라지지 않는다. 매개변수로 인자를 받는 모습이다.

  

• Composition은 매개변수를 받지 않는 모습이다. 요소를 분리할 수 없다.

  

• Dependance는 매개변수나 반환값으로 이어진 관계이다.

  

Sequence Diagram 보고 코딩

Sequence Diagram에서는 표현되기 어려운 부분들도 구현해야한다. 다시말해 diagram과 code가 1:1로 대응하지 않는다는 말이다.

• 화살표가 향하는 객체는 화살표의 함수를 가진다.
• 함수를 사용하기 전에 해당 함수를 가진 클래스의 객체 생성이 필요하다.

State Diagram 보고 코딩

각각의 State는 static 으로 표현되며, state간의 전환을 의미하는 화살표는 함수로 표현된다. 화살표의 개수만큼 함수를 만들어야 한다.

---

리팩토링

리팩토링이란 기존의 기능을 변경하지 않고 코드의 구조를 재조정(Behavior Preserving)하는 것이다. 이를 통해 새로운 코드를 더하기 쉬워지고, 코드 디자인을 향상시키며, 사용자 이해도를 높일 수 있다. 참고로 기존의 기능이 변경되었는지를 확인하려면 전후를 비교하는 테스트를 진행해야한다.

리팩토링을 사용하는 부분은 많지만, 단순하게 몇 가지만 알아보자.

• 두 모듈이 밀접하여 떼어놓을 수 없으면 하나로 합쳐라.

• 같은 결과를 반환하는 모음은 하나로 합쳐라.

  

• 조건이 여러개여서 알아보기 힘들다면 따로 분리하라.

  

• 하나의 클래스에 작업이 몰린다면 여러 클래스로 분산하라. 이는 메소드에도 적용된다.

리팩토링의 리스크

리팩토링은 항상 장점만 있는 것이 아니다. 리팩토링을 시도했다가 오히려 새로운 버그가 발생하고, 불필요한 코드가 증가하기도 한다. 또한 리팩토링은 비용이 많이 드는 작업이다.

• 매뉴얼을 수정해야한다.
• 관련 문서들 또한 수정해야한다.
• 테스트케이스의 변경이 있을 수 있다.

따라서 마감 직전이나, 코드를 건드리기 힘들거나, 굳이 할 이유가 없을때는 리팩토링을 하지 말자.

코드스멜

코드스멜(Code Smell)은 코딩에 있어서 문제를 일으킬 가능성이 있는 프로그램 소스 코드의 특징을 의미한다. 코드스멜을 발견한다면 해당 부분을 리팩토링하여 문제 발생을 예방할 수 있다. 예를 들어보자(Code smell → Refactoring)

• 중복된 코드(Duplicated code) → Extract method
• 여러 클래스 동시수정(Shotgun surgery) → Move method, Inline Class…
• 다른 클래스의 잦은 참조(Feature Envy) → Extract method, Move method

이외에도 많은 코드스멜이 존재한다. 해당 사이트에서 자세한 내용들을 볼 수 있다.

참고자료

• https://ko.wikipedia.org/wiki/코드_스멜
• 소프트웨어 공학의 모든 것(최은만, 생능출판사, 2020)
• https://refactoring.guru/refactoring/smells