【Day014】プログラミングについて学習を始めるにあたり、まず、「達人プログラマー」を読んでみた。
2023年12月04日
プログラミングについて学習を始めるにあたり、まず、「達人プログラマー」を読んでみた。
プログラマー業界の読者の方々は絶賛していましたが、ゼロから初心者の自分にとっては難解な本でした。
巻末にまとめられていたTipsだけでも覚える努力をしよう。
１．自らの技術に関心を持つこと
ソフトウエア開発をうまく進めようという心を持たずして、自らの人生をソフトウエア開発に費やそうとするなかれ。
２．あなたの仕事について考えること！
漫然と仕事を進めるのではなく、自ら制御権を掌握すること。そして、常に批判的な目で自らの作業を評価すること。
３．あなたには現状を打破する力がある
これはあなたの人生についての話である。しっかりと手綱を握り、自らが望むように進めていくこと。
４．いい加減な言い訳よりも対策を用意すること
言い訳ではなく対策を用意する。「できない」などと言わずに「できる」ことを明確にする。
５．割れた窓を放置しておかないこと
まずい設計、過った意思決定、貧弱なコードを見つけたら修正する。
６．変化の触媒たれ
他人に変革を強制することはできない。そうではなく、未来を垣間見せ、その実現に参加できるよう手助けする。
７．大きな構想を忘れないようにすること
詳細に入り込みすぎて、周囲の状況をおろそかにしてしまわないようにする。
８．品質要求を明確にすること
ユーザーを巻き込み、プロジェクトの真の品質要求を決定する。
９．あなたの知識ポートフォリオに対して定期的な投資を行うこと
学習の習慣をつける。
１０．見聞きしたものごとを批判的な目で分析すること
ベンダーの売り文句、メディアの宣伝、独善的考えに惑わされない。あなたとあなたのプロジェクトという観点から情報を分析する。
11．日本語をもうひとつのプログラミング言語として考えること
日本語をもうひとつのプログラミング言語して考え、コーディングを行うようにドキュメントを記述する。DRY原則、ETC、自動化などを順守する。
12．伝えることがらと、伝える方法は車の両輪だと考えること
うまく伝えることができなければ、よいアイデアも無意味である。
13．ドキュメントは付け足すものではなく、作り上げるものである
コートと別に作られたドキュメントは、正確性に劣り、すぐに陳腐化する。
14．よい設計は悪い設計よりも変更しやすい
ものごとはそれを使う人に適合する場合にうまく設計されていると言える。コードの場合、それは変化に対応できなければならないということを意味している。
15．DRY-Don’t Repeat Yourself（繰り返しを避けること）
システム中のすべての知識は、重複なく、明瞭、信頼できる表現となっていなければならない。
16．再利用しやすいようにしておくこと
再利用しやすくしておけば、皆はそれを使うためにやってくる。再利用をサポートできる環境を構築する。
17．関係ないもの同士の影響を排除すること
単一目的のうまく定義され、自己完結した独立コンポーネントを設計する。
18．最終決定などというものは存在しない
石に刻み込まれたような決定はあり得ない。すべての決定を砂浜の砂に描かれたものと考え、変更に備えておく。
19．流行を追い求めないようにする
Neal Fond の言葉、「昨日のベストプラクティスは明日のアンチパターンになる」を噛みしめ、流行ではなく、地に足の付いたアーキテクチャーを選ぶこと。
20．目標を見つけるには、曳光弾を使うこと
曳光弾を使えば、目標の補足と目標にどれだけ近く着弾したのかが判るようになる。
21．プロトタイプの真の目的は学びにある
プロトタイプとは、学習の経験についてである。その価値はでき上がったコードにあるのではなく、学習した教訓そのものにある。
22．問題領域に近いところでプログラミングを行うこと
問題領域の言葉で設計、コーディングを行う。
23．後でびっくりしないために、見積もりを行うこと
始める前に見積もりを行い、前もって潜在的な問題を洗い出しておく。
24．規律に従ってスケジュールを繰り返し、精度を向上させていくこと
プロジェクトの期間見積もりに磨きを掛けるには、その実装によって得た経験を用いる。
25．知識はプレインテキストに保存すること
プレインテキストは、廃れることがなく、デバッグやテストを簡潔にする強力な武器となり得る。
26．コマンドシェルの力を使うこと
GUIで実現できなければシェルを使う。
27．エディターに熟達すること
エディターは最も重要なツールである。やりたいことを迅速かつ正確に実現できる方法を知っておく必要がある。
28．常にバージョン管理システムを使用すること
バージョン管理システムはあなたの仕事で使えるタイムマシンであり、どんな過去にも戻ることができる。
29．非難するのではなく、問題を修復すること
バグの原因が誰にあるかは問題ではない―――問題はあなたのものであり、あなたが解決しなければならないのだ。
30．パニクるな
銀河のヒッチハイカーと開発者はこの言葉を忘れてはいけない。
31．コード修正の前にテストを失敗させること
バグの修正に取りかかる前に、そのバグを再現するテストを作成すること。
32．エラーメッセージをちゃんと読む
ほとんどの例外メッセージには、どこでどういうことが発生したのかも含まれている。運がよければパラメーターの値も表示されている。
33．"select" は壊れていない
OSやコンパイラ、さらにはサードパーティの製品やライブラリーのバグを見つけることはまれである。バグはたいていの場合アプリケーション側に存在する。
34．仮定を置かずに、証明すること
実際の環境———つまり実際のデータと境界条件を用いて仮定を証明する。
35．テキスト操作言語を学ぶこと
毎日多くの時間をテキスト作業に割いているのなら、そういった作業をコンピュータにさせるべきである。
36．あなたは完璧なソフトウエアを作ることができない
ソフトウェアは完璧にならない。このため、不可避のエラーからコードとユーザーを守る。
37．契約を用いて設計を行うこと
ドキュメントには契約の考え方を用い、コードがそれ以上のこともそれ以下のことも行わないようにする。
38．早めにクラッシュさせること
中途半端に動いているプログラムは、停止したプログラムよりもたちが悪い。
39．もし起こり得ないというのであれば、表明を用いてそれを保証すること
仮定を検証するには表明を使用する。表明を用いて不確かな世界からコードを守る。
40．始めたことは終わらせる
リソースの解放は、可能な限りそのリソースを割り当てた関数やオブジェクトが責任を持って行うべきである。
41．ものごとを局所的にする
変更可能な変数のスコープを制限し、リソースの使用時間を短くするとともに可視化できるようにしておくこと。
42．少しずつ進めること―――常に
常に小さな歩幅で少しずつ進める。そしてフィードバックを得た上で、先に進む前に軌道修正を加える。
43．予言は避ける
見えるところまでのみを見るようにする。
44．分離されたコードは変更しやすい
ものごとを結合させると、１つのことを修正するのも難しくなる。
45．照会せずに依頼する（TDA：Tell, Don't Ask）
オブジェクトから値を取得し、その値を操作し、結果をオブジェクトに戻してはいけない。該当オブジェクトにすべての仕事を任せること。
46．メソッド呼び出しを連鎖させないこと
何かにアクセスする際には、ドット（.）を２つ以上続けないこと。
47．大域データを避ける
これはすべてのメソッドにパラメーターを追加して回るのと同じ結果になる。
48．大域データにするだけ重要なものである場合、APIでラップする
・・・とは言うものの、どうしても大域データにしておきたい場合にのみこの手を選択すること。
49．プログラミングとはコードについての話であるが、プログラムはデータについての話である
すべてのプログラムはデータを変換し、入力を出力へと変える。まず、変換を用いた設計を考えること。
50．状態をため込まず、引き渡すようにする
関数やモジュール内にデータをため込まずに、引き渡すようにすること。
51．インヘリタンス（相続）税を払わないこと
インターフェースや委譲、mixin といったニーズに見合った代替策を考慮すること。
52．ポリモーフィズムの表現にはインターフェースを愛用すること
インターフェースは、継承によって生み出されるような結合を気にすることなくポリモーフィズムを実現できる。
53．サービスに委譲すること：has-a は is-a に勝る
サービスを継承してはならない。サービスを保持するようにすること。
54．機能の共有には mixin を使用する
mixin を使えば、相続税を支払うことなくクラスに機能を追加できるようになる。インターフェースと組み合わせて、痛みを伴わないポリモーフィズムを実現すること。
55．外部設定を用いてアプリをパラメーターに対応させる
アプリケーションが本番稼働に入った後でも、ある程度挙動をかえられるようにするには、アプリの外側でそういった挙動を指示する値を保持しておく。
56．並行性を向上させるためにワークフローを分析する
ユーザーのワークフローにおける並行性を明らかにする。
57．共有状態は間違った状態
状態の共有によって、すべてをやり直すしかないほどのさまざまな問題が生み出される。
58．無秩序なエラーはしばしば並行処理によって引き起こされる
並行処理のバグは、タイミングやコンテキストの変化によって無秩序かつ再現性のないかたちで引き起こされる。
59．共有状態を持たないアクターを並行処理で使用する
明示的な同期を用いずに並行処理を管理するにはアクターを使用する。
60．ワークフローを協調させるためにはホワイトボードというコンセプトを活用すること
独立性を保ったまま共通点のない事実やエージェントを協調させるには、ホワイトボードを使用する。
61．爬虫類脳に耳を傾ける
開発中のコードが抵抗しているように感じられるのは、あなたの無意識が何らかの間違いを訴えかけているためである。
62．偶発的プログラミングを行わないこと
信頼のおけるもののみを信頼する。偶発的な複雑さを避け、単なる偶然と意図的な結果を混乱しないようにする。
63．アルゴリズムのオーダーを見積もること
どのくらいリソースを消費するのか、コードを書き始める前に感触をつかむようにする。
64．見積もりの検証を行うこと
アルゴリズムの数学的分析ですべてが分かるわけではない。このため、対象としている環境で実際に測定する。
65．早めにリファクタリングすること、そしてこまめにリファクタリングすること
庭の雑草取りや植物の植え替えと同じように、必要に応じてコードの再記述、再作業、再アーキテクトを行う。そして問題の根本原因を修正する。
66．テストとはバグを見つけることではない
テストとは、コードに対する１つの観点であり、その設計やAPI、結合についてのフィードバックを与えてくれるものである。
67．テストはコードのユーザー第1号である
テストからのフィードバックを活用し、要求に対する洞察を深めること。
68．トップダウンでもボトムアップでもなく、エンドツーエンドで構築していく
エンドツーエンドで小さな機能を構築し、そこから作業を進めながら問題について学んでいく。
69．テスト設計を行うこと
コードの記述を始める前にテストのことを考え始める。
70．ソフトウェアをテストすること、さもなければユーザーにテストを強いることになる
容赦ないテストを行う。ユーザーが先にバグを見つけることのないようにする。
71．仮定を検証するためにプロパティーベースのテストを使用すること
プロパティベースのテストは、あなたが試してみようと思ったことのないテストを試し、想定されていない方法でコードを実行してくれる。
72．KISS の原則を守り、アタックサーフェスを最小化する
複雑なコードはバグや、攻撃に利用できる脆弱性の温床となる。
KISS の原則 (英: KISS principle) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則[1]の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。出典: フリー百科事典『ウィキペディア（Wikipedia）』
73．セキュリティパッチはすぐに適用すること
攻撃者はすぐに攻撃を仕掛けることができるため、それよりも先に手を打つ必要がある。
74．適切な名前を付け、必要に応じてリネームすること
読み手に意図を理解してもらえる名前を付け、意図が変わったのであればすぐにリネームすること。
75．自らが欲しているものを正確に認識している人などいない
全体的な方向性は分かっているかもしれないが、その先に待ち構えている紆余曲折など誰も知らない。
76．プログラマーの仕事は、人々自身が欲しているものを自ら気付いてもらうように支援すること
ソフトウェア開発とは、ユーザーとプログラマーによる共同作業という行為である。
77．要求はフィードバックループの中で学んでいくものである
要求を理解するには、探求とフィードバックが必要となり、意思決定の積み重ねが初期のアイデアを洗練する鍵となる。
78．ユーザーとともに働き、ユーザーのように考える
これがシステムの「実際の使用法」について洞察を得る最善の手である。
79．ポリシーはメタデータである
ポリシーをシステム内にハードコーディングしてはいけない。ポリシーはシステムによって使用されるメタデータとして表現すること。
80．プロジェクトの用語集を作ること
プロジェクトが使用する特定の専門用語や語彙をまとめた用語集を作成、維持する。
81．枠にとらわれずに考えるのではなく、枠を見つけ出すこと
不可能と思える問題に遭遇した場合、「本当の制約」を見抜く。「この手段でやり遂げなければならないのか？」「そもそもやらなければならないのか？」を自問する。
82．1人ぼっちでコーディングに取り組んではいけない
プログラミングは要求水準の高い難しい作業である。このため仲間を連れて行くように。
83．Agile という言葉は名詞ではなく、ものごとの進め方を形容する形容詞である
「Agile」は何かを実行するあなたのスタイルを指す形容詞である。
84．小規模で安定したチームを作ること
チームはメンバー全員がお互いのことをよく知っており、信頼し合い、助け合う、小規模で安定したものとなっているべきである。
85．事を成し遂げるにはまずスケジュールする
スケジュールしなければ何ごとも起こらない。振り返りや実験、学習、スキルの向上をスケジュールする。
86．完璧に機能するチームを編成すること
チームの編成は、職務権限ではなく機能に基づいて実施すること。ユーザーインターフェースとユーザーエクスペリエンスのデザイナーとコーダーを、フロントエンドとバックエンドを、テスターとデータモデラ―を、設計と配備を分離してはいけない。
コードをエンドツーエンドで構築でき、インクリメンタルかつイテレーティブに開発できるチームを編成すること。
インクリメンタル 【incremental】
インクリメンタルとは、増加の、増分の、漸進的な、漸増していく、などの意味を持つ英単語。 インクリメント（increment：増加、増分）の形容詞形で、一気に増えるのではなく徐々に増加する、付け加わる、漸進的に変化する様子を表している。
イテレーティブの名詞がイテレーションで、反復のことです。 アジャイル開発ではイテレーション毎に徐々に機能を追加してプロダクトを増強していきます。 イテレーティブは単に繰り返すという意味で、機能を増やすという意味はありません。
Incremental is not iterative
Using a very interesting combination of pop music and rock star images, Jeff Patton told a story of a failed agile project in his XpDay keynote “Embrace Uncertainty”. The project started off nicely, almost by the book, with customer involvement and stories split into iterations, based on what functionality is to be delivered in what release. After they got something delivered to play with, customers changed their minds (as they so often do) and new stories and features were introduced into the plan. After a few deliveries, the scope kept growing and growing instead of reducing. From the developer perspective everything worked as planned – customer was expanding the scope and developers are there to oblige, because that is the essence of agile practices. Spice Girl Mel B was used for the role of a developer writing user stories and losing all sight of the big picture (while “So tell me what you want, what you really really want” was playing in the background). For the customer, the thing simply did not work - iteration after iteration, they were not any closer to having the project done.
The problem was that the concept of iterating had been lost and iterations were replaced by increments – making the project fall into the same trap as waterfall projects do. Iterations were aimed to deliver blocks of functionality. Jeff demonstrated that visually using the Mona Lisa painting (powerpoint slides from the keynote have still not been released, so the pictures below are not the same ones as Jeff used, but they show the point):
Although both these plans aim for the same thing, the incremental plan does not really reduce the risk of delivering something unsuitable to the client. The big picture appears only at the very end. Because increments are done in detail, a lot of effort is wasted when a piece needs rework (and the initial releases are almost certain to fall into this category). Iterative development offers a chance to see the picture from the start, and guide the development towards the full picture in steps. Not carving stuff in stone from the start allows us to change them easier later on, and we know that we’ll need to do that. Jeff gave the following rule of thumb to check quickly if your plan is iterative or incremental: “it’s not iterating if you do it only once”.
87．流行を追いかけるのではなく、効き目があるものごとを実行すること
他社が実践しているというだけの理由で開発手法や開発テクニックを採用してはいけない。あなたのコンテキストで、あなたのチームに有効なものを採用すること。
88．ユーザーが必要としたタイミングで調達すること
採用しているプロセスを理由にして、何週間も、あるいは何カ月も調達を遅らせてはいけない。
89．バージョン管理によってビルド/テスト/リリースを駆動すること
コミットやプッシュを使用してビルドやテスト、リリースを起動する。本番環境への配備を実行するためにバージョン管理タグを使用する。
90．早めにテスト、何度もテスト、自動でテスト
毎回ビルドを行うたびに実行されるテストは、棚にしまわれているテスト計画書よりもずっと有効なものとなる。
91．テストがすべて終わるまでコーディングは終わらない
これ以上の説明は要らないはず。
92．テストのテストをするには破壊工作を試みる
テストがうまく機能するかどうかを確認するには、目的に応じたバグをソースのコピーに混入してみる。
93．コードのカバレージではなく、状態のカバレージをテストすること
テストは、重要なプログラムの状態を識別して行う。すべての行をテストしただけでは純分ではない。
カバレージ（英：coverage）とは
「カバレッジ」のこと。
用語の中身としては
「あ～、こいつはね。全体に対して、これくらいをカバーしているよ（したよ）」的なことをカッコ付けて言った表現
です。
システムテストの話で出てきた場合は「テストを全部やると、これだけ確認できるはずだよ。それに対して今はこれだけの確認が終わってるよ」な割合（テストカバレッジ）のこと
を意味します。
94．同種のバグを一度に見つけること
テスト担当者がバグを見つけた場合、今後はもうそのバグ自体を人間がみつけることのないようにする。以降は自動化されたテストにチェックさせる。
95．手作業を排除する
コンピュータであれば同じ命令を同じ順序で何度も実行できる。
96．単にコードを調達するのではなく、ユーザーを喜ばせる
業務価値を生み出すソリューションをユーザーのために生み出し、彼らを日々喜ばせる。
97．あなたの作品に署名すること
先人たちが自らの成果物に誇りをもって署名したように、ソフトウェアに署名する。
98．とにかく、害をなさないようにすること
問題の発生は避けられない。誰も問題によって苦しまないようにすること。
99．極悪なことを実行できるようにしない
さもなければ自らも極悪な人間になるリスクを負うことになる。
100．これはあなたの人生だ。皆と共有し、祝福し、生み出していくこと。そして思いっきり楽しむこと！
素晴らしい人生を楽しみ、偉大な成果を成し遂げよう。
次は、リーダブルコードに挑戦しよう。
