HEROHJK Document

Xcodes를 사용할 때, 간단하게 터미널로 심볼릭 링크를 만들어주는 파이썬 스크립트.

HEROHJK — Tue, 25 Apr 2023 18:19:18 +0900

import os
import sys
from pathlib import Path

# 사용 가능한 Xcode 버전을 검색하고 목록으로 반환하는 함수
def find_xcode_versions():
    app_dir = Path('/Applications')
    xcode_versions = [entry for entry in app_dir.iterdir() if entry.is_dir() and entry.name.startswith('Xcode-')]
    return xcode_versions

# 심볼릭 링크를 생성하는 함수
def create_symlink(version):
    xcode_symlink = Path("/Applications/Xcode.app")

    if xcode_symlink.is_symlink():  # 기존 심볼릭 링크가 존재하면 삭제
        xcode_symlink.unlink()

    os.system(f"ln -s /Applications/{version} /Applications/Xcode.app")  # 새 심볼릭 링크 생성
    print(f"\033[32m심볼릭 링크가 /Applications/{version}로 설정되었습니다.\033[0m")

    # 기본 Xcode 버전을 설정
    os.system(f"sudo xcode-select -s /Applications/{version}/Contents/Developer")
    print(f"\033[32m기본 Xcode 버전이 {version}로 설정되었습니다.\033[0m")


def version_tuple(version_str):
    return tuple(map(int, (version_str.split("."))))

# 입력된 버전 문자열과 일치하는 가장 최신 버전을 반환하는 함수
def find_latest_matching_version(input_version, xcode_versions):
    matching_versions = [version for version in xcode_versions if version.name.startswith(f"Xcode-{input_version}")]
    if not matching_versions:
        return None

    latest_version = max(matching_versions, key=lambda x: version_tuple(x.name[6:-4]))
    return latest_version.name


def get_current_xcode_version():
    result = os.popen("xcode-select -p").read().strip()
    if "/Applications/" in result:
        xcode_path = result.split("/Contents/Developer")[0]
        current_version = os.path.basename(xcode_path)
        return current_version
    else:
        return None


def select_xcode_version():
    xcode_versions = find_xcode_versions()
    current_xcode_version = get_current_xcode_version()

    if not xcode_versions:
        print("\033[31mXcode 버전을 찾을 수 없습니다.\033[0m")
        return

    print("사용 가능한 Xcode 버전:")
    for idx, version in enumerate(xcode_versions, start=1):
        if version.name == current_xcode_version:
            print(f"\033[32m{idx}: {version.name} (현재 설정된 버전)\033[0m")
        else:
            print(f"\033[32m{idx}: {version.name}\033[0m")

    print("\033[31m0: 돌아가기\033[0m")

    while True:
        try:
            user_choice = int(input("사용할 Xcode 버전 번호를 선택하세요: "))
            if 1 <= user_choice <= len(xcode_versions):
                selected_version = xcode_versions[user_choice - 1].name
                create_symlink(selected_version)
                break
            elif user_choice == 0:
                exit()
            else:
                print("\033[31m목록에 없는 번호입니다. 다시 시도해주세요.\033[0m")
        except ValueError:
            print("\033[31m올바른 숫자를 입력해주세요.\033[0m")


if __name__ == "__main__":
    print("\n\n\n\n\n====================Xcode-Version-Selector====================")
    if len(sys.argv) > 1:
        input_version = sys.argv[1]
        xcode_versions = find_xcode_versions()
        xcode_version_names = [xcode_version.name for xcode_version in xcode_versions]

        matching_version = find_latest_matching_version(input_version, xcode_versions)

        if matching_version:
            create_symlink(matching_version)
        else:
            print("\033[31m입력한 버전과 일치하는 Xcode를 찾을 수 없습니다. 사용 가능한 버전 목록을 표시합니다.\033[0m")
            select_xcode_version()
    else:
        select_xcode_version()

Xcodes 앱은 Xcode를 설치할 때, 이렇게 설치를 해줍니다.

따라서, 빌드머신이나 스크립트로 ~/Applications/xcode.app 을 설정한 경우 경로를 찾을수 없어 난감해지는 경우가 있는데요,

심볼릭 링크를 만들고, xcode-select 커맨드를 이용하여 기본 버전으로 만들어 주어, 이를 해결해주는 파이썬 스크립트입니다.

저는 ~/.zshrc에 다음과같이 추가하여 사용하고 있습니다.

alias xcs='python3 / input_script_path/xcodeSelector.py'

그러면 터미널에 이렇게 입력하면 됩니다.

xcs
혹은
xcs 14.3

xcode의 버전은 네개로 나뉘어집니다.

14.3을 입력하면 14.3.x버전대의 가장 높은 버전을..

14를 입력하면 14.x.x 버전대의 가장 높은 버전을 선택 해 줍니다.

테스트를 위한 리팩토링

HEROHJK — Thu, 2 Mar 2023 12:28:43 +0900

드디어 마지막장입니다.

간단한 예시 코드를 테스트가 가능한 구조로 리팩토링하고, 그것을 평가하는 시간을 가져보겠습니다!

ERP 시스템 - 이메일 변경 기능

이메일 변경 기능
이메일이 회사 도메인일 경우 직원, 아니면 고객으로 분류.
직원수를 체크
모든 사용자정보는 DB에 저장
변경 후 외부에 알림

class User {
    private(set) var id: Int
    private(set) var email: String
    private(set) var type: UserType

    // 생성자 생략
}


extension User {
    public func changeEmail(newEmail: String, company: Company) {
        if self.email == newEmail { return }
        
        // 이메일 검증 과정, 위에서 구현한 Company에서 처리 (책임 분산)
        let newType = company.isEmailCorporate(newEmail) ? .employee : .customer

        if self.type != newType {
            let delta = newType == .employee ? 1 : -1
            // 직원수 또한 Company에서 처리 (책임 분산)
            company.changeNumberOfEmployees(delta)
        }

        self.email = newEmail
        self.type = newType
    }
}

class Company {
    private(set) var domainName: String
    private(set) var numberOfEmployees: Int
    
    // 생성자 생략
}

extension Company {
    public func changeNumberOfEmployees(delta: Int) {
        Precondition.Requires(self.numberOfEmployees + delta >= 0)

        // 직원 수는 회사에서 관리
        self.numberOfEmployees += delta
    }

    public func isEmailCorporate(email: String) -> Bool {
        let emailDomain = email.split("@")[1]
        
        // 회사 이메일 도메인 검증 또한 회사에서 관리
        return self.domainName == emailDomain
    }
}

public class UserFactory {
    public class func create(data: Data) -> User {
        if !dataCheck(data) { fatalError("Invalid User Data") } // 해당 데이터가 User의 데이터가 맞는지 검사.
        
        let email = String(data[1])
        let type = UserType(data: data[2])
        
        return User(email, type)
    }
    
}

public class CompanyFactory {
    public class func create(data: Data) -> Company {
        if !dataCheck(data) { fatalError("Invalid Company Data") } // 해당 데이터가 Company의 데이터가 맞는지 검사.
        
        let domainName = String(data[0])
        let numberOfEmployees = Int(data[1])
        
        return Company(domainName, numberOfEmployees)
    }
}

class UserController { // 험블 컨트롤러
    private let database: DataBase
    private let messageBus: MessageBus
    
    // 생성자 생략

    public func changeEmail(userID: Int, newEmail: String) {
        // DB를 모델링하는 과정, 리팩토링하며 만든 팩토리 클래스가 수행.
        let user = UserFactory.create(data: self.database.getUserById(userID))
        let company = CompanyFactory.create(data: self.database.getCompany())

        // 이메일을 바꾸는 과정. 아래 재작성한 User가 수행
        user.changeEmail(newEmail: newEmail, company: company)

        // 외부 협력자를 호출
        self.database.saveCompany(company)
        self.database.saveUser(user)
        self.messageBus.sendEmailChangedMessage(userID, newEmail)
    }
}

이런 코드가 있습니다.

조금 더 구체적으로 이 코드는 리팩토링을 진행한 코드입니다.

이 코드만 두고 봤을때는, 당연하다고 생각이 될지도 모르지만, 많은 개발자들은 일정이 그렇게 여유있지 않습니다.

테스트와 프로젝트 관리가 서툴다면 이렇게까지 세밀하게 나누어지는 경우는 드물다고 생각합니다.

(예시코드이긴 하지만, 당장 코드만 보면 그렇게 복잡한 코드도 아니거든요..)

보통은 아래의 코드와 같은 상태일것이라고 예상합니다. (혹은 그것보다 더 안좋거나..)

class User {
    private(set) var id: String
    private(set) var email: String
    private(set) var type: UserType

