일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Akka
- 이더리움
- 파이썬 머신러닝
- play2 강좌
- 파이썬 동시성
- 주키퍼
- 스위프트
- 플레이프레임워크
- hyperledger fabric
- 파이썬 강좌
- akka 강좌
- Hyperledger fabric gossip protocol
- Golang
- 그라파나
- Actor
- play 강좌
- 스칼라 강좌
- 파이썬 데이터분석
- 스칼라 동시성
- 엔터프라이즈 블록체인
- Adapter 패턴
- 안드로이드 웹뷰
- 하이브리드앱
- CORDA
- Play2
- 스칼라
- 블록체인
- 파이썬
- 하이퍼레저 패브릭
- Play2 로 웹 개발
- Today
- Total
HAMA 블로그
개발자의 '코딩'은 소설가의 '글쓰기' 본문
'코딩'은 소설가의 '글쓰기'와 비슷하다고 생각 합니다.
소설가가 '글쓰기'를 잘하기 위해 매일 매일 습작을 하듯이..'코딩'을 잘하기 위해 서는 매일 매일 코딩 하는 버릇을 들이고, 평생 '장인' 정신을 가지고 노력해야하는 일인거 같습니다. 글쓰기는 잘하는 사람이 코딩도 잘할거라는 확신이 있습니다. (여담으로 자신의 생각을 표현하는데 적극적인 작가형 사람은 무엇이든 만들어내는걸 잘 할 것이고, 짧은 생각으로 비판만 하는 습관만 있는 사람이 독창적으로 무엇인가 스스로 만들어 내기 힘들 거란건 충분히 어리짐작 할 수 있겠지요.)
재능과 반복
지나가는 길에 방망이 깍는 노인을 보고, 일기장에 "오늘 방망이 깍는 노인을 봤다, 신기했다" 라고 단편적으로 적는것과 그것을 주제로 수필을 쓰는 능력은 천지차이 겠지요. 꼬아보기,상상력 및 끈기가 필요합니다. 토지같은 장편소설을 글쓰기 하는것은 스프링프레임워크 혹은 데이타베이스를 코딩하는것과 일견 일맥상통 합니다. 글쓰기와 코딩은 이미 모든것을 준비(설계) 해 놓고 쓰는 것이 아니라, 쓰다 보면 쓸거리가 더 생기게 마련인 반복적인 작업 입니다. 어떤 분야든 재능이 중요하지만 반복을 통해 극복가능하리라 생각합니다.
언어의 풍미
글쓰기/코딩을 잘 하려면 해당 언어에 대한 풍부한 지식을 가지고 있어야 합니다. 자기가 알고 있는 어휘가 많을수록(습관도 들여진) 단어와 그 단어와 어울리는 연속된 단어와 문장들을 서술 할 수 있게 됩니다. 언어를 잘 알면 가독성도 좋아지며 적은 묘사만으로 풍부한 해석을 가능케도 합니다. 대부분의 언어는 단순히 자/모음을 가지고 있지만 언어의 풍미는 상당히 다를 겁니다. 해당 언어의 풍미를 살리기 위해서는 네이티브가 아니고서는 파악하기 오래 걸릴 겁니다. 즉 언어를 깊게 배운다는 것은 문화를 배우는 것을 포함합니다.
클리세와 디자인 패턴
수천년의 시간동안 건축에 대한 보편적인 구조/배치등이 정립되어 왔듯이 아침드라마 작가가 되기 위해서는 수 많은 이전 아침드라마에서의 클리세를 참고해서 글을 쓰면 주부들의 마음을 뺏을 수 있을 것입니다. 코딩 또한 기존 선배들이 작성했던 방식을 알고 있다면 일반적으로 유연하고 읽기 좋은 코드를 작성 할 수 있을 것 입니다.
컨텍스트(기반기술)
두 작업(코딩,소설) 모두 해당 컨텐츠에 관련된 컨텍스트를 연구하고 수집해야 합니다. 목적과 주제를 분명히 알고 집중 해야 합니다. 쓰기로 마음 먹은 주제에 대해서 옳은 방향으로 잘 풀어 나가려면, 근거가 되는 컨텍스트에 대해서 면밀하게 조사/분석을 해야 합니다. 해당 컨텍스트를 근거로 실질적 글쓰기는 설계되고 구축이 되어져 가게 됩니다. 컨텍스트에 대한 지식이 부족하면 글쓰기가 마음먹은데로 진행되지 않으며, 의미 없는 고민에 빠지게 됩니다. 그래서 문서나 API를 조사하고 읽는법이 중요한것입니다. 어려운 조립식 장난감의 설명서를 잘 읽고 적용도 잘하는 사람들이 있죠.
잘 읽혀지기
소설과 마찬가지로 코드는 쓰는 시간 보다 읽혀지는 시간이 훨씬 많습니다. 쓰는 사람도 자기가 쓴 글을 쓰는 시간보다 훨씬 많이 읽어보게 되며, 독자나 유지,업데이트를 해야하는 사람들은 더더욱 그러하겠지요. 따라서 잘 읽혀지는 것은 매우 중요합니다. 두고 두고 다른사람들이 보아야 할 것이고 고쳐야 할 것이기 때문에 잘 읽히고, 어떤 부분은 편하게 어떤 부분은 불편하게 사용하도록 변주(變奏)가 필요하며 조율(調律)을 해나가야 합니다. 그리고 한 문장에 하나의 주장을 담아서 간략히 문장을 만들어야 합니다. 만연체로 쓰여진 문장은 읽기 괴롭지요.
근데 "잘 읽혀진다"라는 의미는 단순하진 않습니다. 평소 풍부한 어휘와 배경지식을 많이 가지고 있는 토종 한국인에게 읽혀지는 "토지"에 대한 읽기는 한국어를 어지간히 배운 외국인이라고 어려울 것이기 때문입니다. 그들에게는 모든 언어에서 공통으로 사용하는 단순한 어휘와 문장구조로 쓰여진것이 외국인에겐 더 가독성이 좋겠지요. 그렇다고 토지를 그렇게 작성하는게 옳은거라 생각하진 않습니다.
퇴고와 점진적 향상
마지막으로 이런 모든것을 반복적으로 고쳐가며 개선시키는 퇴고의 과정이 반드시 필요합니다. 아무리 천재소설가라도 천재 개발자라도 퇴고 없이는 부족한 결과물만 나올 뿐입니다. 보면 볼 수록 쓰면 쓸 수록 나아집니다. 쓰는 것을 두려워 하면 안됩니다.누구나 처음은 초라하며 고쳐가며 좋아집니다. 주변사람들의 의견은 많은 도움을 줄 수 있습니다. 많은 피드백을 받을 수 있는 인기 오픈소스의 품질이 좋은 이유도 그것입니다.
p.s
코딩은 공학과 문학의 조화에 있습니다.
공학을 확실한 답이 있는 것(예: 상황에 맞는 자료구조, 정해진 스펙 구현)이라고 정의 하고 ,
문학은 답이 자유분방한 것(예: 예외 처리 설계, 추상화)이라고 정의 한다고 가정 해 볼 경우에
보통 개발자들이 평소에 마주치는 대다수 고민들은 문학적 질문과 답에 있다고 생각합니다.
그래서 더욱더 코딩을 글쓰기와 비견되는 거 같습니다.
'소프트웨어 사색 ' 카테고리의 다른 글
SI,정부과제 vs 서비스 vs 솔루션 장단점 (1) | 2022.03.14 |
---|---|
실패/실수에 대처하는 다양한 방법들 (1) | 2021.11.09 |
스타트업 CTO 가 해야 할 것들 (링크) (0) | 2021.10.20 |
추상화 (1) | 2021.08.29 |
코더보다는 프로그래머가 되라? (5) | 2021.07.01 |