잘못알고 있는 말들이나 지식들을 정리(?)

주석

부적절한 정보

  • 다른 시스템(소스 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템 등)에 저장할 정보는 주석으로 적절하지 못하다.
  • 예를 들어
    • 변경 이력은 장황한 날짜와 따분한 내용으로 소스코드를 번잡하게 만든다.

쓸모 없는 주석

오래된 주석, 엉뚱한 주석, 잘못된 주석은 더 이상 필요가 없다.
주석은 빨리 낡는다. 금방 필요없어질 주석은 달지 않는 편이 좋다.

중복된 주석

코드만으로도 충분한데 구구절절 설명하는 주석
i++; // i 증가

성의없는 주석

필요한 주석은 잘 작성되어야 한다.
주석에도 시간을 들여 멋지게 작성해야 한다.
단어를 신중하게 선택한다. 당연한 소리를 반복하지 않고 간결하고 명료하게 작성한다.

주석처리된 코드

코드를 읽다가 주석처리된 코드가 나오면 불편하다.
중요한 코드인지, 필요없는 코드인지 알 길이 없다.
하지만 아무도 삭제할 수 없다. 누군가에게는 필요한 코드일수도 있으니
따라서 해당 코드는 매일매일 낡아간다.
시간이 지나면서 주석처리된 코드 내에 사용된 변수/함수 등의 이름은 바뀌지만 주석코드를 수정하지는 않는다.
주석처리된 코드는 지워라. 필요한 사람이 이전버전을 확인할테니

환경

여러 단계로 빌드해야 한다

빌드는 간단히 한 단계로 끝나야 한다.

여러 단계로 테스트해야 한다

모든 단위 테스트는 한 명령으로 돌려야한다.
IDE에서 버튼 하나로 모든 테스트를 돌린다면 가장 이상적이다.

함수

너무 많은 인수

함수에서 파라미터의 개수는 적을수록 좋다.

출력 인수

Swift에서는 Stored Property를 사용하는 것이 좋을 듯

플래그 인수

Boolean 인수는 함수가 여러 기능을 수행한다는 명백한 증거이다.

죽은 함수

아무도 호출하지 않는 함수는 삭제한다.
주석처리된 코드랑 같은 느낌

일반

한 소스 파일에 여러 언어를 사용한다

오늘날 프로그래밍 환경은 한 소스 파일에서 다양한 언어를 지원한다.
자바 소스 파일 내에 HTML, JS 등을 포함한다.
이상적으로는 소스 파일 하나에 언어 하나만 사용하는 방식이 좋다.

당연한 동작을 구현하지 않는다

함수나 클래스는 '이름'과 연관된 혹은 당연하게 여길만한 동작을 해야 한다.

경계를 올바로 처리하지 않는다

코드는 올바로 동작해야 한다.
하지만 우리는 올바른 동작이 아주 복잡하다라는 말을 간과한다.
부지런함을 대신할 지름길은 없다.
모든 경계 조건, 구석진 곳, 예외는 우아하고 직관적인 알고리즘을 좌초시킬 암초다.
모든 조건들을 커버할 수 있는(커버리지 넓은) TC를 작성해서 테스트하라.

안전 절차 무시

예전 '체르노빌 원전 사고'는 책임자가 안전 절차를 무시하는 바람에 일어났다.
귀찮고 번거롭다는 이유로...

중복

이 책에서 나오는 가장 중요한 규칙 중 하나
DRY 법칙

  • Don't Repeat Yourself
    책에서 이 규칙은 "모든 테스트를 통과한다"는 규칙 다음으로 중요하다고 꼽았다.

코드에서 중복을 발견할 때마다 추상화할 기회로 간주하다.
중복된 코드를 하위 클래스로 분할하라.
이렇듯 추상화로 중복을 처리하면 설계 언어의 어휘가 늘어난다.

  1. 가장 뻔한 유형으로는 똑같은 코드가 여러 차례 나오는 중복이다.
    Ctrl + C/V 처럼 보이는 코드이다.
  2. 여러 모듈에서 일련의 switch/case, if/else 문으로 똑같은 조건을 거듭 확인하는 중복이다.
    이런 중복은 다형성으로 대체해야 한다.
  3. 알고리즘이 유사하나 코드가 서로 다른 중복이다.
    중복은 중복이므로 템플릿 메소드 패턴이나 전략 패턴으로 제거한다.

