OKKY 포럼글 스크랩

https://okky.kr/article/559243

OKKY | 패러다임, 디자인 패턴, 리팩터링의 중요성 그리고 성능에 대해

---

이해한 만큼 요약해봄

 

디바이스 드라이버나 임베디드 분야는 속도나 메모리 최적화를 위해 C를 사용하지만,

JAVA, C#, Python 등은 속도면에서는 느리더라도 실제 구동 환경에서 언어 자체의 실행 속도가 전체 성능에 미치는 영향이 미미한 경우가 많기 때문에 쓰인다.

 

대학의 프로그래밍 지식은 저수준에서 고수준까지의 폭넓은 지식을 다룬다.

개발자로써 이러한 지식을 배우는 것은 도움이 되지만 당장 필요한 것은 아니다.

예를 들어, 프론트엔드 개발자라면 컴퓨터 구조나 운영체제 같은 지식의 우선도는 뒤로 밀린다.

 

저수준 지식을 공부하다 보면 운영체제나 하드웨어 지식과 닿을 수 있겠고 프로그래밍의 이해에는 도움이 된다.

그러나 JAVA나 C#와 같은 언어를 배울 때에는 그러한 저수준의 공부가 아니라 고수준의 고민을 하기 위해서다.

 

스프링과 같은 프레임워크를 설계하고 고민하기 위해서는 패러다임, 디자인패턴, 리팩터링과 같은 지식이 필요하다.

프레임워크의 구조를 이해하는 데는 코드를 한줄한줄 분석하는 것이 아니라, API 수준에서 클래스의 계층구조나 메서드의 시그니처를 보고 이해해야 하는 것이다.

 

알고리즘 역시 개발자에게는 바닥 아랫쪽(저수준의 지식이 중요한)에서 주요 무기로 사용할 수 있는 지식이고, 그 윗쪽으로 올라오면 유용성이 급격하게 떨어진다. 그래서 자신에게 우선 중요한 지식을 익히려 노력해야 한다.

 

---

인상 깊은 문장

어느 수준의 개발자는 어차피 반복문이 문법만 다르지 뭐 별거 있냐는 식의 우물안 개구리 식의 사고의 틀에 갇혀 있을 때,
누군가는 반복문의 명령형적 특성에 주목하고 이를 선언적 파이프라인으로 대체하는 고민을 하며, 그런 고민의 결과가 람다 같은 스펙으로 반영이 됩니다.

어떤 개발자는 입력값이야 에러 안나게 꼼꼼하게 널체크 해주면 끝이라고 생각할 때,
누군가는 아예 '널'이라는 개념을 사용하지 않는 옵셔널(optional)이라는 새로운 방식을 고안하고 언어에 도입하며,
또 다른 개발자는 계약(contract) 기반 프로그래밍의 가능성을 고민합니다.

또한 누군가 리눅스 좀 만지고 서버 몇 번 구성해봤다고 서버 쪽은 알만큼 안다라고 자만할 때,
누군가는 가상화를 도입하고 마이크로서비스와 서버리스 아키텍쳐를 고민하는 것입니다.