さあ本日はですねエンジニア界にはびこるたくさんの法律との向き合い方を考えていきましょうの回でございます法律は守らなきゃ捕まるやつじゃないですかはい

そうなんですということ脱法をうまくやる話ですか脱法プログラミングの話ですちょっと法律はちょっと言い過ぎたんですけどエンジニアの世界にはですねすごくたくさんの法則がありますありますね法則がいっぱいありますね法則や原則がねいっぱいありますありますいっぱいあるなんか

ドライ原則とか 今最初に出てきたの割れ窓理論だけど割れ窓理論は犯罪心理学です 違うなってなりましたよく言われてますけどね汚いコードがあると まあこういう感じでええんやつって汚いコード書いちゃうみたいなまあそういうことですよねそういう理論や原則がいっぱいあるわけですよ いっぱいありますね

きっとプログラミングを始めたてのエンジニアの方々こういう原則を見てもうゴールデンハンマーのように扱っちゃうと思うんですよね銀の弾丸ではなくゴールデンハンマーですかゴールデンハンマーパターンとして扱ってしまうと思うんですよねなるほどすみませんちなみに一般的な言い方ですか違うのかな僕が知らないだけで説ありますよこれは

一応ちょっと僕が頭の中で描いてるゴールデンハンマーパターンのあれなんですけどその道具を手にするともう

あらゆる対象がその道具を使って解決できるように見えてしまうっていうパターンですね要はもうこの金槌を持ったら全部釘に見えるみたいなネジだよみたいなところも釘に見えちゃうっていうで無理やりそれをその法則というかその道具を使って課題を解決しに行っちゃうっていうのを通称黄金のハンマーとかって言ったりするんですけどはいそうなんですねはいはい

違うかないやすいませんよくわかんないですけどググったら出るのかな出そう出たなただちょっと意味が変わるかもしれないなんやって日本語にすると内出の小槌らしいです本当英語だとゴールデンハンマー気に入った方法があらゆるところで利用できると思い込むっていううんうんうんうんうんうんうんうんうん大体手段を探そうとしなくなるとかそうそういう話ですねそうですはいはいはい

こんなにたくさん原則があったらもうハンマーまみれじゃないですかそうですねはいなので本日はですねこれらの原則まあ有名なやつを紹介しつつも最終的にはこういうふうに原則と向き合うといいんじゃないのかなっていうところで着地させていこうかなというふうに思っているんですけどもいかがでしょうか何卒よろしくお願い致しますはいわかりましたありがとうございます

ちょっとまずはですね有名な原則どんなのあるのっていうのが気になってる方もいると思うのでざっくりこれよく聞くよねみたいなやつをですね不安になってきました僕が全部知ってるかいっぱい持ってきましたいやー不安になってきましたよ知らないかもしれないぞ絶対知ってますうわー怖いぞそのプレッシャー絶対に知ってますはいなぜならさっき同じソースを見てたからですじゃあ大丈夫だはいよかったー

じゃあまずその1ブルックスの法則いや早速そんな聞かんってそんな聞かんくないかいやいやいやいやちょっとごめんこれ上から順に書いてったからそういう順番になってますわかるやつから言えブルックスの法則ですねまずブルックスの法則ですねこれはねかの有名な名著と呼ばれてるはい

人月の神話からの登場した法則でございますこれ非常に古い本でですねおそらく初版は1970年代古い60年代かななんかめちゃめちゃ古いですコンピューターとかないじゃんみたいなあるかあるけど知らないと思うみんなっていうぐらいの認知度の時だと思いますねで

これはどんな法則かというとですね新たに投入された開発者が生産性の向上に貢献するまでには時間がかかるよっていう法則ですうわー仕事終わんねー人増やせー増やしたけど無理ーっていう法則です僕この前やりましたそれ嘘?はいちなみにどうでしたか?変わりません?いやなんならちょっと大変になりますマジで?はいそうなんだはい僕これ

