一種のライティングとしてのコーディング

May 10 2023

ソフトウェア開発者が散文の著者から学べること

ワイオミング州のスネーク川が北に曲がり、川幅が広がり、流れが遅くなる場所がある。ヘラジカがスイレンを眺め、ペリカンが魚を捕まえ、カワウソが遊んでいます。

ワイオミング州のスネーク川が北に曲がり、川幅が広がり、流れが遅くなる場所がある。ヘラジカがスイレンを眺め、ペリカンが魚を捕まえ、カワウソが遊んでいます。その後、川はカールして元に戻り、山に向かって西への旅を再開します。

私のこれまでのキャリアを見てみると、同じループの道が見えてきます。私はソフトウェア開発者から人文科学の教師になり、ソフトウェア開発者に戻りました。工学と人文科学の間には距離があることはよく知られていますが、私はそれを十分に旅してきたので、それが人々が考えているよりも短いことを知っています。その過程で、散文の作者が述べたアドバイスの一部は、ソフトウェアの作者にとっても有益である可能性があることに気づきました。あたかも、コードを書くことが執筆の一形態であるかのようです¹。

かつて、配列に項目を追加し、項目がすでに存在する場合は削除する小さな関数を作成する必要がありました。このような：

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

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

しかしすぐに、私はいくつかのアドバイスの言葉を思い出しました。「自分の作文を読み返して、特に良いと思う箇所に出会ったら、それを削除してください。」これは、18 世紀のエッセイスト、サミュエルジョンソンからのヒントです。³ 賢さへのうずきは、自分の役割を単純化する必要があるというヒントだと気づきました。それを次のように変更しました。

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

私の意見では、「いいえ」です。⁴ 新しい関数は、特定の点ではより複雑ではありますが、それでも平均的なプログラマーにとってはより明確であり、したがって保守が容易である可能性があります。コード行は、構文的には単純でも不明瞭な場合もあれば、構文的には明確でも複雑な場合もあります。まるで散文の一行のようだ。「私が読まれたくないその本を何のために持ってきたのですか?」という文を考えてみましょう⁵ この文は複雑な構文を持っていますが、たとえば構文的に単純な文よりもはるかに理解しやすいです。ミルメコビウスは潜伏した。」簡潔ではなくなりましたが、新しい関数は読みやすくなりました。

もし彼が JavaScript を知っていたら、簡潔な散文の王自身がの簡潔なバージョンに眉をひそめたかもしれませんtoggle。F. スコットフィッツジェラルドはかつて、問題の王である「ヘミングウェイ」は「あなたを辞書に誘導しません」と感謝の気持ちを込めて言いました。⁶ もしそれがを使用していたら、私の関数はほとんどの読者をドキュメントに誘導したでしょうxor。これがなければ、関数はより広範囲に渡って明確になり、そのためより一目瞭然になります。

ラコニックという用語は、ラコニアと呼ばれる地域に住んでいて言葉を無駄にしない古代のスパルタ人に由来しています。かつて敵は彼らに、「もし私がラコニアに侵攻したら、あなたたちをその地から追い出すだろう」と手紙を書いた。彼らは「もし」と返信しました⁸

私が尊敬する文章に関する教訓の 1 つは、小説家やジャーナリストではなく、美術館の設計者からのものです。エドウィン・シュロスバーグによれば、良い文章は「他の人が考えることができる文脈を作り出す」ものです⁹ それは、彼らが想像し、考え、反応するのに役立ちます。博物館の展示のように、そうするためのスペースが与えられます。同様に、優れたコードは、いわば読者のためのスペースを作ります。それは彼らが推論するのに役立ちます。

したがって、コードの作成者が、平均的な読者がすでによく理解しているパターンに従うのは通常理にかなっています。ほとんどの JavaScript 開発者は、上で使用した3 項(疑問符とコロン) に精通していますが、多くは、次のような if-else ブロックをさらに使い慣れています。

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

作成者は読者に対して共感を持たなければなりません。また、コードを保守、デバッグ、または適応させる人に対しても共感を持たなければなりません。ただし、あなたは著者なので、読者の立場に立つのが難しいのは普通のことです。最高のライターから借りた 2 つのテクニックを試してください。

まず、ヘレン・ソードは、「書きながら、肩越しに特定の人が見ているのを視覚化する」ことを提案しています。結局のところ、「最も魅力的なライターは、ほとんどの場合、専門家も非専門家も、同僚も見知らぬ人も、自分の言葉が耳に響く現実の人々に最も細心の注意を払う人です。」¹¹ これはプログラマーにとっても賢明なアドバイスです。

2 番目のテクニック: 可能であれば、コードを 1 ～ 2 日放置してから、コードに戻ります。「短編小説を書き上げて、印刷して、引き出しに入れて、他のことを書いてください」とニール・ゲイマンはかつて作家志望の人に言いました。「準備ができたら、まるでこれまで読んだことがないかのように、手に取って読んでください。読者として満足できない点がある場合は、作家として立ち入って修正してください。それが修正です。」¹² 古代の作家クインティリアヌスも、「自分が書いたものを一定期間脇に置く」ことを推奨しました。

