[Review] 2025-03-08 K-DEVCON DEAJEON 스터디 후기

 

K-DEVCON Daejeon 은 대전, 세종을 중심으로 운영 중인 개발자 커뮤니티 입니다.

 

대전 챕터는 멤버십을 중심으로 운영되고 있습니다.

성장하고 배우고자 하는 분들과 함께 열정적으로 스터디를 이어나가고 있습니다.

 

개발 실력과 상관 없이 코딩에 관심이 있는 다양한 분야에 있는 사람들이 모여서 시너지를 내는 것을 목표로 하고 있습니다.

IT업계에 종사하고 있거나 IT를 공부하고 있다면 누구나 함께할 수 있습니다. 자세한 내용은 아래 링크를 참고해 주세요.

K-DEVCON Daejeon
K-DEVCON Daejeon 정기 스터디 모임 신청 문의

---

안녕하세요 K-DEVCON 대전 디렉터 박종훈 입니다.

 

지난 2월 22일(토) 에는 K-DEVCON 대전 챕터에서는 오프라인 스터디가 진행되었습니다.

대브콘 대전에서는 월 2회씩 오프라인 스터디를 진행하고 있습니다.

 

이번주 스터디의 주요 내용은 다음과 같습니다.

클린 코드 (이예성)
3장 함수, 4장 주석

Spring In Action (박종훈)
10-12장 리액티브 프로그래밍을 이용하여 논블로킹 방식으로 개발하기

개발자 온보딩 가이드 (강성욱)
3장 함수, 4장 운영 환경을 고려한 코드 작성

 

이번 스터디에서도 함께 다룬 내용 중 일부를 정리하여 보겠습니다.

---

함수 - 클린 코드 3장

함수는 작고 단일 작업에 집중해야 하며, 모든 문장의 추상화 수준을 일관되게 유지해야 합니다.

함수 이름은 서술적으로 짓는 것이 좋습니다. 이름은 길어도 괜찮습니다. 함수의 기능을 잘 표현하는 이름을 선택하는 것이 좋습니다.

인수 개수를 최소화하면 좋으며

사이드 이펙트(부수 효과) 가 없을 수 있도록 명령과 조회를 분리하는 것이 좋습니다.

 

책에 있는 예시도 가져와서 함께 어떤 부분을 개선할 수 있을지 고민 후 같이 토론도 진행해보았는데 재밌는 시간이였습니다.

 

주석 - 클린코드 4장

주석은 거짓말을 할 수 있습니다. 주석은 오래될수록 코드에서 멀어지고 때로는 완전 그릇된 내용을 담고있기도 합니다.

 

주석은 나쁜 코드를 보완하지 못하므로, 코드 자체로 의도를 드러내야 합니다. 불필요한 주석을 다는 것보다 함수나 변수로 표현할 수 있다면 함수나 변수로 표현하는 것이 더 좋습니다.

 

책에서는 위 방법보다 아래 방법을 더 권장합니다.

// 직원에게 복지 혜택을 받을 자격이 있는지 검사한다.
if (employee.flags && HOURLY_FLAG) && (employee.age > 65)) { ... }

if (employee.isEligibleFourFullBenefits()) { ... }

 

주석은 법적 정보, 구현 의도, 추가 정보 등 코드로 표현하기 어려운 내용을 제공해야할 때 사용하면 좋습니다.

불필요하거나 중복된 주석, 오해의 소지가 있는 주석은 피해야 합니다.

 

코드는 가능한 한 주석 없이도 명확히 이해될 수 있어야 합니다.

 

레거시 코드 다루기 - 개발자 온보딩 가이드 3장 

수십 개의 파일을 한 번에 수정해버리거나, 리팩터링과 새로운 기능이 뒤섞인 PR이 생성되지 않도록 주의해야 합니다.

 

코드가 맘에 들지 않는다고 처음부터 다시 작성하려거나 표준을 무시하는 행동은 위험합니다. 이 행동은 빠지기 쉬운 함정입니다.

재작성이 제대로 되지 않는다면, 코드베이스가 오히려 불안해질 수 있으며, 코드를 다시 작성하는 동안에는 새로운 기능을 추가하기 어려운 상황이 발생될 수 있습니다.

 

내가 원하는 방식이 아니라 한다고 회사 (또는 업계) 의 표준을 무시해서는 안됩니다. 이전 방식이 왜 나왔는지 이해하고, 대화하고 설득해나가야 합니다. 새로운 기술을 적용하는 것은 많은 비용이 듭니다. 따라서 새로운 방식을 도입하기 위해서는 새로운 방식을 적용하였을 때 얻는 가치가 기존 코드보다 월등히 높아야 합니다.

 

🙆‍♂️ 이것만은 지키자	🙅‍♂️ 이것만은 피하자
점진적으로 리팩터링하자.	'기술 부채'라는 단어를 남용하지 말자.
리팩터링 커밋과 기능 관련 커밋은 분리하자.	테스트를 목적으로 메소드나 변수를 외부에 공개해서는 안 된다.
변경사항을 작게 유지하자.	특정 언어에 연연하지 말자.
처음 상태보다 코드를 더 깔끔하게 유지하자.	회사의 표준과 도구를 무시해서는 안 된다.
평범한 기술을 사용하자.	업스트림 커밋 없이 코드베이스를 포크해서는 안 된다.

 