あんまりやったことないんですよねそうなんですね助かったことはあるでも逆にね意外とそうなんですよねそれでもラッキーパターンですねまずこれなんでじゃあ落ちるのっていう話なんですよはい生産性がはいでこれ3つありまして3つもあるんですねはいでごめんさっきこういう法則ですって言ったやつ原因の1個でした

まずこの法則は大変なプロジェクトに人追加しても早くなんないよっていう法則ですそれは多分言ってましたねその原因が新たに投入した開発者が

生産性の向上に貢献するまでには時間がかかるよっていうのがまず1個ですエンジニアっていうのは非常に難しい作業をしているのでトラックの運転手とかって言うて運転と場所が分かればある程度追加しても貢献できるじゃないですかトラックの運転手してる人だったらね

なんですけどエンジンやって開発できたとしてもそのプロジェクトについての知識とかがないとなかなか活躍できないんですよむずいっすね専門用語とかも飛び交いますしねそうそうそうそうあと複雑なコードだとやっぱりね理解するのにも時間かかりますねはいそうですねでそういうプロジェクト独自の知識っていうのが多いんで急に追加してもちゃんと貢献できるようになるまで時間かかりますとであと

人員増えれば増えるほどチーム内でのコミュニケーション増えるんで言いますね1on1だと1通りだけど3人だと1,2,3,3,2,6分かんないっす確率苦手なんで分かんないっす音声だけででも4人がそれぞれ他の3人とコミュニケーション取んなきゃいけないから4×3じゃね?違うわ4×4×2だと思いますよ4×4×2だと思うので

4,3,6ですねそうか4人の中から2つ組み合わせを作るのかそうですそうです4,4,2ですはい6で5だと10うんみたいな感じで人が増えれば増えるほどとんでもなく増えていくとそうですそれを言いたかったんですねそういうことですはいあとリーダー多分大変だよねこれあーそうですねプルリク見るだけで終わるんじゃない多分1日がうんうん確かにはい

っていうのでコミュニケーションコスト増えますとあとはタスクの分解可能性には限界があると言われてます分解可能性って何ですか要は1個のタスクもここまで分割できるけどそれ以上分割できないよねというか妊婦の話がめっちゃ分かりやすいんですけど例えば1人の妊婦が9ヶ月で赤ちゃんを出産できても妊婦9人集めたら1ヶ月で赤ちゃんを出産できないっていうのと同じっすそれはなるほどねはい

タスクって言ってもねペアプロみたいなので若干加速はできると思うんですけど言うて限界ありますからねそうなんですよこれがブルックスの法則でございますさっきの話に戻るんですけど僕助かったことあるんですよ人増やしておそらく簡単なプロジェクトだけど他のタスクが多すぎて手が回ってないときに増やすのは

まず有効だなと思いましたそれはあるかもしれない背景知識いらなかったらね全然大丈夫だと思いますあとはねうちの場合ちっちゃい会社なんである程度そのコミュニケーションみたいなところを事前に相手がどんなことしてるかふわっと知ってるみたいなところがあるんでそういうのもあって人の追加が結構

プラスになるのかなと思ってましたなるほどねはいそれありますね人足すっていうと普通よくあるのはうんえー害虫さんとかうん

派遣の人呼ぶパターンが多分多いと思うので社内に人いるんだったら呼べますしね社内で苦面することが多い社外から呼んでくるとね大変なんですよね大変だってなった後だと遅いです確かにねこれがブルックスの法則でございます続いて

驚き最小の原則よく聞くやつですねふわっとしてるなと思ったことあるこれはもう名前通りだしそのままなんですけど利用者にとって想像通りの使い方できろよっていう話ですねうんうんうん

だけです例えばで言うとこのディレクトリの下にはこれが入ってるだろうなとかこういうクラスの中ではこういう動きするだろうなとかある程度経験ある人は想像しながら読んでいくんですけどそれ僕書けよってことですねそうですあと多分これUIとかUXにも関係めっちゃあるんじゃないかなって思ってます例えば戻るボタンと次へ進むボタンがあって戻るがなぜか右にあるとか