최근에 나온 디자인 패턴의 대다수는 중복을 제거하기 위한 방법이다

추상화 수준이 올바르지 못하다

추상화는 저차원 상세 개념에서 고차원 일반 개념을 분리한다.
추상화로 개념을 분리할 때는 철저해야 한다.
예를 들어, 세부 구현과 관련한 상수, 변수, 유틸리티 함수는 기초 클래스에 넣으면 안된다.
기초 클래스는 구현 정보에 무지(알고 있지 않는 것이)해야 마땅하다.

EX
public interface Stack{
Object pop() throws EmptyException;
void push(Object o) throws FullException;
double percentFull();
class EmptyException extends Exception{}
class FullException extends Exception{}
}

percentFull() 은 추상화 수준이 올바르지 못하다
Stack을 구현하는 방법은 다양하다.

기초 클래스가 파생 클래스에 의존한다.

개념을 기초 클래스와 파생 클래스로 나누는 이유는 독립성을 보장하기 위해서다.
일반적으로 기초 클래스는 파생 클래스를 몰라야 마땅하다.

과도한 정보

잘 정의된 모듈은 인터페이스가 아주 작다. 하지만 작은 인터페이스로도 많은 동작이 가능하다.
잘 정의된 인터페이스는 많은 함수를 제공하지 않는다. -> 결합도가 낮다.
부실하게 정의된 인터페이스는 많은 함수를 제공한다. -> 결합도가 높다.

클래스는 제공하는 메서드가 작을수록 좋다.
함수는 알고 있는 변수 수도 작을수록 좋다.

자료, 유틸리티 함수, 상수, 임시 변수를 숨겨라

죽은 코드

죽은 코드란 실행되지 않는 코드이다.
불가능한 조건을 확인하는 if / throw 문이 없는 try 문에서 catch 블록
해당 코드는 제거하라

수직 분리

변수와 함수는 사용되는 위치에 가깝게 정의한다.
지역 변수는 처음으로 사용하기 직전에 선언하며 수직으로 가까운 곳에 위치해야 한다.
선언한 위치로부터 몇백줄 아래에서 사용되면 안된다.

일관성 부족

어떤 개념을 특정 방식으로 구현했다면 유사한 개념도 같은 방식으로 구현하라.
착실하게 적용한다면 간단한 일괄성만으로도 코드를 읽고 수정하기 쉬워진다.

잡동사니

비어 있는 기본 생성자가 왜 필요한가?
아무도 사용하지 않는 변수, 호출되지 않는 함수, 정보를 제공하지 않는 주석 등
제거하라

인위적 결합

서로 무관한 개념을 인위적으로 결합하지 않는다.
일반적으로 enum은 특정 클래스에 속할 이유가 없다.
enum이 클래스에 속한다면 enum을 사용하는 코드가 특정 클래스를 알아야만 한다.
범용 static 함수도 마찬가지이다.
편한 곳에 두지 않고, 필요한 곳에 시간을 들여 놓아라

기능 욕심

'마틴 파울러'가 말하는 코드 냄새 중 하나이다.
클래스 메서드는 자기 클래스의 변수와 함수에 관심을 가져야지 다른 클래스의 변수와 함수에 관심을 가져서는 안된다.
메서드가 다른 객체의 참조자와 변경자를 사용해 그 객체 내용을 조작한다면 메서드가 그 객체 클래스의 범위를 욕심내는 것이다.

EX
public class HourlyPayCalculator{
public Money calculateWeeklyPay(HourlyEmployee e){
int tenthRate = e.getTenthRate().getPennies();
int tenthsWorked = e.getTenthsWorked();

    ...

    return new Money(straightPay + overtimePay);
}

}

calculateWeeklyPay 메서드는 HourlyEmployee 객체에서 온갖 정보를 가져 온다.
즉, calculateWeeklyPay 메서드는 자신의 클래스인 HourlyPayCalculator 범위를 넘어 선다.

EX
public class HourlyPayCalculator{
private HourlyEmployee employee;

//생성자(){
    this.employee = e;
}

String reportHoues(){
    return String.format("Name : %s.....", employee.getName(), employee.getTenthWorked()/10...)
}

}

