|  개발의 과정에서

: 코드를 작성할 때 풀어야 하는 문제처한 상황을 함께 고려해야 한다.

ex. 어드민에 특정 기능 하나를 추가하는 것. --> 끔찍한 코드 + 하루의 기간. (if문을 하나 추가한다.). 어떤 것이 가장 효율적일까?

 

|  처한 환경이란?

: 시스템 및 비즈니스 환경 속에서 현재 내가 풀어야 하는 문제를, 어느 시점까지 처리해야하는 가를 고려해야한다.

: 빠른 시간 내에 처리를 해야할 경우, 레거시 코드가 더 효과적일 수 있다.

< 시스템 환경 >

- 저사양 임베디드 시스템 : 용량이나 RAM등 성능 자체가 이슈. 최적화가 가장 중요.
- 고성능 서버군(ex. AWS) : 성능에 대한 제한 보다는 확장성 있고 안정성 있는 시스템을 구축. 모니터링


< 비즈니스 환경 >

- 성장 중인 초기 스타트업 : 비즈니스 골든 타임을 놓치지 않도록 기능 개발을 빠르게 하는게 중요
- 안정기에 접어든 유니콘 : 사업 자체가 일정 궤도에 올라왔기 때문에 시스템을 안정화하는 게 중요

 

|  좋은 코드란?

- 일반적인 좋은 코드란?

시간복잡도/공간복잡도가 낮고,

문서화가 잘 되어 있으며,

유지보수하기 쉽고,

중복이 없으며,

가독성이 높고,

테스트하기 쉬운 코드

- 여기에 가치를 추가한 것이 좋은 코드이다.

 

|  레거시 코드란?

- 신규 프로젝트가 아닌 경우, 기존 시스템에 중간에 합류하여 기능을 추가하는 경우가 많다.

- 레거시 코드란?

더 이상 지원하지 않는 운영체제 및 다른 컴퓨터 기술에 대한 코드,
혹은 다른 사람에게 받은 소스코드이거나 이전 버전에서 받은 소스코드.

- 레거시 코드 요약 : 하휘호환성 + 내가 짜지 않은 코드

- 특징 : 다른 사람이 작성, 복잡한 이해관계, 가독성이 떨어짐

- 원인 : 단순한 기획과 정책으로 시작해 중도에 정책을 추가, 서비스 런칭.

             런칭 후 프로모션 기능 추가.

             고도화 단계에서 신규 기능을 추가하면서 이전 정책과 충돌

             -----> 예외 케이스 허용 -----> IF문의 추가 x 반복

             이후 기획자 및 개발자 로테이션 발생. 과거 히스토리를 모르는 채로 기능을 덧붙이게 된다.

- 현실적으로 중간에 개선할 시간을 주지 않는 경우가 많다.

* 레거시 코드는 어쩔 수 없는 코드. 이 코드를 개선하는 시간이 너무 오래 걸린다면 효율을 위해 코드를 건드리지 않거나, IF문을 하나 더 추가하는 것을 해주어야 한다.

 

|  왜 좋은 코드를 작성해야할까?

- 로버트 C 마틴 - 코드를 읽고 이해하는 시간이 작성하는 시간 보다 10배가 더 걸린다. 우리는 새로운 코드를 작성하기 위해 오래된 코드를 계속 읽어야 한다. 따라서 읽기 쉬울 수록 쓰기 쉬워진다. 

- 소프트웨어 Lifecycle :

: 요구사항 분석 -> 서비스 출시 -> 기능개선/정책변경/서비스확장/프로모션... 등 -> 서비스 종료

* 서비스 출시 전에는 개발단계 비용이 크지만, 출시 이후에는 유지보수 비용이 더 크다.

- 코드의 가독성을 높이는 것이 필요.

 

[ 출처 ]

부트캠프 수업 내용을 들은 후 정리

+ Recent posts