あー確かにそれはありそうっていうのでなんかUI UXとかすごい作ってる人とかはこの辺すごい意識してそうこの名前かどうかわかんないですけどね確かになんかそっちの世界でなんかありそうだよねユーザーフレンドリーっていう言い方かな確かによく聞くそれそれを設計でもやりましょうよという話でございます続いてボーイスカウトルール

あーまあわかるけどわかるのかなまずこれはボーイスカウトルールどっかで話したことあるような気もするけど自分が触ったモジュールは触る前よりも綺麗にして帰ろうねっていうボーイスカウトが山に行った時のやつをそのままプログラミングに落とし込んだようなルールでございますボーイスカウトの人たちは

心が皆さん綺麗なので山に行きますと山に行ったらそこにあったゴミとかもともとあったゴミとかも拾って帰るみたいなそういうルールがあるんですよねそれをやろうぜっていう大事これはですねプログラマーが知るべき97のことよりボブおじさんことロバートCマーティンさんがそこのエッセイに書いておりますねなかなか

できてる人いっぱいいるのかなどうなんだろう僕も忙しかったらサボっちゃうな忙しかったらサボるわそれはでもやりましょう心に刻むこれはまずは完了させることが大事だと思ってそれは間違いないそんなこと言ってるとねいつまでもやんないですからねまあそうね僕結構リファクタリングとか考えるの好きなんで急がなきゃいけない時にたまにそこに足止め食らったりしますね足止めというか

止めちゃうんですねいけそういけそうわかるそれはわかるこの辺からちょっとコードっぽいかなコードの中ヤグニの法則よく聞くやつこれはですね今必要なものだけ作れよ的なやつですねコーディングする中でこれ将来必要になりそうだな作っちゃおってやるなっていう法則ですねうんうん

これあの英語でYou ain't gonna need itなかなかの発音しますね素晴らしい洋楽聴いてるんで洋楽聴こうなので発音がいいですそうなんだ本当かこれはですねエクストリームプログラミングっていうケントベックさんが書いてる本から登場したらしいんですけどそうなんですねはい

後で使うだろうっていう予測のもとに作ったものは実際には10%程度しか使われないしたがってそれに費やした時間の90%は無駄になるってことなのでやめましょうねっていうことですねただこれちょっと僕すごいしっかり読まないとなと思ったんですけど後で使うだろうっていう予測のもとになので将来必要になることが見込まれてるやつは作っていいんじゃないかなって思いました

どうなんでしょうねああマジか見込みも予定も僕は変わると思ってるんですよね確かにな変わった経験もありますからいらないと思ってますなるほど結局ちゃんとコードを書こうと思ったら多分テスト書かなきゃいけないしうん

っていうのでコードの複雑性が上がるので保守性が下がるんですよね多分それだけ最近読んでるグッドコードバッドコードっていう本でもコードは基本的に不採ですとできるだけ書かないようにしましょうっていうのは口を酸っぱく言われてるのでそれゆえなんかヤグニっていうのもいらねーのは書くなっていう話なのかなと思うにはい

抽象化をしっかりできる人は予測しなくていいと思うんですよねうんうんうんって思うんですよちゃんとインターフェースとか作ってそれ通り

ここの層とここの層を切り分けるみたいな作り方できる人はマジで役に従った方がいいと思うんですよただそれを考えずに具象クラスの塊を作るタイプはちょっと考えた方がいいのかなと思いますねそれはそう思いますがそれはそれで別の原則に乗っ取れって話なんじゃないですかね

この後出てくるやつですか多分この後出てきそうなんですぐ行っていいですかそっちにソリッド原則出ました一番複雑でよくわからないやつよく聞くけどまあそうね確かにむずいかむずいんじゃないですかこれは確かにむずいわソリッド原則もそれぞれ5つの原則が合わさってソリッド原則みたいになってるんでなるほどねちょっと確かにむずいですね

