申し訳ないが急に寒くなるのはNG【TECH::EXPERT】

JavaScript Rails TECH::EXPERT プログラミング 応用カリキュラム編

【本日のメニュー】
・JavaScriptで画面上の表示を変えてみよう編突入
・スクレイピング復習
・VSCode 置換
・オブジェクト指向とは(読むだけ)
・チャットスペースチラ見

【JavaScriptで画面上の表示を変えてみよう編突入】
心が不安定になりそうなヒマワリの写真ほか数ファイルをDL、
説明読んでるけど、んニャぴ?よくわかんないでスゥう。
DOMとか全然覚えてないんですのぉおお。

【スクレイピング復習】
JSの2項目目にてスクレイピングの復習的なところがあり、
何も覚えてないので復習のためにMoovieもっかいやります。
明日はこの続きから始めます。

【VSCode 置換】
一度検索したのに忘れてた。メモメモ
⌥⌘F

【チャットスペースチラ見】
これからのカリキュラムはチャットスペースに必要な事柄の勉強だろうと思いまして、
先にチャットスペースの読むだけ部分見てきました。
お手本ページなのを触って見て思ったのが、スラックを必要最低限の機能で実装しようと言う感じでした。
チャットグループとコメントの紐付けらへんが難しそうだなぁ。
ここら辺の設計失敗したらエライコッチャなオイニーがします。

【オブジェクト指向とは(読むだけ)】
▼オブジェクト指向逆から解説
https://media.tomosta.jp/2019/04/29/295/
>わかったようなわからないような感じのオブジェクト志向ですが、その中でもまだわかりやすいのがこの記事でした。もうちょっと学習進めたらもう一回読もうと思った。

複数のオブジェクトを組み合わせてプログラムを構築する考え方で、オブジェクトはテーマを持ったひとつの塊のようなもの。

オブジェクト指向は、ユーザーのためのものではなく、プログラミングしていくうえで開発者の円滑なコミュニケーションのためにある。
理解度を早めたり情報整理のための考え方がオブジェクト指向っぽいですね。

オブジェクト指向との対義語はないが、他の考え方に「手続き型」がある。
手続き型は上から順序通りに書いていく書き方で、シンプルなものを作成するのならこれで事足りる。
要素が増え煩雑になってきたら、テーマごとにまとめるオブジェクト指向にしないと見づらく回収しにくくなる

たとえば本屋で、週刊少年ジャンプの漫画しか売ってなかったら五十音順の、巻数順で並べておけばいいですが、

いろんなところから出版されたいろんな漫画を扱っているので、Classのような概念でくくらなければ非常に分かりにくいことが想像できる。

講談社(出版社名)>アフタヌーン(掲載雑誌)>さ行(五十音)>そんな奴ぁいねェ!!(漫画タイトル)

変化に強い丸め方をした要素の塊を作る→それがオブジェクトとなる。
新たなアプリケーションがたくさん生まれているが、そのほとんどのアプリケーションがすでにある仕組みの再利用と組み合わせでできている。
だからオブジェクト指向をする必要があったんですね。

変化に強くなるには予測力が必要。(今後増えそう、ここと連携しそうなど)
予測力もエンジニアの能力のひとつとなる。
ここに関しては、仕様書が読める、記憶力がある、想像力があるだけではダメなような気がします。サービスへの理解と関心があって、企画部とか依頼主から今後の展望とかのインタビュー力的なものも必要だと思います。
引き出しすぎても話まとまらなくなるけど、よくわかってないと作るの難しいですよね。

▼役立つ原則

DRY > 繰り返しを避ける。コードが多くなりすぎると可読性が下がるでしょ的なこと。
YAGNI > 必要な機能だけ実装しよう。(不要なコードはできるだけ書かないようにしよう。)予測しすぎていろんなコードが混在しているとバグのもと!

単一責任の原則 > クラスにいろんな役割を持たせると汎用性がなくなって余分なコード書かなきゃいけなくなるから、役割が違うなら別のクラスにした方がいいよね。
山田太郎というクラスには野球部と柔道部と畳屋という要素があるが
上記のような人物は世の中に1人しかいない(未確認)ためクラスでくくる意味はない。

野球部のクラス、柔道部のクラス、畳屋のクラス、これらにはそれぞれ所属する人物が複数人存在する”

インターフェイス分離の原則 > 同じサービスでもこのグループはこの機能を使用しないということがあるなら、分離しておくと影響が少なくて良い。

たとえば、ココナラなどで販売者と購入者のインターフェースが見た目上全然違うなどそういうこなのかしら。

【その他】

【アニプリ】シスタープリンセス感想を更新しました。