さあ本日のテーマは引数引数?なんか

深そうですね深そう深そういや深そうというかまぁちょっとこれはですねはいあの僕最近転職しましてメンターからですね一気に開発者という形でめっちゃゴリゴリコーディングをしてるんですけどそうですよねはいそれによってですね僕すごい最近コードについてのモチベーションが高いというか素晴らしいもう超コードについて考えまくってるんですよいいなぁなんか

ひたすら喋りたいそういうのひたすら喋りたい君も欲が高まってるよく高まってますねその中でも今日はですねあの引数について気になることがあったのでめっちゃいろいろ考えた結果こうした方がいいんじゃないかっていうパターンを見つけたというか考えた結果というか実際調べて出てきた部分もあるんですけどはいはいはいはい

めっちゃいいはいなので今日はマジで具体的なコーディングの話をしていこうと思います いや超楽しみ引数なんてねあのプログラム始めてハローワールドはないかもしれないですけどハローワールドの次ぐらいからは全員触りますから そうなんですよ本当に基礎文法をやっている中でねまあ関数に値を渡すといえば引数だろうみたいな はい

感じで出てくると思うんですけどこの引数って結構アンチパターンにはまりやすいなというかこうなってると使いにくいんだって発見があったんでちょっとそれを共有してじゃあそれどうしたら直せるのっていうところをお話ししていこうかなと思いますいいねだいぶ短くまとまってますでもいやわかんない僕が膨らませる可能性あるです

ありがたいちょっと楽しみだなということでまず引数なんですけど結構これはね開発現場あるあるだと思うんですがこの関数引数多すぎないか問題あーはいはいはいなんか10個ぐらいあるじゃんみたいな

あんま見ないけどねたまにあるかもとはいえね多いとやっぱ分かりにくいんですよマジで適当にやるとなりますよねなるこれどの本だっけなソース忘れたんですけど多分クリーンコードだったかなっていう気がするんですけど引数は3個

までだとまあわかる俺もなんかで見た多分クリーンコードかコードコンプリートか達人プログラマーかなんかその辺だと思うんですけど引数はまず3個以上あったら怪しいと思えとていうか3個も結構危ういぞと言ってますそれ以上あった場合はリファクターしろと言ってるんですねなんですけどさっき言った10個は大げさかもしれないですけど4個とか5個とか6個とか結構ある気がするんですよそうですねありますねで

引数が多くなると人間これ減らしたくなりますよね うーんと一歩飛んでるって多分本当ですかえーっとうわ4個とか6個とか一遍に覚えれないよクソがーってなって減らしたくなるんですねそうはいまあなんかしかも見栄えも悪いじゃん まあそうですねなんか関数ね本体よりもでかいやんみたいなね

ってことでねこれ多くなると短くしたくなるっていうのが人間の心理としてあると思うんですよ中級味ありますね中級味あるかなそこは直さなきゃって思うのが大事ですねただこの直し方にね僕は一個アンチパターンが潜んでると思いまして直し方にはい

ニッチですねいいですねその掘り下げこれでもね結構あるあるじゃないかな僕がメンターやってる時も現場でそうやってることありましたっていう報告をいただいてるのでこれはおそらくいろんな現場であるあるだと思うんですけど引数をですね今まで例えば何かのID何かのID何かの文字列っていう感じで一個一個渡してたのを配列に詰め込んじゃうパターン

連想配列にしちゃうみたいなそうするとなんと引数が1個になるんですよそれはじゃあ連想配列を1個の変数に入れてその変数で変数を引数に渡してるってことそう僕はこれをですねアンチパターンと認定しましてちなみに見たことないんですけどそんなことするんですねするんですよなるほど

ちなみにちょっと具体例欲しいな具体例例えばですけどどういう名前の変数になるんだろうとかちょっと気になりますねパラムスあー匂いますねアーグスとか匂いますねそれは匂うでしょ僕はこのパターンをですね名付けましたウィッチズポットパターンと名付けましたウィッチズポットポットはあのポットティーポットのポットポット

ウィッチーズポット魔女の鍋ですウィッチーズは魔女ねあのぐつぐつ煮込んでる緑色のやつですネルネルネルネルのCMでしか見たことないですけどねそうですあのトロトロのネルネルネルネル

