일종의 글쓰기로서의 코딩

May 10 2023

소프트웨어 개발자가 산문 작가로부터 배울 수 있는 것

와이오밍의 스네이크 리버가 북쪽으로 구부러지고 넓어지고 느려지는 곳이 있습니다. 무스는 수련을 탐색하고, 펠리컨은 물고기를 잡고, 수달은 놀아요.

와이오밍의 스네이크 리버가 북쪽으로 구부러지고 넓어지고 느려지는 곳이 있습니다. 무스는 수련을 탐색하고, 펠리컨은 물고기를 잡고, 수달은 놀아요. 그런 다음 강은 다시 구부러져 서쪽으로 산으로 여행을 재개합니다.

지금까지의 내 경력을 보면 같은 반복 경로를 볼 수 있습니다. 저는 소프트웨어 개발자에서 인문학 교사로 다시 소프트웨어 개발자로 돌아왔습니다. 공학과 인문학 사이에는 잘 알려진 거리가 있지만 사람들이 생각하는 것보다 짧다는 것을 알 정도로 충분히 여행했습니다. 그 과정에서 코드 작성이 일종의 글쓰기인 것처럼 산문 작성 작성자의 조언이 소프트웨어 작성자에게도 유용할 수 있음을 알게 되었습니다.¹

한 번은 배열에 항목을 추가하지만 이미 있는 경우 해당 항목을 제거하는 작은 함수를 만들어야 했습니다. 이와 같이:

toggle([], 1) // should return [1]
toggle([1], 1) // should return []

import _ from "lodash";
const toggle = (arr, item) => _.xor(arr, [item]);

하지만 얼마 지나지 않아 나는 다음과 같은 조언이 생각났습니다. 그것은 18세기의 수필가인 새뮤얼 존슨(Samuel Johnson)의 팁입니다.³ 나는 영리함의 간절함이 내 기능을 단순화해야 한다는 단서임을 깨달았습니다. 나는 그것을 다음과 같이 변경했습니다.

const toggle = (arr, item) =>
   arr.includes(item) ?
   arr.filter((x) => item !== x) :
   [...arr, item];

제 생각에는 그렇지 않습니다.⁴ 특정 측면에서는 더 복잡하지만 새 기능은 일반 코더에게 여전히 더 명확할 가능성이 높으므로 유지 관리가 더 쉽습니다. 한 줄의 코드는 구문적으로 단순하지만 명확하지 않거나 명확하지만 구문적으로 복잡할 수 있습니다. 한 줄의 산문처럼. “내가 읽고 싶지 않은 그 책을 무엇을 위해 가져왔니?”⁵ 구문이 복잡하지만 구문적으로 단순한 문장인 “”보다 훨씬 더 이해하기 쉽습니다. myrmecobius는 기권했습니다.” 더 이상 간결하지는 않지만 내 새 함수는 읽기가 더 쉬웠습니다.

그가 JavaScript를 알았다면 간결한 산문의 왕은 toggle. "헤밍웨이"(문제의 왕)는 "당신을 사전으로 데려가지 않습니다"라고 F. Scott Fitzgerald는 언젠가 고맙게 말했습니다 xor. 이 기능이 없으면 기능이 더 확장되고 명시적이며 그 때문에 더 자명합니다.⁷

laconic 이라는 용어는 Laconia라는 지역에 살았고 말을 낭비하지 않았던 고대 스파르타인에게서 유래했습니다. 한번은 적군이 그들에게 “내가 라코니아를 침략하면 너희를 이 땅에서 몰아내겠다”고 편지를 쓴 적이 있습니다. 그들은 "만일"이라고 답장했습니다.⁸

내가 존경하는 글쓰기의 한 가지 교훈은 소설가나 언론인이 아니라 박물관 설계자에게서 나온다. Edwin Schlossberg에 따르면 좋은 글은 "다른 사람들이 생각할 수 있는 맥락을 만들어 주는 것"입니다. 박물관 전시물처럼 그렇게 할 수 있는 공간을 제공합니다. 비슷한 방식으로 좋은 코드는 말하자면 독자를 위한 공간을 만듭니다. 그것은 그들이 추론하는 데 도움이됩니다.