운영 환경을 고려한 코드 작성 - 개발자 온보딩 가이드 4장

 

"예외는 일찍 던지고 최대한 나중에 처리하자." 라는 원칙이 있습니다. 일찍 던진다는 것은 에러가 발생한 지점으로부터 최대한 가까운 지점에서 예외를 던져야 한다는 것입니다. 나중에 처리하자는 것은 예외를 처리할 적절한 위치에 도착할 때까지 계속 호출 스택을 통해 전파시킨다는 뜻입니다. 예외가 발생되었을 때, 어설프게 에러를 처리하는 것보다는 상위 계층으로 전파하는 것이 좋으며, 처리 할 수 없는 예외를 catch 블록 내에서 무시하는 것은 지양해야 합니다.

 

멱등성이 있는 시스템을  구현해야 합니다. 멱등성이란 동일한 작업을 여러 번 실행해도 항상 같은 결과가 출력되는 것입니다. 멱등성을 적용하면 상호작용이 훨씬 간단해지고, 발생 가능한 에러도 현저히 줄어듭니다.

🙆‍♂️ 이것만은 지키자	🙅‍♂️ 이것만은 피하자
런타임 에러보다는 컴파일 타임에 에러를 검출하자.	예외를 이용해 애플리케이션 로직을 결정해서는 안 된다.
가능하면 불변 변수를 사용하자.	리턴 코드로 예외를 처리해서는 안 된다.
입력과 출력을 검증하자.	처리할 수 없는 예외는 잡지 말자.
OWASP가 발표하는 10대 웹 애플리케이션 취약점(OWASP Top 10)은 숙지해두자.	로그를 여러 줄로 나누지 말자.
버그 확인 도구는 물론 타입 또는 타입 힌트도 사용하자.	보안 정보나 민감한 데이터를 로그에 기록하지 말자.
예외 발생 시에는 리소스(특히 소켓, 파일 포인터, 메모리 등)를 해제하자.	머신의 설정을 직접 수정하지 말자.
코드에 지표를 추가하자.	비밀번호나 보안 정보를 설정 파일에 기록하지 말자.
애플리케이션에 설정을 추가해두자.	컫스텀 설정 형식은 채택하지 말자.
모든 설정을 검증하고 로그에 기록하자.	불필요한 동적 설정은 사용하지 말자.

Reactive Programming - Spring In Action 10장-12장

리액티브 프로그래밍(Reactive Programming)은 데이터 스트림 (데이터 흐름) 과 변화의 전파 (데이터가 흐르는 중 어떻게 변경되고, 또 그것이 어떻게 전파되는지) 에 관련된 비동기 프로그래밍 패러다임 입니다.

 

우리가 일반적으로 프로그래밍 하는 방식을 명령형 프로그래밍(Imperative Programming) 이라고 합니다. 명령형 프로그래밍은 순차적으로 작업을 진행합니다. 이전 작업이 끝나야 다음 작업으로 넘어갑니다. 이러한 방식은 성능 병목을 발생시키기 쉽습니다. 스레드로 병렬로 처리한다고 해도 마찬가지로 리소스 낭비에 취약합니다.

출처 : Reactor3 intro By Simon Basle

반응형 프로그래밍은 이러한 문제를 해결하는데 도움이 됩니다.

출처 : Reactor3 intro By Simon Basle

 

반응형 프로그래밍은 기본적으로 비동기 방식으로 동작합니다. 블로킹 작업이 발생하면 다른 작업으로 주도권을 넘깁니다. 이를 통해 리소스를 효율적으로 사용할 수 있으며, 응답성을 향상시킬 수 있습니다. 하지만 반응형 프로그래밍은 학습해야할 것이 많아 진입 장벽이 있는 편입니다.

 

더 자세한 이야기 : https://jonghoonpark.com/2025/03/09/reactive-programming

---

 

K-DEVCON 대전 스터디에 참여하고 싶으신 분들은 언제든지 환영합니다. 🙌

 

돌아오는 3월 29일 에는 오픈 클래스도 준비하고 있습니다.

멤버십에 바로 들어오기 걱정되거나 부담되시는 분은 오픈 클래스에 참여하여 분위기를 느껴보시는 것도 좋은 선택이 되실것이라 생각됩니다.

 

더 자세한 소개는 아래 링크에서 확인하실 수 있습니다 🔥

https://event-us.kr/m/100445/31805

데브콘 대전 : 삼월엔 오픈 클래스 - 이벤터스

 

저희는 단순히 진도를 나가는데 목적을 두는 것이 아니라 해당 주제에 대해 서로 공부해 온 것을 기반으로 이야기 하면서 스터디를 진행하고 있습니다. 모르는 부분은 질문하고, 자기가 알던 내용과 다르면 얼마든지 의견을 제시해도 좋습니다. 같이 더 좋은 것을 얻어가기 위해 함께 노력하고 있습니다.

서로서로 현업에서 있었던 일이나, 최근 있었던 이슈들에 대해서도 이야기 하고 있습니다.

 

멤버십 신청하기

 

많은 관심 부탁드립니다.

오늘도 다들 파이팅입니다!