この記事は？
この記事はGoogleのソフトウェアエンジニアリングの読書ログを私がGoogleのソフトウェアエンジニアリングを読んでまとめていくものです。
第一回にこちらで書きたいことを書いたのでぜひこちらをみてください😊
ソフトウェアエンジニアリングとは何か？
ソフトウェアエンジニアリングとは時間で積分したプログラミングであるとGoogle社内で言われる
時間がプログラムに与える影響を知る方法に「コードの想定稼働時間はどれだけなのか？」という問いがある
「数ヶ月で終わるプロジェクトで色々こだわる必要ない」って意味だと思いました。
僕もちゃんと書く時と手を抜くときの論理の問いかけとして上記の問いかけは適切かなと思いました。
まぁ数ヶ月で終わるかどうかがわかっていれば何の苦労もないですがね。。。
間違ってもいいから想定しておかないといけないってことですね。
1.1 時間の変化
短命なコード開発は、ソフトウェア業界の一般的な場面でも見られる。モバイルアプリの寿命はかなり短いことが多く、また良くも悪くも完全な書き直しが比較的普通のことだ
確かに僕はモバイルアプリエンジニアをしていますが、バックエンドと比較しコードが捨てやすくリプレイス計画についても聞く機会が多い気がします。
この辺は経験による予測も大きいかもしれません。
1.1.1 Hyrum の法則
あるAPIに十分な数のユーザーがいるとき、APIを作ったもの自身が契約仕様として何を約束しているかは重要ではない。作られたシステムが持つあらゆる観察可能(observable)な挙動に関して、それに依存するユーザーが出てくるとのである
APIのオーナーがインターフェースの約束に関して明確であることによりある程度の融通と自由を得る一方で、実際は任意の変更の複雑性と難易度はそのAPIの観察可能な挙動をユーザーがどれだけ有用とみているかにも依存している
「アプリケーションの仕様はAPIのオーナーではなくAPIのユーザーによって定められるものである」と解釈しました。
例えばGitHubなどはAPIの公開をしていますが、多くのユーザーによって利用されており、すでにGitHubだけで仕様を決められる状態にないなどがあると思います。
このようにオーナーがどのように仕様を定義しているかではなくユーザーにどのように使われているかがAPIにとって最も重要だということです。
1.1.2 例：ハッシュの順序付け
1.1.3 「何も変化しない状態」をとにかくめざすのはどうか？
大半のプロジェクトは基盤技術における変動の影響を受ける部分が遥かに多い
「何も変化しない状態」をとにかくめざすのはどうか？ と問われたら大半のエンジニアは「No」というのではないのでしょうか？
期間にもよりますが、僕らの開発環境における依存は大きくiPhoneやAndroidはたいてい2-3年で新しいものに買い替えるし、ブラウザだってパソコンだって数年で変わっていく。
AWSやGCPで提供するOSも変わっていきますし、何も機能追加しなくても変化をしなければならないですね。
数日数ヶ月のプロジェクトであるならまだしも数年になるのであれば考慮せざるを得ないと感じました。
Discussion