해당 reportHours() 역시 HourlyEmployee 클래스를 욕심낸다. 하지만 HourlyEmployee 클래스가 리포트 형식을 알 필요는 없다.
함수를 HourlyEmployee 클래스로 옮기면 OOP의 여러 원칙을 위반한다.
따라서 이와 같은 예외 케이스에는 다른 클래스를 욕심내는 상황이 있을 수 있다.

선택자 인수

함수 호출 끝에 달리는 false 인수만큼이나 밉살 스런 코드도 없다.
예) 초과 근무 수당은 1.5배로 계산해야 하는 메소드 내에서
public int calculateWeeklyPay(boolean overtime){
...
double overtimeRate = overtime ? 1.5 : 1.0 * tenthRate;
...
}
-> straightPay(), overTImePay(), overTimeBonus() ... 로 쪼개는 것이 낫다.
enum, int, boolean 등의 인수로 함수의 동작을 제어하는 것은 바람직하지 않다.

모호한 의도

코드를 짤 때는 의도를 분명히 밝힌다.

잘못 지운 책임

개발자가 내리는 가장 중요한 결정 중 하나가 코드를 배치하는 위치다.
예) PI 상수는 어디에 들어갈까? -> 삼각함수를 선언한 클래스에 넣어야 한다.

부적절한 static 함수

Math.max(a, b)는 좋은 static 메서드다.
특정 인스턴스와 관련된 기능이 아니다.
new Math().max(a, b)나 a.max(b) 같은 형태가 오히려 더 우습다.

EX
HourlyPayCalculator.calculatePay(employee, overtimeRate);

언뜻 보면 static 함수로 여겨도 적당하다. 특정 객체와 관련이 없으면서 모든 정보를 인수에서 가져오니까
하지만 함수를 재정의할 가능성이 존재한다.
수당을 계산하는 알고리즘이 여러 개일지도 모른다.

OverTimeHourlyPayCalculator 와 StraightTimeHourlyPayCalculator 로 분리하고 싶을지도 모른다.
따라서 해당 메서드는 static이 아닌 인스턴스 메서드가 적절하다.

서술적 변수

프로그램 가독성을 높이는 가장 효과적인 방법 중 하나가 계산을 여러 단계로 나누고 중간 값으로 서술적인 변수 이름을 사용하는 방법이다.

이름과 기능이 일치하는 함수

Date newDate = date.add(5);
해당 코드는 5일, 5시간, 5주 등 어떻게 변경하는 함수인지 알 수가 없다.
또한, 있던 date객체를 변경하는 것인지 새로운 Date객체를 반환하는 것인지 알 수가 없다.

5일을 더하여 변경하는 함수라면 addDaysTo()
5일을 더하여 새 Date 객체를 반환하는 함수라면 daysLater() 가 적당하다.

알고리즘을 이해하라

대다수 괴상한 코드는 사람들이 알고리즘을 충분히 이해하지 않은 채 코드를 구현한 탓이다.
잠시 멈추고 실제 알고리즘을 고민하는 대신, 여기저기 if문과 print를 사용하여 코드를 돌리는 탓이다.
알고리즘을 다 안다고 하지만 실제는 코드가 '돌아갈' 때까지 이리저리 찔러본다.

논리적 의존성을 물리적으로 드러내라

한 모듈이 다른 모듈에 의존한다면 물리적인 의존성도 있어야 한다. 논리적 의존성만으로는 부족하다.

If/Else, Switch/Case 보다는 다형성을 사용하라

3장에서 새 유형을 추가할 확률보다 새 함수를 추가할 확률이 높은 코드에서는 switch가 적합하다 주장했다.

  1. 대다수 개발자가 switch 문을 사용하는 이유는 그 상황에서 가장 올바른 선택이기보다는 쉬운 선택이기 때문
  2. 유형보다 함수가 더 쉽게 변하는 경우는 극히 드물다.

표준 표기법을 따르라

팀은 구현 표준을 따라야 한다.
인스턴스 변수 이름을 선언하는 위치, 클래스/메서드/변수 이름 명명 방법 등을 명시해야 한다.

매직 숫자는 명명된 상수로 교체하라

SECONDS_PER_DAY 는 86,400이다.
하지만 TWO, WORK_HOURS_PER_DAY 같은 상수가 필요할 까?
확실히 TWO는 필요가 없다. 현재 법정 근무 시간이 8시간 이지만 바뀔수도 있으니 WORK_HOURS_PER_DAY는 필요할수도 있다.

정확하라

