9. 코딩

●코딩

분리하여 구현할 수 있는 작은 단위를 프로그래밍하는 작업

설계 명세에 나타낸 대로 요구를 만족할 수 있는 프로그래밍

 

●언어

COBOL(사무 응용 분야), Fortran(과학 및 공학 분야), C 언어(시스템 프로그래밍, 임베디드 응용), Pascal(프로그래밍 교육), Modula-2(시스템 프로그래밍), Ada(실시간 처리 응용), Lisp,Prolog(인공지능), HTML,ASP,PHP,JSP(웹 프로그래밍), JAVA(인터넷 프로그래밍), Android,Object0C(모바일 프로그래밍), Scratch(교육용)

 

●코딩 오류

메모리 누수, 중복된 프리 선언, NULL의 사용, 별칭의 남용, 배열 인덱스 오류, 수식 예외 오류, 하나 차이에 의한 오류, 사용자 정의 자료형 오류, 스트링 처리 오류, 버퍼 오류, 동기화 오류

 

●메모리 누수

메모리가 프리 되지 않고 프로그램에 계속 할당되는 현상

오래 수행되는 시스템에는 치명적인 영향

 

●중복된 프리 선언

프로그램 안에서 사용하는 자원은 먼저 할당되고 사용 후에는 프리로 선언

이미 프리로 선언된 자원을 또 다시 프리로 선언하는 경우 오류

 

●배열 인덱스 오류

배열 인덱스가 한도를 벗어나면 예외 오류 발생

배열 인덱스가 음수 값을 갖는 경우 오류 발생

 

●사용자 정의 자료형 오류

오버플로우나 언더플로우 오류가 쉽게 발생

 

●동기화 오류

공통 자원을 접근하려는 다수의 스레드가 있는 병렬 프로그램에서 흔히 발생

데드락 : 다수의 스레드가 서로 자원을 점유하고 릴리스 하지 않는 상태

레이스 컨디션 : 두 개의 스레드가 같은 자원을 접근하려 하여 수행 결과가 스레드들의 실행 순서에 따라 다르게 되는 경우

모순이 있는 동기화 : 공유하는 변수를 접근할 때 로킹과 언로킹을 번갈아 하는 상황에서 오류가 많이 발생

 

●정보 은닉

모듈 사이의 결합을 줄이고 시스템의 유지보수를 쉽게 만듦

소프트웨어 개발에서 복잡함을 다루는 중요한 수단

C++, Java, C#은 정보 은닉을 실현하는 메커니즘을 언어 자체가 가지고 있음

 

●디메테르의 법칙

프로그램의 모듈 사이의 결합을 최소화 하려는 것

코드의 적응성과 강인성 향상

 

●MISRA-C 코딩 표준

영국 협회인 MISRA에서 C프로그래밍 언어에 대한 코딩 가이드라인 발표

안전성이 중요한 자동차, 우주항공, 철도, 국방 부분에 사용되는 임베디드 소프트웨어의 결함을 줄이기 위한 코딩 표준

 

●연관의 구현

클래스 A와 B 사이에 1대 1연관 관계가 있다

1대1연관 : A에서 B의 함수를 호출할 필요가 있다면 A가 B에 대한 참조를 갖도록 구현, 반대도 같은 방식

1대다 : 클래스 A에서 인스턴스 B의 메소드를 호출할 것이 있다면 클래스 A가 클래스 B의 참조를 모음으로 가지고 있도록 구현

다대다 : 중간에 연관 클래스를 도입하여 1대다의 관계로 바꾸어 설계하기도 함

 

●시퀀스 다이어그램의 구현

객체의 동적인 측면을 모델링한 것

오퍼레이션의 종류와 클래스 사이의 관계를 파악하기 위하여 각 객체가 주고받는 메소드를 나타냄

 

●상태 다이어그램의 구현

상태 : 상태정보를 저장하기 위한 속성을 클래스에 추가

