Programming

[Review] 토스에서 말하는 "가독성 좋은 코드" 란 무엇일까?

Introduction최근 토스 테크 블로그에 토스 프론트엔드 팀에서 나눈 "코드 가독성" 에 대한 이야기가 공유되어 한번 살펴보게 되었다. 기억에 남는 이야기들을 간단히 정리하고, 개인적인 생각을 덧붙여 보고자 한다. https://toss.tech/article/firesidechat_frontend_1 모닥불 | EP.1 토스에서 말하는 “가독성 좋은 코드” 란 무엇일까?모닥불 피워두고 같이 도란도란 이야기 나누는 것처럼, 토스 프론트엔드 개발자들은 '모닥불'이라는 시간을 통해 함께 기술적인 문제를 나누고 해결방안을 찾아가는데요. 최근 모닥불 중 가장toss.tech 코드 퀄리티, 꼭 챙겨야 할까?어떤 사람들은 개발이란 단순히 비즈니스를 위한 수단이라 주장. 코드 퀄리티를 챙기는 것이 중요한가?코드..

[Design patterns] Proxy Pattern (프록시 패턴)

Introduction 구조 시스템 패턴 시리즈의 완결까지 본 글을 포함해 두 편 남았다! 이번에 소개할 디자인 패턴은 Proxy 패턴이다. Proxy 패턴을 한줄 요약하면 다음과 같다. 어떤 오브젝트로의 접근을 중간에서 제어하기 위한 대리자 (proxy) 오브젝트를 제공한다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 살짝씩 내용을 변경한 부분이 있다. Motivation 어떤 오브젝트의 생성 코스트가 너무 커서, 전체 시스템을 처음 구성할 때에 바로 생성하지 않고 그것이 실제로 필요할 때 까지 잠시 생성을 미루어야 할 때가 있다. 프록시 패턴은 어떤 오브젝트의 접근을 가로챈 후 그 오브젝트가 놓여야 할 곳에 대신 자리를 차지함으로써, 원래 ..

[Programming] 큰 PR vs 작은 PR

Introduction 프로젝트를 여러 명이서 진행하다 보면 필수적으로 Pull Request (흔히 줄여서 PR) 이란 것을 하게 될 것이다. PR은 개별의 개발 참여자가 작업한 코드를 메인 코드베이스에 통합하기 전에, 코드를 검토 받기 위한 일련의 과정을 의미한다. 각각의 작업자가 독립적인 환경 (피처 브랜치) 에서 작업물을 여러 커밋에 걸쳐 기록하고 나면, 이 커밋들을 메인 코드베이스 (메인 브랜치) 에 통합하기 위해 Pull Request를 생성하고, 관련된 다른 작업자들이 리뷰어로 참여해 변경 사항을 검토하고 수정 제안 혹은 최종 승인을 할 수 있다. 보통 한 가지의 독립된 기능을 구현하기 위해 피처 브랜치를 파고, 해당 기능 구현이 완료되면 피처 브랜치를 병합하기 위해 PR을 날리기 마련이다...

[Design patterns] Facade Pattern (퍼사드 패턴)

Introduction 구조 시스템 패턴을 다루는 과정에서 패턴 이름들이 알파벳 순서로 나열되었던 게 좋았었는데 (Adapter, Bridge, Composite, Decorator), 이번엔 E로 시작하는 패턴이 나올 차례지만 안타깝게도 그런 디자인 패턴은 없다... 이번 글에서는 눈물을 머금고 알파벳 한 자리를 건너뛰어 Facade 패턴에 대해 소개하고자 한다. Facade 패턴을 한줄 요약하면 다음과 같다. 복잡한 시스템을 더 쉽게 사용하기 위한 high-level의 인터페이스를 제공한다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 아주 살짝씩 변경한 부분이 있다. Motivation 시스템을 여러 서브시스템으로 나누는 식으로 전체 시스템..

[Design patterns] Decorator Pattern (데코레이터 패턴)

Introduction 오늘 소개할 내용은 데코레이터 (Decorator) 패턴으로, 그 기능을 요약하자면 다음과 같다. 클래스 내용을 수정하지 않으면서 동적으로 오브젝트에 기능을 추가할 수 있다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 아주 살짝씩 변경한 부분이 있다. Motivation 전체 클래스 오브젝트의 동작을 수정하는 대신 특정 오브젝트에만 어떤 기능을 동적으로 추가해야 할 때가 있다. 즉, 기존에 작성된 클래스 코드를 전혀 건드리지 않으면서도 새로운 기능을 자유롭게 얼마든지 추가할 수 있으며, 기능이 추가되어도 외부에서는 기존 오브젝트와 동일하게 상호작용 할 수 있어야 한다. 코드 수정 없이 기능을 추가하기 위해 기존 클래스를 ..

[Design patterns] Composite Pattern (컴퍼짓 패턴)

Introduction GoF 디자인 패턴 중 structural pattern (구조 패턴) 들을 하나씩 다루고 있는데, 이제 한 절반쯤 왔다. 이번에 소개할 내용은 Composite 패턴으로, 한줄로 요약하자면 다음과 같다. 오브젝트를 트리 구조로 구성해 계층 구조를 표현하는 동시에, 개별 오브젝트와 오브젝트의 composition을 동일한 방식으로 다룰 수 있게 한다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 아주 살짝씩 변경한 부분이 있다. Motivation 단순한 기능을 하는 작은 오브젝트를 모아 큰 오브젝트를 구성하고, 이들을 다시 동일한 방식으로 모아 더 큰 단위의 오브젝트를 구성해야 하는 경우가 있다. 예를 들어, Point-..

[Design patterns] Bridge Pattern (브릿지 패턴)

Introduction 이번 글에서는 또다른 structural pattern (구조 패턴) 인 브릿지 패턴에 대해 소개하고자 한다. 브릿지 패턴은 인터페이스와 실제 구현을 분리해, 각각이 독립적으로 수정될 수 있도록 도와준다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 아주 살짝씩 변경한 부분이 있다. Motivation 인터페이스는 동일하게 유지한 채로, 실제 기능은 여러 가지 방식으로 구현하고 싶을 땐 다음과 같은 방법을 사용할 수 있다. 먼저 추상 클래스 (abstract class) 를 정의해 인터페이스를 설정한다 (추상화, abstraction). 이후엔, 그것을 상속하는 실체 서브클래스 (concrete subclasses) 들에선..

[Design patterns] Adapter Pattern (어댑터 패턴)

Introduction 이번 글에서는 structural pattern (구조 패턴) 중 하나인 어댑터 패턴에 대해 소개하고자 한다. 어댑터 패턴에 대해 요약하자면, 현재의 클래스 인터페이스 X를 요구되는 인터페이스인 Y로 변환해 주는 디자인 패턴이라 할 수 있다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 아주 살짝씩 변경한 부분이 있다. Motivation 재사용을 위해 작성해놓은 툴킷 클래스가, 실제로 그것을 사용하는 쪽에서 요구하는 특수한 인터페이스를 가지고 있지 않아 사용이 불가능한 경우가 있다. 이런 상황에서 여기저기서 재사용되는 기존의 툴킷 클래스의 소스 코드를 변경하지 않고 현재의 특수한 인터페이스 요구 상황에 맞추기 위해 어댑터..