コンポーネント指向は上手く作っていくと一つひとつがシンプルにまとまるから分かりやすくなる。みたいなことでしょ?」程度の認識だったのだが、今はガッツリ案件で使っている。書くのが2系から4系以降。フルスタックなフレームワークはチーム開発に向いているということ。作って」「サービスはこう作って」という決まりが多く、これによって開発者ごとの実装方法に差異が発生しにくい。よってファイルの雛形も自動生成されるし、ますます開発者ごとに自分勝手なことはしづらくなっていて、統一感が生まれてチーム開発に大変向いている。以降は毎週パッチバージョンがアップデートされ、半年ごとにメジャーバージョンアップするという方針になっていて、新機能や破壊的変更に追随していくのが大変。公式のドキュメントも、一番分かりやすいとは云われているけど、そこからの発展形をどうしていけばいいのかが分かりにくい。使えなくなっている方法だったり、とにかくググラビリティが低い。そのものの理解を深めないとまともには実装できず、しかし理解を深めるための文献が少ない・古くて使えない、というのがかなり難点。巷では軽めのフレームワークで未だ人気。使っている案件も散見されるが、もう下火。できる汎用ライブラリ。いうものもあり、これも案件で使っている。操作は止めようね」な流れにはなっている。向けにラップされたパッケージを使ったりする。これからどうなるんだろう。別物」という時代では完全になくなった。対応していて、勝手にコンパイルしてくれて楽チン。使っている案件は見たことない。なんか知るかよ!」という仕事が多く、大変助かっている。対応とかやってた前職はホントどうしてるんだろうな...。設計ができる人間が恐ろしく少ない。ファイルの最上部に随時追加していって、カスケードも継承関係も全く無視、不必要なプロパティを記載していたりして「分かっていないまま書いている」人間が多い。Lint、脳内トランスパイラを正しく備えた開発者は思いの外少ない。設計力じゃないか?とすら思うほど。雑に書こうとする人間が多くて物凄くイライラしている。ように「何回『ボタン』って書くんだよ!!」みたいなコードも、少しは慣れてきた。名前付けるしかないじゃん」ってな風潮。概念も理解せずデタラメに使っているバカも散見される。ライブラリを色々扱ってきて、仕事にしてきて思ったのは、こんなこと。それぞれのツールに対する知識はなんとでもなる。知っているか、という知識量は、突き詰めれば暗記モノということなので、決まりを全部正確に覚えられればよく、自分の推測は要らない。暗記型の文系でも出来る。暗記は「全てを」「正確に」覚えないといけない。プログラミングは通常の口頭会話とは違い、「ほら、アレだよ、何かこう...」という曖昧なアウトプットでは理解してもらえない。曖昧なコードをアウトプットすると必ずバグが生まれるので、見聞きしたことを正確にアウトプットし直せるように、正確なノートを残せる力が必要になる。正確な情報はノートに記録しておくのだ。フレームワークやライブラリを使う時は、その「思想」を受け入れること。(むしろ勝手な思想を縛るためにある)。自分の好き嫌いでモノを語るのは不要なこと。(そのフレームワークを使うのを止めるか、あなたがその仕事を辞めるか)。ツールで自動化できることは自動化する。自分の頭は自動化できないところに使う。Lint、コード整形は自動化できる。レビューで「空行が」「インデントが」なんて指摘に時間を使わないようにする。自動化するためには初期投資として時間をかけるべき。できない人には一生まともにできない。それらをチーム内で共有し強制させていくには、相手に理解して従ってもらうよう説明・説得しないといけないので、相手のレベルに合わせた客観的な視点を持てていない人間はこれができない。いずれのポイントでも必要なのは、「概念を把握すること」「概念化して理解すること」という、概念化の力かなと思う。調べ方ができるようになったりする。応用が利くというのは、概念を理解しているかが直結してくるので、常に概念を理解することが大事。»ProfileNeo個人的に言いたいコト・主張・気持ち。PagesBookmarkTwitterFacebookPocketスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。