잉여개발자

좋았던 애자일 경험

일하면서 좋았던 애자일 경험일전에 스타트업에서 일하면서, 좋았던 경험/프로세스를 잊어먹기 전에 남겨본다. 프로세스1. 스프린트 (2주) 간 작업 진행2. 스프린트 회고 (스프린트 마지막 금요일) 진행- 소요시간 약 1시간- 다같이 모여서 이번 스프린트 간 구현 된 기능을 확인한다. (시연한다)- 시연은 파트별 (FE든, BE든) 진행 3. 시연 간 보완 점 및 개선 아이디어를 발굴한다. - 페이지마다 피드백 / 요구사항 miss 종합 -> 약 2~4개- TODO 보완 사항 -> 약 2~4개 - 거의 10개 미만의 추가 티켓이 나온다.- 우선순위를 정해서 다음 스프린트에 반영할 일부 티켓을 골라내고, 나머지는 백로그로 옮긴다.- 최종 PM은 티켓으로 만들고, 그 자리에서 대충 업무 정리를 끝낸다. (길어지..

Non-Tech 관련코드 리뷰코드 리뷰에 관한 생각 정리 : 코드 리뷰에 대한 가치관 및 좋은 견해 개발자, 커리어주니어/중니어/시니어의 역할 정리 : 주니어, 중니어  의 역할을 비교해보며 나는 어디쯤 속해있나 돌아보기 좋은 글. 팀프로젝트테크스펙으로 모두 함께 성장하기 , 링크2 : 개발 기간 산출 전 테크 스펙 확인하기 기타사용자 행동 로그국내의 UX/UI 모바일 패턴 수집 Tech 관련PythonPython과 FastAPI로 지속 성장 가능한 웹서비스 개발하기Fastapi 콜 한줄한줄 따라가기CPython 3.13버전에서 기대되는 기능(A Per-Interpreter GIL)Python @Dataclass 이해하기파이썬과 인터페이스: 프로토콜에서 ABC까지메타 프로그래밍이란? 설계 / 배포uvic..

개요수치형 필드 설계시 효율적인 데이터 저장을 위해 나름의 현실에서 만들어 질 수 있는 필드들에 기준을 세워보았다.  수치형 필드 기준횟수(유한) / 일수 / 개수일반적인 (unsigned) Integer 필드DB 내부적으로 21억 이하의 정수 비즈니스 로직상으로 무한정 커질 수 없는 경우ex) 일 노출 횟수, 기간 일 수, 댓글 개수 금액 및 횟수 (무한)(unsigned) BigInteger 필드DB 내부적으로 63경 이하물론 꼭 Big 으로 필요는 없고 유연하게 하여도 됨)ex. 상품 단가, 최종 금액, 조회 수  Enum 값, 작은 단위의 값 (유한)TinyInteger, SmallInteger 필드 (일반적으로 256 또는 32767 이하) ex) 유저 타입, 상태값, 할인율 (0~100) 실..

개요테스트 코드를 작성시 어떤 도구로, 어떠한 것을 어떻게 작성 해야 될 까에 대한, 아직 경험이 부족하지만 이해한 바를 토대로 가이드라인 겸 항목 정리를 해보았다. (이해도가 높아질 때마다 계속 업데이트 해보는걸로..) 현재 개발 방식이 TDD(Test Driven Development)일 수도 있고 아닐 수도 있을 것이고, 스타트업 같은 만약 제품을 먼저 내야 하는 상황이면, 테스트 코드 작성 비용은 다소 부담스럽고 우선순위가 자연스럽게, 뒤로 밀릴 수 있다.혹은 완성된 서비스의 안정성을 높이기 위해, 테스트 코드를 넣으려는 경우, 방대한 서비스 코드의 모든 부분에 대해 테스트 코드를 채워 넣는 것 또한 다소 비효율적으로 느껴질 수 있다. 따라서 테스트 코드 작성시 '모든 것에 테스트 코드를 작성할 ..

기본 원칙무결성 - 데이터베이스 내에 모든 값은 언제나 정확한 값을 유지해야 한다.유연성 - 데이터베이스 구조는 요구사항 변화에 대해 수정이 쉬워야 한다.확장성 - 데이터베이스 구조는 기능 확장에 대해서 수정이 쉬워야 한다. 엔티티 이해유형 엔터티 : 물리적인 형태 o, ex. 상품, 회원)개념 엔터티 : 물리적인 형태 x, 개념적, ex. 부서, 학과)사건 엔터티 : 행위로 인해 발생, ex. 주문, 이벤트 응모) 기본키 생성시 자연키 vs 인조키 기본 키란 해당 레코드를 식별하기 위한 유일한 값 자연키 (DB에서 자동으로 생성해주는 것)장점 : 자동으로 인덱싱 해줌단점 : 혹여 기본키 수정해야 될 상황 발생시 문제 발생 인조키 (직접 생성 후 지정)장점 : 비즈니스 로직으로 인한 기본키 변경시에도 유..