이벤트 : 객체의 상태를 변화시키는 것

컨디션 : 상태변화를 일으키는 조건을 나타낸 것

액션 : 메소드 안에 탑재

초기 상태에서 첫 상태로 진입하는 것은 생성자로 구현

생성자 안에서 상태 변수와 기타 변수를 초기화

 

●리팩토링(Refactoring)

프로그램 실행 결과의 변경 없이 코드의 구조를 재조정

이미 존재하는 코드의 디자인을 안전하게 향상 시키는 기술

가독성을 높이고 유지보수를 편하게 하기 위한 것

겉으로 보이는 동작의 변화 없이 내부구조를 변경하는 것

목적 : 소프트웨어의 디자인 개선, 이해하기 쉽게, 버그를 찾는데 도움, 빨리 작성할 수 있게 도와줌

 

●리팩토링 과정

소규모의 변경 : 단일 리팩토링

코드가 전부 잘 작동되는지 테스트

전체가 잘 작동하면 다음 리팩토링 단계로 전진

작동하지 않으면 문제를 해결하고 리팩토링한 것은 undo하여 시스템이 작동되도록 유지

 

●코드 스멜(Code Smell)

프로그램에 대한 작업을 어렵게 만드는 것

읽기 어려운 프로그램

중복된 로직을 가진 프로그램

실행 중인 코드를 변경해야 하는 특별한 동작을 요구하는 프로그램

복잡한 조건문이 포함된 프로그램

소프트웨어를 보다 쉽게 이해할 수 있고 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화없이 내부 구조를 변경

 

●코드 스멜 사례

중복된 코드 : 기능이나 데이터 코드가 중복

긴 메소드 : 메소드의 내부가 너무 길다

큰 클래스 : 한 클래스에 너무 많은 속성과 메소드가 존재

긴 파라미터 리스트 : 메소드의 파라미터 개수가 너무 많음

두가지 이상의 이유로 수정되는 클래스 : 한 가지 종류의 책임만을 수행하는 것이 아님

여러 클래스를 동시에 수정 : 그때마다 관련된 여러 클래스들 내에서 자잘한 변경을 해야함

다른 클래스를 지나치게 애용 : 빈번히 다른 클래스로부터 데이터를 얻어 와서 기능을 수행

유사 데이터들의 그룹 중복 : 3개 이상의 데이터 항목이 여러 곳에 중복

기본 데이터 타입 선호 : 객체 형태 그룹을 만들지 않고 기본 데이터 타입만 사용

Switch, If 문장 : switch문장이 지나치게 많은 case를 포함

병렬 상속 계층도 : 비슷한 클래스 계층도가 지나치게 많이 생겨 중복 유발

 

●Divergent Change

문제 : 한 클래스가 두 가지 이상의 이유로 수정되는 경우

해결책

+ 한 가지 이유만으로 수정되도록 클래스 변경

+ 한 가지 종류의 책임만을 수행하도록 변경

+ Extract Class Refactoring 적용

 

●Shotgun Surgery

특정 클래스를 수정하면 관련된 여러 클래스들에 대한 변경 필요

Divergent change와 유사하지만 반대 개념

하나의 변경이 여러 클래스에 걸쳐서 발생

해결책 : Move Method, Move Field, Inline Class

 

●Feature Envy

메소드가 정의된 클래스보다 다른 클래스에서 더 사용되는 경우

빈번히 다른 클래스로부터 데이터를 얻어 와서 기능 수행

해결책 : Method Move, Extract Method

 

●Data Clumps

데이터 항목이 여러 클래스나 메소드에 중복되어 나타나는 경우

해당 데이터들은 독립된 클래스에 함께 정의함

해결책 : Extract Class, Introduce parameter objects, Preserve whole objects

 

●Primitive Obsession

객체 형태 그룹을 만들지 않고, 기본 데이터 타입만 사용

