見出し画像

コーディングの動機づけ - 脳に収まるコードの書き方③ - ReadLog

前回のつづきです。章ごとにキッパリ分かれているのでここから読んでも一応は大丈夫です。

概要

タイトル:脳に収まるコードの書き方
ジャンル:技術書(情報系), ソフトウェア開発, プログラミング技法
備考:コードサンプルが具体的すぎて退屈

ここは本の紹介と記録を目的としたマガジンです。
時間がない人や面白い本を探している人向けです。
本の一部を引用しながら、少しでも興味を持ってもらうことを目指してます。

今回取り上げるのは、4章~6章です。
ソースコードの改善を、具体的なC#コードを示しながら説明してくれる親切さが逆効果になっており、読むのが非常にダルいという欠点があります。

内容は相変わらず重要なんですが…
本記事は「面白さ」を説明することが主題ですので、面白いところだけ書きます。厳密なことは元の本をあたってくださいね。


3つの章タイトルの駆け足説明

4章 バーティカルスライス

考えつく中で一番シンプルな機能をユーザーインターフェイスからデータストアまで全部実装することです

p.39 4章 バーティカルスライス

例えば、ユーザーインターフェース, API, DBなど、ユーザーの操作を実際のデータ操作に変換するまではいくつかの層に分けられます。

これを、層ごとに実装するのではなく、単一の機能に絞って一気に実装しよう、ということです。

5章 カプセル化

この本以外の定義をまず参照してみると

(前略)外部に対して必要な情報や手続きのみを提供すること。

カプセル化とは - IT用語辞典

で、私の読解だと、この説明だと不足しているらしくて、

本質的に、カプセル化はオブジェクトが無効な状態になることがないことを保証すべきです。

p.84 5章 カプセル化

と著者は述べています。

要するに、いくら必要な操作だけを公開していたとしても、不正な操作を受け付けるようではカプセル化とは言えない、というわけです。
無効な操作に対してはエラーを返す必要があります。

※先ほど参照したIT用語辞典でも、詳細部分でオブジェクトが不正状態にならないことについて触れられています。

6章 三角測量

4章と5章では、章タイトルに沿って「テスト駆動開発」による機能の実装について説明されます。

最初にテストを書き、そのテストが動作する必要最低限な実装をとりあえず行なった後、コードを洗練させる、という短い工程を繰り返すスタイルである。

テスト駆動開発 Wikipedia

6章では、既存コードがNGになるテストケースの追加と実装の修正を交互に行うことで、精密なテストケースとコードを作成する方法について述べられます。

まるで敵対的生成ネットワーク(GAN)のように、正常に見えるコードと、そのコードの問題を検出するテストケースのいたちごっこをするわけです。

GANsは生成ネットワーク(generator)と識別ネットワーク(discriminator)の2つのネットワークから構成される。

敵対的生成ネットワーク Wikipedia

生成AIの基礎技術と似た手法なので、非常に効果的だと思います。(素人考え)


開発の動機づけについての私見

一身上の都合により、「動機づけ」という言葉には関心と一家言とアレルギーがあります。

コードを変えるモチベーションが何かを見つけましょう。そのようなモチベーションでコードを駆動するのです。

p.42 4章 バーティカルスライス

個人的には、この場合駆動されるのはプログラマーだと思うのです。

世の中にはナントカ駆動開発がいっぱいあります。この本で紹介されているので言うと、(駆動開発 の部分は省略します。)

テスト,  ふるまい, ドメイン, タイプ,  プロパティ

さらに追加で、軽く調べて出てきた以下の記事から差分を抜粋すると

ユーザー機能, チケット, 締め切り, コンポーネント

※個別の駆動開発について正確に語る知識を私は持っていません。

実装コードを改善するために、いろいろな方法でプログラマのやる気を出させるわけです。

テスト駆動開発なら、「NGになるテストをパスするようにしたい」というのが動機の原因になるでしょう。


ところで、動機には分類があります。ここでは「自己決定理論」による分類を下敷きにしましょう。

自己決定理論において動機は、「動機づけがない状態」から、「環境により(外発的に)動機づけられている状態」、そして「主体的に(内発的に)動機づけられている」までの3分類6段階に分類されます。

細かい話をすると長くなるのでざっくり行きますが、外発的な動機づけより内発的な動機づけのほうがやる気たっぷりな状態だと思ってください。

外発的な動機づけは細かく分類されていて、以下の4つに分けられます。
下に行くほどより内発的動機づけに近づきます。

  1. 金銭や罰がある

  2. 周囲の評価がある

  3. 行動への価値を自覚している

  4. 自己の目的と一致している


で、テスト駆動開発における「NGになるテストをパスするようにしたい」という動機づけがどれに当てはまりそうかというと、かなり内発的動機付けに寄っていると思います。

  1. 金銭や罰がある
    →テストケースの達成による歩合制の仕事ではなさそう
    →解決できなくて怒られることもなさそう

  2. 周囲の評価がある
    →テストケース1件解決した程度で褒められることはなさそう

  3. 行動への価値を自覚している
    →ソフトウェアの完成のために必要なことだから

  4. 自己の目的と一致している
    →ソフトウェアを完成させたい(人による)

  5. 内発的動機づけ(楽しさ)
    →問題(テストNG)を解決することが楽しいから(人による)

結論何が言いたいかというと、テスト駆動開発ってプログラマを効果的に動機づけできてそうでいいね!!ってことです。
容易にやる気を生産できるなら儲けものです。

他の駆動開発の方式についても同様の議論ができそうです。気が向けば。


後半は勝手な余談になってしまいました。
7章から面白くなるので次をお楽しみに!!

次:


この記事が気に入ったらサポートをしてみませんか?