일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 그래프
- 문자열
- heap
- Queue
- string
- sort
- Algorithm
- 큐
- Greedy
- 힙
- 완전탐색
- DVWA
- binary search
- 카카오 기출
- programmers
- Brute Force
- 동적계획법
- 백준
- django
- 프로그래머스
- DFS
- Code Refactoring
- Dynamic Programming
- DP
- 코딩테스트
- 정렬
- BFS
- 탐욕법
- graph
- 알고리즘
- Today
- Total
목록Code Refactoring (3)
생각과 고민이 담긴 코드

저번 포스팅에서의 문제 인식에 이어서 Rest api 설계를 진행 중이다. 처음엔 django의 template 기능을 활용하여 풀스택으로 개발된 프로젝트를 DB에 접근하여 데이터를 처리하는 부분을 따로 분리시켜 REST api 형태로 개발하고자 한다. 간편하고 빠른 개발을 지향하는 Django에서는 역시나 Rest api를 쉽게 개발할 수 있도록 Django Rest Framework 라이브러리를 제공한다. 따라서 이 DRF를 활용하여 설계를 진행하였는데 문제는 처음부터 Rest api를 목적으로 프로젝트를 진행한 것이 아니기 때문에 이미 많은 코드가 구현되어 있었다. 그러므로 구조적으로 어느 부분을 어느정도만큼 재구성할지 boundary를 설정해야 했다. DRF에서는 정말 추상화 정도에 따라서 다양한..

현재 진행 중인 팀프로젝트에서는 제조원가를 예측하는 웹 플랫폼을 개발하고 있다. 기술 스택은 Django 프레임워크와 html, javascript를 사용하고 있다. 현재 웹페이지 화면은 총 16개 정도의 화면으로 이루어져 있으며 대부분의 화면들은 DB의 데이터들을 보여주는 grid 형식의 화면이다. 또한 장고의 FBV를 사용하여 화면마다 한개의 html 파일 랜더링 해주는 view함수를 배정해주고 있는데 문제는 화면마다 CRUD 기능이 필요하기 때문에 각 화면마다 최소 3개이상의 view 함수와 url 경로가 더 필요하게 되었다. 그 결과 다음과 같은 매우 비효율적인 구조가 되고 말았다. 위와 같이 화면마다 총 4개의 url을 맵핑하게 되었고 그에 따라 view함수도 4개씩 필요하게 되었다. 16개의 ..

현재 진행 중 인 팀 프로젝트에서는 제조업 관련해서 원가 데이터를 입력받을 수 있는 웹페이지를 개발 중이었다. 기술 스택은 Django 프레임워크와 html, javascript를 사용하였다. 각자 소스코드들의 통일성을 유지하기 위해서 팀원들의 코드를 계속 리뷰 할 필요가 있었다. 팀원들은 각자의 화면을 맡아 개발하고 있었고 그 중 예를 들어 위의 화면에서는 법인정보 데이터를 입력하는 화면인데 각 Row에는 수정, 삭제하는 버튼이 각각 1개씩 존재하였다. {% for i in rsCo %} 프론트에서는 백엔드로 부터 context 변수로 넘겨 받은 rsCo라는 객체 리스트을 for문 돌려서 각각의 객체에 접근하는데 이 객체가 DB에 Row에 해당하게 된다. 따라서 두 버튼에서는 각row의 수정, 삭제기능..