기본 데이터 타입 : 객체가 아닌 타입으로 int, float, char 등을 의미

해결책 : Replace data value with object, Replace type code with class

 

●Switch Statements

switch 문장이 지나치게 많은 case를 포함하는 경우

동일한 클래스의 다른 인스턴스들에 대한 로직을 포함하는 switch 문장들이 존재

해결책 : 서브클래스 작성, case 문에 있는 로직을 각 서브클래스의 메소드로 이동

 

●Lazy Class

클래스 생성으로 인한 비용은 무시할 수 없으므로 충분한 기능을 하지 않는 클래스는 제거

Inline Class refactoring을 통해 기능이 미비한 클래스 제거

서브 클래스들이 충분한 기능을 수행하지 못하면 Collapse Hierarchy를 사용

 

●Hide Delegate Refactoring

클라이언트에게 delegate 객체를 숨김

클라이언트는 delegate에 대한 세부적인 내용을 알 필요 없이 원하는 서비스를 제공받을 수 있음

Delegate에 대한 코드가 변경되어도 클라이언트 코드는 변경할 필요가 없음

 

●안전하게 리팩토링

리팩토링을 작게 유지해라

한번에 하나의 리팩토링을 해라

즉각적으로 필요하지 않은 변경 사항 목록을 작성 후 나중에 수행

 

●코드 품질 향상 기법

코드 인스펙션 : 프로그램을 읽어보고 눈으로 확인하는 방법

정적 분석 ; 수행되지 않는 데드 코드(Dead Code)가 없는지, 선언이 되지 않고 사용한 변수가 없는지 등을 검사

페어 프로그래밍 : 애자일 방법에서 프로그래밍과 테스팅을 담당하는 두 사람이 머신을 공유하며 코딩

 

●코드 인스펙션

프로그램이 성공적으로 컴파일 되고 정적 분석 도구에 의해 검사된 후 이루어짐

코드에 묻혀있는 결함을 찾아내는 것(효율성, 코딩 표준의 준수 여부 등)

심각도 : 결함의 우선순위를 나타냄

결함의 타입 : 로직 문제, 컴퓨팅 문제, 인터페이스/타이밍 문제, 데이터 처리

 

●정적 분석

프로그램 텍스트를 조직적으로 분석하여 결함을 찾아내는 것

소프트웨어 도구를 이용해 자동으로 가능

방법 : 코드에 존재하는 결함으로 나타날 비정상적인 패턴이나 원하지 않는 패턴을 찾아내는 방법, 실행할 때 프로그램의 고장을 일으킬 코드 상에 존재하는 결함을 직접 찾는 방법

자료 변칙(Data Anomaly) : 자료 흐름을 분석하면 자료가 정의되지 않고 사용되거나 정의되고 사용되지 않는 비정상적인 패턴을 찾는 것

사족(Redundatnt Code) : 컴파일러에 의해 검출되지 않음(중복된 배정문, 데드 코드, 조건 중복 등)

 

●FindBugs

자바 프로그램에서 정적 분석을 위한 툴

버그 패턴을 기반으로 버그를 찾음

 

●페어 프로그래밍

두 사람이 같은 컴퓨터를 사용하면서 같이 프로그램을 완성

스트레스와 성공의 기쁨을 나눌 상대가 있기 때문에 프로그래밍에 재미가 있고 압박을 줄일 수 있음

파트너와 아이디어를 교환하기 때문에 팀의 소통을 향상시킬 수 있음

팀 구성원이 서로를 이해하고 여러 가지 방법으로 서로에게서 배우기 때문에 상호 이해와 협력이 향상

토론이 창의적인 사고로 발전하여 문제 해결에 도움이 되므로 간단하고 효율적인 해법을 만들어 낼 수 있음

핑퐁 프로그래밍 : 한 개발자가 테스트를 작성하고 다른 개발자가 기능을 구현