あのパターンと名付けましたまあなんでしょう闇鍋とかなんかそういうそういうことそういうこと要するにその煮込んでるものから一体何が入れられたのかわからないああいい最強の命名しましたなんかいい時間の使い方してますのりさんそれいい時間の使い方してる俺あの引数のそのなんでしょう連想配列見てそんなこと思わんす本当

ついねなんかこれパターンとしてあるなと思ったんでいい命名したくなっちゃったんですよねそれ記事にしましょうこれあの5年後に広まってたら鼻高いっすいや誰かが言っちゃうってそれもらいってもらいってなっちゃう先に記事にしとくないかなそっかそっか音残ってるからいいかそうだはい

これがねなんで良くないかっていうまず話ですよカイチ君はもう気づいてると思うんですけどこれまずですねやってることが同じなんですよどういうことですか今まで細かいのに分けてたのを一個の配列にまとめたら確かに一個に見えるんですけど一個に見えてるだけでそれは薄い膜でラップしたたくさんの引数と変わんないんですよなのでそもそも質的に改善してない

あえて聞くんですけど引数多いなって思った時の多分直したいモチベーションってお尻でっかちになってるみたいななんて言うんでしょうなんか見た目悪いなっていうモチベーションで多分そういうアーグスとかパラムスに

うーんってまとめてそうやってるんでその目的は達成してると思うんですけど 見た目は確かに達成してるんですけど今回の問題別に見た目じゃないと思うんですよね引数が多いことってはい 引数って渡してえっと引数のそもそもの目的ってその関数内の 変えたい部分というか柔軟にしたい部分を外から渡すことが多いと思うんですよ

関数って絶対決まったことするじゃないですかでもある時このパターンの時だけここいらないんだよなみたいな特殊なことをしたいケースがあるじゃないですか例えばログインしてるユーザーにはこのデータは表示しないとか

しないとかねもっと言うとAPIとか想像すると多分リクエストのクライアントHTTPリクエストクライアントのクラスかなんかがあってゲットもポストもプットもデリートも全部同じメソッドでやりますっていう時に引数の数ゲットとポストじゃ変わるじゃないですかボディがあったりなかったりするじゃないですかそういうのをゲットの時はボディ部分なしでポストの時はボディも渡してみたいにしたいみたいなそういうことですかねそう

で要はその関数で基本決まった処理やるんですけど引数の目的ってのは中の可変にしたい部分を変えるためにありますよとだけど引数が多いと可変の箇所が多すぎて意味が分からなくなるっていうのが今回のおそらく認知的負荷を高める原因だと思うんですねなんかどういう作用があるのかが見えづらくなるってことなのかないろんなことしようとしてるってこと?

そうだねいろんなことしようとしてるねで引数が多くなって見た目が悪いなっていうのは確かにあるんですけどそれをちっちゃくするっていうのは要は病気になったけど隠しちゃえっていう感じだと思うんですよ要はなんかダメな症状出てるけど本来はそれを治さなきゃいけないじゃないですかなんですけど解熱剤でごまかしてるみたいなそんな気配を感じます僕は

結局そのコードの見た目が悪いのが悪いっていうのは見た目が悪いのが悪いんじゃないんですよねそれによってやりたいことが不明確になるのが悪いっていうことなんですよね今までバラバラになってた時は見た目のフィードバックとして現れてたのがさらにそれも隠されてしまうので大変良くない状態ですと良くない状態ですねしかももっと具体的なことを言うとですね

この関数をですね使い回そうとした時に大変なんですよ例えば連想配列ってキーとその値があるじゃないですかでも

今まで引数で分かれてたら4個渡せばいいんだなって分かるんですけど配列にまとまられた瞬間にこれどういうキーを持ってる配列渡せばいいのってのが分かんなくなるんですようんうんうんでじゃあそれを知るためにはどうしたらいいかってなるとそのソースコード読んでってあこのキー使ってるからこのキー必要だなあここでこのキー使ってるからこれも必要なんだなっていうのを読まないと分かんなくなるんですねあーねーはいあーねーそれあれですよねなんか

適当なやつ渡しちゃうとどっかでこんなやつねーよって言われるんですよねそんなやつねーよって言われるし何なら必要なのに渡さなかった時にもエラー出ますよねっていうので非常にその関数の使い方も見えにくくなりますさらにもっと言うと言語によってはですね配列の中の型なんて気にしない言語もあるんで型チェックも効かなくなります