관례보다 구조를 사용하라

설계 결정을 강제할 때는 규칙보다 관례를 사용한다.
예를 들어, enum 변수가 멋진 ㄴwitch/case 문보다 추상 메서드가 있는 기초 클래스가 더 좋다.

조건을 캡슐화하라

부울 논리는 이해하기 어렵다.
조건의 의도를 분명히 밝히는 함수로 표현하라
if(shouldVeDeleted(timer)) 라는 코드는 아래의 코드보다 좋다
if(timer.hasEcpired() && !timer.isRecurrent())

부정 조건을 피하라

부정 조건은 긍정 조겅보다 이해하기 어렵다.
if(buffer.shouldCompact()) 가 아래 코드보다 좋다.
if(!buffer.shouldNotCompact())

함수는 한 가지만 해야 한다.

함수를 짜다보면 한 함수 안에 여러 단락을 이어, 일련의 작업을 수행하고픈 유혹에 빠진다.

EX
public void pay(){
for (Employee e : employees){
if(e.isPayday()){
Money pay = e.calculatePay();
e.deliverPay(pay);
}
}
}

위의 함수는 3가지 임루를 수행한다.

  1. 직원 목록을 루프로 돌며
  2. 각 직원의 월급일을 확인
  3. 해당 직원에게 월급을 지급

public void pay(){
for(Employee e: employees){
payIfNecessary(e);
}
}

private void payIfNecessary(Employee e){
if (e.isPayday()){
calculateAndDeliverPay(e);
}
}

private void calculateAndDeliverPay(Employee e){
Money pay = e.calculatePay();
e.deliverPay(pay);
}

숨겨진 시각적인 결합

때로는 시간적인 결합이 필요하다. 시간적인 결합을 숨기면 안된다.
public void dive(String reason){
saturateGradient();
reticulateSplines();
diveForMoog(reason);
}

보다는

public void dive(String reason){
Gradient gradient = saturateGradient();
List< Spline > splines = reticulateSplines(gradient);
diveForMoog(splines, reason);
}
가 더 좋다.
함수가 복잡해지기 하지만 시간적인 결합을 명백히 드러내어 수정을 방지하는 역할을 한다.

일관성을 유지하라

코드 구조를 잡을 때는 이유를 고민하라.
그 이유를 코드 구조로 명백히 표현하라.
구조에 일관성이 없어 보인다면, 다른 사람들이 맘대로 바꿔도 된다고 생각한다.

경계 조건을 캡슐화하라

경계 조건은 빼먹거나 놓치기 십상이다. 경계 조건은 한 곳에서 별도로 처리한다.
코드 여기저기에서 처리하지 않는다.
if(level + 1 < tags.length){
parts = new Parse(level + 1);
}
보다는
int nextLevel = level + 1;
을 사용해야 한다.

함수는 추상화 수준을 한 단계만 내려가야 한다

함수 내 모든 문장을 추상화 수준이 동일해야 한다.
그 추상화 수준은 함수 이름이 의미하는 작업보다 한 단계만 낮아야 한다.

설정 정보는 최상위 단계에 둬라

추상화 최상위 단계에 둬야 할 기본값 상수나 설정 관련 상수를 저차원 함수에 숨겨서는 안된다.
대신 고차원 함수에서 저차원 함수를 호출할 때, 인수로 넘긴다.

추이적 탐색을 피하라

일반적으로 한 모듈은 주변 모듈을 모를수록 좋다.
A가 B를 사용하고 B가 C를 사용한다 하더라도 A가 C를 알 필요는 없다.
이를 디미터의 법칙이라 부른다.
내가 아는 모듈이 연이어 자신이 아는 모듈을 따라가며 시스템 전체를 휘저을 필요가 없다는 의미이다.
여러 모듈에서 a.getB().getC() 라는 형태를 사용한다면 설계와 아키텍처를 바꿔 B와 C사이에 Q를 넣기가 어렵다.

점진적인 개선

출발을 좋았으나 확장성이 부족했던 모듈을 소개하고 개선하는 단계로 살펴본다.

.....

이름을 붙인 방법, 함수 크기, 코드 형식

프로그램을 처음부터 잘 짜기란 쉽지 않다.
또한 대부분이 그럴 수 없다.
프로그래밍은 과학보다는 공예에 가깝다. 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다.

