背景
プログラマではないが、プログラマ並の知見が求められるのがインフラエンジニアだったりすると痛感する昨今。
書いている言語で至らない点が数多く存在し、こんなんじゃダメだと思ったのがきっかけで読み始めた。
メモ程度の記述しかしないかもしれないし、文章として至らないことは数多く存在するかもしれない。
予めご了承ください。
読んだ本
章立てについて
全４部7章で構成された構成となっている。
第1部:本番システムのプログラミング
コードを鍛える
品質を保証する為のテストはいくつか種類が存在する。
ここではそういったテストの紹介がされていた。
テストの紹介だけなので割愛する。
最後に、テスト実施後にその製品が壊せるかどうかも試すとよいとあった。そして壊し方を元にバグレポートまで記載すると良いとのこと。
正しさにこだわる
小さなプログラムなら正しいか正しく無いかを見分けるのは簡単だ。
しかし大きなプログラムの場合入力が多数になるし、システムの状態も考慮に入れる必要が出てくる。
こういったもののチェックは容易ではないので、以下を実践してほしいとあった。
・使っているプログラミング言語について、単体テストフレームワークを調べなさい
ほとんどの言語は通常の基本機能とフェイクオブジェクトの為の何らかの機能を持っている。
その両方を実行する為に必要なツールをインストールしなさい
・自分で選んだ言語で同じことをするプログラムをつくり、アプリケーションコードの全ての行の正しさを保証する単体テストを書きなさい
テストしながら設計する
プログラミングも問題を解きながら理解を進めていく作業なので、同様に設計についてもテストしながら設計するのが望ましいとしている。
テストには3つの目的があると著者述べている。
①外部コンポーネントとのやりとりを細かく分析せずにテストができることにより、作業スピードを上げられる。
②テストによって自然にコードの書き方がモジュール化されていく。
③テストをしているので、将来のメンテナーが意識せずに何かを壊してしまうことを避けられる
こういったテストの目的を踏まえてテストを実施していくのが望ましいが、テストのやりすぎは良く無い。
必要な値によるテストのみを実施すること。
複雑さを手懐ける
複雑になりがちな問題に誰しも直面することがあるだろう。
そういった時、複雑の反対は「単純」と思い浮かべるかもしれないが、必ずしも全てのコードが「単純」化されるとは限らない。
じゃあどういったものを考えれば良いのかというと、**「明快」**を意識するのが良いとしている。
（複雑の反対は明快だと著者は述べていた。）
「明快」には2種類あり、「明快な思考」と「明快な表現」のことを指す。
明快な思考とは
何かの定義を1つに絞りまとめること。
例えば時間に関する格納方法は1つに限定し、まとめてしまうことなどが挙げられる。
明快な表現とは
モジュールについての考えが明確で、プログラムの他の部分のモジュールを綺麗に分離して表現することのこと。
穏便に失敗を収める
コードにてエラーが発生するのは最も避けたい事象だ。
よって、どのようにした結果エラーが発生したのか、その動作を確認するのはとても大切なことである。
まず、失敗してしまった場合、処理の順序から確認する必要がある。
処理を確かめる為にも「モンキーテスト」と呼ばれるテストを実施し、処理をチェックするのも良いだろう。
スタイリッシュになろう
良いスタイルでコードを書くことは、ソフトウェアの品質の１要素であると述べている。
この章の冒頭に以下のような要約が記載されていた。
良いスタイルでコードを書けば、プロの世界に入る前から役に立つ
使っている言語のスタイルガイド、または社内規定で定められたルールでもかまわない。
個々のルールの根拠を説明したものをよく読んでおくことで、コードを読みやすくする意図を理解することが出来る。としている。
レガシーコードを改良する
古いコードは書き直して全て新しくしなおした方が読みやすいことこの上ないだろう。
しかし、そうもいかないので、レガシーコード（テストが書かれていないコード）を改良するのが望ましいとする。
環境を最適化する
開発ツールは毎日使うものだ。
数年前に選んだツールが今もこれからもベストなツールであり続けるとは限らない。
よって、プログラムを書く為の環境は常に見直す必要があると述べている。
言語に精通する
プログラマは翻訳者だ。
人間の言語で書かれたプログラムの仕様説明を受け取り、プログラミング言語で書かれた本物のプログラムに翻訳するのがプログラマの役割とされている。
よって、有能な翻訳者になる為には両方の言語に精通している必要がある。
プログラミング言語に精通する近道は残念ながら存在しない。
本当の実力をつけるためには、1万時間の専門的な練習が必要としている。
上記の1万時間とは約10年と見積もっている。
いきなり1万時間達成する為の目標を立てるのは酷なので、まずはプログラミング言語を1・２種類マスターすることを念頭に学習を進めると良い。
自動化によって仕事を楽にする
産業プロジェクトであれば、プログラムのビルドは自動化されており、プログラム自体はmakeするだけで簡単に完了するのが大半かもしれない。
しかし、ソースコードのコンパイルで用いられているツールは汎用の自動化ツールだ。
コンパイラの実行以外にも様々な用途で使用することが可能だ。
自動化の目標は2つあり、1つは面倒な仕事を削減すること、もう1つは繰り返し同じ結果が得られるようにすることとある。
こうした目標を達成する為にも、自動化を積極的に利用していく必要があると述べている。
以上がこの章の流れとなった。
コードを作る上で意識すべきことなどがコード事例と共に記載されている。
第2部:人としてのスキル
己を高めていく為の手段が記載されている部分だった。
大まかに要約すると以下になる。
・メンターを見つける
・「自分のスタイル」が持てるよう、30分時間を設け仕事で自分が発したいイメージを書き出してみる
・書き出したイメージと今の自分を照らし合わせ、不足している部分を補うにはどうしたらいいのか考える
・服はイメージを形作るので、クローゼットを整理し不要なものは捨てる
・人事考課を通り抜ける為、考課前に管理職の方に直接「自分の仕事ぶりはどうでしょうか。」と聞いてみる
また、聞いた上で帰ってきた答えから改善出来る部分を探し、修正する。
・自分のストレスを認識し、対処法を考える
・仕事をする上で自分にとって最適な環境をつくる
・チームメンバーの名前を書いてそれぞれのつながりをチャート図にする
図をつくった後、日常のやり取りから関係性を把握する
・他のプログラマとも会話するように心がける
・会議は効率よく行う
第3部:企業の世界
同僚を知る
どんな組織でも、成果をあげる為には他者との協力が必要だ。
同僚の中には様々な職分に分かれており、個々に様々な役割がある。
プログラマ、テクニカルリーダー、アーキテクト、管理職（マネージャー）が例として挙げられており、それぞれの役割について述べられている。
それらが紹介された上で、「チーム内でのあなたの役割」という題の元、自分が果たすべき役割が何なのか、チームで求められていることは何かを意識して行動することが良いとしている。
企業の解剖学
すべての企業は、人と同じように独自の個性を持っている一方、基本的な構造は大差ない。
組織の中において、部署を超えた会話は起きるものなので、他部署の人とも会話するきっかけを持つことが大切だと述べている。
このトピックでは、それぞれの役職に応じて、他部署との交流きっかけとしての会話例が記載されている。
プロジェクト管理の手法
多くの人が「プロジェクト管理」と「プロダクト管理」を混同してしまう傾向があると筆者は述べている。
双方は全く異なるもので、それぞれを以下に記している。
・プロジェクト管理とは、日程を決めてそれに遅れないように管理することだ。
プロジェクトとは、計画され目標がある企図である。開始、終了が明確にある時間的な存在だ。
それに対し、製品管理は、会社が販売する商品を決めてマーケティングすることだ。
製品を実際に構築していくこととはまったく無関係である。
上記の説明により、「プロジェクト管理」の定義の明確化がされたところで、ウォーターフォール型のプロジェクト管理についての説明が入る。
説明内では、ウォーターフォール型では欠点が2つあり、1つ目は新規改善策の導入が必要な場合、プロジェクト開始時点から導入までに至る作業時間、工程が読めないことが挙げられる。もう1つは、最後の完成段階になるまでテストを実施しないことにより、仮にテストで失敗した場合1から作成をし直さなければならないということだ。
こうした欠点から、新たなプロジェクト管理方法が現れた。それが「アジャイルプロジェクト管理」だった。
アジャイルプロジェクト管理は、端的に言うと「作りながら考える」ことで、最初に定義してしまわないことが特徴としてある。
アジャイルのイテレーションは計測と修正の機会だ。
と本文であったが、ここで言ってたのは結局、以下のことだったように思う。
「アジャイルプロジェクト管理では、イテレーション（短期間で繰り返す開発サイクル）を回す機会としてあげられるのが「計測」と「修正」であり、
ここで言う「計測」とはその日何をしてどれだけの進捗率があるのかの確認を計測することを指し、「修正」に関しては「スプリントレビュー」と呼ばれるものを元に目標の達成率を把握し、都度修正を行うことを指す。
（製品の）ライフサイクルを考える
すべての製品は誰かの頭の中の閃きからスタートしている
本文で一番刺さった文でもあった。
製品における寿命（ライフサイクル）について考えるトピックだった。
上記一文の続きから、プログラマの視点からライフサイクルを見ていくとの切り出しが入り、ライフサイクルの図は以下のようになる
[コンセプト]→[プロトタイプ]→[開発]→[メンテナンス]
このフローを繰り返すことで製品のライフサイクルになる。
そして続けて4つそれぞれの詳細な説明が記載されていた。
コンセプト
マーケットを調査してチャンスを探す部分にあたるコンセプトでは、調査が肝となる。
市場で顧客がお金を支払いそうなものをキャッチする部分となる。
もう一つコンセプトの件で「スパイクの発動」というものも紹介されていた
スパイクって何？
新しいテクノロジや可能性を評価するために、狭い範囲を深く掘り下げる調査の形のこと。
プロトタイプ
コンセプトに生命が吹き込まれるのは、動くプロトタイプを作った時だと述べている。
プロトタイプをつくる目的は2つあり、以下引用する。
① 将来の顧客に製品が何をするのか教えること
リソースに先立って製品を宣伝し、預かった資金で役に立つ仕事をしていることを出資者たちに見せるために非常に効率がいい為。
② 本物の製品のつくり方を学ぶこと
プロトタイプはクラッシュアンドバーンの場であり、失敗してその結果から学ぶことが必要だとしている。
開発
プロトタイプを作り、上の役員たちが製品コンセプトに実があるという確信をつかんだら、実際の商品を作り始めることになる。
本文では以下のように開発部分を示している。
計画と日程が決まり、「本物の」プログラミングに取り掛かるのはこの時点だ。
開発における目標は長期的なものとなり、近道はない。
トピックとして記載されていた文章で、以下の言葉が個人的に刺さった。
本物のアーティストは作品を世に出す
プログラマもバグをフィックスしたいという誘惑に狩られながら仕事をする。少しでもよりよいものにしたいと思った時、製品のリリースは遅れて行ってしまう。
一方で、マネジメント側としては一刻も早くデプロイしたいと思うもので、双方に差が生じる。
引用した言葉から、プログラマも「本物」になるべくリリースを促進していけるよう善処するのが望ましいのかもしれない。
メンテナンス
リリースしただけで作業は終了しない。その後のメンテナンス段階が重要となる。
製品のバージョン管理など、「同じ場所に止まっているだけのために走らなければならない」と言うように、変化していく世界に歩調を合わせなければならない部分になる。
第4部:未来に向かって
カイゼン
日本語の「改善」に倣った章の紹介となっている。
「カイゼン」は知的レベルでものを学ぶことばかりではないと筆者は述べている。
知的レベル以外の部分で言うと、情緒的な部分のことを指しており、他の人との付き合い方や、プロとしての開発能力、製品のリリースの能力などのことを言う。
こうした些細な部分の対応が、未来に影響を与えると言っている。
本文の引用は以下の通り。
あなたの態度があなたの生産性と未来の日常の両方に影響を与える
まとめ
気兼ねなく読めたので、朝読書に向いてる本だった。
さらっと流し読みするのにはおすすめ。
※qiita内で触れた部分と触れてない部分があるのであしからず。