そうですねうん特に php なんかそうですねうん多分ルビーとか js とかその辺もそうなのかなjs は ts 使えばいいかライブラリありそうですけどねチェックできるあの詳しくないんでわかんないですけどそうまあとにかく使い方がわかんなくなるって迷子になるんですよその1個の配列にまとめてしまうとなるほどはいこのウィッチズポットパターンはい

解消方法をお教えしましょうなんと解消方法ないと何の話やねんってなるんでクレーム出すとこでした危なかったこれの1個目2個あります解決方法1つ目はちょっとこれあの

具体的なことは何も言えないやつなので先に言うんですけどそもそも引数が多い場合っていうのは関数の設計をミスってる可能性が高いので

関数を分けたりとかもしくはその関数を作るレイヤーをミスってる可能性もありますね例えばMVCのものを考えましょうかMVCによくあるものとしてコントローラーからモデルを呼んでデータベースの情報を取得したりロジックをいろいろやったりしてっていう感じで

作ってた結果大変になってサービス層みたいなの挟むことが多いと思うんですよサービス層にはドメインのロジックを置いてモデルにはデータベースのこととか色々置くみたいなちょっとスローダウンしてMVCは一旦いいかなその後のサービス層は例えばどういうことをやるんですかね例えばECサイトで有料顧客に対しては

割引をするとかそういうアプリケーションの都合とか関係なくそのお店が業務ロジックとして持っているものというかそういうのを作るのがサービス層の役割とかだったりしますねじゃあ実際にデータベースを叩くわけでもなくリクエストを受けるコントローラーでもなくその間で何でしょう

ビジネスロジックビジネスロジックって言葉嫌だよねとしか言えないんですけどそういう特殊な事情の処理というか

僕がビジネスロジック一番イメージつきやすいなって思ってる表現はアプリケーションがあってもなくても関係ない業務に発生するロジックだと思ってますねそれこそさっきの割引とか銀行振込手数料とかみたいな話ですね何時の時は何円みたいなねアプリケーションでやろうが実際に店舗で人がやろうが同じ業務が発生するじゃないですかDB叩く前とかにかまさなきゃいけない処理が入ってるとこ

まあそうね前か後かはロジックによるかもやりたいことかロジックというかそうかロジックによりますねやりたいことによりますねそうそうそうそう間のやつはい間のやつサービス層とかであった時にもうサービス層でデータベースのロジックやっちゃってるとかあーいとかはいはいはい

その逆ですねモデル側でなんかそういうドメインのことをやっちゃってるとかっていうなんか場所を間違えてるとねなんか引数必要なことが多くなっちゃう傾向あるんですよそれちょっとあんまりイメージしきれてなかったりするんですけどそれは2つのことをやろうとするから引数の数が倍になってるみたいなこと?いや多分…

関係ないロジックの情報が必要になるからたくさん値を渡さなきゃいけなくなるんだと思うなるほどっていうので引数多くなりがちなのでもしかしたらレイヤーミスってるかもしれないし1個の関数がデカすぎるっていうケースもあるよねなのでそういう関数をちょっとまず小さくなるようにリファクタすると引数減りがちそうねなんかむずいのがうわ引数増えたわってなった時にそれって

一つのメソッドでどうにかしようじゃなくてアプリケーション全体の模様替えが必要っていうのが少し難しいポイントですね多分それは先輩に相談してもいい案件な気がしますそうですねこの辺は結構むずいとは思いますこのロジックを適切に然るべき場所に置くっていうのは意外とむずいむずいですね影響あったりしますしね他にもねあるねー

テストコードとかないと怖いんだよねこれやるの無理ですね直すのやんないです絶対テストコードないとやります?やりますパワープレイすぎるやりますすげー我慢しちゃうんだよな俺そうなんだテストコードないわこれはもうこのプロジェクトはここちゃんとやる気がないんだって思うあそういうこと?

結構PHPの現場はテストコードないあるあるありますからねないあるあるないあるあるあると思うよめっちゃわかるここら辺を勉強するのが面白いんですよねここら辺を勉強し始めてからアプリケーションじゃなくてシステムのレイヤーのアーキテクチャーもすごい興味出てきたしアプリケーションの中のコードの