따라서 일반적으로 코드 작성자가 일반 독자가 이미 잘 이해하고 있는 패턴을 따르는 것이 이치에 맞습니다. 대부분의 JavaScript 개발자는 위에서 사용된 삼항 (물음표와 콜론)에 익숙하지만 많은 사람들이 다음과 같은 if-else 블록을 훨씬 더 편안하게 사용합니다.

const toggle = (arr, item) => {
   if (arr.includes(item)) {
      return arr.filter((x) => item !== x);
   } else {
      return [...arr, item];
   }
}

작성자는 독자에 대해 공감해야 하며 코드를 유지 관리, 디버그 또는 조정할 사람들에 대해서도 공감해야 합니다. 그러나 당신이 저자이기 때문에 독자의 입장이 되는 데 어려움을 겪는 것은 정상입니다. 최고의 작가에게서 빌린 두 가지 기술을 시도하십시오.

첫째, Helen Sword는 "글을 쓸 때 어깨너머로 특정 사람들을 바라보는 모습을 시각화하라"고 제안합니다. 결국, "가장 매력적인 작가는 거의 변함없이 전문가와 비전문가, 동료 및 낯선 사람과 같은 실제 사람들에게 가장 세심한 주의를 기울이는 사람들입니다. 그들의 귀에는 자신의 말이 메아리칠 것입니다."¹¹ 코더를 위한 현명한 조언도 있습니다.

두 번째 방법: 코드를 하루나 이틀 동안 따로 보관해 두었다가 다시 사용하십시오. Neil Gaiman은 한때 작가 지망생에게 “단편 소설을 완성하고 인쇄한 다음 서랍에 넣고 다른 것을 쓰십시오.”라고 말한 적이 있습니다. “준비가 되면 한 번도 읽지 않은 것처럼 집어 들고 읽으십시오. 독자로서 만족스럽지 못한 것이 있으면 작가로서 들어가서 수정하십시오. 그것이 개정판입니다.”¹² 고대 작가 Quintilian은 또한 “우리가 일정 기간 동안 쓴 것을 제쳐두십시오”라고 권했습니다.

그래서 우리가 일정 시간이 지난 후에 다시 방문했을 때 그것은 참신함과 다른 사람의 작품이라는 분위기를 갖게 될 것입니다. 그렇게 함으로써 우리는 우리가 갓 태어난 아이에게 아낌없이 주는 모든 애정을 가지고 우리의 글을 바라보는 것을 스스로 막을 수 있기 때문입니다. ¹³

다른 종류의 기호에 대해 저작 지침을 적용할 수 있다는 것은 그리 놀라운 일이 아닙니다. 지식의 영역은 종종 서로 침투합니다. 소설가 찰스 존슨(Charles Johnson)은 다음과 같이 아름답게 표현했습니다.

예술적이고 지적인 표현의 한 형태는 다른 형태를 양육하고 먹입니다. 우리가 창의성과 상상력이라고 부르는 것이 무엇이든 간에, 이 두 가지 위대한 신비는 어떤 창작자들에게는 그들의 삶에서 "글로벌"한 것으로 경험될 수 있습니다. 왜냐하면 모든 인문학(과학과 함께)은 서로 연결되어 있기 때문입니다. ¹⁴

여기에서 권장하는 접근 방식을 사용하여 자신만의 코딩을 실험하려면 루틴을 변경해야 할 수 있습니다. 강물처럼 감속 하고 더 사려 깊고 관대해질 수 있는 우회로입니다 . 그래서 강에서 페이지를 가져옵니다. 선형 경로를 따르지 않습니다.

코딩 작성 유추에는 확실히 한계가 있습니다. 예를 들어, 모순은 소스 코드에서 거의 금지되어 있으며 예술, 특히 시에서 모순이 정의를 얻습니다. 포르투갈어를 몰라도 소리내어 읽는 것을 좋아하는 페르난도 페소아의 시가 있습니다. 시작이다:

O Poeta é um fingidor
Finge tão completamente
Que chega a finger que é dor
A dor que deveras sente.

시인은 가장하는 사람입니다.
그는 진짜를 완전히 속이고

그가 느끼는 끔찍한 고통 과 괴로움 까지 속 입니다 .¹⁵