    public func changeEmail(userID id: Int, newEmail: String) {
        /// 이 코드처럼 도메인 클래스가 스스로 DB를 검색하고 저장하는 방식을 활성 레코드 패턴이라고 함.
        /// 코드 베이스가 커지면 커질수록, 확장에 애로사항이 생김.
        let data = Database.getUserById(id) // 외부 협력자
        self.id = id
        self.email = String(data[1])
        self.type = UserType(data: data[2])

        if self.email == newEmail { return }

        let companyData = Database.getCompany() // 외부 협력자
        let companyDomainName = String(companyData[0])
        let numberOfEmployees = Int(companyData[1])

        let emailDomain = newEmail.split("@")[1]
        let isEmailCorporate = emailDomain == companyDomainName
        let newType: UserType = isEmailCorporate ? .employee : .customer

        if self.type != newType {
            let delta = newType == .employee ? 1 : -1
            let newNumber = numberOfEmployees + delta
            Database.saveCompany(newNumber) // 외부 협력자
        }

        self.email = newEmail
        self.type = newType

        Database.saveUser(self) // 외부 협력자 
        MessageBus.sendEmailChangedMessage(self.id, newEmail) // 외부 협력자
    }

    public enum UserType {
        case customer
        case employee
    }
}

DB와 통신을 하고, 이메일을 변경하는 비즈니스로직이 합쳐져있습니다.

DB와 메시지버스는 외부 의존성입니다.

협력자수도 많고, 애플리케이션의 핵심 로직이므로 지나치게 복잡한 코드로 분류가 됩니다.

1. 암시적 의존성을 명시적으로 만들기

아이디와 이메일은 명시적입니다.

하지만 DB와 메시지버스는 암시적 의존성으로 분류할 수 있습니다.

따라서 클래스 내 DB와 메시지버스의 인터페이스를 추가합니다.

테스트시에는 Mock으로 처리합니다.

(DB는 저장, 메시지버스는 전송 측면이므로 둘 다 명령의 기능을 가지고 있습니다.)

2. 애플리케이션 서비스 계층 도입

1번의 연장인데, 외부 서비스와 직접 통신하기 위해 User에서 험블 컨트롤러를 따로 만들어, 책임을 나누어줍니다.

class UserController { // 험블 컨트롤러
    private let database
    private let messageBus
    
    public init(database: DataBase, messageBus: MessageBus) {
    	// 추후 추가적인 요구사항이 생긴다면 이또한 팩토리 클래스로 나눠볼만 하다.
    	self.database = database
        self.messageBus = messageBus
    }

    public func changeEmail(userID: Int, newEmail: String) {
        // DB데이터를 모델링 하는건 서비스에 속하면 안됨.
        let data = self.database.getUserById(userID)
        let email = String(data[1])
        let type = UserType(data: data[2])
        var user = User(userID, email, type) 
        
        // 위와 마찬가지
        let companyData = self.database.getCompany()
        let companyDomainName = String(companyData[0])
        let numberOfEmployees = Int(companyData[1])

        let newNumberOfEmployees = user.changeEmail(newEmail, companyDomainName, numberOfEmployees)

        self.database.saveCompany(newNumberOfEmployees)
        self.database.saveUser(user)
        self.messageBus.sendEmailChangedMessage(userID, newEmail) // 이메일이 이전과 다른지 검사하지 않고, 무조건 메시지를 전송.
    }
}

그리고, 협력자가 제거된 User 클래스를 만들어봅니다.

class User {
    // 위 험블 컨트롤러를 반영한 후 수정된 changeEmail.
    // 더이상 협력자를 필요로 하지 않지만, 여전히 많은 책임을 지고 있다.
    public func changeEmail(newEmail: String, companyDomainName: String, numberOfEmployees: Int) -> Int {
        if self.email == newEmail { return numberOfEmployees }

        var numberOfEmployees = numberOfEmployees

        let emailDomain = newEmail.split("@")[1]
        let isEmailCorporate = emailDomain == companyDomainName
        let newType: UserType = isEmailCorporate ? .employee : .customer

        if self.type != newType {
            let delta = newType == .employee? 1 : -1
            let newNumber = numberOfEmployees + delta
            numberOfEmployees = newNumber
        }

        self.email = newEmail
        self.type = newType

        return numberOfEmployees
    }
}

우선 User Class 자체는 외부 협력자와 격리되었습니다.

3. 서비스 복잡도 낮추기

우선 복잡도를 낮추기 위해 Company 클래스를 만들어봅니다.

그리고, User와 Company를 팩토리 패턴을 사용하여, 모델링을 위한 생성자를 만듭니다.

이는 ORM을 용이하게 사용하기 위함입니다.

class Company {
	var domainName: String
    var numberOfEmployees: Int
    
    // 생성자 생략..
}

public class UserFactory {
	public class func create(data: Data) -> User {
    	if !dataCheck(data) { fatalError("Invalid User Data") } // 해당 데이터가 User의 데이터가 맞는지 검사.
        
        let email = String(data[1])
        let type = UserType(data: data[2])
        
        return User(email, type)
    }
    
}

public class CompanyFactory {
	public class func create(data: Data) -> Company {
    	if !dataCheck(data) { fatalError("Invalid Company Data") } // 해당 데이터가 Company의 데이터가 맞는지 검사.
        
    	let domainName = String(data[0])
        let numberOfEmployees = Int(data[1])
        
        return Company(domainName, numberOfEmployees)
    }
}

이후, Company에서 이메일 검사와 직원수 변동에 대한 처리 로직을 작성합니다.

extension Company {
	public func changeNumberOfEmployees(delta: Int) {
        Precondition.Requires(self.numberOfEmployees + delta >= 0)

        // 직원 수는 회사에서 관리
        self.numberOfEmployees += delta
    }

    public func isEmailCorporate(email: String) -> Bool {
        let emailDomain = email.split("@")[1]
        
        // 회사 이메일 도메인 검증 또한 회사에서 관리
        return self.domainName == emailDomain
    }
}

정리된 코드

정리된 코드를 전체적으로 살펴보면 이렇습니다.

class User {
    private(set) var id: Int
    private(set) var email: String
    private(set) var type: UserType

    // 생성자 생략
}


extension User {
    public func changeEmail(newEmail: String, company: Company) {
        if self.email == newEmail { return }
        
        // 이메일 검증 과정, 위에서 구현한 Company에서 처리 (책임 분산)
        let newType = company.isEmailCorporate(newEmail) ? .employee : .customer

        if self.type != newType {
            let delta = newType == .employee ? 1 : -1
            // 직원수 또한 Company에서 처리 (책임 분산)
            company.changeNumberOfEmployees(delta)
        }

        self.email = newEmail
        self.type = newType
    }
}

class Company {
    private(set) var domainName: String
    private(set) var numberOfEmployees: Int
    
    // 생성자 생략
}

extension Company {
    public func changeNumberOfEmployees(delta: Int) {
        Precondition.Requires(self.numberOfEmployees + delta >= 0)

        // 직원 수는 회사에서 관리
        self.numberOfEmployees += delta
    }

    public func isEmailCorporate(email: String) -> Bool {
        let emailDomain = email.split("@")[1]
        
        // 회사 이메일 도메인 검증 또한 회사에서 관리
        return self.domainName == emailDomain
    }
}

public class UserFactory {
    public class func create(data: Data) -> User {
        if !dataCheck(data) { fatalError("Invalid User Data") } // 해당 데이터가 User의 데이터가 맞는지 검사.
        
        let email = String(data[1])
        let type = UserType(data: data[2])
        
        return User(email, type)
    }
    
}

public class CompanyFactory {
    public class func create(data: Data) -> Company {
        if !dataCheck(data) { fatalError("Invalid Company Data") } // 해당 데이터가 Company의 데이터가 맞는지 검사.
        
        let domainName = String(data[0])
        let numberOfEmployees = Int(data[1])
        
        return Company(domainName, numberOfEmployees)
    }
}

class UserController { // 험블 컨트롤러
    private let database: DataBase
    private let messageBus: MessageBus
    
    // 생성자 생략

    public func changeEmail(userID: Int, newEmail: String) {
        // DB를 모델링하는 과정, 리팩토링하며 만든 팩토리 클래스가 수행.
        let user = UserFactory.create(data: self.database.getUserById(userID))
        let company = CompanyFactory.create(data: self.database.getCompany())

        // 이메일을 바꾸는 과정. 아래 재작성한 User가 수행
        user.changeEmail(newEmail: newEmail, company: company)

        // 외부 협력자를 호출
        self.database.saveCompany(company)
        self.database.saveUser(user)
        self.messageBus.sendEmailChangedMessage(userID, newEmail)
    }
}

지금의 예시코드는 간단한 코드이기에, Factory 패턴이 필요가 없긴 하지만, 우선은 넣어보았습니다..

이렇게 처음에 보여진 코드의 형태로 완성되었습니다.

도메인 모델 및 알고리즘 테스트

