オブジェクト指向でなぜ作るか 第3章を読みました

はじめに

kzk0829.hatenablog.com

このエントリーの続き。
引き続き思考の整理、アウトプットとして。

第3章 OOPを理解する近道はプログラミング言語の歴史にあり

先人たちがオブジェクト指向という「ソフトウェア開発の総合技術」にたどり着くまでの歴史について。
どのようにプログラミングは発展し、何が問題で、どのように解決してきた結果オブジェクト指向プログラミングにたどり着いたのかということを述べた章。

ざっくりとした歴史の流れは以下

• 2進数で記述された機械語 ↓
• アセンブリ言語の登場
  • 人間に少しだけ分かりやすくなった ↓
• FORTRANやCOBOLなどの高級言語の発明
  • より分かりやすく ↓
    分かりやすさ重視の構造化プログラミングへ

高級言語の発明までは、表現力の向上に重きが置かれ、構造化プログラミングは保守性、再利用性の向上に重きが置かれている

では、構造化プログラミングとはどんなものか？
正しく分かりやすい構造にする必要がある、という考えのもと普及した。これは、当時ソフトウェア需要が増大していたことにも関係してくる。
この構造化プログラミングの基本三構造は以下の通り。

• 順次進行
  • 処理は呼ばれた順に上から実行
• 条件分岐
  • 命令によって次の処理を決定
• 繰り返し
  • ある条件に当てはまるまで一定回数繰り返す

この理論がシンプルだったため当時受け入れられたという。 また、当時の工夫が独立性を高め、保守に強くすること。
例えば、グローバル変数の使用を少なくするという工夫。何か不正があった場合に調べる範囲が広く保守性が低いため。
自分も意識しないうちにグローバル変数をあまり使わないように意識していたので、納得感が高かった。
この保守に強い構造にするということは、プログラムの寿命が伸びたことに起因している。
当時は10年以上後も自分の書いたコードが使われるという考えはなかったという。
それが違うと分かってきて、複雑さを避け、理解しやすさを重視し、使い回しによる生産性の向上が求められるような時代に入っていった。
ただ、グローバル変数の利用制限、大規模な再利用は構造化プログラミングでは限界があったことによって生まれたのがOOPであるという。

次の章からオブジェクト指向プログラミングの話に入っていく。

オブジェクト指向でなぜつくるのかを読み始めました

はじめに

タイトルの通り。

オブジェクト指向でなぜつくるのか 第2版

なぜ読み始めたのか

OOPであるPHPを利用して当たり前のようにLaravelで開発しているものの、オブジェクト指向は雰囲気でしか理解していないし、一度しっかりとしたインプットをして活かしていきたいと思ったから。
例のごとく1章ずつ読むたびにこまめにアウトプットしていこうと思う。

第1章 オブジェクト指向はソフトウェア開発を楽にする技術

この書籍の導入となる章。
細かな話は何もない。
オブジェクト指向とは「ソフトウェア開発の総合技術」だが、難しく感じてしまう理由は以下の通り

• 用語の洪水
  • 難しい専門（横文字で聞いたことない）用語がたくさん出てくる
• 比喩の乱用
  • 説明時の比喩が分かりにくく理解しにくい
• なんでもオブジェクト症候群
  • 言葉が広すぎてなんでもオブジェクトになってしまう

確かに、比喩でしっかり理解できた感覚はないし、難しい用語が多いなと感じる。
しっかり読んで身につけていこうと思う。

第2章 オブジェクト指向と現実世界は似て非なるもの

まず、オブジェクト指向の三大要素である、

• クラス
• ポリモーフィズム
• 継承

について、超ざっくり説明があった。言葉の意味はだいたい知っているし、意味も分かっているが、ポリモーフィズムはうまく使いこなしてるとは言えない。
ネットで調べると、たまにあるくらいの入門的な内容。

上記1,2章が導入だった。

ソフトウェア・ファーストを読みました

はじめに

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略を読んだので備忘録。

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略

なぜ読んだか

最近、自分のキャリアを考えたときに、エンジニアとしてプロダクトを育てられうような人材になりたいと思った。
では、その文脈で語られる、プロダクト志向ってどんなものだっけと言語化したくなったので、この本を手に取り読んだ。

感想

1~3章はそれぞれ、ソフトウェアファーストとは？、日本の課題、必要な変革について書かれていた。
この辺はソフトウェアを外注していたような伝統的な企業がどうすべきかということを中心に論じられ、現在ソフトウェアを中心に割とモダンな環境で仕事をしている人には当たり前のことも多いかもしれない。
なので個人的には4,5章から学びや気づきは多かったと思う。