レイヤーの設計もすごい興味出てきたところがあるんでここはすごい面白い分野だなって思います面白いですよねこの辺面白いパズルみたいな

いわゆるさっきも出てきたクリーンコードとかあと多分マーチンファウラーさんのリファクタリングとかがね結構この辺学べる本なのかなと思いますねマーチンファウラーのリファクタリング読んだことないんで今年読みたいな僕それはね1年目に背伸びしてねすっごい簡単なパターンしか学べなかったんでそろそろ読み直した方がいいなって思ってるんですよね読んできますいつかエピソードにしましょうですねいっぱいパターン載ってるんであれネタに困らないと思う

楽しくなって脱線しましたが1個はレイヤーを整理するって話が解決策その1レイヤーが適切だった場合は引数用のオブジェクトを作成するのがいいと思いますねどういうことちゃいこれはさっきの配列と何が違うのっていう感じなんですけどオブジェクト要はクラスから作るインスタンスのことですねうんうん

インスタンスってプロパティ持ってるじゃないですかそのプロパティの中にそれぞれの値を設定するようにするんですよこれやってることさっきの配列と同じじゃんっていう気持ちになると思うんですけど一個違うのはクラスがあるかないかっていうことですねわかるクラスがあるとなんで嬉しいのっていう話なんですけどまずクラスのプロパティって

言語とかバージョンにもよるんですけどまずプロパティに型を持たせられるなのでどういうデータが欲しいよっていうのがそのクラス見ると分かるようになってるんですよ設計図があるみたいな状態か本当に配列って設計図なしでボーンって書くじゃないですか

書くそれがどこにあるかが頑張って探さなきゃいけないんですよねさっきの配列で言うと探さなきゃいけないがマジでドキュメントない場合はコード読んで何が必要なのかを読み解かなきゃいけないっていう感じだったんですけどこうやってオブジェクトにしてあげるとクラスがあるんでそのクラスを見たらどういう引数が欲しいのかっていうのが分かるようになってるとそうですねしかも

クラスってインスタンス化するときにおそらくJSみたいなプロトタイプベースって呼ばれるオブジェクト思考言語があるんですけどそうじゃなければ多分クラスからインスタンス作るときにコンストラクターっていうインスタンス化するときに動きますよみたいなメソッドがあると思うんですよその中で

各プロパティにどんな値を設定するかっていうロジックも書くことができるんでただ単に整数で良ければ整数突っ込むこともできるしマイナスの値入らないですよっていうようなロジックとかがあったら例えばif文でこの値は0以上じゃないと例外投げますよみたいなロジックを書いていくことによって

よって単純なその整数とか文字列とかいうよりもより具体的なことを書いていけるとっていうので実はこれ配列をしっかりしたクラスに変えてあげるだけでめちゃくちゃ分かりやすくしかも綺麗なコードになるわけですねっていうので分かる?分かる。ありがたい。分かる。っていうのでこれ今難しい話してないかな大丈夫です僕が楽しんで笑

多分オブジェクト思考言語やってる人はわかるじゃないですかとりあえず今駆け出しの段階で今ちょっと難しい部分混ざってたかなっていう気はするんですけどとにかく関数の位置とロジックが合ってるのか

合ってるんだったらそれは引数用のオブジェクトにした方が分かりやすいんじゃないのかっていうこの2点を考えることによってですね引数の設計っていうのは非常に分かりやすいものになるんじゃないかなと思っておりますのでぜひとも配列にパンパンに詰め込んでよく分かんない方のデータにしちゃうっていうのはやめて綺麗なコードを書いていただけたらなと思ってる次第でございます2つ質問いいですか1つ目がですねえっと

うわー引数多いわーってなりましたとその時このケースではレイヤーが適切に分かれていない状態のうわー引数めっちゃ多いわーっていう人がいますとただその人はクラスを作るというかオブジェクトを作るという選択をしてオブジェクトを作りましたこれはいいんですかっていうでこれはいいんですかっていうのは良くないんですけどじゃあどうやってそれが良くないっていう判断を判断をすべきか

