アートオブクリーンコードの紹介
こんにちは、エンジニアの三長です。
こんにちは、エンジニアの博崎です。
ゆるテクは、三長と博崎が、ゆるく技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい、というわけで、今日も2人で話していきたいなと思っております。
よろしくお願いします。
お願いします。
はい。
はい、でですね、早速今日のトピックの話に入っていくんですけれども。
はい。
今日は、書籍の感想会にしたいなと思ってます。
お、久しぶり。
久しぶりの。
はい。
でですね、今日読んできた書籍っていうのが、いつ発売だっけな?
8月の、確か16ぐらい。
ちょっとつい開いてみよう。
8月12と書いてあります。
すいません、8月の12でした。
8月の12に発売された、アートオブクリーンコード、
複雑さを避けてシンプルに生きるためのベストプラクティスっていう本を読んだんで、
その話を博崎さんと一緒にしたいと思います。
楽しみ、これ見たこともしかしたらあったのかもしれないですけど、
小屋ぐらいは。
はい。
けど、プログラミングの詳細の話だなと思って、いいかと思ってた記憶が、
もしかしたらそうだったのかもしれない。
なるほど。
ちなみにこれ、収録前にちょっと博崎さんと話してたんですけど、
面倒なことはすべてPythonにやらせようみたいなやつ?
そうそう、そういう本。
この同じような表紙ですよね。
シリーズ系っぽいですよね、表紙からすると。
同じ出版社のところから出てるんでしょう。
はい。
多分全部内容を話していくわけにもいかないかなと思うんで、
ざっとこんなんだったよっていうのを一緒に話せればいいかなって思ってます。
はい。
で、先ほど博崎さんが結構プログラミングの詳細の本なんじゃないかって話をされてたと思うんですけど、
僕逆にこの本知ったときに、ちょっと前評判調べたときに、
プログラミングに限らない話とかも結構入ってる本ですみたいな紹介を受けたんで、逆に買ったんですよね。
80対20の法則
そうなんですね。
はい。多分詳細だったら今そこまで読むエネルギーねえなってなってたんで。
これ読んでますと。
じゃあこれどんな本なのっていうところで言うと、とはいえクリーンコードっていうタイトルとかも入ってるんで、
コードの原則とかも結構書かれてました。
コーディングするときにこういうふうに考えて設計するといいよねとか、
こういうふうに考えて実装するといいよねみたいなことはもちろん書いてました。
ただ、他のそういう本と違うところって、コードの原則だけじゃなくて、
そもそも自分の仕事に対してどういうふうに向き合いながら進めるといいのかっていう、
マインドセット面っていうのを結構紹介してくれてる本っていう印象です。
確かに今三沢さんが貼ってくださってるリンクから目次が見れるんで、
目次ざっと見てるんですけど、あんまりプログラミング的なこと確かに書いてなさそうですね。
ですです。もちろん本の中には実際のプログラミングのコードとかクラスの設計がこうあったらこうするといいよっていう例は書いてるんですけど、
それの使い方も紹介してるマインドセットに対して、
じゃあ具体例コードで考えるとこんな感じだよねみたいなことを紹介してるんですよね。
なのでよくあるマインドセットを学んでみて、
めっちゃ抽象的でよくわかんないよなってなってる人に対して、
自分の得意な領域、特にエンジニアとかだと多分コーディングとかが得意な人が多いかなって思うんですけど、
そこでちょっと具体イメージをつきやすくさせてるからすごく取っつきやすいんじゃないかなと思いましたね。
なるほど。コードで書くとこんな感じねっていうのが飲み込みしやすいって感じですかね。
ですです。あくまで一例としてはこういう感じだよ。
でもフラクタル、世の中フラクタルな構造になっていることが多いから、
抽象度上げていくとこういう場面でも同じことが言えるよねみたいなことをちょこちょこ出てきてる感じでした。
面白そう。
はい。で、あとはなんかこんなこと言うと怒られちゃうかもですけど、
僕が読んだ漢字、何でしょうね、リーダブルコードとか、あとユニックスという考え方っていう本があるんですけど、
ユニックスの哲学とかを紹介している本。
割とあの2冊のエッセンスも散りばめられている感はありましたね。
その2つで言うと、あれなのかな、シンプルさが大事みたいなことが書いてあるんですかね。
クリーンでシンプルなコードを書く方法であったりとか、
シンプルであるために言って、ユニックスの原則みたいな話が引用というわけじゃないです。
上げられてたりするんで、より詳細を知りたいとか、より歴史的背景を知りたいとかになってきた場合は、
今挙げたリーダブルコードとかユニックスという考え方とかを読んでいくと、
よりアートオブクリーンコードで言ってたので、多分こういうことだったのかな、みたいなのにつながりそうな予感です。
ちなみに三田さんが、この後話すかもしれないですけど、
一番この本のメッセージとして受け取ったものって何ですか。
シンプル is ベスト。
そこなんだ。
シンプル is ベストって言ってるけど、
集中してシンプルに進めていこうみたいなところがメッセージとしては僕は強そうには感じていて、
ただ個人的に面白かったところ、強いというより面白かったところを挙げていくと、
じゃあここから実際内容とかになっちゃうんですけど、
第2章のところで、
80対20の法則、原則だ、ごめんなさい、っていうのがあって。
あれだ、パレートの法則だ。
そう、パレートの法則、働きあり的なやつも同じような話なんですけど、
ここが基本パレートの法則ってフラクタルになってるから、
なるべくこの20パーにベッドできるようにフォーカスして集中して仕事を進めていこうみたいな話が書かれていて、
そっかそっかって思って読んでたんですけど、
これを読むまで僕があんまり気づかなかったのが、コードに対してもそれを当てはまるっていう表現があって、
要は一つのソフトウェアに対してすごくコアな部分ってそのコード全体の20パーしかないんだみたいな話が書かれてたんですよ。
これ確かにプロダクト作りとかをしていく中で、
いろいろ機能つけてもその他の80パーに当てはまってたらあんまり意味ないんだなって改めて気づかされたというか。
なんかでもあるな気がしましたけど、
その矛盾というか、
その20のところだけを狙って書いてしまうと結局そのさっき三田さんがフラクタルって言いましたけど、
その部分の中でも結局20パーしか動いてないみたいなことになりますか?
めちゃめちゃいい質問で、まさにそういうことは書かれていて、
その20パーのところを狙って書いていっても結局さらにその中でまた80、20になっていくっていうのは本当書かれていて、
結局それを言いたいのはどうやら結局常にその20パーをなるべく引けるようにしていきたいよねみたいな。
力技。
力技は書かれていて、
じゃあその20パーを引いていくためにはどういうことをやるといいんだっけっていうのが2章に書かれているんですけど、
ちょっと定量っぽいことを言うと、メトリクスをちゃんと把握していこうみたいな。
なるほど。
メトリクスとかをちゃんと測ることによって、
それが今80と20の中の20側なのかどうかとかを見極めていこうみたいなことが書かれていましたね。
シンプルな仕事の進め方
なるほど、なるほどね。
だから順番か。
80対20になるにしても、
20側から作っていこうみたいなことなんだろうな、じゃあ。
なんだろうなって思うし、
とはいえ結局20側を狙って作ってもどうしても80側に行って入っていくんだろうなとも思うんですよね。
そうですね、そういう法則ですもんね、これ。
そういう法則だから。
なので結構これを日常に、自分の日常に当てはめるなら、
新しくじゃあ01で始めるときって、
なるべくその20打てるようにみんな物事作っていくと思うんですけど、
途中から算入する系とかで、
マジでそこをちゃんと見極めないとずっと80の何かをやってて、
すごくやってるんだけど気づいたらあんま成果につながってないんじゃないかみたいなことが
起こっていきそうだなぁ感は思いましたよね。
耳が痛いというか心当たりがいろいろありますね。
これ、僕めちゃめちゃ心当たりあるなって思ったのが、
前にユルテクとかで博多区さんに相談してたと思うんですけど、
苦手なエリアとかに自分が行ったときに、
どうしてもちょっと得意なところで手頃な成果を出そうとしちゃう行動を取ってしまうみたいな。
今それを振り返ると、実はそれって80のところになってたんじゃないかなって、
すごいこれを読んで思いました。
そうですね。でもあれはちょっと歯を食いしばらなきゃいけないですからね。
20を狙い続ける勇気というか、20を取ろうとし続けるマインドを保ち続けないと、
多分一定80に無意識のうちに流れちゃうんだろうなとかすごい思いますね。
なんかそういう、その言葉を借りると20を狙い続けるための
具体的な方法論みたいなことも結構書いてあったんですか?
これ具体的かどうかは言えないんですけど、
20を狙い続けるための大事なチップスは書かれていて、
いくつか読み上げると、
これスケールでかいなって思っちゃうんですけど、人生の大きな目標を見つけるとか、
確かにスケールがでかい。
失敗を反省するとか、
業界の本を読むとか、
ちょっと逆に身近なことで言うと、既存プロダクトの改善と調整に時間を使う。
多分不必要にいろいろ増やすなっていうことなんだろうなって思って捉えました、僕は。
なんかめちゃあれですね、経験主義ですね。
経験主義。
皆さんがこれを聞いた後からすぐできるやつとして、
笑顔を増やすって書いてた。
今笑顔になりましたよ。
笑顔になりましたね。
なるほどな。笑顔を増やすとどういう文脈でしょうか?
笑顔を増やすとどうなるんですか?
笑顔を増やすと、笑顔を出してる人自体がポジティブな印象になるから、
いろんな人があなたに協力しやすくなるよっていう、
すごくダサン的な笑顔かもしれないんですけども。
機嫌がいい人はいいから。
仕事しててもニコニコしてる人の方が話しかけやすいよねっていうところかなっていう感じです。
MVP開発とフロー状態
自分本人としても機嫌よく仕事した方がパフォーマンスは出ますよね。
機嫌よくした方が自分もストレスたまらないし、
周りも幸せかもしれないしで、そんなにネガティブなことはない気はしますよね。
そうですね。形から笑顔から入ったら、
気持ちもきっと笑顔には楽しくなっていくんでしょう。
です。
っていうところが、他の本にはあまりなさそうだなって思ったところ。
そこから中盤ぐらいはMVP開発の話とか。
MVP開発していく中でシンプルに作っていくにはどうしたらええねんみたいな話とか。
ちょっと今目次見てて気になったというか、
6章がフローって書いてあるんですけど、これはフロー状態とかのフローですか?
おっしゃる通りです。ちょうど僕もそこはあげようかなって思ってて。
多分この6章のフローの話、
フローっていうキーワード自体は他の本でもちょこちょこ出てきてるかなと思うんですけど、
割とフロー状態に入っていくにはどういう風な環境を整えるといいんだろうねみたいなことがいくつか書かれていて、
それは比較的珍しそうな気はしましたね。
ちょっと興味あるな。
ちょうど僕のメモの中にも、
エンジニア用のフロー状態のためのTipsみたいなのが。
エンジニア用とかあるんだ。
正しくはプログラマーのためにって書いてましたけどね。
フロー状態を促進するためのTipsとして、
ここにいくつか僕も書いているんですけれども、
こういう条件が揃っていると入りやすいぜっていう話ですね。
読み上げていくと、まずは何をすべきかが分かっている。
多分目標とかゴールが明確なんだってところですよね。
その次がそれをどうやるべきかを理解している。
目標ゴールに対してたぶん道筋も一定分かっているというか。
その次がどの程度できているかを把握している。
たぶん現状把握って話なのかなって勝手に思いました。
向かうべき場所が分かっている。
こっちのほうがゴールかな。
ここまでのやつは要するに後はやるだけ状態ってやつですね。
後はやるだけ状態。
残りあと3つあるんですけど、
後はやるだけ状態なんだけど、
次出てくるのが調整を求める。
なるほどね。調整を求めるなんだ。
いわゆる簡単すぎない程度の程よい難易度って感じだと思うんですよ。
あとは程よい難易度だろうが、
その難易度に対して課題を克服するためにスキルを自分で磨いていく。
なるほどね。
一番最後、これができたら困らないんだけどって思うんですけど、気が散らないようにする。
その方法が知りたいねみたいな感じですね。
でも前半の方に何か書いてた気もしてて、
表現はおぼろげなんですけど、
気の散る要因を排除するっていうのが書かれてて、
例えばスマホでちょいちょい見ちゃうっていう人がいるんだったら、
スマホをそもそも仕事部屋から遠ざけるであったりとか、
SNS系が気になっちゃうんだったらSNS系のアプリもろもろ削除しちゃうとか、
結構バイオレンスな感じのことも書かれてたんですけど、
そういったことがありましたね。
そうですね、という感じですね。
この辺読んでて、もちろんおすすめな項目として、
こういうのができたら確かにいいんだろうなって思ってるんですけど、
たぶん一番身近なそういう僕らの体験って、
僕は結構コードを書いてる時だなって思うんですよ。
このコードを最終的にどういう動きにしたいかも分かってるし、
何を書かなきゃいけないかも分かってるし、
どう書いていけばいいかも分かってるしみたいな。
みなさん、僕含めてコードに集中しまくってる時って、
割とこの7つの要素が全部揃ってる時なんだろうなって思いますよね。
あとここに書かれていない感じが、
気が散らないようにそれに入るかもしれないですけど、
適度な緊張感みたいなのがあるかなと思っていて、
自分はそれがないとフローに入れないんですけど、
締め切り直前とかがいい例ですかね。
直前ではないんだよな。直前だとプレッシャーが勝ちすぎていて。
程よい切りつき感みたいな。
そろそろ期限が迫ってきているぐらいの程よい緊張感が必要かなと思ってますね。
期限が全くないタスクではフローに入れないなと思ってます。
確かにそれおっしゃる通りですね。
それ系のことは書いてなかったんですけど、
例えばですけど、一定調整を求めるとかに近かったりするんですかね。
そんなことはないのかな。
メンタル的なニュアンスは近いですね。
うん。とかはありつつも、
でもフローの状態の中に時間経過の感覚がなくなりますとかって書いてるから、
ちょっと矛盾そうな感じもありますけど。
そうですね。あまりにも時間のあれとかが強すぎると逆にまた集中できないですね。
早く終わらせなきゃってなるから。
というのが、他の書籍にあまりない珍しい表現というかの項目なのかなって思ったですね。
エンジニアとしての気づき
そうですね。目次をざっと見た感じ、この小構成というか組み合わせの方は確かにそんなに見たことないかもしれない。
うん。はい。
というところで、それ以外は本当にUnixの原則とか、
なるべくシステムを構築デザインするときにミニマリズムでシンプルに出してこうであったりとか、
あとは決まった方向性にフォーカスして、
フォーカスした努力によって成果につなげようという話が書いてあったりとか。
人によってはこういうところでインプットしたことあるなーみたいなものもあるんですけども、
こうして割とバランスはいい本だったと思いましたし、
ある意味エンジニアに限った話じゃなくて、
特に今、いろんな仕事を担当してて、
暴殺されてるかもとか、ちょっと自分器用貧乏になってるかもなーって思う人がいたら、
こういうのを読んでみると、自分を見直すいい機会になるんじゃないかなって思いましたね。
良さそう。良さそうだが、これはユルテックの本紹介の回あるあるなんですけど、
ここまで紹介されると、なんか読んだ気になってもういいかってなるこの気持ちは。
投稿するときには大幅にカットさせてもらって。
自分は気になるところを三田さんにここは?とか聞いてるから満足してるけど、
これを聞いた人は気になるな、そこじゃないんだってなって、実際読んでみたくなるかもしれない。
いいですね。ちなみにちなみに、ユルテ180ページぐらいのボリュームなので、
ちょっとした読み物としてサッと読んでみても、僕は全然いい本だなとは思ってますね。
ナイスフォローです。
はい。そんなところで、今日は以上にしようかなと思います。
では、今回はArt of Clean Codeという本の感想について話しました。
感想などは、ハッシュユルテックをつけて投稿するか、Mixi2のコミュニティまでお願いします。
お願いします。
今日はありがとうございました。
ありがとうございました。