Pessoa는 참과 거짓에 대한 관습적인 생각을 잠시 제쳐두도록 우리를 초대하고 있습니다. 시인은 자신의 시 뒤에 자신을 숨기고 그렇게 함으로써 시를 통해 자신을 볼 수 있게 된다는 모순을 당당하게 진술하고 있습니다. 부울 논리를 뒤로하고 Pessoa는 자신만의 논리를 발명합니다. "시인은 가장하는 사람이다": "내가 말하는 모든 것을 지어낸 것입니다. 이 말을 포함하여 모두 거짓입니다."가 아니라면 이것은 무엇을 의미합니까? 이것은 자기 반박적인 진술이며 논리적인 거짓입니다. 하지만 단어의 어원을 살펴보면 “O poeta é um fingidor”는 “만드는 사람은 만드는 사람입니다.”를 의미합니다. 논리적 진실. 그가 언급한 모의 고통처럼 시인의 주장은 표면적으로는 거짓이고 그 아래에서는 사실이다. 코드와 시는 종종 비논리적인 세계에 대처하기 위한 보완적인 전략을 제공합니다. 하나는 모순으로부터 피난처를 제공하고,

각주

[1]: 코딩-작성 유추는 Brian Kernighan과 PJ Plauger , Donald Knuth , Richard Gabriel , James Devlin , Jeff Atwood , Rebecca Sutton Koeser 등에 의해 이전에는 다르지만 이전에 만들어졌습니다 . Steve McConnell은 비유를 비판합니다.

lodash[2]: 다음은 실행 중인 라이브러리 기능 의 예입니다 xor. Boggle에서는 문자 그리드에서 단어를 찾습니다. 아무도 찾지 못한 단어를 찾으면 점수를 얻습니다. JavaScript로 게임 버전을 만들고 있다고 가정해 보겠습니다. 다음 데이터가 있습니다.

const wordsFoundByPlayerOne = ["apple", "peel"];
const wordsFoundByPlayerTwo = ["apple", "leap"];
const wordsFoundByPlayerThree = ["apple", "able"];

_.xor(
   wordsFoundByPlayerOne,
   wordsFoundByPlayerTwo,
   wordsFoundByPlayerThree
); // Output: ["peel", "leap", "able"]

[4]: 다음을 사용하여 읽기 쉬운 대안을 만들 수도 있습니다 Set.

const toggle = (arr, item) => {
  const set = new Set(arr);
  if (set.has(item)) set.delete(item);
  else set.add(item);
  return Array.from(set);
}

[6]: 2019년 기사 에서 Gary Gilson 코치가 인용했습니다 .

[7]: 대조적으로 블로거 Jeff Atwood는 " Spartan programming "을 홍보했습니다.

[8]: 플루타르크, On Talkativeness .

[9]: 물리학자 Konstantin Likharev가 2021년 책 에서 인용했습니다 .

[10]: 2012년 강연 "Simplicity Matters"에서 Rich Hickey는 프로그래머가 어려움을 두려워해서는 안 된다고 주장합니다 . 부분적으로는 그것이 우리 작업을 흥미롭게 만들기 때문입니다. 그러나 우리의 작업은 학교 수업 의 경우처럼 지루함과 과중함 사이의 골디락스 영역에 속할 때 가장 흥미로울 것입니다 .

[11]: Helen Sword, Stylish Academic Writing (2012), p. 44. 명료성을 향상시키기 위해 많은 작가들이 자신의 말을 들으면서 자신의 작품을 소리내어 읽습니다. 철학자 조나단 베넷(Jonathan Bennett)은 이렇게 썼습니다 . 무엇보다 그 통찰은 쓰레기 구덩이에서 어떻게 품위 있는 산문으로 올라가기 시작하는지를 보여 주었습니다.” Kernighan과 Plauger는 프로그래밍에 대해 유사한 통찰력을 제공합니다. “코드의 일부가 명확한지 여부를 결정하는 유용한 방법은 '전화 테스트'입니다. 누군가가 전화로 큰 소리로 코드를 읽을 때 코드를 이해할 수 있다면 충분히 명확한 것입니다. 그렇지 않다면 다시 작성해야 합니다”( 프로그래밍 스타일의 요소 , p. 21).