코드 또는 다이어그램을 작성할 떄 어떤 설계 원칙을 적용해야 할까? 이 장에서는 UML 다이어그램이나 코드가 잘 설계되었는지 평가하는데 도움이 될 다섯 가지 설계 원칙을 논의하고자 한다.
백엔드에서 모델의 관계는 크게 3가지 알고 있습니다. 일대일 일대다 다대다 다형성 관계는 모델이 하나의 모델과 관련되지 않고 여러 개의 모델과 관련될 수 있는 관계로 관계형 DBMS 의 SQL 로는 표현할 수 없는 관계입니다. 예를 들어 아래와 같이 pictu
실크는 장고프레임워크를 위한 프로파일링 툴이다. 실크는 HTTP 요청들과 데이터베이스 쿼리들을 가로체고 저장한다.
Python API 연동 시 > ConnectionError : ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',)) 클라이언트에서 api 요청 실패가 발생하였고 생각보다 실패 비율이 상당하여 관련된 문제를 찾아보았다. 카카오 인프라에서는 h...
장고를 처음 접하면서 비지니스 로직을 어디에 관리를 두어야할 지 막연하게 가이드가 없어 찾아보고 정리를 하였다. 비지니스 로직을 어떻게 관리를 해야할지 잘 모르는 흔한 초보 개발자라면 흔히 View단(MVT 장고 패턴)에 모든 구현 코드를 적어 방대한 현장에서 방대한
모든 것을 다이어그램으로 그려야 한다는 규칙을 만들지 마라. 이 규칙은 그냥 쓸모없는 정도가 아니라 해를 끼친다. 여러 사람이 동시에 작업하기 때문에 모두 설계에서 특정한 부분의 구조를 이용해야 할 때 그려러. 모든 사람이 이해했다고 동의하면 그때 멈춘다.두 명 이상이
UML의 주요 다이어그램은 세 종류로 나뉜다. 정적 다이어그램 : 클래스, 객체 데이터구조와 이것들의 관계를 그림으로 표현해서 소프트웨어 요소에서 변하지 않는 논리적 구조를 보여준다. 동적 다이어그램 : 실행 흐름을 그림을 그리거라 실체의 상태가 어떻게 바뀌는지 그림으
테스트코드에서 일자/시간은 테스트 수행중인 시각을 사용한다. 만약에 비지니스로직에 시간에 따라 분기하는 코드가 있다면(ex: 야간에는 서비스 중지, 이용요금 야간 할증) 테스트코드가 수행하는 시각에 따라 알맞게 분기가 되면서 테스트코드가 실패 될 수 있다. 리액트에서
회사에서 백엔드, 프론트엔드 개발팀으로 분리되면서 최신 흐름을 잘 아는 전문적인 프론트개발자가 없어 본인은 백엔드 포지션이였지만 그나마 vue를 사용한 경력자로써 React 시니어가 채용전까지 리액트 프로젝트를 셋업하고 어느정도 진행 해야하는 상황을 맞이 하였다. 리액