글을 쓸 때도 초안 -> 수정 -> 수정 -> 최종안 을 거쳐가 듯, 코드도 단계적으로 개선해야 한다.
대다수의 신참 프로그래머는 해당 단계를 무시하거나 충실히 따르지 않는다.
그들은 돌아가는 프로그램을 목표로 잡는다. 일단 돌아가면 방치한다.

1차 초안

이 표현은 낯 뜨거운 표현이다.
결국 미완성이다.
누구든 첫 버전부터 엉망이진 않다. 버전을 거치며 구현하는 기능이 많아지고 코드가 길어지는 등의 단계를 거듭할수록
코드는 점점 내 손을 벗어난다. (그래서 작게작게 만드는 거??)

최종 목표가 모든 자료형 타입의 인자를 받는 다고 가정하자.

버전 1. boolean 타입만 구현
코드가 그리 엉망은 아니다
버전 2. String 타입도 구현
코드가 점점 길어지며, setBoolean, setString 등의 같은 기능을 하는 중복 메소드가 생긴다.
-> 책에서는 class 상속을 이용하여 중복 메소드를 하나로 줄였다.
버전 3. Int, Double 등 구현
class 상속을 이용하지 않고 별도로 구현시, 사용하는 프로퍼티/메소드 등 쓸데없는 중복이 많을 것이다.

그래서 멈췄다.

버전 2를 마친 후, 코드를 더 작성해서는 안된다.
-> 아직 추가할 타입이 2개나 남았는데, 벌써 코드가 이렇다고? 그 2개를 더 작성하면 어떻게 될지 눈에 훤하다. 그런데도 계속 작성할 것인가?
-> 물론 밀어붙이면 어떻게든 돌아가는 프로그램을 완성했겠지만
-> 그 이후가 문제다. 어떻게 유지보수할 것인가?

코드 구조를 좋은 상태로 만들기 위한 일시정지

  • 기능을 더 이상 추가하지 않고 리팩터링 시작
  • String, Integer 인수 타입을 추가한 경험을 통해, 새로운 인수 타입을 추가하려면 주요 지점 세 곳에다 코드를 추가해야 한다는 것을 겪었다.
    1. HashMap을 선택하기 위해 스키마 요소의 구문을 분석
    2. 인수 유형을 분석해 진짜 유형으로 변환
    3. getXXX 메서드를 구현해 호출자에게 진짜 유형을 반환
  • 인수 유형을 다양하지만 모두가 유사한 메서드를 제공하므로 클래스 하나가 적합하다고 판단하여 ArgumentMarshaler Abstract Class를 작성

점진적으로 개선하다

프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 하에 구조를 뒤집는 행위다
-> 프로그램을 '개선' 전과 같이 돌리기가 어렵다.
-> TDD를 통해 작성되어 있던 TC를 이용할 수 있다.

책에서는 Args Class를 구현하기 이전에 이미 단위테스트와 인수테스트를 만들었다.
그리고 해당 테스트를 모두 통과하면 올바로 동작한다고 봐도 무방했다.

순차적인 개선

기존에 변경되어야 하는 곳(parse, get, set) 메소드를 단번에 수정하지 않는다.

  1. ArgumentMarshaler Abstract Class가 아닌 ArgumentMarshaler Class의 골격을 추가하여 코드를 최소로 건드리는 변경만 가한다.
    • 해당 변경으로 꺠지는 코드를 수정
  2. 수정 후에 테스트케이스를 모두 통과하는지 확인해야 한다.
    • 단번에 많은 코드를 수정하고 테스트를 돌리면 어디가 잘못되었는지 알 수 없다.
  3. 구현할 인수 타입들을 모두 구현한 뒤, ArgumentMarshaler 를 추상 클래스로 선언하고 타입마다 XXXArgumentMarshaler Class를 선언
    • get/set 메소드를 추상 메소드로 선언
  4. Integer/String 에는 Iterator가 필요하지만 Boolean에는 필요가 없었지만, ArgumentMarshaler에서 모두 처리하기 위해, Iterator를 매개변수로 갖는 추상 메소드를 선언
  5. Args Class에서 던지는 예외는 Args와 관련이 있는 것
    • Integer관련 Exception은 IntegerArgumentMarshaler Class에서, String은 StringArgumentMarshaler에서 던진 후, Args와 같은 호출한 곳에서 Args와 관련있는 Exception으로 치환 혹은 생성하여 throw