void func test_고객에서_직원으로() {    
    let company = Company("mycorp.com", 1)
    var sut = User(1, "user@gmail.com", .customer)

    sut.changeEmail("new@mycorp.com", company)

    XCTAssertEqual(2, company.numberOfEmployees)
    XCTAssertEqual("new@mycorp.com", sut.email)
    XCTAssertEqual(UserType.employee, sut.type)
}

void func test_직원에서_고객으로() {}
void func test_타입은_변하지않을때() {}
void func test_이메일이_바뀌지않을때() {}

이런식으로 도메인 모델, 알고리즘 사분면에 속한 코드들에 대한 테스트를 진행합니다.

물론 이후에 컨트롤러도 통합테스트의 영역에서 테스트가 필요합니다만, 현재는 단위테스트의 영역만 다루겠습니다.

단위테스트의 4대 요소에 대한 평가.

1. 회귀 방지: 코드의 양이 많아지거나 복잡해지는 경우 발생할 가능성이 높습니다. 복잡한 코드를 전과 비교해서 작은 단위로 나누었기 때문에 회귀방지에 어느정도 도움이 된다고 볼 수있습니다.

2. 리팩터링 내성: 거짓양성이 발생하는 케이스입니다. 이후 UserController를 테스트할때는 추가적인 조치가 필요하겠지만, 현재의 경우 구현 세부사항 자체를 제가 생략(ㅡ,ㅡ)했기 때문에, 예시코드에서는 보기가 어렵지만.. 저기에 들어갈 세부적인 로직을 분리하면 됩니다..

3. 빠른 피드백: 이 부분도 UserController로 의존성을 옮겼기 때문에, 상대적으로 피드백이 빨라졌다고 할수 있습니다.

4. 유지보수성: 계층이 나누어져서 전체적으로는 코드가 많아졌지만. "단위테스트"의 측면에서는 테스트하려는 기능이 나뉘어졌기 때문에 짧아졌고, 이해하기가 쉬워졌습니다.

끝으로..

간단하게나마, 정리가 필요해보이는 코드를 나름의 근거를 가지고 어떻게 나누고, 평가해야할지 알아보았습니다.

하지만 통합테스트, 컨트롤러의 테스트 및 추가적인 처리사항등 공유할내용이 많습니다.

하지만 이는 단위테스트의 영역을 벗어나기 때문에, 추후 기회가 되어 한번 더 다루었으면 좋겠습니다.

단위테스트를 위한 리팩토링 준비하기

HEROHJK — Thu, 23 Feb 2023 10:58:31 +0900

앞에서는 단위테스트를 어떻게 평가해야하는가? 에 대해 알아봤습니다.

이번에는 그럼 리팩토링단계로 넘어가서, 어떻게 리팩토링해야 단위테스트를 수월하게 할수 있는지를 알아보겠습니다.

1. 아키텍처

1.1 함수형 아키텍처

결정을 내리는 로직 코드와, 결정에 따라 작용하는 코드(주로 입력과 출력)를 나누는 일종의 마이크로서비스 패턴입니다.

1. 가변 셀이 모든 입력을 수집후 코어로 보내고

2. 코어는 입력받은 데이터를 토대로 로직을 수행합니다.

3. 계산된 값들은 다시 가변 셀로나와 사이드이펙트로 변환됩니다.

1.1.1 함수형 프로그래밍?

함수형 아키텍처 이전에, 함수형 프로그램을 먼저 이해하는게 좋습니다.

예전에 제가 Rx Swift에 관한 영상을 제작한적이 있는데요, 도입부를 보다보면 함수형 프로그래밍에 관한 설명이 나옵니다.

필요한 부분만 요약 하자면,

1. 함수를 일급 객체로 취급. (= 수학적 순수 함수)

2. 함수가 불변성을 가짐. (전역 상태에 의존하지 않아, 참조 투명성을 가짐)

이전에 설명드렸던 출력 기반 테스트와 궤가 같습니다.

1.1.3 단점..

기능을 최대한 쪼개어 사용하기 때문에 코드베이스가 커집니다.

따라서 구현시간도 늘어나며, 잘 설계가 되지 않을 때 그만큼 중첩이 되고, 성능에 영향이 갑니다.

그리고 현실적으로, 모든 코드를 함수형 아키텍처로 전환하기는 어렵습니다.

1.2 육각형 아키텍처

이 또한 비즈니스 로직을 중심으로 계층화하는 마이크로서비스 패턴입니다.

구현세부사항 같은 코어 로직과 도메인계층을 분리하는데요,

도메인계층 -> 코어 로직으로 들어갈 때에는 단방향으로 흐릅니다.

외부의 서비스와 통신을 할때에는 도메인계층에서만 통신이 되구요.

1.2.1 함수형 아키텍처와 비교?

'입력 -> 처리 -> 출력'이라는 단방향의 흐름은 같습니다.

분리의 경우..

함수형 아키텍쳐는 Core, 즉 메인 로직과 메인 로직이 아닌것을 분리합니다.
육각형 아키텍처는 도메인 계층, 서비스 계층 모두에서 사이드 이펙트를 구분하여 분리합니다. (인터페이스)

2. 리팩토링할 코드 식별하기

자 이제 테스트를 위한 아키텍처도 알아보았으니, 현재 코드를 어떻게 리팩토링해야할까?

즉, 어떻게 고쳐야할까를 생각해봐야 합니다.

일단.. 어떤걸 리팩토링해야하는지 식별하는게 중요합니다.

2.1 코드의 네가지 유형

크게, '복잡도 및 도메인 유의성'과, '협력자 수'를 기준으로 식별하여 분리합니다.

해당 코드가 프로젝트에서 개선이 필요한 코드의 도메인과 얼마나 연관이 있는가를 판단합니다. 그것을 도메인 유의성이라고 하며, 그것을 확인하다보면 코드가 정리가 안되 뭉쳐져 있는 경우가 있습니다. 따라서 한꺼번에 복잡도 및 도메인 유의성으로 구분합니다.

내부의 의존성을 제외한 가변 의존성과, 외부 의존성의 경우 테스트 비용이 증가합니다.

협력자가 외부 협력자일 경우도 테스트 비용이 증가합니다.

도메인 모델과 알고리즘

이부분이 단위테스트에서 테스트할 항목입니다. 적은 비용으로 가장 큰 가치를 얻을 수 있습니다.

간단한 코드

기본 생성자, 한줄짜리 속성등 한눈에 이해가 가능한 아주 간단한 코드들입니다. 비용을 생각해서, 특별한 테스트가 필요하지 않습니다.

컨트롤러

외부 서비스를 조정하거나, 내부 비즈니스로직들을 조합하여 서비스를 컨트롤하는 부분입니다. 이부분은 단위테스트가 아닌 통합테스트가 필요합니다.

지나치게 복잡한 코드

이부분이 리팩토링이 필요한 부분입니다.

예를 들어서 iOS 개발의 ViewController과 같이, 지나치게 Massive한 코드이며, 이 코드를 위 3가지 항목으로 구분하여 최대한 작게 분리하는게 중요합니다.

보통 컨트롤러에서 로직이 포함되면, 이 항목인 지나치게 복잡한 코드가 되기 쉽습니다.

2.2 험블 객체 패턴

지나치게 복잡한 코드는 여러 기능들이 섞여있는데요.

'테스트를 하기 위해 리팩토링'을 하는 관점에서 볼때는 단순하게 '테스트 하기 쉬운 행위', '테스트 하기 어려운 행위'로 나눌수 있겠습니다.

이 때, '테스트 하기 어려운 행위'를 '테스트 하기 쉬운 행위'로 분리하기 위해 로직과 인터페이스들을 단일 책임 원칙에 따라가도록 리팩토링을 하게 되는데요.

이것을 험블 객체 패턴이라고 합니다.

아주 간단하게 나누는 방법을 설명하자면..

보통 인터페이스와 같이 외부와 연결되는 것들은 테스를 하기가 어렵습니다.

따라서 중요한 로직과 그 외의 것들을 분리합니다.

그러면 위에서 소개한 함수형 아키텍처, 육각형 아키텍처 처럼 모양이 잡힙니다.

아래 그림처럼요

앱에서는 이런식으로 구분된 디자인 패턴들이 많죠? MVC, MVP, MVVM등..

그 패턴들도 잘 생각해보면.. 뷰, 모델, 로직을 분리하는데 특화되어있고,

결국은 지나치게 복잡한 코드를 분리하는것으로 귀결됩니다.

여기까지가 테스트를 수월하게 도입하기 위한 리팩토링 방법 준비에 대한 설명인데요,

다음은 마지막 포스트로, 위의 가이드대로 리팩토링을 한번 진행해보고, 그것을 앞서 말한 평가 방법으로 평가하는 것까지 설명드리겠습니다~

