본문 바로가기

LANGUAGES, METHODLOGY

 (42)
터지지 않는 앱의 역설(논리 에러) 최근 개발을 하다 리포트받은 버그가 있었는데, 이는 컴파일 과정이나 런타임중에 확인 할 수 없었던 부분이었다. 디버깅을 하고 나니 이는 소켓통신 결과에 따라 신규 데이터를 처리할 때 필수적인 변수에 default argument가 설정되어 있기 때문이었다. 여기서 해당 변수에 대한 mapping이 일부 누락이 되었고 이로 인해 오동작을 하게 된 소위 논리 에러가 발생하게 된 것이었다. 이번 버그를 통해 얻은 교훈이 있다면 필요에 따라 중요한 요소에 대해서는 의도적으로 개발자를 불편하게 할 필요가 있다는 것이었다. 가장 좋은 에러는 릴리즈 이전에 맛보는 에러이기 때문에, 중요한 기능들에 대해서 올바르게 구현되지 않았다면 개발자가 최소 런타임 중에, 나아가서 컴파일 중에 에러를 경험하도록 의도하는 것이 결국..
[STUDY] 깨끗한 코드란 무엇일까? 로버트 C.마틴의 클린 코드 보통 개발자 커리어를 시작하게 되면 여러 종류의 코드를 경험하게 되는데, 저마다 가진 '더럽다, 지저분하다' 느끼는 코드들을 머릿속에 가지고 있을 것이다. 그렇다면 '더러운 코드'란 소위 어떤 코드일까? 반대로 깨끗한 코드, '클린코드'란 무엇일까. 그리고 클린 코드가 가져다줄 수 있는 이점들은 무엇이 있을까? 로버트 C.마틴의 클린 코드를 완독하고 핵심 내용들에 대해 되새겨보고자 포스트를 쓰기로 했다. 책 전반에 있어 좋은 내용들이 참 많지만, 핵심적으로 간추려보고자 직관적인 개념인 '더러움' 과 '깨끗함'으로 나누어 정리해본다. Dirty code - 함수의 역할을 곧바로 읽을 수 없어 추측과 내비게이션을 반복해야 한다. - 유사한 내용이 군데군데 반복되고 있다. - 과한 주석이 코드를 읽기도 전에 ..
[Kotlin] 컬렉션의 lazy 연산을 짚어보자 (Sequence) 코틀린에서는 다양한 형태로 시퀀셜하게 결과값을 이어나가는 코딩이 가능하다. 문제는 컬렉션을 베이스로 시퀀셜하게 코드 블럭을 잇는 경우, 이에 대한 결과값들이 연산 이후마다 만들어지기 때문에 (우리는 최종적인 값만을 필요로 함에도 불구하고) 메모리적으로 비효율 적이라 할 수 있다. (특정 컬렉션에 사용하는 조건이 다양하고 많을 수록 받는 영향은 클 것이다) 이를 위해 코틀린은 Sequence를 제공하고 있는데, 컬렉션에 이를 사용하는 경우 호출 원본 리스트에서 이어진 시퀀셜한 모든 연산을 뒤로 이를 toList 등으로 추출하기 이전까지 어떠한 임시 컬렉션 변수를 생성하지 않는다는 것이다! 방법은 간단한데, 보통 사용하던 컬렉션 API 사용에 앞서 원본 리스트에 asSequence()를 호출하고 사용하는 것..
[Kotlin] 컬렉션 함수형 API로 컬렉션 쉽게 갖고 놀기 개발을 하다 보면 리스트형 변수와 필연적으로 마주하게 되는데, 단순히 이런 컬렉션 객체를 사용하는 것에서 넘어 특정한 조건에 따라 필터링을 한 목록을 얻는다던지, 검색한 모든 결과값에서 원하는 결과가 있는지 확인한다던지 하는 요구사항을 필요로 한 적이 있을 것이다. 코틀린을 사용할 때, 이러한 요구사항을 손쉽게 충족해주는 API를 정리해보고자 한다! 컬렉션 함수형 API 우선 Kotlin in Action에서 소개하는 함수 중 필수적인 함수로 소개하는 filter와 map에 대해 살펴보자. filter filter를 사용하는 경우, 호출하는 대상 컬렉션으로부터 필요한 조건을 filter 코드 블럭에 선언하면 조건에 맞는 List로 이를 반환하게 된다. val targetList = listOf("윤철수"..
[객체지향] 최소 지식의 원칙 퍼사드 패턴 리뷰에 앞서 책에서 객체지향의 최소 지식의 원칙에 대해 짚고 넘어가는 곳이 있어 리뷰 후에 넘어가고자 한다. 우선 최소 지식의 원칙은 드미트리의 원칙이라고도 불리며, 아래의 네 가지 규칙을 준수하는 것이 포인트이다. 자기 자신만의 객체 사용 메서드에 전달된 매개변수 사용 메서드에서 생성된 객체 사용 객체에 속하는 메서드 사용 적어두고 생각해보면 알겠지만, 네 가지 원칙을 준수하게 될 경우에 가질 수 있는 장점은 결합도를 낮추는 것이 될 것이다. 우선적으로 자기 자신만의 객체를 사용하고, 필요한 외부 데이터가 있는 경우 이를 매개변수로써 전달받기 때문에, 특정한 다른 클래스를 사용하게 되는 경우에 사용하는 클래스가 변경됨으로써 가질 수 있는 불이익으로부터 자유로운 것이다. (이는 메서드에 전달..
[클린아키텍처] 4부 : 컴포넌트 원칙 클린 아키텍처에서 실제 아키텍처 장에 들어가기 전에 컴포넌트에 있어 지켜야 할 원칙들에 대해 보이고 있는 장이다. 중요한 개념을 가지고 있으면서, 여러 이 개념을 이해하고 응용하는데 필요한 용어들이 다수 있기에 이를 정리해보고 리마인드 하고 싶은 내용을 마저 정리해보고자 한다! REP : 재사용/ 릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다. 개발자는 릴리즈 단위를 통해 어느 시점의 컴포넌트를 사용해야 하는지 알 수 있다. 요즘엔 너무도 일반적인 사용 예! CCP : 공통 폐쇄 원칙 동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라. 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라. SRP와 OCP 원칙을 가지고 이 원칙을 적용해낼 수 있다. CRP :..
[클린아키텍처] 3부 : SOLID 원칙 계속 머릿속에 되뇌이면서 코드에 녹여내야 할 중요한 원칙 SOLID에 관한 내용이다. 단순한 코드 차원에서 나아가 전반적인 구조를 어떻게 구성해야 할 지에 대한 내용에 더 가깝다. 기존에 살폈던 내용과 책을 읽고 난 뒤 다시 정리 차 내용을 끄적여 본다. SRP(Single Responsibilty Principle) 단일 책임 원칙 각 모듈은 하나의 구성원에게만 책임을 진다. 유사한 기능을 수행하는 로직이 있을 지라도, 이는 사용하는 대상과 더불어 대상에 따라 다르게 적용될 이후 수정사항들이 존재할 수 밖에 없기 때문에, 이를 분리함으로써 하나의 기능 수정이 모든 모듈에 미칠 수 있는 영향을 제거하는 것이다. OCP(Open Close Principle) 개방 폐쇄 원칙 기존의 코드를 건드리지 않고, ..
[클린아키텍처] 2부 : 프로그래밍 패러다임 우리가 개발자로써 업무를 진행하면서 겪게 되는 다양한 애로사항들, 거기에 있어서 우리가 가져야 하는 자세와 중요한 원칙에 대해 1부에서 짚어 보았다면, 이제 2부에서는 우리에게 익숙한 구조적 프로그래밍, 객체지향 프로그래밍, 함수형 프로그래밍으로 정리되는 패러다음들의 핵심이 무엇인지, 그 이전과 그 이후가 어떠한지 설명하고 있다. 권한의 박탈과 구조적 프로그래밍 각 프로그래밍 패러다임의 핵심을 로버트 C. 마틴은 '권한을 박탈하는 것'으로 시작과 끝을 맺고 있다. 프로그래밍 패러다임이 있기 이전인 1950년대에는 어떤 특정한 원칙 없이, 기능 구현을 위한 방법이 말대로 무궁무진하게 열려 있었기 때문에, 개발자들이 필요 이상으로 복잡한 설계를 만들게 되고, 불필요한 세부사항을 양산하는 일이 만연해 있었다...

티스토리툴바