버전 1에서부터 점진적으로 리팩토링을 진행하면서

  • 주로 Args Class에서 코드를 삭제했다.
    • 삭제된 코드는 ArgsException Class, ArgumentMarshaler Class로 옮겨졌다.

결론

그저 돌아가는 코드만으로는 부족하다. 돌아가는 코드가 심하게 망가지는 사례가 흔하기 때문이다.
설계와 구조를 개선할 시간이 없다고 변명할 지 모르지만 동의할 수 없다.
나쁜 코드보다 프로젝트에 악영향을 미치는 것은 없다

  • 나쁜 요구사항
    • 다시 정의하면 된다
  • 나쁜 팀 역학
    • 복구하면 된다
  • 나쁜 코드
    • 썩어 문드러진다.
    • 팀의 발목을 잡는다.

처음부터 코드를 깨끗하게 유지하기란 상대적으로 쉽다. 아침에 엉망으로 만든 코드를 오후에 정리하기는 어렵지 않다.
그러므로 코드는 언제나 최대한 깔끔하고 단순하게 정리하자.

탭바를 아래로 내리고 위로 올리는 애니메이션을 적용하고 싶었다...

 

그래서 tabBar.frame.size.height = 0 를 animate코드에 넣었는데 원하는 동작이 아니었다...

알아보던 중 size가 아닌 origin.y를 내리고 올리는 방식은 정상동작 한다더라...

if let frame = tabBarController?.tabBar.frame {
	let factor: CGFloat = true ? 1 : -1
	let y = frame.origin.y + (frame.size.height * factor)
	UIView.animate(withDuration: 1.0, animations: {
		self.tabBarController?.tabBar.frame = CGRect(x: frame.origin.x, y: y, width: frame.width, height: frame.height)
	})
}

 

원인은 숙제로 나중에 알아봄!

이전 포스팅에서 간략하게 iOS에서의 애니메이션을 알아보았다.

 

이번에는 좀 더 자세히 알아볼 것이다.

 

View를 구성하는 방법

  1. Frame을 이용
    1. code
  2. AutoLayout을 이용
    1. xib
    2. storyboard

크게 이 두가지 방법을 통해 View를 그리게 된다.

 

Frame-Based Layout

각 View들의 frame을 programmatically하게 설정하여 배치

frame에는 상위뷰(Super View)의 좌표계에 대한 자신의 위치 = origin

상위뷰(Super View)의 좌표계에 대한 자신의 크기 = size

를 가진다.

 

(bounds라는 개념도 존재하는데... frame vs bounds는 이후에 포스팅하는 걸로

중요한 점은 frame은 상위뷰의 좌표계, bounds는 자신의 좌표계라는 것이다.)

 

쨋든 이어서

frame의 정보를 일일이 코드로 작성해야 한다.

-> 일일이라고 적어놓으니깐 불편해 보이는데 좋게 말하자면, AutoLayout의 그 많은 Constraint들을 일일이 작성하지 않아도 된다.

이렇게 말하면 좀 편해보이나?

하지만, 가장 중요한 점 = 아이폰은 지금 12까지 나왔다!

각 아이폰 기기 별 크기는 다르다. -> 개발자가 모든 화면별로 사이즈를 대응해서 코드로 작성해줘야 한다. -> 굉장히 굉장하네

 

frame은 상위뷰 좌표계에서 그려지고 동작한다. 만약, View -> View -> View 같은 nestedView Depth가 깊어질 경우

개발자의 머리는 남아나질 않을 것이다. -> 모두 계산해줘야 하니까

 

 

AutoLayout

frame과는 다른 개념이다. frame체계를 머리속에서 지워보자

 

AutoLayout은 view 사이의 관계를 맺음으로써 화면을 그린다.

Constraint을 기반으로 각 View들의 크기와 위치를 계산한다.

 

이전 포스팅에서 간단하게 작성된 것을 보면 될 것 같다.

 

 

Animate

애니메이션 글인데 왜 frame과 AutoLayout을 적었냐 하면... 사용법에 차이가 있어서 설명했다...(라고 할뻔)

이전 포스팅에 있는 예제를 살펴보자

 

UIView.animate(withDuration: 2.0) {
	self.playPauseButton.frame = CGRect(x: 0, y: 0, width: self.playPauseButton.frame.size.width, height: self.playPauseButton.frame.size.height)
}