단위테스트, 어떤 항목을 평가해야 할까?

HEROHJK — Wed, 22 Feb 2023 22:45:51 +0900

앞 포스트에서 단위테스트가 무엇이고, 왜 해야하는지 알아봤습니다.

단기성 프로젝트가 아닌 이상, 지속적인 유지보수를 해야하고,

리팩토링은 대표적인 유지보수 방법입니다.

하지만 그 리팩토링이 과연 효과가 있었는가? 를 확인하기 위해 단위테스트를 이용한다고 설명을 했었는데요,

그렇다면 단위테스트는 어떻게 만들고 어떻게 평가를 해야할까? 에 대해 포스팅합니다.

1. 단위테스트의 구조

1.1 AAA 패턴

단위테스트는 대표적으로 AAA패턴을 사용하여 진행합니다.

AAA 패턴이란, 준비(Arrange) - 실행(Act) - 검증(Assert)의 순서로 진행되는 패턴입니다.

public class CalculatorTests {
    public void test_두_수의_합을_검증() { // 알아보기 쉽게, 읽기 쉽게 작성하는걸 추천하기에, 한글 사용을 권장합니다.
        /// 준비
        let first: Double = 10
        let second: Double = 20
        var calculator = Calculator()

        /// 실행
        let result = calculator.sum(first, second)

        /// 검증
        XCAssertEqual(30, result)
    }
}

준비 구절에서는 테스트를 진행하려는 테스트 대상 시스템과, 의존성들을 원하는 상태로 세팅합니다.

(이후 테스트 대상 시스템은 SUT(System Under Test)라고 표현하도록 합니다.)

실행 구절에서는 SUT에서 테스트가 필요한 메서드를 호출하고, 미리 준비한 의존성을 전달하여 출력이 있는 경우 출력값을 저장합니다.

검증 구절에서는 저장된 출력값과 예상하는 값을 비교하여 검증합니다.

이 때, AAA 항목들이 여러개로 나누어지면, 단위테스트가 아닌 통합테스트가 됩니다.
따라서 여러개의 동작단위를 검증하는것은 지양하도록 합니다.

1.2 구절의 크기?

테스트코드에서 if문을 사용한다면, 위에서 말한 여러개의 동작 단위를 검증하게 될 수도 있기에 지양합니다.

준비구절이 보통 가장 큽니다만, 너무 커진다면 오브젝트 마더, 테스트 데이터 빌더 등 빌더 패턴을 사용하여 테스트 코드에서 분리하도록 합니다.

실행 구절은 되도록이면 한번만 실행하며, 한번이 넘어간다면 베이스코드를 의심해 리팩토링을 준비하는게 좋습니다.

'하나의 기능'만 테스트한다는 가정 하에, 검증구절은 몇개가 있어도 상관 없습니다 만..

그래도 많아진다 싶으면 리팩토링을 준비합니다.

(추상화, 비교 메서드 등을 점검 해 봅시다.)

2. 좋은 단위 테스트의 4대 요소

단위테스트를 평가하는 네가지 지표가 있습니다.

2.1 회귀 방지

만약 내가 리팩토링을 통해 코드를 수정했는데, 의도대로 작동하지 않는 경우 다시 원상복귀를 시키는 경우가 있습니다.

이것을 회귀라고 하며, 단위테스트를 평가할 때 해당 코드가 회귀를 해야하나도 평가하게 됩니다.

코드의 양이 많아지거나, 코드가 복잡해지는 경우 회귀가 발생할 가능성이 높습니다.

더군다나 복잡한 비즈니스 로직은 시스템의 핵심과도 같은데, 여기서 발생하는 버그는 시스템에 가장 큰 피해를 입힙니다.

또 SUT의 해당 코드가 얼마나 도메인에 적합한지도 확인을 해봐야 합니다.

2.2 리팩터링 내성

단위테스트를 진행하다보면, 분명 리팩터링을 한 코드는 잘 작동하는데.. 단위테스트에서 실패하는 경우가 있습니다.

이것을 거짓 양성(false positive)이라고 합니다.

SUT가 구현의 세부사항과 강하게 결합이 되어있을 때 주로 발생합니다.

개인적으로 이 리팩터링 내성, 거짓양성이 가장 악질적인 케이스라고 생각을 하는데요.. 제가 생각하는 이유는 다음과 같습니다.

두가지 케이스가 있는데요..

1. 일단은 일정이 중요하다. 마감이 얼마 남지 않았고, 기능작동에는 문제가 없으니 테스트는 제거하고 나중에 다시 들여다보자.

2. 아니다.. 테스트에 통과하지 못하는것은 내가 아직 발견하지 못한 무언가의 이유가 있을것이다.. 일단 코드를 원상복귀 시킨 후 나중에 다시 들여다보자..

네.. 이렇게 둘이서 러시안 룰렛을 하게 됩니다.

결국 둘중 하나만 살아남는(테스트 코드 or 리팩터링된 코드) 비극이 발생합니다..

2.3 빠른 피드백

더 많은 테스트를, 더 자주 수행할수 있기 때문에 테스트는 빠를수록 좋습니다.

2.4 유지보수성

테스트코드는 이해하기 쉬울수록 좋습니다.

가독성을 부숴트리고 라인을 억지로 줄인다거나.. 변수명을 억지로 짧게만드는등 억지로 압축을 하지 않는 선에서 간결하고 잘게 쪼개서 진행하도록 합니다.

2.5 이상적인 테스트?

위의 네가지 요소를 지키면서 리팩터링을 진행하고, 테스트코드를 작성하는건 이상에 가깝습니다.

결국 리팩터링 내성을 최대한 유지하면서, 회귀 방지와 빠른 피드백사이에서 절충하는 방법을 일반적으로 추천하더라구요.

3. 대역?

테스트를 진행하는데 SUT가 아닌 SUT에 필요한 의존성들은 대역으로 처리하는 경우가 많습니다.

상황에 따라 단위테스트 코드안에 모든 의존성들을 준비하기가 어렵기 때문입니다.

3.1 종류들

단위테스트에 관심이 있다면 Mock, 목 이라는 말을 많이 들어보셨을텐데요..

목은 대역의 일부입니다.

그리고 아래처럼 세분화가 가능합니다.

목 (Mock)	목
목 (Mock)	스파이
스텁 (Stub)	스텁
	더미
	페이크

3.1.1 목

목은 SUT에서 외부로 나가는 상호작용을 대체 하는데 도움이 됩니다.

보통 명령의 역할을 가지고 있습니다.

3.1.2 스텁

스텁은 외부에서 SUT의 내부로 들어오는 상호작용을 모방하는데 도움이 됩니다.

보통 조회의 역할을 가지고 있습니다.

/// Mock의 예시
func test_이메일전송() {
    var mock = Mock<EmailGateway>()
    var sut = Controller(mock.object)

    sut.greetUser("user@email.com")

    // SUT에서 사이드 이펙트를 발생시킬 때(이메일 전송), 미리 만들어둔 Mock 대역으로 사용.
    XCTAssertEqual(mock.sendGreetingsEmail("user@email.com"), true) 
}

/// Stub의 예시
func test_report_생성() {
    var stub = Mock<Database>()

    // dummy의 개념으로, 미리 10명의 유저를 생성
    stub.setUp { $0.GetNumberOfUsers() }.returns(10)

    var sut = Controller(stub.object)

    let report = sut.createReport()

    XCTAssertEqual(10, report.numberOfUsers)
}

두가지는 보통 단위테스트 라이브러리에서 묶여있는 경우가 많습니다.

하지만 이를 잘 구분할줄 알아야 합니다.

5. 스타일

4.1 출력 기반

입력을 넣고 생성되는 출력을 점검하며, 불변성을 가진 함수형 프로그래밍에서 검증하기가 좋습니다.

가장 간결하고 명확하지만, 조건을 만들기가 쉽지는 않습니다..

4.2 상태 기반

테스트 실행 후 시스템의 상태들을 변화를 점검합니다.

4.3 통신 기반

목을 사용하여 SUT와 협력자(목)간의 통신을 검증합니다.

4.4 단위테스트의 4대 요소를 기반으로 비교.

위에서 설명한 좋은 단위테스트의 4대요소를 기반으로 스타일마다 어떤 특성이 있는가를 비교해봅니다.

4.4.1 회귀방지, 빠른 피드백의 지표로 비교

실행되는 코드의 양, 도메인 유의성
- 셋 모두 관계 없습니다.
코드 복잡도
- 테스트 시 SUT외의 모든것을 Mock으로 사용할 가능성이 있지만..
- 이는 각 스타일의 문제점이 아닌 테스트 코드를 좋지 않게 작성한 경우입니다.
- 따라서 복잡도도 크게 관계가 없습니다.
빠른 피드백
- 외부 의존성과 연결되어있지 않는 한, 세 스타일 모두 유의미한 차이는 없습니다.