そのため、しばらくしてからその作品に戻ったときに、その作品には斬新さと他人の手仕事のような雰囲気が漂います。というのは、こうして私たちは、生まれたばかりの子供に惜しみなく注ぐ愛情を込めて自分の著作を扱うことを妨げてしまうかもしれないからである。¹3

執筆上の指導が異なる種類のシンボルに適用できることは、それほど驚くべきことではありません。知識分野はしばしば相互に浸透し、小説家のチャールズ・ジョンソンは次のように見事に表現しています。

芸術的かつ知的表現の 1 つの形式が、他の形式を育み、栄養を与えます。私たちが創造性と想像力と呼ぶもの、この 2 つの大きな謎は何であれ、一部のクリエイターにとっては、人生において「グローバル」なものとして経験されており、単一の表現形式に局地化されるのではなく、むしろあるジャンルから別のジャンルへ、芸術的または芸術的または芸術的または芸術的または芸術的または芸術的または芸術的または芸術的または芸術的形式への広がりまたは流出を経験している一部のクリエイターにとっては、なぜなら、すべての人文科学は（科学とともに）関連しており、相互に接続されているからです。¹⁴

ここで推奨されているアプローチを使用して独自のコーディングを実験するには、ルーチンの変更が必要になる場合があります。川のように減速し、より思慮深く、より寛大になるための回り道。川からページをめくってみましょう。直線的な道をたどるわけではありません。

確かに、コーディングとライティングの類似には限界があります。たとえば、ソースコードでは矛盾はほとんど禁止されていますが、矛盾が正当に評価されるのは芸術、特に詩です。ポルトガル語はわかりませんが、声に出して読むのが好きなフェルナンドペソアの詩があります。始まります：

指を
完成させて
、指を完成させてください
。

詩人は偽りをする人だ。
彼は本物を完全に偽造し、実際に

感じているひどい痛みや苦しみさえも偽造します。¹⁵

ペソアは、真と偽に関する従来の考えを一時的に脇に置くよう私たちに勧めています。彼は、詩人は詩の背後に自分自身を隠し、そうすることで詩を通して自分自身が見えるようになるという矛盾を悪びれることなく述べています。ブール論理を置き去りにして、ペソアは独自の論理を発明します。「詩人とは偽りをする人だ」：そうでないなら、これは何を意味するのだろうか、「私が言っていることはすべてでっちあげだ――まさにこの言葉も含めて、すべて虚偽だ」ということだろうか。これは自己論駁であり、論理的な虚偽です。しかし、言葉の語源を調べてみると、「O poeta é um fingidor」は「作り手は作り手だ」という意味です。論理的な真実。彼が言及するシミュレートされた痛みのように、詩人の主張は表面的には誤りですが、裏では真実です。法典と詩は、しばしば非論理的な世界に対処するための補完的な戦略を提供します。矛盾からの避難所を提供し、

脚注

[1]: コーディングとライティングの類似性は、形は異なりますが、ブライアン・カーニハンと PJ プラウガー、ドナルド・クヌース、リチャード・ガブリエル、ジェームズ・デブリン、ジェフ・アトウッド、レベッカ・サットン・ケーザーなどによって以前にもなされています。Steve McConnell はこの類似性を批判しています。

[2]: これは、実際のlodashライブラリ関数の例です。xorBoggle では、文字のグリッド内で単語を検索します。他の人が見つけなかった単語を見つけた場合は、その単語に対してポイントを獲得します。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 年の記事でライティングコーチのゲイリー・ギルソンが引用。

[7]: 対照的に、ブロガーのジェフ・アトウッドは「スパルタプログラミング」を推進しました。

[8]: プルタルコス、おしゃべりについて。

[9]: 2021 年の本の中で物理学者コンスタンチン・リクハレフが引用。

[10]: 2012 年の講演「Simplicity Matters」で、Rich Hickey は、プログラマは困難を恐れるべきではないと主張しています。その理由の 1 つは、それが私たちの仕事を面白くするからです。しかし、私たちの仕事は、学校の授業の場合のように、退屈と負担の間のゴルディロックスゾーンに該当する場合に最も興味深いものになります。

[11]: ヘレン・ソード、スタイリッシュなアカデミック・ライティング(2012)、p. 44. 明瞭さを高めるために、多くの作家は自分の作品を声に出して読み、自分自身の声を聞きます。哲学者のジョナサン・ベネットは次のように書いています。「ギルバート・ライルはかつて私にこう言いました。『耳に伝わらないものは、目にもよく読めない』という言葉が私の人生を変えました。何よりもその洞察力は、ゴミ箱からまともな散文の平原へ這い上がる方法を私に教えてくれました。」カーニハンとプラウガーは、プログラミングに関して同様の洞察を提供しています。「コードの一部が明確かどうかを判断する便利な方法は、『電話テスト』です。電話で誰かがコードを読み上げて理解できれば、それは十分に明確です。そうでない場合は、書き直す必要があります。」 (「プログラミングスタイルの要素」、p. 21)。