언제 아키텍처를 고민하게 될까
담당하는 유사한 사이트가 늘어날 때 자연스레 고민하게 된다. 물론 시스템을 새니티하게 유지하고자 하는 경우에 말이다. 그리고 DRY 를 안하려고 하게 되면 자연스레 접어들게 된다.
아는 CTO 께서는 '관리하는 사이트가 두 개 이상되면 CTO 지...' 하시기도 했다.
컨벤션을 유지하는 가장 큰 이유
- 개발 과정에서 컨텍스트를 유지하기 위함
그래서 '최소 놀람의 법칙' 같은 것도 필요하다.
이게 왜 필요한가 하면, 혼자 개발하지 않기 때문이다. 소스를 남에게 보여줄 필요가 없을 때에도 문제되지 않는다. 하지만 소위 협업 이라는 단계에 들어가게 되면 얘기가 달라진다.
소프트웨어 공학이 나온 배경을 이해하면 알겠지만 소프트웨어 개발이 산업화가 된 이후의 현상들을 이해할 때 자본과 투자 그리고 비용 회수에 대한 전제를 깔아두면 좋다.
다 이유가 있다. 돈과 결부되기 때문이다.
그래서 개발자(뿐 아니라 모든 비용의 대상은)의 비용은 늘 최소화 되어야하고 이를 위한 노력이 동반되어야 한다. 이게 소프트웨어 '과학'이 아니라 '공학' 인 이유다.
벨류 타입
스위프트의 경우 struct 가 값 타입으로 제공되지 않던가 싶다. Go 에서도 가능하구나.
Go 가 처음에는 모던 C 가 될 줄 알았는데, 되었다고 봐야 하나? 아무튼 지금 봐서는 Zig 가 그 맥을 잇고 있다.
그나저나 Go 는 좀 만져봐야 한다. 2.0 언제 되나...
링크들
- JS로 작성된 package를 import 할 때 Tip (declare module)
- How I Write SQL, Part 1: Naming Conventions
- Vim: Remove swap, backup and undo Files from Working Directory
- 송파구에서 일을 더 잘하는 11가지 방법
- 송파구에서 일을 더 잘하는 11가지 방법-몽촌토성역편
- 제니퍼소프트에서 하지 말아야할 33가지
- 10.x 때 한 번 더 봐야겠다 rescript
- 선언과 정의 - 메모리 점유
- git patch file, apply
- SRT 프로토콜 - RTMP 의 대안
NodeJS 백엔드 웹 개발자입니다.