따라서, 테스트코드를 정상적으로 작성한다는 가정 하에, 회귀방지와 빠른 피드백의 경우 세 스타일 모두 큰 차이는 보이지 않습니다.

4.4.2 리팩터링 내성 지표로 비교

리팩터링 내성은 곳 거짓 양성이 얼마나 적은가에 대한 척도입니다.

구현 세부사항과 결합이 강할수록 거짓 양성의 발생 확률이 올라가는데요..

출력 기반
- 코드 자체가 불변성을 띄고있기 때문에, 거짓 양성 방지에 가장 우수합니다.
상태 기반
- 테스트와 SUT코드의 결합도가 높을수록, 구현 세부사항과 얽매일 가능성이 높아, 상대적으로 위험해집니다.
통신 기반
- Mock을 상대적으로 많이 사용하기 때문에, 세가지 스타일중 거짓양성 발생에 가장 취약합니다.
- 따라서 Mock이 되는 협력 의존성을 잘 설계할 필요가 있습니다.

4.4.3 유지보수성 지표로 비교

유지보수성은 얼마나 크고 얼마나 복잡한가를 확인하는데요..

출력 기반
- 대부분의 코드가 짧고 간결하기에, 유지보수가 가장 쉽습니다.
상태 기반
- 테스트를 위해 더 많은 코드를 짜야하기 때문에.. 출력 기반에 비해 상대적으로 유지보수가 어렵습니다.
- 헬퍼 메서드를 사용해 완화할수는 있지만, 결국 이로 인해 비용이 더 증가하게 됩니다.
통신 기반
- Mock과의 상호작용 검증이 필요하므로, 가장 유지보수가 어렵습니다.

4.4.4 결론

지표	출력 기반	상태 기반	통신 기반
리팩터링 내성을 지키기 위한 노력	낮음	중간	중간
유지보수 비용	낮음	중간	높음

결국 출력 기반 -> 상태기반 -> 통신기반의 순으로 4대요소에 부합하게 됩니다.

단위테스트가 무엇이고, 왜 해야할까?

HEROHJK — Wed, 8 Feb 2023 12:11:15 +0900

(단위테스트 책 스터디 후 발표자료를 공유하기 위해 작성했습니다.)

저는 10월 ~ 1월까지 블라디미르 코리코프의 단위테스트 책을 가지고 북스터디를 진행했습니다.

단위테스트(Unit Test)란 무엇일까요?

소프트웨어 테스트 방식 중 하나로, 독립적으로 작동하는 코드 단위 중 가장 작은 코드를 테스트하는 것 입니다.

하나의 기능을 최대한 빠르고 가장 정확하게 테스트 하는 것을 목표로 하며, 이것들이 보장되어야 후에 진행할 통합테스트가 수월해집니다.

엔드투엔드 -> 통합 -> 단위로 이루어진 테스트 피라미드

그러면 왜 단위 테스트가 필요할까요? - 실패한 리팩토링 시나리오

1. 제품이 지속될수록 점점 길어지는 일정

단위 테스트 '만' 놓고 본다면 중요성은 그다지 크지 않습니다.

작은 코드 '만' 놓고 본다면, 실수할 여지도 크지 않고, 그저 발견된다면 고치면 되니까요.

어차피 테스트를 해주는 테스터 팀도 있고, 여태까지 우리 회사의 제품은 잘 굴려져 왔기에, 이번에도 어떻게든 잘 굴러갈거라고 믿어 의심치 않습니다.

분명 우리 제품의 초창기에는 기능의 추가나 수정요청이 들어오면.. 기능의 추가나 수정요청에 대한 일정이 합리적이었습니다.

소프트웨어를 개발하는 개발자도 납득이되고, 제품 개발에 참여하는 다른 팀원분들도 충분히 납득이 되는 시간과 기능입니다.

개발을 하고, 어디 빠진부분은 없나 제법 꼼꼼하게 체크도 합니다.

중간중간 아주 사소한 마찰이 있을수는 있겠지만.. 아주 사소한 마찰일 뿐 입니다.

그런데 생각해보면 뭔가 이상합니다.

1년이 지나고 2년이 지나고.. 마이너, 메이저버전이 올라가면 올라갈수록, 비슷한 규모의 기능 추가 / 수정이 개발자 입장에서는 점점 납득이 되지 않습니다.

하지만 이걸 설명하기는 귀찮습니다. 일단은 요구사항대로 개발을 진행합니다.

시켜서 하긴 하는데.. 자꾸 여기저기 걸리는부분이 많습니다..

중간중간 애로사항이 많이 꽃핍니다. 하지만 그래도 개발을 계속 합니다.

초기 설계에서 염두에두지 못한 기능이라 설계를 우회해야하고, 지금 당장 이 코드를 어디에 분류할지 몰라서 일단 바깥쪽에 둡니다.

미래의 내가 어떻게든 해줄겁니다.

이것은 절대 제가 게을러서 그런게 아닙니다. 시간이 모자란겁니다. 시간으로부터, 사회로부터 억까를 당하고 있는겁니다.

이렇게 기능개발을 또 하나 둘씩 마칩니다.

2. 회고를 해 보니..

개발을 마치고 회고를 해봅니다.

(거창하게 생각할것 없이 그냥 왜 이런가 생각만이라도 해볼수는 있으니까요)

더이상 미룰 수 없습니다.

구조 개선을 해야만 할 것 같습니다.

조금 더 지금 상황에 유연하게 대처가 가능한 구조를 짜고, 미뤄왔던 코드들(기술부채)을 정리하기로 결심합니다.

3. 리팩토링?!

리팩토링에 대한 시간을 보장받기는 상당히 어렵습니다. 그래도 반드시 필요한작업입니다.

보통은 개발 일정을 길게 잡아 남는 시간에, 혹은 정말 어렵게 어렵게 시간을 보장받아 진행합니다.

후자라면 다행이겠지만.. 전자라면 그것 마저도 시간이 모자랍니다.

대충 머릿속에서 생각해왔던 방식으로 구조 개선을 진행합니다.

처음에는 코드를 깔짝깔짝 건드리면서 리팩토링을 합니다.

처음에는 그럴싸하게 됩니다. 깔짝깔짝 건드리지만 나름 합리적으로 보입니다.

동작에도 크게 문제는 없어보이네요. 다른코드도 하나둘 건드려 봅니다.

내 생각과 다른부분이 조금씩 발견되지만.. 크게 이상한부분은 없어보이고, 여기까지 와서 중단하기도 좀 그렇습니다..

그러므로 계속해서 리팩토링을 진행합니다.

3.1 진행한 리팩토링이 가치가 있었을까?

의심되는 부분이 있었지만 어쨋든 리팩토링을 마쳤습니다.

기존 업무를 벗어난, 뭔가 코드에 대한 퀄리티를 높이는 작업이었기에 나름 성장했다는 기분도 들고 아주 뿌듯합니다 ㅎㅎ

하지만, 리팩토링의 가치는 무엇일까요?

코드가 유연해졌기에 추후 작업에 대한 일정을 단축시킬수 있을까요?

구조적 문제로 생긴 버그가 줄어들었을까요?

다 끝내고 보니, 업그레이드 되어있어야할 코드가 옆그레이드가 된건 아닐까요?

과연 그것을 어떻게 판단할 수 있을까요?

4. 리팩토링 이후에..

새로운 추가 개발건이 들어옵니다.

리팩토링한 코드를 검증할수 있는기회입니다.

'시간을 얼마나 줄일수 있을까?'

'얼마나 간단하게 추가할 수 있을까?'

'얼마나 깔끔하게 추가할 수 있을까?'

근데 요구사항을 들어보니 내 바램과 달라도 너무 다릅니다.

아.. 내가 개선한 코드가 빛을 보지 못합니다 ㅠㅠ

일정에 변화는 없습니다.

여전히 이상하게 걸리는 부분들이 있고, 기술부채를 힘들게 해결한게 엊그제인데,

해결하자마자 또다른 기술부채가 쌓이게 됩니다.

그래도 어떻게든 되겠지.. 라고 위로하며 여차저차 개발 마무리 합니다.

힘겹고 고통스러운 개발 이후, 테스트 기간때 기둥 너머로 테스터분들의 눈치를 살핍니다.

표정이 안좋습니다. 얼굴이 울긋불긋 해집니다. 하필 그 타이밍에 저를 쳐다봅니다.

동료들과는 완만하게 지내는게 좋습니다.

처음에는 메시지로 전달해 줍니다.

'기존 기능이 작동을 안하네요~'

다음에는 자리에 와서 아주 상냥하게 여쭤봅니다.

'이 기능이 이렇게 바뀌었는데 왜 이러는걸까요~? ^^'

자리에 찾아오는 빈도가 높아집니다.

나도, 테스터도 퇴근하는 시간이 점점 늦어집니다.