현재의 팀에서는 아직 PR 에 대한 문화나 규칙 등이 완전히 설립되지는 않았는데, Pull Request를 받거나 요청하면서, 코드 리뷰를 하다 보면 참 많은 고민 지점이 생기는 것 같다. 깊게 몰입해서 하면, 1시간 ~ 2시간은 금방이고 의견과 피드백을 작성하 기 위해 그때 그때 다른 레퍼런스를 보다 보면, 반나절에서 하루 종일 PR 만 봤던 적도 있던 것 같다. (물론 각잡고 학습하자느니 뭐니 혼자 계획하고 설치는 것 보다, 그 순간 리뷰를 위해 특정 부분을 빠르게 학습하는 것 또한 효율적이였던 것 같기도) 그러던 중 다음의 '아주 사적인 코드 리뷰 생각' 이라는 정말 좋은 아티클을 보게 되었고, 많은 공감을 하게 되었던 것 같다.(본인이 주니어거나 코드 리뷰에 무언가 고민이 있다면 꼭 읽어보아도 좋..

DI (Dependency Injection) 란?하나의 객체가 다른 객체를 필요로 할 때(의존성을 가진다), 객체를 클래스 내부에서 직접 생성하여 사용하지 않고, 외부에서 생성해 놓은 객체를 사용(주입)하여 결합도를 낮추는 것. DI의 장점결합도 감소: 객체 간의 의존성이 명시적으로 주입되어, 객체들이 직접적으로 결합되지 않아 결합도가 낮아짐.유연성 및 재사용성 증가: 의존성 주입을 통해 객체의 구성 요소를 쉽게 교체하거나 재사용할 가능테스트 용이성: 의존성을 외부에서 주입받기 때문에, 모의 객체(Mock Object)나 테스트 더블(Test Double)을 사용하여 단위 테스트를 쉽게 작성 가능유지 보수성 향상: 의존성이 명확하게 드러나고 관리되므로, 코드의 가독성과 유지보수성 향상 Python DI..

개요상태, 유형, 타입, 등급 등의 들어갈 수 있는 값에 제한이 있는 필드들에 대해서 추가적인 참조 테이블 설계가 필요할지, 아니면 Enum 값 정도로 괜찮을지에 대한 장단 비교, 기준 등  Enum 사용시 장단점장점추가적인 테이블이 필요 없다.조인이 불필요하여 조회 속도가 빠르다. 단점Enum 값들에 연관된 추가적인 값들을 저장이 불가 (ex. 등급 이란 개념의 추가 필드, eng_name 등등)Enum 값의 변경시 코드 등도 직접 수정되어야 함 (변경시 비용이 큼) 참조 테이블로 설계시 장단점장점해당 테이블 개념에 부가적인 개념등을 테이블의 필드로 자유롭게 추가 가능하다. 제한된 값이 늘어날 때, 추가에 유연하다. 단점조인이 발생하여, 조회 속도가 저하될 수 있다.  결론핵심 기준은 유연성, 향후 변..

배경회사나 팀마다 로깅성 혹은 어떤 작업에 대한 변화 히스토리나 결과에 대해서 테이블 화 할 때 각자 정한 테이블명 규칙이 있거나 라이브러리 등 연동시 기본적으로 생성해주는 테이블명 등 혹은 개인적으로 어울린다고 생각하는 테이블 명이 있을 것 이라 생각한다. 나름의 기준으로 테이블 명 규칙을 적어보았다. log, result, history_log정의 : 시스템 레벨의 정보 저장인 경우, 시간의 흐름에 따른 경우, 일정 시간 후에 삭제 가능 경우예시- request_response_log : 요청/응답 로그- web_log : 웹 전반에서 발생하는 로그- system_log : 시스템에서 발생하는 로그- cron_log : 크론 등에서 발생하는 시스템 성 로그 _results 정의 : 작업(계산, 분석 ..

구조 (Structure) 패턴구조 패턴 이란 객체 간의 상호 작용에 대한 구조적 관계를 명확히 정의하여, 코드의 유연성과 재사용성을 높이는 디자인 패턴 주요 패턴으론 다음 사항들이 있다.어댑터 (Adapter) 데코레이터(Decorator) 복합자(Composite) 파셔드(Facade) 플라이웨잇(Flyweight)프록시(Proxy)브릿지(Bridge) 파서드 (Facade) 패턴 이란복잡한 클래스 세트/하위 시스템에 대해 클라이언트 에게 단순화 된 인터페이스를 제공하는 구조적 디자인 패턴아래 그림과 같이 안에는 복잡하지만, 최종 바깥 문 (=단순화된 인터페이스)를 제공하는 것  주로 다음 경우에 많이 사용된다.복잡한 하위 시스템에 대한 제한적이지만 간단한 인터페이스가 필요한 경우하위 시스템을 레이..