tomoyaki BLOG

いちSEの学習記録

第1章 フロントエンド開発の潮流とVue『Vue3 フロントエンド開発の教科書』を読む(1/n)

Vue.jsを体系的に学ぶため、評判のよさそうなこちらの書籍を読むことにした。ハンズオンもあるようなので、今回は技術評論社のサイトからEPUB/PDFセットを購入してみた。

PDFからそのままリンクに飛んだりコピペできたりするので、この手の書籍は物理本よりPDFの方が便利かも。

メモ

第1章 フロントエンド開発の潮流とVue

JavaScriptの歴史とVueのようなフレームワークが登場した経緯について。

  • JavaScriptの登場(1995)、不遇の時代
  • GoogleMapの登場によるJavaScriptの復活(2005)とWeb2.0のはじまり
  • JavaScriptの仕様の乱立
  • JQueryの登場(2006)、ブラウザごとのScriptの違いを吸収してくれるように
  • ES5の登場(2009)、各ブラウザがECMAScriptへの準拠開始
  • HTML5の正式リリース(2014)、Edgeの登場(2015)
  • 各ブラウザのECMAScriptへの準拠完了
  • ES2015以降:モダンJavaScritptとよばれる
  • Node.jsの登場(2009)
    • JavaScriptエンジン(V8)をブラウザから切り離し、単独で動作するようにしたソフトウェアのこと。
    • ちなみにGeckoWebkit、Blink等はHMTLレンダリングエンジン。
  • ジョブズiPhoneFlashのインストールを許可しなかった*1
  • JQueryからのInversion of Control
    • ライブラリの活用から、JavaScriptフレームワークの利用へ
    • 「基本全てを書いて、部品を利用する」考え方から「基本の型は書かれていて、差分を書く」という考え方にシフトしていった
    • AngularJS(2009)→Angular(2016)
    • React(2011)
    • Vue.js(2014)
      • Vue3(2020)
        • 内部のソースコードが全てTypeScriptでリライトされた
        • 2022年2月にVue.jsと連携する主要モジュールのVue3対応が完了し、Vue3がVueのデフォルトとなった

歴史上の転換点がWeb魚拓で遡れるの、感慨深いな・・・。

『SEを極める50の鉄則 入門編』を読んだ

雑感

  • タイトルに惹かれて図書館で借りてみたが、案外よかった。
  • 目次からして精神論が多い印象だが、内容を読んでみるとSEとして活躍するためのエッセンスがよくまとまっている。(実際のところ、SEとして活躍・昇進していくにあたって精神論は無視できないほど重要な位置付けだと、個人的に考えている)
  • SEという職業を技術とビジネスの両輪から描いていて、バランスが取れているのもよい。
  • ただ、全体的に「熱血的な」内容の本なので読むのに体力・精神力が要る。モチベーションの高いときに読まないと、効果が薄そう。実際、今回は結構な飛ばし読みをしてしまった。
  • 手元に持っておいて定期的に読みたいと思ったので、新装版を購入した。こちらは後ほど読む。

メモ

SEとは?

  • 出だしから熱い。
  • SEに要求される基本能力はピラミッド構造になっている。
    • 土台にビジネスパーソンとしての心構え、エンジニアとしての心構え、IT基本知識があって、プロフェッショナルなスキル(=技術力)はその上に成り立つ。
    • いくら技術力(ピラミッドの一番上)だけを磨いても、SEとしては優秀とはいえない。
  • ビジネスパーソンの意識と技術屋魂が重要
  • 目指すはビジネス常識を持つIT専門家

SEとして活躍していくためには資格取得等のハードスキル向上を進めていくイメージがあるが、コミュニケーション能力・心構えといったソフトスキルを確固たるものにすることがより重要であるという内容。むしろそういった土台があってこそ、技術力が光るという内容に読み取れた。自分としてもついハードスキルに走ってしまう部分があるため、はっとさせられた。

顧客

  • 迷ったときの判断基準、「顧客が51、会社が49」
  • 顧客の意見が個人か、顧客企業の考えか?を見極める
  • ビジネスに強いと大仕事ができる
  • 顧客に強くなる
    • 体で顧客の本音を知る
    • 自分の中で顧客感(顧客が悩んでいること、心境など)を形成する
    • 顧客も案外自信がないもの、悩みを聞いてあげる

SEの成長

  • SEの能力はトラブルの時の動きをみればわかる
  • 5年ごとに落第の危機があり、以下のような場合は要注意。
    • 28歳・33歳頃:成長期に付加価値のある仕事をあまり経験していなかった、ビジネスパーソンとして厳しく鍛えられてこなかった場合
    • 38歳・43歳・48歳:上記に加え、新しいITや製品についていけない、SEとしての夢がもてない場合
  • 若手は一芸で挑む、顧客から一目置かれる芸を磨く

『プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則』を読んだ

この本について

  • プログラマとしてチームで開発を行う際に、理解しておきたい「べきべからず集」のような内容。辞書的に読むのがよさそう。
  • ひとつの原則に対してWhat, Why, Howの3段構成となっており、原則の背景、使いどころなどがわかりやすくまとまっている。
  • 個人的には各原則に出典と関連書籍が記載されているのが嬉しい。気になる本はメモして、今後の読書キューに入れておく。