4章 これからの「強い開発組織」を考える

この章で特に印象に残っているのは、Howを考え実装するのが従来のソフトウェアエンジニアの役割だが、WhyやWhatの部分も考えるという部分（個人的に噛み砕いた解釈）
これは読書や勉強会等でインプットしているだけでできるようになることではないし、Howの部分に大きな楽しさがあることは事実なので、しっかりと開発段階で意識して、チームで議論しながらでないと身につかないものだなと思った。
幸いにも、そのような習慣をつけていたが、まだ規模が小さいので大きなプロダクトと大きなチームで挑戦したいと思った。

また、組織構造についても言及があった。職能別組織、事業別組織、マトリックス組織と言及があったが、大学の授業で履修していたのでそれらの一長一短は深くはないものの理解している。
その中でいいなと思ったのが、技術方針を定めておく必要があるという部分。
これは、意思決定の助けにもなるし、同じような志向の人が集まりチームワークも取りやすくなるのではと考える。技術方針を明確に打ち出しているチームは入る前にイメージしやすいだろうし、いいなと思った。

5章 ソフトウェア・ファーストなキャリアを築くには

この章は、章題の通りキャリアの築き方についてだった。最初にT型人材について話が出てきたが、これはよく聞く。
さらにそこから進化させるパターンが複数あるという。専門を深める=スペシャリストや、専門以外も深める=π型（パイ型）人材、専門を広げる等。
まだ、2年の経験しかないのでとにかくTを深めてきちんとしたT型になるように意識をしなければと思った。
また、この章だけじゃなく書籍を通して語られていたことだが、学びを辞めた時に人の成長は止まる、学び続ける必要があるというメッセージ。深く同意だ。

その他メモに残っている印象に残った言葉や考え方、自分が考えたこと

• 現代社会における多くの仕組みがソフトウェアで構成されている。→つまり世の中にインパクトを与える機会が多い
• ソフトウェアはユーザーエクスペリエンスを実現するためにある。その体験がユーザーの感情を動かす
• どのような立場にいても変わらずに変化し続けることを大切にしたい
• 生存戦略よりも成長戦略

まとめ

技術書と違ってさくっと読みやすいので、のんびり読みしてしまう自分でも1日1章で5日で読んでしまった。
読み物として面白く、納得感も得られたので読んでよかった一冊。話題になるのも分かるなあという感じ。
著者の及川さんありがとうございました。

SQL アンチパターン第21,22章を読んだ

はじめに

SQL アンチパターン第20章を読んだの続き

kzk0829.hatenablog.com

SQLアンチパターンについて

SQLアンチパターン

第21章　シュードキー・ニートフリーク（擬似キー潔癖症）

テーマとしては、主キーに欠番があることだった。
個人的には、気にならない。

アンチパターンとしては以下が挙げられていた。

• 欠番を割り当てる
  • 複数台のアプリケーションサーバから同時処理が行われた場合に、片方がエラーになるため良くない
• 既存行に番号を振り直す
  • ステップ数が多い
  • そのキーを参照しているレコードがあった場合にそちらもupdateする必要がある
  • キー管理テーブルの変更も伴ってしまう

上記のようなリスクがあるため、基本的には変更をかける必要がない、識別のための番号なので連番である必要性はない。

また、GUIDについても言及があった。
GUIDとは、128bitの擬似乱数のこと。
同じ識別子が振られる可能性は極めて低いが、ディスクの使用スペースが多く値が長いことがデメリット。

第22章　シー・ノー・エビル（臭いものに蓋）

テーマはクエリのコーディングについて。

アンチパターンは以下。

• 診断せず判断する
  • データベースへのアクセスした後のクエリを確認しないこと
  • 画面には何も表示されないことが多い
• 見逃しがちなコード
  • SQLクエリの構築時のコードしか読まないこと

ここに関しては、かなり起こりにくいアンチパターンかなと感じた。
開発者として、返り値の確認や、期待した結果が得られなかった時のデバッグ過程の中で発行されたクエリを確認することは当たり前だと思う。
灯台下暗しみたいなことなのかな。

SQL アンチパターン第20章を読んだ

はじめに

SQL アンチパターン第19章を読んだの続き

SQLアンチパターンについて

SQLアンチパターン

第20章　SQLインジェクション

ここら辺もフレームワークがよしなにやってくれる箇所だから意識していないが、意識しなければ。

難しいのは、望まない操作を許可しないように、ソフトウェアをセキュアにすることです

大事。

対応策として用意されているのが以下。

• 値のエスケープ
  • バックスラッシュでエスケープする