このソリッド原則はですね先ほどボーイスカウトルールでも登場したボブおじさんことロバートCマーティンさん原則の父ですね原パパだよマジでカナジーカナジーやばいっすアジャイルソフトウェア開発の奥義っていう奥義これねタイトル

アジャイルかって思ってるんですけどこの本はすごくオブジェクト思考のバイブルと呼ばれてますねその中で多分それぞれソリッドのそれぞれの頭文字の5個の原則自体は元からあったような気がするんですけどこれをまとめてソリッドって言ったのがこの人なんじゃないかなっていう仮説ですなるほど僕この本読んでないんで分かんないですノリ説はい

じゃあひまじんプログラマー公式見解としてそうだろうとそれぞれの原則も名前がまた難しいんですよねいや言えないですもんなんならまず1個目シングルなんとかその通りシングルレスポンシビリティプリンシパルほら言えない単一責務の原則とクラスは1個のことだけ持たせよねっていうよりもえーとね

一つのクラスには一つの責務を持たせよねっていう感じですねよく書籍で言われてるのは変更の理由より一個のクラスを変更する理由は一つであれみたいなそんな感じですねもしその変更する理由が二つあるなとしたらそれはクラスを二つに分割するべきだみたいな具体的に言うとどういうことなんですかねえっとねこれアクター図書くと分かりやすいんですけどアクター図だっけユースケース図ですねユースケース図ユースケース図っていうのは

人アイコンみたいなのがあってそれぞれどういう操作できるかみたいな感じなんですけどそのアクターが一人であれっていう感じだったなんかの本にそんなこと書いてあってゆうすけすず書いたらわかりやすいじゃんって思った記憶があるそうなのかそうなんだなるほどあれが要は変更すべき理由らしいですへー

あんまりその発想なかったな今まで呼び出し元の数ってことですよねそうだね止め置いておきます続いてソリッドのOオープンクローズドプリンシパル出ましたはい

開放閉鎖の原則これも名前が難しいですねなんかふわっとしてますねこれはですね拡張に対しては開いており修正に対しては閉じているべきであると全然言ってる意味わかんないですねマジでこれは意味わかんないんですけど僕これはヘッドファーストデザインパターンのカフェのやつデコレーターパターンっていうのを説明するためにカフェのやつをやってるんですけどあれが非常にわかりやすいなと思いました

と言いますとあのショーで実際にこの原則について触れてるんですけどあのショーでやってることって機能を追加するために既存の機能を修正するんじゃなくて新しいクラスを追加して機能を変えてるんですよ例えばコーヒーの新しいメニューを追加しようと思ったらビバレッジとかだっけビバレッジだったと思う飲み物っていうのから

派生させたというかカスタマイズみたいなやつカスタマイズ用のクラスを作ってそれを乗せてどんどん変更していくんですけど元のVivaregeは変わってないんですよねあれをやるとき元のソースコードを変えずに新しい機能を追加していくみたいなことをやってましたねこれがオープンクローズドプリンシパルですそしてLリスクオフサブスティテューションプリンシパル

通称リスコフの痴漢原則って言われてるやつですね名前も分かりづらいですねまたまたこれもね名前は分かりづらいんですけど意外とシンプルな法則だった気がするシンプルですね一旦その一般的な定義で言うとですねちょっとすいません元の文字見失ったんで覚えてる範囲で言うんですけどお願いいたしますオリジナルクラスとサブそれから派生したクラス

親子的な話ですね入れ替えてもちゃんと動くようにしろよっていう法則ですねほうほうほうほう要はシグネチャー変えるなよってことかな引数とか返り値とかのうんうんうん多分ですけど独自解釈なんで違ってたらすいませんって感じなんですけどインターフェース使ったら解決するんですよこの原則要はインターフェース使うと引数と返り値の型揃うじゃないですか