雑感

  • プログラマでなくても、ソフトウェア開発に携わる者として読んでおいて損はない。
  • ひとつひとつの原則にそこまで目新しさはないが、アイディアが言語化されて腹落ちしたものが多々あった。
  • 単純な疑問として、世のプログラマーはどれほどこれらの原則が身に染み付いているのだろうか?
  • 自分は職業プログラマーではないので何とも言えないのだが、これらの原則を常識レベルで身につけているメンバが集まれば、相当クオリティの高いソフトウェア開発ができるのではないか?と思う。ひとまずプログラマーであれば必携書になりそう。
  • 設計やプログラミングで行き詰まった際に、アイディアをもらうための本として定期的に読み直したい。

メモ

第1章 前提〜プログラミングの変わらぬ真実〜

銀の弾丸」はよく見かけるキーワードだが、出典を抑えられていなかった。後で読む本リストに追加。

日本のSIerのSEにはクリティカルヒットするプリンシプル。コードを書けないなら「設計できる」とはいえないと言われているようでツライ。「設計〜プログラミング〜テスト」はすべて設計の枠組みのため、分担すべきでないという主張が出てくるが、これは大規模かつウォーターフォール開発プロセスにおいても同じことが言えるのだろうか?出典書籍を見るにアジャイルを前提としているような気もするので、もう少し深掘りたい。

第2章 原則〜プログラミングのガイドライン

  • YAGNI(You Aren’t Going to Need It)
    • コードは「たぶん必要になるだろう」「必要になるかもしれない」で書いてはいけない
    • 本当に必要になった時、必要なものだけを書く
    • 色々な事態に備えてコードを盛り込んでおても、結局利用されない
    • 結果、そのプログラミングの時間が無駄になる

これは頭の中ではなんとなく正しいと思っていたが、言語化されると納得感がある。一方で、改修を見据えてコードに拡張性をもたせるという考え方もあると思うので、そのバランスをどう取るべきかが気になった。少しググると「YAGNI 思考停止」とか出てくるので、そのあたりの解釈についての議論はありそう。

第3章 思想〜プログラミングのイデオロギー

  • アーキテクチャ非機能要件
    • ソフトウェアの目的は、機能を作ることではなくユーザが目的を果たせるようにすることであるため、非機能要件が大きな役割を占める

こちらも言われてみれば当たり前だが、経験上、機能要件に対して非機能要件は曖昧であったりスキが生まれやすい傾向にあるため、意識する必要があると再認識。

  • 再利用性
    • ソフトウェア開発を効率よく、品質よくするためには「できる限り作らないこと」が重要。つまり、どこかから借りてくる。

便利なライブラリがあればそれを利用するという行為は通常無意識的に行っているが、効率・品質観点のメリットを考えるとより積極的にライブラリ活用を行なっていくべきだと思った。

コードレビューの観点としてある程度体系化されたものがあるというのは知らなかった。コードを書くときにも使えるので、頭の片隅に入れておきたい。

初耳の概念だったが、読んでいる中で興味深いものがいくつかあったため、以下抜粋。

  • 明確性の原則
    • コードを書くときにもっとも重要な観点は、コードを実行するコンピュータを相手にするのではなく、コードを読んで保守をするプログラマを相手にする。
    • コードは、人に対して読みやすく書かなければならない。
  • 驚き最小の原則
    • インターフェースの設計では、意味もなく新奇なことをしたり、過度に巧妙なことをしたりすることは避ける。
    • 「一見似ているが微妙に異なる」ということを避ける。
  • 経済性の原則
    • プログラマの時間を大切にする。ハードウェアが貧弱だったり、使用するソフトウェアに対して制限があったり、環境に関するルールや制限が厳しいとプログラマの時間を浪費してしまう。

よくあるのは、インターネットにおいて、開発に必要なサイトなのに、アクセスできない場合です。クラウドで稼働するソフトウェアが使用できないルールのところもあります。インターネット接続すら禁止されている場合もあります。しかし、そもそも、情報処理技術者から、情報を遮断してはいけません。

ハードウェアやソフトウェアの購入を抑制するのは、経費節減のためです。しかし、設備の費用とプログラマの費用は、比較にならないほど後者が高価です。設備に投資して、プログラマが効率よく、気持ちよく仕事ができれば、簡単に投資は回収できます。

なかなか面白い観点だし、日本の大企業のあるあるだったので深く頷きながら読んだ。

  • 最適化の原則
    • 速いコードより正しいコード。正しく動作する前に最適化に走ることは、コードの設計を台無しにする。
    • 透明性や単純性が犠牲になったり、部分に対する半端な最適化が、全体最適化の妨げになる。
    • まず動かし、正しくしてから、速くする。
  • データはテキスト
    • バイナリよりテキストファイルに保存する。
    • テキストファイルは、もっとも一般的で移植性が高い。人間がただちにデータを確認できる。ツールやコマンドが扱いやすい形式。

第4章 視点〜プログラマの観る角度〜

心に残った箇所は特になし

第5章 習慣〜プログラマのルーティーン〜

第6章 手法〜プログラマの道具箱〜

心に残った箇所は特になし

第7章 法則〜プログラミングのアンチパターン

  • ブルックスの法則
    • スケジュールが遅れているソフトウェア開発プロジェクトにおいて、遅れを取り戻すために後半に人を追加すると、さらなる遅延を招く
    • 「人」と「月」は交換不可能
      • 依存関係によるオーバーヘッド
      • 教育に時間をとられる
    • リスケジュールせよ

炎上プロジェクトあるあるそのまま。出典書籍の『人月の神話』は有名だけど未読。後で読む。

組織編成を先にしてしまいがちだが、アーキテクチャがある程度見えてから組織を編成すべきという話。