00:12
はい、みなさんこんにちは。keethことくわはらです。本日もやっていきましょう。 keethのエンジニア雑談チャンネル。この番組では、ウェブ業界やエンジニアリング、いろんな技術についての情報を、雑談形式で発信していきたいと思います。
で、今日ですけども、昨日、衝動買いした本、といってもずっとトゥードゥに残していて、読みたいと思っていた本があります。
これを機に、買ってしまおうと思って買ったんですけども、
思考の生理学という書籍ですね。ご存知の方も多いんじゃないかなと思いますし、名著の一つだと思います。かなり良い本ですし、人気もある書籍だと思いますので、もし知らない方は買ってみてください。
僕まだ今3章まで昨日読んだんですけど、本当に読書のスピードが遅い。僕でもさらっと昨日1日で3章ぐらいまでは読めた。
早い人はたぶん1日で一気に読み終わってしまうような感じだと思います。そんな難しくない書籍ですし、本人のエッセイまでいかないですけど、考え方っていうのをダーッとただただテキストで並べられているというような書籍です。
まさに読み物みたいなものです。バーッと読めるような本なんですけど、その中でも読んでいく中で感じるものとか考えるなーっていうものがたくさんあって。
いくつかメモしたんですけど、昨日感じたのがタイトルにあります。全体は部分の集合にあらずという言葉。これは本当僕共感するところが多いし、今まで仕事でフロントエンドの開発をやってきた。
別にフロントエンドだけじゃなくてAPIも作ってきたし、バックエンドBFFも作ってきたことはありますけど、その開発とこの言葉はものすごくリンクするなと感じたんですね。
まさに部分の集合をしたからシステムとかアプリケーションができましたというわけではないなと。
今フロントエンドって主流というかデファクトでしょう。デファクトと言って良い考え方、概念、設計手法としてコンポーネント思考というものがあります。
設計手法じゃないな。このコンポーネント思考はまさに物事を細分化、コンポーネントという単位に分けて、それでページを作っていったりパーツを作っていって、それをガチャガチャ合わせていって最後アプリケーション全体として完成させていくというものですね。
でなんですけど、コンポーネントとかを細分化するということが人によって開発分けることが分担はできるんですけど、多少の開発の差異とか人によっての癖が出たりするとは思います。
そういうのをプルリクエストとかでレビューしたりとか、自分のコードをみんなのコードにするっていうところがプルリクエストとマージという手順だと思いますので、その時にしっかりレビューしたり是正したり方向性合わせましょうねっていう話はすると思うんですけど、それでも分担をするということは部分に分けるということなので、
03:03
最後それをマージするっていうところがちゃんとマージになっているか、とりあえず入れましたっていうようなものになっているか、僕の中のイメージは積み木で積み上げていくものなのか、それともちゃんと混ぜ合わせて一つの色にしようかな。絵の具の色の方がイメージしやすいかも。いろんな色を混ぜていって最後一つの色にするみたいな感じでもいいと思います。
とにかく僕は混ぜ合わせるみたいなイメージがマージのイメージなんですね。じゃなくて積み木のようにどんどん積み上げていくっていう、そういう思想の方も、感覚の方もいらっしゃるし別に間違ってはないと思いますけど、やっぱ部分の集合にあらずっていうところを聞いたときに、なんかこれ積み木っぽいことを言ってるんだろうなと思ってて、積み木だと積んでいくんですけど、やっぱ土台となるものがしっかりしてなかったり、途中途中で空間が空いたりとか変な置き方をすると、
上に行けば行くほどグラグラしたりバランス悪くなったりするので、システムとして不具合生じたりみたいな、僕はそういう感覚があるんですね。ですのでなるべくは混ぜ合わせるものとして、その色の美しさっていうのがどうなのって話になるんじゃないかなという感じです。
色が悪いものを入れたらアプリケーション全体としても影響出てしまうし、その悪さっていうのが強かったら、色んな色がありますけど黒色混ぜたらやっぱ一気に引っ張られますからね、ドーンと。絵の具混ぜたことある経験は皆さんもあると思いますけど、黒ってほんと強いんですよね。
それだけ癖が強いものを入れた瞬間、今までバランスよくやってきたものが一気にグジャーって崩れてしまうので、そういうのは良くないよねという話ですね。なので、土台となる設計というか全体方針、幹となるような取り決めをプロジェクトをスタートの時に先にやっておく。
しっかりみんなで共有し合う。その微調整はもちろんするかもしれないし、最後の枝端としての描き方みたいのはもちろんあると思いますけど、大元の幹となるところはしっかり考えをしておかないと、後からそういうデカい考えを変えるっていうのはつらいものがあるし、ほぼ作り直しみたいところもあると思うので。
よくある話ですけど、こういうこともある、ああいうこともあるっていうのは後から気づいたり分かってきて、こういう設計じゃないほうが本当は良かったなとか、先にBFF入れとけば良かったなとか、いろんな考え方価値観があるんですけど、そういうことをこの言葉を聞きながら思ったし、スタートというか開始が大事なんだなっていうのはつくづく思いましたね。
とはいえ、じゃあ一人がガーッと大元を作り上げるかとか、一人で同じようにいろんなものを全部作り上げていったほうがズレとかはなくなるし、一人の思想のままいけるので、統一性を図られる可能性は多いにありますけど、パフォーマンスが悪いし、開発スピード出ないですよね。そもそもスケールしないですよね。
大きいものを作るには複数人でやるのが鉄則だと思いますね。一人の能力の限界はあります。時間とお金をつぎこまれてやろうと思ったら別に全然できますよ、一人でも。
会社のビジネスとか成長目標だったり、納期みたいなところを加味すると、複数人でやって大きな仕事をするということになりますので、どっかしらの際だったり、他の人たちとのコラボっていうのが必要になりますよね。
06:16
もちろん部分に分けなきゃいけないんですけど、単なる部分の集合として、とりあえずこれを作ってあれを作ってとかでやっていって、マージするときに、まあ動いてるし良さそうだろうっていうので、ガチャンとマージするというのは、厳密に言うとマージっていう手順を踏んでますけど、合わさってるわけではなくて、個々人のコードの組み合わせをしたキメラみたいなアプリケーションになってしまうよなっていうので、そこがよろしくないっていうようなお話だと僕は感じました。
というので、まあ短いですけど、今日はそんなところのお話をしてみたくなりました。まあ考え方というか気をつけましょうねっていうような心持ちのお話ですね。参考になれば幸いですというところで。はい、今回はこんなところで終わっていきたいと思います。いつも聞いてくださり本当にありがとうございます。ではまた次回の収録でお会いしましょう。バイバイ。