それはやってみましょうまずそして良くなかったら後で罰が当たりますちょっとじゃあ僕の仮説というか僕は一応こうなんじゃねっていうのを持ちながら質問したんですけど多分ですけど

そのオブジェクトクラス作ったクラスにいい感じの名前つけれないと思うんですよ引数が多分いろんなものに使うものが含まれてるから結局そのアーグスとかメソッド名パラムスみたいな謎の命名をせざるを得なくなることがあるんじゃないかなと思っててうわーそれはどうなんだろうなそうではない

えっとねオブジェクトの場合は結構ざっくりしたことになるケースもあるかなという気はしますねなんかそれこそ引数多いわっていう時って多分何でしょうユーザーに関するいろんな情報を入れたくなるとか何々に関するいろんな情報を入れたいからそれをひとまとめにするためにクラス作るみたいなイメージだったんですけどそうでもないんですかね

例えばですけどちょっとクリーンアーキテクチャーみたいな話になるんですがはみ砕きますインプットバウンダリーっていってサービス層に渡すためのデータを定義するクラスみたいなのクラスというかインターフェースみたいなのを作ることがあるんですけどあれって多分結構抽象的なざっくりしたものになっちゃうんじゃないかなって気がするんですよね覚えてね読んだのにそうなのか

多分それはクライアントから受け取るインプットをまとめたオブジェクトっていう意味になるんで結構そういうふわっとしたものができやすいんじゃないかなって気がするので一概には言えない気もするちょっと待ってくださいねちょっとインプットバウンダリー書籍とかを参照しながら見てたんですけどやっぱりのりさんの言う通りというかむずいのはインプットバウンダリー何かっていうとコントローラーからその外下

サービス層というかさっきの構造で言うとサービス層にコントローラーからリクエストパラメーターやら何やらを渡すやつのインターフェースがインプットバウンダリーってやつなんですけどそれにそれって結構ふわっと定義するから中身って結構コンテキストバラバラになるんじゃねっていう話を多分カッコをカッコをの前にやってたと思うんですけどはい

ただちょっと今ざっくり話してる感じ多分普通のWeb APIだったらそのWeb APIでやりたいことって多分一つだとなのでそのやりたいことのデータで多分一個のクラスとして綺麗に分けられるはず大抵の場合はなので多分何かしらのラベルは付けられるはずってことですねその引数をオブジェクト化しようと思った時にはそうじゃない時は良くないまとめ方やぞって

すんなり名前が付けれたらそれは大丈夫そうってことですかねっていう判断軸があるかもしれないですねちゃんとねコードレビューの時にねいやさすがにこれ無理やりだろうっていう指摘をしてくれると信じてプッシュするんでしょうねそうです

その辺は先輩の力量にもかかってますねなのでレビューする側も油断せずにいきましょうありがとうございます2つ目の質問いいですか僕はあんまりオブジェクト思考以外の言語で真面目にプログラミングした経験がないんですけど関数型とかでこういうことってあるんですよね多分やろうと思うとオブジェクトにまとめられない言語ってあるんですよね関数型の場合は

僕もちょっと関数型がっつり触ってないんですけど僕の中の関数型のイメージってちっちゃい関数めっちゃ作ってめちゃくちゃネストして呼び出すみたいなイメージあるんですよなんで一個一個の関数で引数が増えるケースがあんまりなさそう例えばですよ一個一個の関数めちゃくちゃネストして処理するって言ったじゃないですかネストしてるってことは

樹形図みたいになってるんですよね関係としてなので大元の関数って引数めっちゃあるんじゃないですかそんなことない?どうなんだろうネストしてるのも

関数を呼び出したまず関数型のプログラミング言語って純粋関数型言語とその他があるんですけど純粋の方でいくと確か全部が関数でかつ引数と乖離値が絶対あるんだっけな一個一個の関数がべき等じゃなきゃいけないって言って例えば

この状態の時は違う型が返ってくるよみたいな処理をやんないんですよ確か何回やっても同じものに同じ結果になるというかこの引数を渡したら絶対これになるみたいなのが決まってる言語というかでその返り値をさらに次の引数にしてみたいなバトンリレー形式のイメージなんですよねなるほどそれで見た目上減ってるというかちょっとねあんまり詳しくないありがとうございますありがとうございます