はいなので入れ替え可能になるんですよそこの部分インターフェースで実装してるところそうですねはいでそれをやるとリスクオフの時間減速が満たせてるっていう状態になると思ってますうーんちなみになんか多分別のページ見てるんですけどはい僕の理解ではうん子クラスがうん親クラスと同じリクエストされた時に同じもの返せよってうんいうものだと思ってますうん

言ってることはナウリさんとおおむね似てるかなと思って聞いてましたでも痴漢だからどっち使ってもいけるようにしとけよってことでそうですそうですリスコフの痴漢原則そして4つ目インターフェースセグリゲーションプリンシポルセグリゲーションセグメントのセグリゲーション

インターフェース分離の法則です分離するんですねこれ僕クリーンアーキテクチャ読んだ時にしっかり意味分からなかったんで今なら分かるかなちょっと今聞いたで見た記事がめちゃめちゃ分かりやすかったんでその例をそのまま使うんですけどインターフェースってそれに対する実装のクラスがあるわけじゃないですかその実装クラスで使わないやつをインターフェースに用意すんなよっていうパターンですね

これに載ってるねポケベルとスマートフォンとかの例がめちゃめちゃわかりやすいんですけどポケベルって基本的にはメッセージを送ることしかできないですよねでもスマートフォンって電話したりとかアプリ使ったりできますよねっていう時に共通のインターフェース作ったら必然的にスマホに合わせたインターフェース定義しなきゃいけなくなるじゃないですかはい

それポケベルに使ったらでもメール以外の機能というかその文字を送る以外の機能使わなくなるじゃないですかそれ良くないっていう原則ですねでポケベルとスマホでインターフェース分けろよっていうのでインターフェース分離の方法をするかもねというかねむしろなんか機能ごとにインターフェース使ってるなうんうんうんセンドメールみたいなインターフェースとコーリングみたいなインターフェースと

またスマホアプリ使うみたいなアップみたいなインターフェース作ってそれらを別々に継承してる感じになってるねなるほどねなるほどっていうのがこのインターフェース分離の原則ですと最後ディペンデンシーインバージョンプリンシポ依存性逆転の原則ですねこれも

意味わかりませんねこれはね僕納得いってないんですよね納得いってないんですか意味はわかったんですけどえーみたいなどういうことですかまずこれ依存性ってどうした方がいいかっていうとビジネスロジックに依存性向くようにした方がいいんですよもう少しわかりやすく言ってくださいはいまずこれよくクリーンアーキテクチャとかで出てくる丸い図わかりますかね同心円状の丸が4つぐらい重なってるやつ

あれって実は中からどうなってるかっていうと一番中のコアの部分がビジネスロジックその次にアプリケーションロジックその次にインタラカンターその次にインタラカンターみたいな感じで層が分かれてるんですねその層の内側に依存するようにしましょうっていう原則があるんですよ内側に依存するってのはどういうことかっていうと例えばデータベースを変更しましたとそういう影響が内側に来ないようにしましょうねっていうことなんですよ

データベース変更してもビジネスロジックは変わらないじゃないですかでもコーディングミスると変わるんですよどういうことですかコーディングの仕方ミスってビジネスロジックのところにデータベースのロジックとか書いてるとそういうことか例えばデータベースロジックが変わっただけデータベース使わなくなって別の新しいシステムとかを使うようになっただけでビジネスロジック変更しなきゃいけなくなって影響範囲すごくでかくなっちゃうんですよだから

基本的には外側の円の内容を変更したことによって内側の円が変わらないようにしましょうっていうルールがまずあるんです依存ルールとしてちゃんとレイヤー化してというかレイヤー化してって話かそうですこの依存性逆転の法則っていうのはどうしても外側に依存を向くときあるんですようんうんうんわかるまず依存関係っていうのははい

クラスってそもそも上位のクラスと下位のクラスっていうのがあるんですね基本的には上位のクラスってのがビジネスロジックよりで下位のクラスっていうのがインフラよりになっていくかなデータベースロジックとかその依存の向きって基本的には下位が上位に依存してないといけないんですよはい