• プリペアドステートメント
  • queryの前処理時にパラメータを残す方法

初学時にプリペアドステークスで対策をするように言われたことを思い出した。

安全なSQLコードを保証するフレームワークはありません。

この一言で、改めてアンチパターンは知識として持っておくべきだと感じた。

また、「20.5.1 入力のフィルタリング」や「20.5.4 ユーザーの入力をコードから隔離する」に関しては普段から慣れてできている。改めて確認することができてよかった。

まとめ

この章の内容もある程度知識として持っているものだった。
ただ、フレームワークを使い慣れているとどうしてもそこまで深くは意識しないので、アンチパターンに対して正しい対策と、レビューを心がけようと思った。

初学者時に、プリペアドステートメントでSQLインジェクション対策を行なっていたことを思い出した。

SQL アンチパターン第19章を読んだ

はじめに

最近結構読書をしているが、まとめてというよりはこまめに読むかつ、厚めの本を読む機会もあるのでインプットしたことをなるべく早めにアウトプットしようと思う。

SQLアンチパターンについて

SQLアンチパターン

第19章　リーダブルパスワード

めちゃくちゃ普段から意識しなければならない内容。

アンチパターンについても、うなずける内容だった。

めちゃくちゃうなずける反面、普段使っているLaravelだと意識せずとも、Hashファサードが用意されており、簡単にできてしまうのでアンチパターンとして学ぶことができてよかった。

なので意識すべきことは、

• SQL文に平文のパスワードを含めない
  • 予めハッシュ化したパスワードをデータモデルに引数で渡すことで解決

かなと思う。

また、リセット手法については書籍に記載している、トークンを用いる方法を使っている。

Laravelでは使用したことはないが、これも用意されているみたいですね。

リーダブルコードを読んで

はじめに

2年目エンジニアも終わりそうな今更、やっとリーダブルコードを読了したので感想とか。
実は、1年目の6月くらいに先輩に勧められて購入したものの、実務に入っておらず、読んでもあまり頭に入ってこなかったので諦めていた。
今なら血肉になるのではないかと思い改めて読み始めてみたもの。

対象読者

結構巷では初学者が読むべきと書かれていることも見る。
内容的にも割と基本的なことが多いが、個人的には、実務経験を積んだ人が読むことでより意識して良いコードが書けるようになるのではないかと感じた。

内容とか感想とか

1部【表面上の改善】

変数や関数の命名について、コードの表面上の統一性、コードブロック、コメントなど表面上について書いてあった。
特にコメントについては、あまり強く意識したことはなかったので為になった。
変数名、関数名、読みやすさなどはチーム開発において、コードを読むことに対して大きく影響を与える。
他人=チームメンバーや数ヶ月後の自分が少ないコストでコードを理解することに役立つ為、常に意識し、改善していくべきだと思わせられた。
この1部は初学者でも読みやすく意識しているとチーム開発にもスッと溶け込めると思う。

2部【ループとロジックの単純化】

行数を短くするよりも、他の人が理解するのにかかる時間を短くする。

この1文に内容は詰め込まれている。
ループ内部のネストを浅くすることや、変数スコープを小さくするなどは割と、日常的に意識できているのではないかと思う。
ただ、説明変数を作ったり、要約変数を作ることは割とチームの文化であったり、好みにもなってくるのかなと感じた。
バランスも難しいが、コードが増えていくことを考えると上記の変数達はあったほうがいいのかなとも感じる。
結構複雑なif文の条件を作りがちになるので、教訓にはしたい。

リーダブルコード8章8.4にある「どうして1行で書こうとしたのだろう？そのときは『オレは頭がいい』と思っていたのだ。ロジックを簡潔なコードに落とし込むことに一種の喜びを感じていた。」
これクッソわかる

— Kazuki Takahashi | kop (@cuzkop) 2020年1月2日

この通り。

3部【コードの再編成】

Utilを集めたり、タスクを小さく分割したりと、割とコーディング中に頭の中で設計しがちな内容だった。
自分は割と汎用コードをたくさん作るが、初期段階で経験則から汎用的になるだろうとして作るものの、意外と使う場がなかったりすることもある。
割とYAGNI原則に反してしまっており、汎用コードは汎用的になる場面で改めて作ろうと感じた。
また、やっているつもりではいるが、気づいたらメソッドが大きくなっていたりということもあるので、小さく軽量な1タスクのメソッドやクラスを作ることを意識していこうとおもう。

まとめ

割とサクッと読める読み物なので、やはり界隈で言われるように必読の名著だと思う。
数年に一度読んで振り返るのも大事かも。

次は、なぜプログラムは動くのかを読む。