補足のお手入れお待ちしてますもしくは感想が助かってますよと興味あるんでねちょっと僕今年こそ今年こそ5を触らないとやばいと思ってるんで5はでもあれじゃなかったっけ手続き型じゃなかったっけ手続きだっけいやこういうとこですよ本当によくないなちょっと待ってくださいね5はねマジでねあんまり得意じゃないんですよね5は性的片付けあ違うちょっと待って

ベターシーとかって呼ばれてますよねよくシーゲン語よりいいと書きやすいシーゲン語構造化手続き型命令型オブジェクト思考関数型オブジェクト思考もそうなのそうなんだじゃあクラス作れるんじゃないクラス作れないはずでもオブジェクト思考っていうのクラス作れないんだけど継承とかできんなんかクラスじゃないのでオブジェクトみたいなことやってるなって思った記憶はあるそうなんだ

失礼しましたじゃあまあどうにかなりそうだななるほど関数型だと多分ハスケルとかスカラースカラーはね結構ミックスされてるねそうなんだミックスされてるのが多いっすかねそうですねあれじゃないですか純粋だとハスケルとかエリクサーがよく出てくるイメージありますねありがとうございますはいはい

っていうのが僕の質問でしたありがとうございますあとちょっと補足のところでJSJavaScriptとかでReactとか使ってるとReactって1個のページも1個1個のコンポーネントに分割して作ったりするんですよパーツみたいなもんですねそれをまとめてるページみたいなのがあってその中にコンポーネントいっぱい呼び出して作ったりするんですけどその時に引数プロップ数みたいな感じで

雑渡しみたいなのをすることが結構あるんですよただ

さっきの話の中でいう配列にまとめてるみたいなことをしてるんですけどTSと使うと型定義できるんでそうなのめっちゃいいじゃんめっちゃいいじゃんその辺はしかもTSと使うことが多いと思うんでそうやって型定義したらいいのかなっていうのとちょっとフロントとバックエンドの話だと若干文脈も違うかなっていうのはあるんでそこは

そこはちょっとねフロント詳しい人を今度呼びましょうはいそうしましょうありがとうございますではお便りいただいているのでお便りを読みますねはいお願いしますラジオネームもっちゃんさんからのお便りですもっちゃんはいまずどうしようかな感想から読みますはいいつも楽しく聞かせてもらってます博士課程の大学院生なのですがプログラムの綺麗さが研究の進捗には直結しないことが多く

だんだん動けばエイヤーの行動になってますついつい気が緩んだ行動を書くことってありませんか?あるよってあるよね人間あるよねなんなら俺大学の時はもっとそう

それゆえ社会人の時めちゃめちゃ鍛えられたというかなるほどねこの綺麗さみたいなのって社会人になった時の方が大事というか特に事業会社とかで大事だなってめっちゃ思ったんですよねチームで開発する時に大事なんですよねっていうのでちょっと次に繋がるんですけどポッドキャストで話してほしいことチーム開発と個人開発と違い個人開発だとGitHubやタスク管理ツールなどよく名前聞くけどありがたみがピンとこないツールがあります

これらの個人開発での活かし方他にもチーム開発と個人開発で違いがあるのかお話聞かせてほしいですというところでギットはめっちゃわかるわタスク管理ツールもめっちゃわかるめっちゃわかるというので僕も大学院まで行って研究してたんですごいわかるんですけどマジで動けばいいんですよコードなんて動けばいいんですよ変数の名前Aとかなんですよマジで

やばいねこれは僕のスペックにも関係してるかもしれないですけどC言語とかで授業やるんですよ最初そうやって授業やるときって本当に足し算するだけとかそういうとこから始まるんですけどそういうときの当時のコードは絶対に意味のある命名してなかったんですね変数XとかYとかAイコール2Bイコール3えー

XYイコールAプラスBプリントXみたいなね本当に計算だけするやつ今思えばねトータルにしろよみたいなねトータルイコールAプラスBとかでいいやんとかX1X2にするとか

そういうこと思うんですけどなんで研究室の時のコードはそういう意味のない命名ってやってわかんなくなるからコメントアウトでなんとかこうやってるよっていうのを自分のために書くみたいなねそういうことやってましたけどここにすごいチーム開発と個人開発の違いがあるなと思っててやっぱ人がわかる人が見てわかるなおかつ自分が1年後2年後