말투도 건조해져 갑니다.

'아직이에요?'

'네..'

'언제 돼요?'

'...방 돼요...'

'뭐라고요? 크게좀 말해봐요'

'.... 금방 돼요...'

계획에 없는 야근때문에 예민해진 테스터와, 최대한 눈을 안마주치려고 노력하는 개발자, 그리고 무슨일인가 싶어 구경하는 동료 개발자들.

네.. 이번 리팩토링은 망했습니다. 개발 일정 단축도, 버그를 잡는것도 모두 실패했습니다.

무엇이 문제였으며, 이게 테스트와 무슨 상관이 있을까?

힘들게,, 어쩌면 개인 시간까지 투자해가며 리팩토링을 진행하는경우가 상당한데, 그 리팩토링이 과연 효율적인가? 성공적인가? 를 판단해야 합니다.

그리고 리팩토링의 성공 확률을 올려야 합니다.

단위테스트와 통합테스트를 이용한 개발 및 유지보수는 그것에 대한 아주 좋은 방법입니다.

테스트를 포함한 개발을 처음 한다면, 절대로 쉽지 않습니다.

단위테스트를 위한 작은 구조를 만들어야 하고,

지금 작성한 코드가 단위테스트의 영역인지, 통합테스트의 영역인지 구분해야 합니다.

구분이 안가면 분리해야합니다.

처음의 높은 러닝 커브(Learning Curve, 학습 곡선)를 감내하더라도, 초기 개발 이후 제품이 지속되는 단계에서는 그 초기 투자 비용이 빛을 볼수 있습니다.

개인적으로 생각하는 테스트를 포함한 개발은 어떤 이점이 있는지 생각 해 봤습니다.

1. 단위테스트, 통합테스트, Mockable 등을 구분하기 위해 코드를 명확하게 분리 하는것을 항상 염두에 둔다. 따라서 코드의 구분이 상대적으로 명확해진다.

2. 코드의 구분이 명확해지므로 이후 추가 개발, 수정에 대한 부담이 상대적으로 줄어든다.

3. 아주 기본적인 테스트를 개발자단계에서 진행하기에, 제품 자체를 테스트하는 테스터들의 부담이 그만큼 줄어들게 된다.

4. 따라서 테스트 기간이 짧아지며, 이는 제품 전체의 개발기간 단축으로 이어진다.

그래서, 개발할 때 테스트를 해야돼?

결론부터 얘기해서, 해서 손해볼게 그다지 없습니다.

처음부터 완벽한 코드를 만들수는 없습니다.

코드는 지속적으로 리팩토링을 해야합니다.

하지만 이왕 리팩토링 하는거, 잘 하는게 중요합니다.

앞에서 말했듯이, 테스트를 포함한 개발은 그것에 대한 명확하고 효과적인 방법중 하나입니다.

일정이 줄어든다고 생각이 되시나요?

줄어들기 전의 일정은 원래부터 빠듯한 일정이었습니다.

코딩 측면에서는 모르겠지만, 최소한 제품 개발의 측면에선 그렇습니다.

(아래는 만약에 PT자료나 영상을 만들게 되면 쓸 내용입니다. 아직 미완성..)

제가 좋아하는 시티즈 스카이라인이라는 게임으로 예시를 들어보겠습니다.

시티즈 스카이라인은 도시를 설계하는 게임입니다. 특히 도로 계획, 교통에 따른 트래픽에 많은 중점을 두고있는 꽤나 현실적인 게임입니다.

(실제로 우리나라 몇몇 시/도청에서 저 게임으로 도로계획 공모전을 실시한적이 있습니다)

게임을 하는 누구나 저 위에 스크린샷처럼 멋진 도시를 구현하고 싶어합니다.

처음에는 이렇게 소박하게 시작을 합니다. 작게나마 도로를 만들고, 주거지역을 설정하고, 상가를 설정하고, 산업지역도 설정을 합니다.

여기까진 괜찮습니다.

하지만 지속적으로 인구가 유입이 됩니다. 그러면 도시 확장을 해야합니다.

도로를 파고 다시 구획을 나눠야 하죠.

미리 생각해둔 계획이 없거나.. 미리 생각해둔 계획이 있더라도 뭐든지 일들은 내 예상과 바램대로 흘러가지 않습니다.

게임이기 때문에, 운석, 홍수같은 자연재해를 일으켜 다 없애 버리고 새로 시작해도 되긴 합니다.

순식간에 교통이 정체가 됩니다.

교통이 정체된다면 공공서비스가 중단이 됩니다.

소방차, 경찰차도 제시간에 운행되지 못하고 쓰레기차또한 마찬가지입니다.

즉, 잘못된 도시계획으로 가정이 무너지고 사회가 무너지게 됩니다.

트랙패드 핀치(줌인/아웃) 버그

HEROHJK — Wed, 6 Jul 2022 09:46:35 +0900

트랙패드를 사용하다보면 가끔 핀치(줌인, 줌아웃)기능이 안될때가 있습니다.

이럴때는 트랙패드를 껐다가 켜거나, 환겅설정 -> 트랙패드 -> 핀치 기능을 비활성화했다가 활성화를 해야지 버그가 풀립니다.

몇년전부터 모든 맥 환경에서 마우스를 없애고 트랙패드를 사용하기 시작했는데 스트레스가 이만저만이 아니었습니다.

그래서 조금 찾아보다가, 터미널 커맨드로 해당 기능을 ON / OFF할 수 있는 방법을 찾아 스크립트와 알프레드 워크플로를 공유합니다.

Fucking Trackpad.alfredworkflow

0.01MB

알고리즘 풀 때 자주 쓰는 몇가지 테크닉

HEROHJK — Mon, 16 May 2022 14:23:38 +0900

1. 배열 순회중, 오버플로우 체크

if (0 ..< arr.count).contains(i) {
  arr[i] = 
}

2. N ~ M까지 순회가 필요할 때

(N ... M).forEach { 
  $0
}

3. 나머지가 0인지 아닌지 판별할 때

소수 판별이나 비슷한 문제에서, N까지 순회하지 마시고, N / 2 까지만 순회하세요.

N/2를넘어가게되면 나머지값이 0이 나올 수 없습니다.

그리고 개인차긴한데, 0혹은 1부터 시작하지말고, 2부터 시작하는게 자신이 생각하는 논리에 조금 더 근접하다고 느껴집니다.

func isPimeNumber(at: Int) -> Bool {
  for number in 2 ... at / 2 {
    if at % number == 0 { return false }
  }
  
  return true
}

4. 2개의 배열을 연관지어 처리할 때

zip 함수를 이용합니다.

func mergeArray(arr1: [String], arr2: [String]) -> [String] {
    return zip(arr1, arr2).map { "\($0)\($1)" } // ["A1", "B2", "C3", "D4", "E5"]
}

print(mergeArray(arr1: ["A", "B", "C", "D", "E"], arr2: ["1", "2", "3", "4", "5"]))

5. 배열들을 합칠 때

reduce를 이용합니다.

let arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

print(arr.reduce(0, +)) //55

6. 배열의 일부만 이용하고자 할 때

func arraySum(_ arr: [Int], _ left: Int, _ right: Int) -> Int {
  return arr[left ... right].reduce(0, +)
}

let arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
print(arraySum(arr, 2, 5)) // 18

7. 진법 변환

실제로 코테에서 이걸 허락할지는 모르겠는데, 아주 간단하게 변환이 가능합니다.

(연습을 하는 목적이라면 직접 구현하는 코드를 테스트하는 의도이기 때문에 추천하지는 않습니다..)

(2 ... 16).forEach {
    print("\($0)진법:")
    print(String(10, radix: $0))
}
/*
 2진법:
 1010
 3진법:
 101
 4진법:
 22
 5진법:
 20
 6진법:
 14
 7진법:
 13
 8진법:
 12
 9진법:
 11
 10진법:
 10
 11진법:
 a
 12진법:
 a
 13진법:
 a
 14진법:
 a
 15진법:
 a
 16진법:
 a
 */

8. 배열을 Stack or Queue 처럼 사용하기.

var arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

// 스택처럼 사용 (후입선출)
if let last = arr.popLast() { // 배열에 인자가 없을 경우 nil 반환
    arr.append(last)
}

// 큐처럼 사용 (선입선출)
let first = arr.removeFirst()
arr.append(first)


/// 하지만 인자가 없을 때 removeFirst를 하면 오버플로우가 발생하므로
/// 코딩테스트에서는 count 체크를, 실제 코딩에서는 extension을 만들어 사용하는것을 추천

if arr.count > 0 {
    let first = arr.removeFirst()
    print(first)
}

extension Array {
    mutating func safeRemoveFirst() -> Element? {
        if self.count > 0 {
            return self.removeFirst()
        } else {
            return nil
        }
    }
}