要は外側から内側に依存してないといけないですよとだけど普通に使ったら例えばビジネスクラスの中でデータベースに保存するみたいな処理を呼ぶことになるので上位から下位に向いちゃうんですね矢印がそれを防ぐためにまずインターフェースを挟みますとインターフェースを挟むとさっきまで上位から下位に向いてた矢印がですね上位も下位も内側にあるインターフェースに矢印が向くようになりますと

今間にいますねインターフェースが間にいますこのインターフェースを上位レイヤーに置いてみるとあら不思議境目の部分は内側向いてますっていうインターフェースをふわっとさせてレイヤーだけを見ると結果的に矢印の向き依存性が逆転してるよねっていう原則です

だからこれインターフェースの置く位置の発想の問題じゃんって思っててああはいはいはいゆえに納得いってないというかじゃあ間にインターフェース挟めって最初からゆえって思いましたね僕はまあこの位置も大事なんじゃないですかインターフェースの大事なのかなうんでもインターフェースって単独で動かねえしなと思いながらコード見るときは思っちゃうんですよねインターフェースがあると上位レイヤーに置いておくと呼び出し元が

抽象化ができるって言うんですかその解文字の中身をよく知らんでもいい感じに情報が抽象化されて何読んでるかが分かるからそういう風にやるのかなと僕は解釈してましたでもそれって結局さ一個のプロジェクトの中にあるさファイルの中のどこに置くかみたいな感じじゃないですかっていうのでなんか

発想の転換みたいな問題だなと思ってまあそれもそうですねそっちの方が探しやすいという風にされてるんでしょうね僕は内側に置くとみなしましたみたいな感覚がどうしてもあるというかそれはあるかもなまあでもそうまあそういう風に言われてるとはいこれら5つの原則を合わせたのがソリッド原則というやつですよといやーボリュームありましたねソリッド原則いやーソリッドやばかったわ以上ソリッド原則でございましたはい続いて

ドライ原則よく聞くやつDon't repeat yourself2回同じこと書くな達人プログラマーより達人プログラマーなんですね達人プログラマーの第2版ではですね作者たちが嘆いてましたコードのことだけじゃねえって前も話しましたねコメントやドキュメントそこもコードでわかることは書くなって結構強いことを言ってましたねうんうんうん

これがドライ原則ですと最後キスこれもよく聞くやつですね一番よく一般的に言われてるのはKeep it simple, stupidシンプルにしやがれバカ野郎ですストレートでよろしいわかりやすいでも語呂合わせするためにバカ野郎つけたんじゃないかなっていう感じも否めない

いいんじゃないですか?いいか収まってるしそうね愚かさが出てるなんか愚かさが出てる?そうでもこれなんか最初に言った人はシンプルとスティーピッドの間のカンマない想定で言ったらしくてシンプルなバカであれってこと?いやシンプルでグドンにしろってあーいう意味で言ったとも言われてますへー真相は闇の中でもまあどっちでもいいしバカの方がなんかいいっすいいっすねはい

必死感があっていいですねそうですねあと第三の説としてキープイットショート&シンプルっていうのがあるんですけどこれもスティーピットの価値かなって思ってますキャッチーなワードですねスティーピットの方がねそうねキープイットショート&シンプルはあの

Gitみたいな感じなのかなと思っててGitって由来知ってます?知らんすあれLinus Tobalesが作ったんですよGitLinux作ったLinusは自分は傲慢だから自分が作ったプロダクトには自分に関係ある名前にするんだみたいなっていう感じで最初のソフトウェアはLinux

これはGitだって言ったんだけどGitっていうのはスラングで間抜けっていう意味があるらしくてなんかちょっと自分を皮肉るみたいな感じでそれを言ったらしいんだけど周りの人が何とかして解釈しなきゃってなってグローバル

インフォメーショントラッキングっていうやつの頭文字だっていう解釈が生まれたみたいなへーそれに近しいものを感じるなと思っていやよく語呂合わせしましたねねまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあまあや

っていう感じでいっぱいルールがありますとでじゃあ皆さんこれどう使っていくかっていう話なんですよ本題入りましたね僕結構これ初心者あるあるというかまさに最初の頃の僕そうだったんですけど原則を法律だと思ってる守らなかったら捕まってしまうとでそれに囚われすぎてコード書くのめっちゃ遅くなったりとか謎の理論形成したりとかするんですよそうなんですねはい

いや性格ですよでもどうなんでしょう俺覚えきれねえよって思ってやってましたそうなんだしかもたまにバッティングするんですよね

あーまあバッティングはありそうですね確かにでそれぞれの原則にこれも完璧に合わせようとしたらもう実戦向きじゃないと思うんですよルール厳しすぎてみたいなまあそうですね守るのは結構ハードル高いですねそうなんですよなのであくまでこうした方がいいよっていう方針として心の中に持っておくのが一番いいんじゃないかなと私は思っているのでぜひねあのー

これらの原則を黄金のハンマーだと思わずにお母さんに言われたお約束ぐらいの気持ちで思っておくのがいいんじゃないかなって思います俺守らなかったら殺されると思ってたな最初あーやばいお母さん強い制約をかけてしまったかもしれないはい僕個人としては何かの判断に迷った時とかこういう原則に立ち返ってあー

役にだからつけるのやめようみたいなこの機能を足した方がいいんだっけみたいなのが出た時にこういう原則に立ち返って考えるのがいいかなと思います確かに原則の話って過去にしてなかったっけ一個一個紹介したのありましたねそうだっけ話してるうちにあれなんか過去に話したことあるなって記憶がふわっと出てきたような出てきてないような定期的にアップデートするぐらいがいいんじゃないですかねそうですねはい

じゃあ最後に軽くツイート紹介しましょうか アンマーやんなかったんですけどアマジンプログラマーのハッシュタグでツイートしてくれてるやつへの軽レスポンス あんまりとか全くやってないかもしれない本当ですかやったっけ一応見てはいるんですけどねじゃあ1個目ですねエゴサの鬼なんで あまりにも変身したかったんで

アカウント名とかやめようかな調べるやすぐ出るんですけど聞いてたら多分なんかわかるよねそうですね最近聞いてて面白いので各人フォローしましたがカイチさんが一番コミュニケーションっぽいのにFF少ないのはこれはいかんツイートしてる方がいましたけどこれちょっと交じれさせてくださいまずこれ多分カイチ君のツイート遡ってみた方がいいと思いますいやまず僕が一番コミュニケーションっぽいのはちょっと微妙なところだと思ってます嘘?はい

そこが合ってると思いますよそれは微妙な気がするな順平もコミュニティだと思うけどノリさんも結構いろんなとこ行きますよね僕そんなコミュニティそんな多くないんでまあでもそれは置いといてよFF少ないのはちょっと言い訳させてくださいうん

まずこれ僕本アカじゃないですそうなんですよねエンジニアアカウントですエンジニアアカウントですからねただこのエンジニアアカウントもですね初めてのひまじんプログラマー始めてからなんでまだまだこれからすごく成長させていくぞって感じでそうですよねそういうアカウントなんですがただですよこのアカウントちなみにもともとどういうアカウントなんだって

めちゃくちゃ僕のツイートをね遡っていただけるとですねひたすらモンストのオーブプレゼントのツイートをしてるキャンペーンとかをリツイートするためのあれだよね捨て垢でした捨て垢だよね元々エンジニアアカウント作りたいこれあるからそのまま使っちゃおうって軽い気持ちで使い回してるんですけどツッコまれてたもんねツッコまれてましたね

カイチがエンジニアアカウント始めたんだと思って遡ったらモンストの何アカウントだったっけモンストのオーブプレゼントツイートするだけのアカウントだったみたいなせやねん笑ったなあれいや俺も笑いました遡るやついるんだと思った今でこそね多分ツイートでどんどん上積みが溜まってってもう大変ですよ多分遡るのもうきついと思うけどねでもちょっとね