コードをとらぶった時にもう一回見なきゃいけなかったりするのでコードというかシステムか改めて見た時に分かるように書かなきゃいけない思い出せるように記録を残さなきゃいけないっていう意味で分かりやすいコードを書くとかGitHubのプルリクエストとかコミットが残ってるとかタスク管理ツールにこのタスクやった時の事情が残ってるとかいつやった誰やったとかね

そういうのがめちゃくちゃ効いてくるんじゃないかなってこの社会人生活で思うところではありますなるほどねちなみに研究の行動って結構使い捨てみたいになるんですか僕は後輩に受け継いだりとかはなかったんである人はいるんですけど研究室によってはそうなんだ僕はなかったんで使い捨てですなるほどね使い捨ての行動ほどなんか

あんま重視しなくなっちゃうよねこの辺は使うんだったら多分先生がもう一回見て書き直すんだと思いますなんかその過読性めっちゃ重視するじゃないですか個人的には過読性を一番重視すべきだなって最近思ってるんですけどやっぱその理由ってウェブサービスとかって絶対にバージョンアップを重ねるというか常に改良していくじゃないですかってなった時にコードの過読性悪いとどう

どうしても開発速度遅くなっちゃって競合に負けるじゃないですか開発スピードとかでってなった時にやっぱ過読性を一番重視すべきだなっていうのは思っていてちょっとこの話とは少しずれるかもしれないんですけどパフォーマンスと過読性ってトレードオフになるとき結構あるじゃないですか例えばこう書いたら綺麗に読みやすいけどクエリ発行しすぎててパフォーマンスに問題ありそうだなとか

まあありますねそれはあるんですねはいとかまあ普通にさあのメモリーの話だけど まあこれちょっと条件式長いから変数に格納しておいて意味持たせとくかみたいなのもまあ言うてあのまああんま変わんないけど メモリー少し引っ張っあの使うわけじゃないですかねっていうのがあった時も過読性を優先して

パフォーマンスはいざ問題が出てきたらやるべきだなって気がするんですよねそれはあるっていうぐらい綺麗さを重視しておくと社会に出た時に良さそうって思いますねいやーただねそれねマジでムズいんだよね学生の時にねめっちゃ余裕があったらやるでいいですし個人的にはレベルの高い企業に就職したいとかだったら意識しなきゃダメだと思うんですけど学生の時から

そうじゃないんだったら僕は社会に出てからでもどうにかなりますなるほどねなるでしょうねそもそも僕はプログラミング知らないまま社会に出たぐらいなんでなんとかなりますよそれは思う逆に個人開発のGitHubとかタスク管理ツールの活かし方とかありますかタスク管理はあるんじゃないと思うんですけど普通に自分のタスクを細分化して例えば

いつまでに終わりそうみたいな見積もり作ってでそれ通り進んでるかどうかを後から確認してなんかこう自分の見積もりの精度を正すのに使ったりとかできるんじゃないかなって思うんですけどGitHubはマジで無理じゃねって思いますねまあねGitHubはマジでチーム開発で使わないと何がいいのか分かんなかったなって思うわえっと研究室はまだあると思ってて例えばですよなんか

スクリプトを実行することによって例えばですけどネットワークのパケットを1日とか取るみたいな行動があったとしてそれを分析するみたいな研究をしてて実験何回もやるわけじゃないですかその時にいろいろ変化していく中でうわこれ取っときゃよかったみたいなのが多分実験してる中で出てくると思うのでうわ戻してとかあの時どうやって書いてたっけって思い出すにはGitHubいいとは思う

けどそうじゃなかったら確かにのりさんの言う通りなくてもいいし僕は使ってなかったし存在も知らなかったそうねこれチーム開発でやったら絶対ないと死んじゃうでしょっていうツールなんだけどねギター版チーム開発やばいですねタスク管理ツールはこれも難しいところで僕学生の時使ってなかったんですよタスク管理ツールなぜかっていうと別に頭で覚えれる範囲のボールしか持ってなかったというかなるほどタスクしかなかったからうんうんうん

就活ぐらいからですねタスク管理し始めたのそうなんだ早でもあの時からここの会社のこれここまでだからいついついいですかみたいなのをメモで管理し始めたへー