arr = [1]

if let first = arr.safeRemoveFirst() {
    print(first)
}

생각나는대로 또 나중에 적어볼께요

맥 설치 후 세팅

HEROHJK — Mon, 16 May 2022 10:45:31 +0900

최근에 Karabiner가 말썽을 일으켜서..

이참에 세팅을 좀 정리하기로 했습니다.

1. 키보드 세팅

a. 키보드 배열 변경

Command <-> Option 위치 변경

b. 한영키 윈도우처럼 맞추기

com.changing.KeyRemapping.plist

0.00MB

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> 
<plist version="1.0"> 
    <dict> 
        <key>Label</key> 
            <string>com.changing.KeyRemapping</string> 
        <key>ProgramArguments</key> 
            <array> 
                <string>/usr/bin/hidutil</string> 
                <string>property</string> 
                <string>--set</string> 
                <string>{"UserKeyMapping":[ {"HIDKeyboardModifierMappingSrc":0x7000000E7, "HIDKeyboardModifierMappingDst":0x70000006D} ]}</string>
            </array> 
        <key>RunAtLoad</key> 
            <true/> 
    </dict> 
</plist>

위 파일을 받거나, 코드를 긁어서 ~/Library/LaunchAgents에 저장.

근데 이상하게 제가 쓰는 키보드는 좌우가 바뀌는지..

"HIDKeyboardModifierMappingSrc" 코드를 E7이 아닌 E3로 해줘야 되더라구요.

c. 입력 소스 변경

변경했으면 사진처럼 F18로 변경~

여기까지 하면, Command, Option은 맥 기본 키배열과 동일하고,

오른쪽 Command는 한영키로 대체합니다.

d. 데스스토커 2를 위한 karabiner 설정

아.. 카라비너를 안쓰기로 다짐했건만.. 키보드를 레이저의 데스스토커2로 바꿨는데.. 키매핑이 어려워 어쩔수없이 다시 사용중입니다.. ㅠ_ㅠ

이건 제 개인적인 매핑을 저장하기 위해 기록합니다

볼륨up 스크롤을 command, + 조합으로 대체 (텍스트 크기 조절용)

볼륨down 스크롤을 command, - 조합으로 대체 (텍스트 크기 조절용)

재생 버튼을 command, r 조합으로 대체 (xcode 빌드용)

볼륨버튼을 command, ctrl, q 조합으로 대체 (시스템 잠금용)

{
    "description": "데스스토커 전용",
    "manipulators": [
        {
            "conditions": [
                {
                    "identifiers": [
                        {
                            "is_keyboard": true,
                            "is_pointing_device": true,
                            "product_id": 663,
                            "vendor_id": 1678
                        }
                    ],
                    "type": "device_if"
                }
            ],
            "from": { "key_code": "volume_increment" },
            "to": [
                {
                    "key_code": "equal_sign",
                    "modifiers": ["left_gui"],
                    "repeat": false
                }
            ],
            "type": "basic"
        },
        {
            "conditions": [
                {
                    "identifiers": [
                        {
                            "is_keyboard": true,
                            "is_pointing_device": true,
                            "product_id": 663,
                            "vendor_id": 1678
                        }
                    ],
                    "type": "device_if"
                }
            ],
            "from": { "key_code": "volume_decrement" },
            "to": [
                {
                    "key_code": "hyphen",
                    "modifiers": ["left_gui"],
                    "repeat": false
                }
            ],
            "type": "basic"
        },
        {
            "conditions": [
                {
                    "identifiers": [
                        {
                            "is_keyboard": true,
                            "is_pointing_device": true,
                            "product_id": 663,
                            "vendor_id": 1678
                        }
                    ],
                    "type": "device_if"
                }
            ],
            "from": { "key_code": "play_or_pause" },
            "to": [
                {
                    "key_code": "r",
                    "modifiers": ["left_gui"],
                    "repeat": false
                }
            ],
            "type": "basic"
        },
        {
            "conditions": [
                {
                    "identifiers": [
                        {
                            "is_keyboard": true,
                            "is_pointing_device": true,
                            "product_id": 663,
                            "vendor_id": 1678
                        }
                    ],
                    "type": "device_if"
                }
            ],
            "from": { "key_code": "mute" },
            "to": [
                {
                    "key_code": "q",
                    "modifiers": ["left_gui", "left_control"],
                    "repeat": false
                }
            ],
            "type": "basic"
        }
    ]
}

2. 독 딜레이 없애기

defaults write com.apple.dock autohide -bool true && defaults write com.apple.dock autohide-delay -float 0 && defaults write com.apple.dock autohide-time-modifier -float 0 && killall Dock

3. 개발 툴 세팅

a. Xcodes 설치

원래는 AppStore에서 Xcode 따박따박 받아서 썼었는데, 업데이트할때마다 속도가 너무 느리기도 하고..

최신 Xcode에서 오류가 나는경우, Legacy 버전을 설치해서 써야하는 경우가 종종있습니다.

그래서 Xcodes라는 툴을 설치하여 Xcode를 관리합니다.

https://github.com/RobotsAndPencils/XcodesApp

GitHub - RobotsAndPencils/XcodesApp: The easiest way to install and switch between multiple versions of Xcode - with a mouse cli

The easiest way to install and switch between multiple versions of Xcode - with a mouse click. - GitHub - RobotsAndPencils/XcodesApp: The easiest way to install and switch between multiple version...

github.com

b. 텍스트 에디터 설치

Visual Studio Code와 Sublime Text의 속도 비교

예전에 윈도우 개발할때는 NotePad++를 쓰다가,

맥을 사용하다보니 대체제를 찾기가 애매 하더라구요.

처음에는 Visual Studio Code를 썼는데.. NotePad++처럼 뭔가 바로바로 팟! 하고 열리는게 아니라.. 로딩시간이 좀 걸려서 찾아보니,

SublimeText라는 좋은 툴이 있더라구요.

무료버전을 이용하면, 구매하라는 팝업이 종종 뜨는걸로 알고 있습니다.

그래도 간단한 텍스트 수정(plist, json 등등)할때 이만한 툴이 없네요.

https://www.sublimetext.com/

Sublime Text - the sophisticated text editor for code, markup and prose

Available on Mac, Windows and Linux

www.sublimetext.com

c. git GUI Tool 설치

원래는 xcode 순정을 사용 했었는데, 프로젝트를 벗어난 관리가 필요하거나, 여러가지 Branch를 컨트롤하거나 할때 종종 에러가 나서 이것저것 찾아보다가, UI가 예뻐서 정착했습니다.

유료입니다.

https://www.gitkraken.com/

GitKraken Legendary Git Tools | GitKraken

Meet GitKraken, the creator of legendary Git tools for developers and teams - like the GitKraken Client, with Git GUI and CLI, Git Integration for Jira, and GitLens for VS Code.

www.gitkraken.com

d. gitignore 설정

깃을 관리할 때마다 같이 commit되는 쓸모없는 파일들이 있습니다.

이런것들은 그냥 git 전역 설정으로 설정을 하는게 편한데요,

대표적으로 .DS_Store 파일이 있죠?

저같은경우는 추가로 JetBrains 제품들도 사용을 하기 때문에, .idea 디렉토리도 있습니다.

이런것들은 글로벌로 ignore 처리를 해줘도 무방한데요, 다음과같이 설정합니다.

1. ~/ 디렉토리에 .gitignore 파일 생성

2. .gitignore 파일에 ignore 설정 추가

.DS_Store
.idea

3. git에 적용

git config --global core.excludesFile ~/.gitignore

이렇게 설정해주면 됩니다.

파일명, 디렉토리 명은 자신이 원하는대로 설정해도 됩니다. 반드시 ~/ 디렉토리의 .gitignore일 필요가 없습니다.

4. 기타

a. Alfred 설치

WorkFlow로 이것저것 활용이 가능하다해서 구매를 했었는데.. 솔직히 쓸모는 없네요.

이미 쉘 스크립트로 대부분의 작업을 커버합니다..

그래도 산게 아까워서 + 제가 레이저 장비를 좋아해서 뭔가 감성적으로 사용하는 프로그램 입니다.

b. Magnet 설치

윈도우의 윈도우 분할기능을 해주게 하는 프로그램입니다.

https://apps.apple.com/kr/app/magnet-%EB%A7%88%EA%B7%B8%EB%84%B7/id441258766?mt=12

‎Magnet 마그넷

‎하나의 앱에서 다른 앱으로 컨텐츠를 이동하거나, 데이터를 나란히 비교하거나, 기타의 방법으로 복수 과제를 수행할 때, 윈도우를 이에 따라 정렬해야합니다. 마그넷은 이 절차를 깨끗하게,

apps.apple.com

b.2. RectAngle 설치

마그넷의 대안인 RectAngle입니다.