UIView.animate(withDuration: 2.0) {
	self.view.backgroundColor = .black
}

두 애니메이션 모두 정상적으로 돌아간다.

그렇다면 frame이 아닌 AutoLayout으로 이뤄진 화면에 적용해보자!

View의 높이를 0으로 만들것이다!

 

 

// view1이라는 녹색 View를 붙였다.
func setView() {
	view.addSubview(view1)
	view1.centerYAnchor.constraint(equalTo: view.centerYAnchor).isActive = true
	view1.leadingAnchor.constraint(equalTo: view.leadingAnchor).isActive = true
	view1.trailingAnchor.constraint(equalTo: view.trailingAnchor).isActive = true
	view1.heightAnchor.constraint(equalToConstant: 60).isActive = true
}

 

자 이제 애니메이션을 적용해보자

 

UIView.animate(withDuration: 1.0) {
	self.view1.frame.size.height = 0
}

 

엥? 난 분명 높이를 0으로 줬는데 왜 오히려 커졌다가 줄어들어?

위에서 view1을 UIView(frame: )으로 생성한 것이 아닌 AutoLayout으로 뷰를 그렸기 때문에, 애니메이션 방법도 달라야 한다.

 

높이 Constraint를 변경하기 위해 프로퍼티를 생성한 후, 참조시키자.

 

var heightConstraint = NSLayoutConstraint()
....
func setView() {
	view.addSubview(view1)
	view1.centerYAnchor.constraint(equalTo: view.centerYAnchor).isActive = true
	view1.leadingAnchor.constraint(equalTo: view.leadingAnchor).isActive = true
	view1.trailingAnchor.constraint(equalTo: view.trailingAnchor).isActive = true
	heightConstraint = view1.heightAnchor.constraint(equalToConstant: 60)
	heightConstraint.isActive = true
}

 

UIView.animate(withDuration: 1.0) {
	self.heightConstraint.constant = 0
}

그리고 실행 시켜보자.

 

0으로 되긴 했네... 근데 애니메이팅이 아니라 그냥 뿅??

 

frame이나 alpha, backgroundColor 는 Animatable한 built-in 속성이기 때문에 애니메이팅이 동작한다.

하지만 Constraint는 Animatable한 built-in 속성이 아니기 때문에, layoutIfNeeded()라는 메소드의 호출이 필요하다.

layoutIfNeeded()는 또 이전 포스팅에 있다.

 

호출이 필요한 이유는 Constraint의 변경이 실제로 View에 적용되기 위해서는 일련의 순서가 필요하기 때문이다.

  1. 변경될 값에 맞춰 시스템이 해당 Constraint를 포함하여 연관있는 Constraint들의 모든 값들을 재계산
    1. 앞에서 말했 듯, Constraint는 view들의 관계이기 때문에, 하나의 View가 변경되면 다른 View들도 그에 맞춰 변경되기 때문
  2. layout 엔진이 재계산된 Constraint에 맞춰 모든 View들의 frame들의 값을 재계산하고 배치한다.
  3. 해당 frame들을 화면에 그린다.

그럼 그렇게 다시 해보자!

heightConstraint.constant = 0
UIView.animate(withDuration: 1.0) {
	self.view1.layoutIfNeeded()
}

엥? view1.layoutIfNeeded()까지 했는데 왜 안돼...?

(개인적인 생각으로는 view1의 Constraint들은 대부분 self.view와 연관되어 있다. 그러한 이유로 안되지 싶다...)

 

그럼 코드를 바꿔서 진행해보자

heightConstraint.constant = 0
UIView.animate(withDuration: 1.0) {
	self.view.layoutIfNeeded()
}

정상적으로 원하는 대로 동작한다..!

 


정리

  1. frame방식과 AutoLayout을 통해 View를 그릴 수 있다.
  2. frame과 AutoLayout 각각 다른 코드진행으로 animate할 수 있다.
    1. frame과 alpha 등은 Animatable한 built-in 속성이기 때문에, layoutIfNeeded()가 필요없다
    2. AutoLayout은 Animatable한 built-in 속성이 아니기 때문에, layoutIfNeeded()가 필요하다
  3. animation을 적용한 view에서 layoutIfNeeded()를 호출하는 것이 아니라, 해당 view와 Constraint로 관련되어있는 SuperView에서 호출해야 한다.

 

 

+ Recent posts