うわ懐かしい俺手帳使ってたわ普通にでもそうですよね当時はねツールとか別になかったですよね多分ねなかったねまだだってスマホとかも出てきて出てきててか普及して間もなかったような記憶ある俺らが大学生の時に大体みんなガラケーからスマホに移行し始めたみたいなだからスマホアプリとかマジでピンポンの玉をシュッて転がしたりとか

数字を順番にタップしていくみたいな変なゲームあるのばっかだった記憶あるわ懐かしい懐かしいパズドラだから革命でしたよねパズドラ革命だっただから懐かしいなっていう感じだったんでタスクが増えてないんだったら別にいらないんじゃないかなとまだ思いますねうんうん

あとあれですねここでGitHubって言われてますけどGitHubっていうよりGit使ったらって感じじゃない?GitHubって言うてそのGitをホスティングするサイトじゃないですかそれはマジでチーム開発じゃないと本当に使わないなっていうか自分のポートフォリオ公開するかチーム開発じゃないと使わないなって感じなんですけどGitは確かにさっきのカイチが言ったようなタイムマシン的な使い方できていいかなって気がしますね

ちょっと無知で申し訳ないんですけどGit単体で使えるんですか使える使えるどこにリポジトリどこに行くんですかリポジトリがそもそも必要ないリポジトリはローカルだけで使える確かに確かにプッシュしないってことかアドとコミットとブランチだけあるってことかそうそうそうそう上げていいじゃん上げていいじゃないですか上げてもいい上げた方が使いやすいです

上げてもいい確かに確かになるほどねプッシュしなくていいですねあれプッシュしなくていいんだプッシュしない使い方出てこない気がしますけどねあんまり俺結構ローカルでやりますねブログとか調べると絶対GitHubとかと一緒に使ってそうじゃないですか確かにね情報が少なそうですけど確かにそれでいいですねなるほど勉強になりましたありがとうございます

おっちゃんさんお便りありがとうございましたありがとうございます博士課程なんてちょっと研究ガチでだと思うので就職先が研究所だとやっぱりギター部は使うしタスク管理ツールも使うと思いますけどコーディングの雰囲気もちょっと違うと思うので僕は研究所とかの行動も見たりしますけどやっぱり保守性はちょっと低いコードが多いイメージなので研究者として結局その研究でやった

コードってコーポレート側に使ってもらうためのものなんでそういうところでちゃんとできると差別化できたりするのかなちょっと研究員の評価基準ちょっと分かりかねてますけど論文全部理談なんじゃないかとかっていう気もするんで確かにコードむずいなうん

だったら研究のところで尖った方がいいっていう戦略もあるのかもしれないしほとんどの人がそうしてるからコードがそうなってるのかもしれないしまあ確かになーっていうのでちょっとどこにリソースを割くかっていうのがあると思うんですけど一旦回答としてはこんな感じでしたっていうところですねお便りありがとうございましたありがとうございました

気軽に送ってください嬉しいです本当に学生が聞いてくれてるっていうのがたまんないですね就職しましたとかもね素晴らしいありがとうございますというわけでSNSでフィードバック募集してますのでJavaScriptの引数事情とか就職しましたとかね時期的には

始まってんのかな年中やってない就活ってかもしれないですね気軽にポストお願いしますあとは説明欄のGoogleフォームからお便り募集してますのでそちらの方から質問要望何でも募集してますお気軽にお願いいたします何でも聞いてくださいあと各種ポッドキャストプラットフォームでのフォロー高評価お待ちしてます

高評価の数とリスナーの数が全然合ってないので高評価をお願いいたしますそれが我々のモチベーションにつながりますのでというわけでのりさんありがとうございましたちょっとコードの話はねいっぱいできる気がするいっぱいできる?まだいっぱいあるいっぱいあるよねだって引数だもん今日すっごい一部すっごい一部ですよねすっごい一部の話してる好きなんで再生数伸びなかったらやめるかもしれないですけど伸びてくれいっぱい聞いてくださいまた次回バイバイ

初めて触ったMacBook思い出がいっぱいのチーム開発再起動したら治った謎のバグ僕たち私たちは卒業します駆け出しエンジニアを卒業したいあなたへひまじんプログラマーの週末エンジニアリングレッスン各種ポッドキャストで配信中