저는 예전부터 결제한김에 마그넷을 사용했는데요.. 트랙패드 핀치랑 오류가 많아서 바꿧슴다 ㅠ

https://rectangleapp.com/

c. AIDante 설치

이건 노트북 환경일때만 설치하면 됩니다.

배터리 최대 충전량을 줄여주는건데요, 저는 60%로 설정해놨습니다.

몇년전에 스웰링(배터리가 부풀어서 맥북이 빵빵해지는..) 현상을 겪은 경험이 있어서, 설치는 하는데 효과는 아직 모르겠네요..

https://github.com/davidwernhart/AlDente

GitHub - davidwernhart/AlDente: macOS tool to limit maximum charging percentage

macOS tool to limit maximum charging percentage. Contribute to davidwernhart/AlDente development by creating an account on GitHub.

github.com

d. Homebrew 설치

개발을 하다보면 이것저것 설치할일이 많이 생깁니다.

맥에서는 Homebrew를 많이 이용하는데요, 홈페이지에 들어가서 설치가이드를 따라 설치를 해도 괜찮고,

아래 코드를 커맨드에 입력하여 설치해도 괜찮습니다.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

이정도만 하면 당장 개발하는데 뭐 더 필요한건 없겠네요..

그 외에 추가적으로.. oh my zsh랑 iterm도 설치하면 좋기는한데, 이건 내용이 조금 길기도하고, 항상 제가 쓰면서도 iOS 개발자 입장에서 굳이..? 라는 생각이 매번 들어서 나중에 기회가 되면 다루겠습니다.

그외에는 나중에 뭔가 또 생각나거나 생기면 추가 하겠습니다.

UIColor Custom

HEROHJK — Wed, 11 May 2022 09:55:49 +0900

뷰를 개발하다보면, UIColor를 사용할일이 정말 정말 많습니다.

이를 좀 더 편하게 사용하기 위한 커스텀 코드를 몇번 작성하다보니, 정리가 필요하겠구나 싶어 포스팅 합니다.

위와 같은 코드를 작성하게되면, 아래와 같이 편하게 UIColor 값을 조절할 수 있습니다.

myLabel.textColor = UIColor(0, 0, 0)
myLabel.textColor = UIColor(rgb: 0x000000)

그리고 추가적으로 조금 더 들어가서..

각 뷰의 색상값을 아래처럼 정의해두면 조금 더 가독성이 높은 코드가 완성 되겠죠

extension UIColor {
    static let titleColor: UIColor = { UIColor(rgb: 0x000000) }()
    static let subtitleColor: UIColor = { UIColor(rgb: 0x888888) }()
}

이렇게 정의해둔 다음..

titleLabel.textColor = .titleColor
authorLabel.textColor = .subtitleColor

이런식으로 활용해 볼 수 있겠네요.

스터디 github 가이드

HEROHJK — Wed, 27 Apr 2022 12:10:23 +0900

서론

스터디를 하는 이유?

(너무 길어서 내용을 접어두었으니, 읽어보실분은 펼쳐 보세요)

저는 스터디를 매년 2~3번씩 꾸준히 정기적으로 참여하는 편입니다.

12개월중 6~9개월정도는 되도록 스터디에 참여를 하고, 나머지는 휴식시간을 가지는데요.

곰곰히 생각해보면 스터디보다는 스스로 공부하는것이 훨씬 효율이 나겠지만(관리, 진도 등의 이유로)

저같은경우 보통 스터디를 하게 되면 같이 하는 공부 속에서 혼자 공부를 하게됩니다.

그냥 쉽게 말해 혼자 공부하게되면 대충 하다가 말게되는 게으름때문에..

오히려 취업준비할때까지는 쳐다도 안봤는데.. 2017년에 일을 시작한 이후부터는 여유가 생겼는지 매년 빼지않고 꼬박꼬박 참여하는 편 입니다.

그런데 연차가 이제 조금씩 쌓이면서 주니어 티를 벗어나는 수준이 오니, 상대적으로 경력자분들끼리 모여서 하는 스터디는 인맥을 통해서 하는게 아니면 조금 구하기가 힘들어져서, 초보 스터디에 참여를 하게 되는데요 ㅠㅠ

그런곳에 매번 참여할때마다 '아 이번에는 가만히 따라만 가야지', '나서지 말아야지..' 라고 마음을 먹지만, 항상 종장에는 리드를 하게 되더라구요 ㅠㅠ

물론 스터디 진행을 리드하는거지, 기술, 공부 자체를 리드하지는 않는 편입니다.

어쨋든.. 스터디를 운영하다보면 구성원의 범주가 정말로 다양합니다.

학생, 취준생, 비전공 취준생, IT 관련 종사자(기획자, 디자이너 등), 다른 포지션의 개발자 등등..

만약에 iOS 앱 개발 프로젝트 스터디를 진행한다고 하면, iOS 개발에 관심있는 다양한 카테고리의 인원들과 함께하는 경우가 많습니다.

당연히 수준도 천차만별이고, git의 사용을 어려워 하는 분들도 종종 계십니다.

개인적으로 github을 사용할줄 아냐 모르냐로 역량을 판단하지는 않습니다. (그러고 싶지도 않고..)

중요하다고 생각하는 우선순위를 정해보면..

첫번째로 참여 의욕

개발자는 자기 프로젝트 바쁘대서 잠수타고~ 학생은 시험있다고 잠수타고~ 취준생은 취업했다고 잠수타고~ ㅠ.ㅠ
그리고 스터디 문의를 할 때마다 항상 참여자중 현업 개발자는 몇분이냐고 물어보시는데, 왜 물어보시는지 이해는 되지만.. 상당히 실례라고 생각합니다 ㅠ

두번째로 친화력

스터디를 10번정도 하면, 3~4번정도는 단톡방에 아무런 얘기가 없을때가 많습니다.. 공부를 하는거지 월급받고 일을 하는게 아닙니다. 처음 공부하는것이기 때문에 부끄러워할 필요가 전혀 없습니다. 얼마든지 물어보시고, 공유해주세요!

마지막으로 코딩 능력

공부하는 부분으로 서로 소통하는데 문제만 없으면 괜찮다고 생각합니다.
부족하다고 생각해서, 스터디를 마치고 나니 머릿속에 들어온게 없어서.. <- 이건 본인의, 그리고 스터디원 개인의 문제지 스터디원 전체에게 영향이 가는건 아니니까요^^;;
스터디라고 하지만, 공부는 결국 본인이 하는거라서요

말 정리가 항상 부족해서 서론이 상당히 길었네요.

이제부터 작성할 내용도, 제가 이번에 스터디를 진행하면서 스터디원들을 위해 작성한 가이드라인인데요.

PR로 서로 리뷰하며 코드를 공유하는 방식인데..

일단 스터디장이 Repo를 만들었다는 가정 하에 설명 합니다.

스터디는 하나의 Repository에서 스터디원들의 이름을 딴 Branch를 사용하여 코드를 관리할 예정입니다.

이런 방식으로 사용하는 이유는 몇가지가 있습니다만, PR을 활용하여 서로에 대한 코드를 리뷰해주는것이 가장 큰 목적입니다.

하지만, 이런방식으로만 관리를 하게 된다면.. 개인의 github Repositories에는 저장이 되지 않습니다.

PR?

(이 부분도 그다지 필요한 부분은 아닌것 같아 접어둡니다)

PR은 Pull - Request의 줄임말로, github을 비롯한 많은 git Platform에서 사용중인 Merge 및 Code Review 방식입니다.

대략적으로 github의 Repository의 구성이 이렇다고 치면..

수정할 내용이 생겨서 기여자가 수정을 하게 될 때, 리뷰를 받고, 리뷰에 대해 승인을 받게 되면 그때 코드가 합쳐지는 방식입니다. (요청 - 승인 없이 기여자 독단적으로 Repository의 코드를 수정한다면, 관리가 힘들게 되겠죠?)

따라서 이때 Pull - Request라는 방식으로 수정된 코드를 확인하고, 병합하는 과정을 거치는데요.

기여자가 수정할 코드를 PR 요청을 통해 요청을 한다면,

관리자는 해당 코드를 해당 Repository(기여자가 Fork하거나, 아니면 요청할때 임시로 생성된 저장소)를 Pull하여 확인합니다.

확인하는 과정이 일종의 Code Review가 되는것이죠.

진행 사이클

코드에 대한 기록은 다음과 같이 진행합니다.

0. (중요) 모든 작업은 Fork를 한 Repository에서 자신의 Branch에서만 작업을 합니다.

1. 원본 저장소를 내 저장소로 Fork 합니다.

2. 코드를 작성 및 수정합니다.

3. 코드가 정리되었다면, PR을 요청합니다.

4. PR에 대한 승인 및 병합작업은 원본 Repository의 Owner(스터디장)이 진행합니다.