SW 재사용 - 코딩오류,코드스멜,리펙토링

코딩오류,코드스멜,리펙토링

 

1. 코딩 오류 : 코딩은 모듈에 대한 원시코드 작성하고 오류를 검출하는 단계로 코딩오류는 설계 명세상의 누락이나 프로그래밍 기법상의 결함 지칭

2. 코드 스멜 : Kent Beck에 의해 처음 제시되어 프로그램 가독성이 나쁘고 중복된 로직을 포함하는 등 코드품질을 저하시키는 요인들을 총칭

  (ex-길다, 많다, 겹쳐있다, 이름이 어색하다, 객체지향적이지 않다 등)

 

3. 리팩토링 : 코딩 오류 가능성을 최소화하기 위해 프로그램 내에서 이해하기 어렵고 수정하기 힘들며, 확장하기 어려운 코드(=코드 스멜)를 원래 기능을 그대로 두면서 내부구조를 개선하는 활동

 

4. 코딩오류 종류 : 메모리 누수/중복된 Free선언/NULL의 사용/별칭의 남용/배열 인덱스오류/수식예외 오류/하나 차이에의한 오류/자료형 오류/스트링/버퍼 동기화

 

5. 코드스멜 종류 : 중복된 코드/긴 메소드/큰 클래스/너무 많은 인수/두 가지 이상의 이유로 수정되는 클래스(Divergent Class)/여러 클래스를 통시에 수정

         다른 클래스를 지나치게 애용 (Feature Envy)/유사 데이터들의 그룹 중복(Data Clumps)/기본 데이터 타입 선호 (Primitive Obsession)

 

6. 리펙토링 주요기법 :

1) Extract Method : 그룹으로 함께 묶을 수 있는 코드 조각을 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드를 추출

2) Replace Temp With Query : 어떤 수식의 결과값을 저장하기 위해서 임시 변수를 사용하고 있다면, 수식을 추출해서 메소드를 만들고, 임시

             변수를 참조하는 곳을 찾아 모두 메소드 호출로 교체

3) Move Method : 메소드를 가장 많이 사용하고 있는  클래스에 비슷한 몸체를 가진 새로운 메소드 생성

4) Extract Class : 두 개의 클래스가 해야 할 일을 하나의 클래스가 하고 있는 경우 새로운 클래스를 만들어 관련 있는 필드와 메소드를

              예전 클래스에서 새로운 클래스로 이동

5) Rename Method : 메소드의 이름이 그 목적을 드러내지 못하고 있다면 메소드의 이름 변경

6) Substitute Algorithm : 알고리즘을 보다 명확한 것으로 바꾸고 싶을 는 메소드의 몸체를 새로운 알고리즘으로 교체

7) Inline Method : 메소드 몸체가 메소드의 이름 만큼이나 명확할 때는 호출하는 곳에 메소드의 몸체를 넣고 메소드를 삭제

 

 

인스턴트 앱의 크기 제한은 로컬로 빌드된 바이너리에 적용되지 않으므로 인스턴트 앱을 개발하는 동안 바이너리 크기에 대해 염려할 필요는 없습니다. Play Developers Console을 통해 바이너리를 개발 트랙(개발 과정에서 인스턴트 앱을 신속히 배포할 수 있는 특별 트랙)에 게시할 수도 있습니다. 개발 트랙의 크기 제한은 10MB이고, [1, 2] 바이너리가 개발 트랙을 거치고 나면 4MB 제한이 적용됩니다.

 

각 기능 모듈에는 주어진 URL에 대응하는 진입점(즉, Activity)이 하나 이상 있을 수 있습니다. 단일 코드베이스를 다중 모듈로 분할할 때 기능마다 각기 다른 진입점을 구성할 수 있으며, 필요에 따라 관련 기능을 추가로 로드할 수 있습니다. 특정 진입점에 다운로드해야 하는 총 바이너리는 4MB 미만이어야 하므로, 기능 모듈과 기본 모듈을 합친 크기가 4MB 미만이어야 한다는 점을 유의하시기 바랍니다.

 

 

각각의 기능과 기능을 수행하기 위한 Activity, 및 해당 기능에 진입하기 위한 URL 매핑을 먼저 정의한 후각 진입점에 대한 바이너리 크기를 줄이는 방향으로 리팩터링 작업을 구성하는 것이 좋습니다.

 

라이브러리를 어떻게 포함할지도 고려해야합니다. 특정 기능 모듈에만 필요한 라이브러리의 경우 기본 기능 모듈에 추가하는 대신, 해당 기능 모듈에만 라이브러리를 포함시킬 수 있습니다. 예를 들어 라이브러리 X, Y, Z에 종속되는 애플리케이션이 있다고 가정해 봅니다. 그러면 모든 종속 사항을 기본 모듈의 gradle.build 파일에 정의하여, 기본 모듈에 모든 라이브러리를 패키징할 수 있습니다. 하지만 기능 모듈의 코드에 라이브러리 Z만 필요한 경우 기본 모듈에서 해당 종속 사항만 기능 모듈로 이동하는 것이 합리적입니다. 여러 기능 모듈이 같은 라이브러리를 사용하는 경우에는 기본 모듈에 라이브러리를 유지하는 것이 좋습니다.

 

 

 

“실행보다는 선언 : 선언적인 방식의 프로그래밍은 코드를 변경하지 않으면서 유연성을 제공할 수 있다.”

 

《프리팩토링》, “Chapter 5. 클래스 작성”, 107p, 한빛미디어

 

• 추상화를 하려면 끝까지 추상화하라
• 고객의 언어를 사용하라
• 결합된 것을 분할하는 것보다 분할된 것을 결합하기가 더 쉽다
• 찬 공기가 들어오지 못하도록 하라
• 크게 계획하고 지역적으로 개발하라
• 꿀 먹은 벙어리가 되지 마라
• 코드로 의사소통을 하라
• 목적지를 알기 전에는 속력을 내지 마라
• 디버깅하기 가장 쉬운 코드는 작성되지 않은 코드다

 

실사례 : https://helloworld.kurly.com/blog/rms-refactoring/?fbclid=IwAR0Ej8tnklxyc0kPVeyxX_CMKDSmtY_IyyGo2WHfMHRoxMEN6VF1TsF5lZQ

코드 악취를 맡는 후각 훈련의 시간

https://developers-kr.googleblog.com/2017/09/android-instant-apps-best-practices-for-managing-download-size.html

안드로이드 인스턴트 앱 다운로드 크기를 줄이는 모범 사례를 만나보세요.