頑張ります価値あるツイートしてフォロワーさん増えるようにでもう一個ですねソンメズソンメズさん確かにメンソズソンメズ事件メンソズソンメズ事件ありましたねいやーそうダイヤニキとか言ってたのに名前間違えてるっていうね大変申し訳ない本当に恥ずかしい反省した松本ゆきひろさんを松本ひろゆきさんって呼んでるみたいな一緒ですねほぼ一緒本当に

ぶん殴ってやりたい残ってしまうからなこれがデジタルタトゥーなのに皆さん気をつけてくださいねすごいよね続いてのツイートはブログ記事書いたからコメントしてもらえると言ってたのでよろしくお願いしますとツイートしていただいている方いましたありがとうございますブログは見させていただきました聞いたですねすいませんがどこになんてコメントしようかっていうのがちょっとわからなすぎてごめんなさい

そうですね僕でも一番刺激受けたのは応用情報即日復習ってやつですねノリさんと同じ日に違うわ一個後かいや同じじゃないですか同じか同じ日に受けたやつですね午前試験の知らない単語かなをおそらくメモってアウトプットしてるっていうことを見てですね負けたと思いましたいやいいなすごいそうやって使うんだな

だいたいここに出てきたやつ確かに俺も知らないと思ってへー例えばライダーライダー?LIDARですかあそうこれさエンジニアやってても出てこなくない?車作ってないと出てこなくないと思ってもしくはiPhoneに今ついてますねそうなんだライダースキャナーがねなんか光を照射してはいはいはいあの物体までの距離を測るセンサー的なやつですかねうん

今時というとIoTとかロボットドローンとかやってる人が多分触れる分野ですね遠隔で監視するとか何かのものを点検するキャプチャーするとかそういう時に使うやつっていうイメージそうなんだちょっとこれは一生馴染みなさそうだなと思いましたノリさんの携帯にはついてるかもしれないですよ確かにでもなるほど素晴らしいですねすごい本当に続けていってくださいマジで

全然関係ないですけどの暇プロでハッシュタグ暇プロでツイートしてくれてる方結構いるんですねすみませんそっちはめちゃめちゃ見てなかったですフルで検索してるよねだいたいはい結構いるんだ知らなかったわ

ありがとうございます皆様ひまプロの方が多分間違えられにくいよねひらがなカタカナ問題というかひらがな漢字問題みたいなのってはいというのでツイートいつもありがとうございます実は見てます僕これからひまプロの方もちゃんと見ていこうと思うのでマジで見てなかったです引き続き言っていただけるとモチベーション上がるのでお願いしますお知らせしておりますか最後にハッシュタグひまじんプログラマー

ですよねひまプロ?あれだよねひまプロってさなんかひまわりプロジェクトみたいななんか謎のやつとバッティングしたんだよねバッティングしてたんですよ最近ないですねでもこうやって調べるとひまわりプロジェクトを圧倒しつつあるうん

ひまプロもいっちゃうかいっちゃうか表記ブレすると調べづらいけどどっちもいいですすでに2パターン検索してるんでひまじんプログラマーひまプロどっちかでツイートいただけると僕らのポッドキャストのエピソードのブラッシュアプリもありますしモチベーションになりますのでお願いしますあとはグーグルフォームの方も質問とかなんか言いたいこととか思いの丈ぶちまけていただいて

そうすると僕らが取り上げてお話ししたりコミュニケーション取れると思うのでぜひお願いしますお願いしますでは今週もここまででありがとうございましたバイバイバイ初めて触ったMacBook思い出がいっぱいのチーム開発再起動したら治った謎のバグ僕たち私たちは卒業します駆け出しエンジニアを卒業したいあなたへ

ひまじんプログラマーの週末エンジニアリングレッスン各種ポッドキャストで配信中