#216 VSボブおじさん最終回。A Philosophy of Software Designに学ぶコメントの流儀

2024/1/24 ·

エピソード概要

今回は『VSボブおじさん最終回。A Philosophy of Software Designに学ぶコメントの流儀』です！

ソフトウェアエンジニアはソフトウェアの複雑性を下げるようなコーディング、ソフトウェア設計をしていく必要があります！

ということで、今回はコメントの書き方についてです。

ドキュメントがない開発をしないようにできるかつ、綺麗なソフトウェアを書くためのTipsをお持ち帰りください！


【紹介した本】

・A Philosophy of Software Design, 2nd Edition 


-----------------------------------------------------------------------------------

お便りはこちらにラジオネームをご記入の上お送りください！

[email protected]

質問内容はなんでもOK！

今困っていることや、キャリアについて、これからエンジニアを目指すにあたっての悩みなどどしどしご連絡ください

こちらのGoogleフォームへの回答でもOKです！


Twitterで「#ひまじんプログラマー」をつけてツイートしてくれたらめちゃくちゃやる気出ます！

よろしくお願いします！

-----------------------------------------------------------------------------------

Twitterのフォローもよろしくお願いいたします！

・かいち(https://twitter.com/KaichiWork)

・のり(https://twitter.com/ittoku_ksm)

・じゅんぺい(https://twitter.com/panpaaaaash)

-----------------------------------------------------------------------------------

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

  • あ、フィロソフィーオブソフトウェアの最終回ですうわ、出た!ファイナルバトル寂しいファイナルランドだ今日はですね、えーっと、まあボブおじさん編なんですけどバーサスバーサスまあ最終決戦、決着は別につかないんですけどちなみにこっちの作者の人は名前何なんでしたっけジョン・オスターハウトさんですね全然知らなかったスタンフォード大学の先生だと思います、たぶんうーん、ジョン

  • ジョンさん?オスターハウンドそうですねジョンジョンおじさんジョンおじさん僕おじさんおばさんじゃないよねジョンは男かっていうのでコメントとの向き合い方はいいやクリーンコードでもありましたよコメントですかコメントの話コメントはあったなそして別になんなら俺らもちょっと意を唱えてましたうん若干ねうん

  • その辺の話でもポッドキャストの中では大枠割とコメントは最小限にしましょうねという話をしてきましたけど多分クリーンコードですよねそれに対してフィロソフィー用ソフトウェアデザインは何の話をしているんでしょうかというのが今日の話になりますなのでそうですね本当にこの本でコメントの話って20章構成なんですけどそのうち4章がコメントですえぇ

  • 間違ってるよそんなに比率なのでかなり熱が入ってます一番多い気がするそうなの変な人じゃんそのぐらいソフトウェアの複雑性を下げるためにコメントが大事だって話をしてるんですよなるほどねすごいだからバトってるんですよそうなんだここはちょっとバトルの匂いするしなんか暇プロとも対立しそうじゃないですか確かにちょっと

  • コキコキ鳴らしてる今日はですね話を聞くとコメントをうまく使いながら分かりやすいコードを書くためのテクニック

  • とクリーンコードとは違う考え方を学べるといいねいろんなのを学ぶのが大事ですからいろんなのを学ぶのが大事そして僕らというか僕らはリスナーの皆様が読めない本を読んで情報を提供しますし逆もお願いしますって感じでやっていければと思っているのでというのでまず最初クリーンコードでは何を言ってたでしょうか復習からいきましょうまずクリーンコードから引用なんですけど適切なコメントの使用方法とは

  • コードでうまく表現するのを失敗したときにそれを補うのに使うことです知りぬぐいクリーンコードでコメントに対しては基本的に否定的なスタンスをとってます一方でクリーンコードではコメントは常に失敗ですとあれちなみにさコードに

  • 書けないことを書けって書いてあったのはなんだっけコードに書けなかったことを書くのもクリーンコードですけどそれを書けなかったのはお前のコーディング力不足だみたいなそうだっけなぜとかそういう出てこない意図を残すのに使えって書いてあったのはあれは97の方かわかんねえ97の方かもしれないちょっとじゃあなしでいやただクリーンコードにもいやすいません書いてます意図の説明とかはなぜそうしたのかとかトゥードゥコメントとか

  • あとなんだこれ実行するとめっちゃ時間かかるでみたいなそういうのは書くべきですとただ関数名とか変数名から読み取れるともっといいよねっていうのがクリーンコードのスタンスでだから基本的にコメントは少ない方がいいと言ってますこれで順平の説明に必要なクリーンコードのパーツが揃いましたここまでがクリーンコードです一方アフィロソフィーオブソフトウェアデザインの反論

  • まずコメントは少ない方がいいがコメントは失敗を表すものじゃないぞとうんうんコメントの目的の一つはコードを読む必要をなくすることなんじゃないかという風に言ってますあーわかるかもしんないそれ例えばこのコメントを読むことでそのメソッドを呼び出すのに必要な情報を全て得ることができるとで逆にマーチンはマーチンはって言ってるんですけどマーチンは逆のアプローチでメソッド名に全て情報を入れようとしてると

  • なのでマーチンっていうのはすみませんボブおじさんですマーチンボブマーチンファウラーじゃない方かそうですマーチンファウラーじゃない方ですボブおじさんの名前ですロバートシーマーチン全然ボブじゃないんですよボブおじさんって昔の会社の先輩に言われたんだよね確かあだ名あだ名

  • なのでそのこの本フィロソフィーオブソフトウェアデザインで言ってるのはコメントを読むことでメソッドに必要な情報を得るのが良いとマーチンはメソッド名に全部入れようとしてるとでマーチンっていうかボボおじさんっていうかボボおじさんのやり方は長い名前のメソッドへ変数を生み出すことになりますなるこれはなるわかるでもこれって

  • 開発者に対してそれを呼び出すためにドキュメントを再入力させ続けているのと一緒じゃないかと言ってます言ってみて分かります?要はコメントに書こうがメソッド名に残そうが結局何かが変わったらどっちも変えなきゃいけないよねっていうだしあと使いづらくなるメソッド名長いと分かる分かるあのー

  • ゲットなんちゃらかんちゃら&なんちゃらかんちゃらとかゲットなんちゃらかんちゃらifなんちゃらかんちゃらかんちゃらみたいなもし何々だった時に何々を取得するみたいなさなんかとんでもない名前のやつが生まれたりするよねそうそうそうそう愚直にやるとそうなるんですよねめっちゃわかるわかるわちゃうやろというのがまずこのスタンスアフィロソフィオブソフィアゼのスタンス

  • でじゃあコメントはじゃあ何の目的で書くのかというところはまあそのボボジさんとあんま変わんないんですけどコードを読んでわからなそうなこと明確になってないことを補うように書くべしまあこの辺はまあ一緒うんうんですがもっと言うと開発者えーとそのメソッドを使う人うんは参照されるコード以外だからなんでしょう内部にいろいろメソッドってあるじゃないですかはい深くうんうん

  • その辺を読まないでモジュールによって提供される抽象化を理解できるように一番頭のインターフェースのメソッドを作るようにしましょうとそれをやるためにコメント書きましょうねどういうことですかちょっと前のエピソードで言った画像認識のお話になるんですけど

  • そうですね例えばで言うと画像認識するためにはRGBカラー画像である必要がありますでもそれってコード多分素直に書くと分かんないじゃないですかカラー画像を入れてくださいっていう風なコードを書くのってちょっとめいめい色々難しくなりそうじゃないですかその辺の制限をちゃんとインターフェースのドックコメントに書きましょうねドックコメントねうん

  • っていう話をしてますそうなるべきだとインターフェースはだから使う側はインターフェースさえ見れば今からやることも分かるしその制限とか副作用も全部分かるそれをゴールにするためにコメントを書くっていう話をしてますなるほどドックコメントもインターフェースに含むという感じのイメージなんですかそうですそうですそれで言うとボボおじさんで言うとコメントは意図の説明とトゥードゥコメントと警告コメントあとジャバドックうん

  • まあまあ書いてもいいかなみたいな話をしてたところではあるんですけどこのアーフィロソフィアソフトウェアデザインの中では4分類しててインターフェースコメントとデータ構造のメンバーに関するコメントデータ構造のメンバーあとは実装コメント実装コメントこれは内部でどう動いているかを記載する基本的に書くなって言ってるんですけど

  • あとはモジュール間のコメントモジュール間の依存関係を説明するこの4種類のコメントを構成するのがいいという風に言ってるんですけど基本的にはインターフェースとデータ構造のメンバーに関するコメントこの2つを書きましょうインターフェースのコメントはさっき言ったようにこのモジュールのインターフェースについて説明するわけなんですけどこのインターフェースモジュールはこういうことをします

  • っていうのを引数とか副作用事前条件返り値とか出すエラーとかそれをコメントに書くっていうことをやっていきましょうって書いてますねなるほどこれはわかりやすい僕は確かにこれあるといいなと思うんですねこれさらに別のドキュメントにすることもできるじゃないですかぶっちゃけクラス図とかクラス図なのかエクセルドキュメントなのかそういうドキュメントじゃなくてコメントに書くといいという風に

  • 力説してるんですけどそれはちょっともう少し後に話しづらいかもしれませんが方針の都合で言ってたりしますでもう一個のデータ構造のメンバーに関するコメントっていうのはちょっとまあ馴染みない人は分かりづらいかもしれないんですけどえーまあデータ構造に関するインスタンス変数とかがこれ何を表すかとか書いてるやつですねまあ例えばユーザークラスの中のユーザーのAGとかだったら年齢みたいなねお肉だったら熟成期間みたいなねうん

  • そういう読み取れなさそうなものをちょっと都度都度説明したりとかあとはなんかテンパラチャーとかだと-273.15以上しか入りませんとかそういう摂取ですよ歌詞ですよそうそうそうそうその辺の入れるコメントそれは入れましょう逆にコードに書いてコメントに書いてはいけないことこれはコードを見れば分かることは書くなとそこは同じなんですね一緒ですねドライ原則なんでしょうね本当に

  • なんか言い方が違うなーって感じするな聞いてると今のところうんまあでもそうなのかなーちょっと待ってくださいねまあただボボボジさんはコメント失敗だと言ってるのでうんそこのスタンスは違うかもしれないですねあーあー

  • そうねなんかコメントにしてるものは同じだけど言い方が違うというかボブおじさんはそれあまりにもその影響力が強すぎてそれを曲解してマジで信じ込んでしまい変な行動を量産する人たちを生み出してしまったからそのアンチテーゼとしてジョンおじさんが出てきたのかもしれないクリーン行動の本の中でも多分長いメソッド名のメソッドつけてますよねあれはやるなっていうことだと思いますうーん

  • 割とじゃああれはやるなっていうスタンスに読めました読みづらいやろとでもなんだっけななんかでこれちょっとボブおじさんかどうか怪しいんですけど短い名前で意図が伝わらないよりはまだ長い方がマシだってなんかに書いてあったなどうせボブおじさんじゃないですかボブかなこれ達人な気もするんだけどな

  • あとコメントに書いてはいけないことコードを見ればわかることもう一つ実装の詳細について違うレイヤーの話書くなっていう風に書いてますちょっと具体的に言うと画像認識の話で言うと画像処理するメソッドのコメントの中にこれはこういうアルゴリズムでこういう風に画像を処理して処理してますっていうコメントは書くなって書いてますねレイヤーが違うから同じレイヤーのところで書けとそれは本当に必要ならなるほどね

  • というような形でインターフェースの話とデータ構造のメンバーに関するコメントを書く一方未来は分かることとか抽象度が合わないことは書くなっていうのが概要スタンスまあそうね結局誰も彼もがやっぱ同じことは書くなっていうのは言ってますね一貫してますねドライ原則というかまあとはいえですよ僕もちょっとこの本読んでて気になってたいやいやとコメントなんて書いてたら古くなっちゃうぞとうん

  • そういう問題あるじゃないですか本当にそれをやらないようにするなんならコメントをこうやって書くと早いやつもっと楽しくなるよって話をしてますポジってるねなのでジョンおじさんがジョンおじさんにしちゃいますけどフィロソフィーオブソフトウェアデザインっていうのがちょっと疲れてきたんでジョンおじさんにしたんですけどジョンおじさんがどうやってコメントを書くのかというお話に移ります

  • 2つ書いててですねポイント2つかやり方は1つ仮想プログラミングみたいな話が書いてます仮想プログラミングでしたっけ疑似プログラミングまずコメントっていつ書いてるっていうところで後から書くのは良くないぞと言ってますコメント後から書くことが多いんですよドキュメントもそうですけどねただですよ時間が空けば空くほど実際に実装に関する知識が薄れていきますなんだっけなこれってなりますじゃあ

  • そういう薄れた後にコメントを書くとどうやるかっていうと目の前のコード見てコメント書くんですよ目の前のコードを見て書いたコメントコードを見れば分かるんですよ確かにそんなコメント書くんじゃなくていいコメントはコードから読み取れないものを書くんですよだからコメントから書き始めましょうって話をしてます

  • どうやってやるかというと具体的にまず新しいクラスを書くとき作るとき最初にインターフェースのコメントを作りますこのクラスはこういう風なものを受け取ってこういうことをやってこういうものを返しますエラーは多分こういうのが出ますインターフェースコメント書き終えましたただまだメソッドの本体は書きません

  • 正しそうな設計になるまでブラッシュアップしましょうクラスのインターフェンスコメントっていうのはこういうメソッドがあってこういうプロパティがあるよみたいなやつってこと?もうちょっとオープンAPIみたいなのに近いと思います本当に入り口出口の定義何を返すとか何を受け取って何を返すとかだと思いますそれはメソッドごとに書くんですか?クラスって言ってるんで多分メソッドごとというよりはクラスとかだと思いますねほう

  • リュードはパブリックメソッドは書けます多分プライベートメソッドは書かない気もしますリファクタリングの範囲ですな気がするんでそれはでそうやってブラッシュアップしてこれでいいインターフェースできたわインターフェースというかいい設計できたわってなってから実装コメントを書くと実装し終わった頃にはもうコメントがあるとドキュメントがあると

  • これやると何がいいことかっていうと最初に言った通りコード書き立ててコメントブラッシュアップしていくのでいいコメントが書けますコードを見てコメントを書くっていうことじゃないからコードから見てもわからない情報を入れることができる最初にブラッシュアップするのでいいソフトウェア設計も書けるこれは擬似プログラミングと一緒だと思うんですけどあとはコメントって退屈じゃないですかドキュメント書くのとか設計フェーズに書くんで楽しいって言ってます

  • これは感性の問題なので僕はすごい分かるんですけど設計楽しいんですよこうやって作ってとかそういう時にコメントを書くので同じコメントを書く同じドキュメントを書くっていう作業なんですけど楽しいよってなるほどね楽しいかどうか分かんないですけど頭は整理されそうだなとは思いましたね最後に書くと大切な作業になるからね確かに

  • でそれでコメント書いていってでじゃあ今後そのソフトウェア長く生きていく中で修正漏れが発生するんじゃないかって話もありますけどいやいやとこうやってるこうやると修正漏れなくなるよって減るよって話もあってまずなぜ更新が忘れられるのか2つ原因があります1つ目は変更時にコメントが目に入らないわかるあいつらだいたいエディターですっごい薄いからあそこなんだしかもあとは変更すべき場所がわからない

  • あそこのコメントも直さなきゃいけなかったんだみたいななるほどね遠いところにあるケースもあるのかそうですそうですでじゃあどうするかというとコードの近くにコメントを置くべきあとはドキュメントとなるコメントは一箇所にすべき一箇所にすべきなんだもし複数箇所で使われているメソッドもしくは変数があったとして複数の場所に書きたいなって思ったとしたらそのコメントへのリンクを貼っておくコメントへのリンクはい

  • 晴れるの?方法は多分何個かあると思っててファイルパス直接書いてコピペしてもらうかもしくはGitHubのリポジトリのあれ行数しかできないのかなリンク貼っとくとかですかねファイルの相対的な指定が無難だな多分GitHubのリンクとかだとコード変わった時に違うコードを参照しそうだからいずれにせよリファレンスするようにしておきましょううんうん

  • コピペでいろんなところに同じものを書くんじゃなくてっていうことをすると修正漏れなくなるよねって話をしてますなるほどねGitHubのレビューするときとかも変更した行の前後4行ぐらいしか出ないじゃないですかあの枠に入るようにしましょうねってところなんだろうかなと思ってますなるほどそういうコメントをうまく作るツールとかないのかな

  • TSみたいな感じでよりコメント長期のを付け足すけど実際作るときはビルドされてコメントは特になくなるよみたいなビルドするときにコメントってなくなった方がいいんですか多分あっても変わんないですよねファイルサイズがちょっと大きくなるかもしれないですけどちなみにあんまり使ったことないんですけどJavaDockとかってそういうもんなんじゃないですかリッチなコメントというか飛べたりする?飛べます呼び出し

  • でそのメソッドにJavaDocが付いてたらどっかでそのメソッドを呼び出した時にちょっとカーソル当てるとそのJavaDocのコメントバーって出てきて読めるでなんか押して確かすぐ飛べますねなのでなんかお話としてはその

  • 近くに置きましょうっていう話をしてる近くに置きましょうと一箇所にまとめましょうって話をしててこれを全部読み取って僕が思ったことはチームとしてそういうJavaDocみたいなツールを使うポリシーにしてコメントとともにコードとともにコメントドキュメントを書いていく運用が一番綺麗そうだなって思ってました結局IDで表示してくれるしうんうんうん

  • あとGitHubに上がるんでバージョン管理しやすいしそのままで多分ドキュメント見るときって結局コードも並行して見るんで2つバーンって開くよりも1箇所で見れた方が楽だろうなっていうのは思うのでなんかこの1箇所の概念がよく分かんなくなってきたかもほうえ?どういうこと1箇所ってファイルというか本当に物理的に1箇所です本体は

  • 例えば普通に我々が普段触っているプログラムだと例えばコントローラーあるじゃないですかそしたら大体クラスの上にクラス用のドックがあって各プロパティの上にも何かあるときはあって各メソッドの中にもそのメソッドの説明があるじゃないですか場合によってはそのメソッドの中の処理の中で謎のif文とかがあってなんでこれをやってるかが伝わりにくそうだなってときはその上になんでこの条件分岐があるかみたいなことが書かれるじゃないですかはい

  • ってなってるって散らばってるってことですか今ノーですノーなんだノーです今のはまとまってんの今のはまとまってますまとまってるって言ってるのはまずのりさんの今の話に2つの2種類のコメントが入ってたと思っててインターフェースコメントと実装コメントですねで実装コメントはなんでしょうYを書くものワットもあるかもしれないですけどねよっぽど難しいことをやってたら

  • それは近くでいいです僕が今言った一箇所の話はいろんなところにインターフェースコメント書くなとか定義元で一箇所にまとめておくべきものを散らばらせるなっていうニュアンスですなるほど例えば今説明したクラスを使っているクラスの方に

  • そのコメントを書くんじゃないよっていうことですか?そうですそうですそっち側でなんかこの引数はこれを意味するみたいなことは書くなという意味ですはいなるほどですねっていうような運用にしていくのがいいのかなと思いましたインターフェースコメントは正直あんまり書いた記憶はないんですが書いた方が優しいなって思ったのでちょっと本当に触ったことないんでなんとか読系書けるようになりたいですさらっとあれでも

  • 習慣ですよねいやあれはねあの拡張機能ですぐできますよそうなんですけどやったことないんであーなるほどねうんですねはいつのでまとめますとこの本はいジョンおじさんジョンおじさんはいはいジョンおじさん曰くえーもうインターフェースのうんインターフェース見るだけでこいつが何をするのかが分かるようにインターフェースコメント書きましょううん

  • あとデータに関しても書きましょうデータのメンバーに関しても書きましょうあと実装コメントについてはWhat? Why? Why not?Whatはあんま書くなWhyは書こうWhy notも書こうWhy notっていうのはなんでこれをやらなかったのかなんでこんなよくわかんない実装になってたのかこうやった方が効率いいんじゃないかって思われそうだなってところを先回るっすとなるほどね驚き最初の原則から違反してる場所に対してWhy notを残すみたいなそうです

  • あとは今後の未来の開発者のためにですねっていうような形でインターフェース周り他のユーザーが触るとこを手厚くしていきましょうねというのがOur Philosophy of Software Designクリーンコードはコメント最小にしようでもJavaDocとか書こうっていうのは言ってますけどねコメントとかっていうところもそうですけどどっちかっていうとメソッド長くするぐらいだったらコメントかけぐらいの話なのかもしれません

  • メソッド名そうですねっていうのがこの本ジョンおじさんのコメントの流儀というところでコメントから書き始めようというのは取り入れやすいプラクティスかなと個人的には思うのでドキュメント書くのめんどくさいんですよそうねー

  • なのでドキュメントから書けばいいんだって改めて思ったというかまあこれはやったことなかったからなやりたいなと思いましたっていうので2トークちょっといいですかこの本読んでみてそうですねクッソ大変だったんですよちょっとね最初読みやすいなと思ったんですけど4倍くらいかかりましたね体感日本語の本の同じページ数の800ページやん

  • そうかもしれないどういう風な読み方今年でよかったと思ってすごい読むの2023まずすごくよかった点ポイント一つKindleがですねドラッグすると和訳出してくれるんですよ確かにスマホのやつとか出してくれる僕ちょっと知らなかったんですけどKindleって一冊あたりコピーできるワード数決まってるんですよ

  • 最初Kindleの文章をコピーしてDeepLに貼って和訳してちょっと分からないニュアンスというかちょっと違くないかっていうのを調べながら和訳した日本語をマインドマップに入れて全文訳して読んでたんですよ最初2章ぐらいでコピーの上限引っかかって

  • 上限あるんですよ知らなかったそれなかったら無限に本増産できますからねてかさそもそもPC版とかだとコピーできなくない?できますよできますできますその文章じゃない謎のページ情報みたいなやつしか取れない気がする本文と本のタイトルと著者の名前が一緒にポンってそれに巻き込まれてたから気づかなかったそうかもしれないです

  • それでまあ引っかかっちゃうんですけどKindleってコピーじゃねえやドラッグじゃなくて選択するだけで和訳出してくれるんでそれも読みやすかったのとあとですねこうやってメモ取るじゃないですかバーって

  • 結構な分量なんで言うて本なんで結局何ってなるんですよ定期的になので僕は章ごとかな章ごとに結局何をまとめてっていう風に進めてたんですけど結局何っていうところとあとここどういうことっていうディスカッションをするのにチャットGPTがすごい便利なんですねえー

  • 僕マインドマップでいろいろメモとかバーって全部取ってて英語、かいち日本語の日本語も取ってるんですけど僕の使ってるマインドマップってマークダウンファイルなんですね結局このマークダウンファイルをまるっとチャットGPTにボガーンってぶち込んでディスカッションができるんですよディスカッションって何するの?例えばこの本で書いてるここの部分ってどういう意味なの?とか

  • これそういうってことはじゃあこの場合はこうこの場合はそうだけどこの場合はそうじゃないってことなのみたいななんかその解像度を上げる作業がその僕のマークダウンファイルとあとインターネット上の情報を並行で参照して相談に乗ってくれるんですよすごいなそう本読んでてちょっと分かんないなって思ったところを聞けるすごいなそれよくあるわそれ特に背伸び本でよくあるそうそうそう割と背伸び本だったんで僕の中ではやっぱり英語がマジでヤバすぎてうん

  • なのでその理解をしながら読むっていうことについては去年できなかったんでこれ多分そっかなかった4.0はないGPT4.0は強いそうなんだかなり強いっていうのですごい感謝いいっすねで最終的にその5章までかな5章じゃない10章か10章まではマジで全文早く打ってでうわ読むスピード上がってきたかもと思って11章から

  • は全文は訳しないで節ごとにまとめ作ってやってたんですけど多分英文読むスピード4倍ぐらいになりましたね4倍めっちゃ遅かったんですけどすんごく英語力上がった気がしますマジかとんでもない時間かかりましたけどね

  • でもなぁなんか最近さこのひまプロという番組をやってて思ったことがあるんですけどカイチが読んだ本を読むモチベーションの上がんなさすごいんだよね絶対そうこれ読んでもアウトプットできないからなっていうこれなんなんっていう本当っすよねめっちゃわかるわなんかもったいない感出ちゃうよねわかる良くないよねいい本先に取ってから出てきないんですよね

  • 僕も次の要所何にしようかなとちょっとずつ探してるマジかマジかすごいなでもまあ当分読まないですよマジで当分読まないマジかそれぐらい削られた削られたな削られたでも読んでめっちゃ良かったです本当に良かったし簡単だったと思ううんうんうんやろうアウトプットできないけどアウトプット逆になんかだからその日本語って読んでアウトプットできるじゃないですか分かってるわ

  • 英語でもそれをできるようにするためにはもう本当に気合でアウトプットするしかないんでしょうねきっとねなるほどね多分ねなので僕の今年の脱英語苦手キャラのまあゼロ褒め言って去年だったんで多分これ読んだのそうだねというのでちょっと終結って感じです多分これ次読んだらまた違う読解力があると思うのであーそっか前半よりもうだってね今のカイチの方が英語力高いから英語力高いから前半の部分解像度高く読めるなってるかもしれないですねはいうんうんうん

  • とあとは自己肯定感があります 樋口:おーまあわかる 深井:もちろんね樋口:領書読んだことあるぜいって感じだもんね 深井:はい深井:まあさらっと読めるようになりたいですよね樋口:うーん 確かにな 深井:それはまた引き続き今後ですね樋口:僕今デュオリンゴで特訓中なんで 深井:わかる樋口:のりさんが始めたって言ったんで僕も始めました 深井:うん

  • 絶対負けないじゅんぺいがその年始とかで英語1年通じてできるといいんですよねってフィードバックくれたんでその1年2年でやる仕組みとしてデュオリンゴをやってみようっていうあれねすごいよねすごいあのさデュオリンゴの話になるんですけどデュオリンゴのすごいポイントさアプリとしてすごくない綺麗めちゃめちゃすごいめちゃくちゃなんか

  • あらゆる機能をすごい盛り込んで作ってねって感じしちゃったあれエンジニアとしてなんか興味湧くビオリンゴは作りいいですよねすごいなんか定期的に励ましてくれるしあとあの続けるためにホームじゃなくてロック画面のビジェット

  • 追加できるようになってたりするし そうそうそうそうそういう細かい気遣いとかあとやってる途中に1回さオフにしてもう1回画面つけたらなんかDUOLINGOに戻ってこないかい?みたいなやつ出るんだよね出ますね あれとかなんかどうやってんだろうと思ってであと続けたくなる仕組みとして競わせる仕組みもすごいありますしね あるあれはねアプリとしてすごいっすね 素晴らしいあれはもう本当に人間人間研究者がいますね いるえーちょっとやりたくなっちゃうな 唯一気になるのは

  • 文章が意味不明すぎて分かんない時があってあるある結構衝撃的な記憶が残ってるのはそれは石鹸ですかいいえカレーですっていう文章があってそんなシーンあるかなみたいなそういうのがあるあとなんだっけな

  • 絵があってその下に英文があって1個埋めるみたいなクイズ出てくるんですけど絶対にこの絵その文じゃないだろうっていうのが2回ぐらいありましたマジで?具体的には思い出せないんですけどその象はワインしか飲みませんとかでもあれ多分乱数で作ってる感じじゃないですよね多分問題セットをひたすら作ってると思う人間がいますよねあれいると思う

  • しかもあれさ日本語ってさ語順結構どうでもいいじゃんどうでもいいあれの漢字とかもちゃんと採点してくれるよねそうそうそうそううん英文とかも曖昧にやってくれますよね違う単語使っても正解出してくれますよね意味一緒だったらねそうそうそうそうそうよーやってるなと思うしかも早いし早いどうやって判定してんのってくらい早いめちゃくちゃ感動してるビロリングめっちゃ感動してるいやマジでよくできてるあれそりゃユーザー多いわって思う確かにわーやるかー感動したあれは感動した

  • 英語マスターしたら英語の和社がドイツ語を学ぶやつみたいなやつでやっていくのもありかなと思ってるすごいモチベーションですねそれはすごいだねデュアリンゴそれはすごいモチベーションだわっていうのでおすすめですデュアリンゴおすすめですそうね新年何かチャレンジを探したい人はデュアリンゴなら1日5分くらい開ければできるんで多分そうですねあけど俺代わりに技術書読めなくなっちゃいました

  • 電車とかでディオリンゴやっちゃうんですよ簡単だからやりやすいんだよなスキマ時間の使い方がちょっと変わったなスキマ時間の使い方むずい今ディオリンゴに汚染されるよね汚染されてるそうなんだよねわかるわそれちょっとうまく付き合っていきたいですディオリンゴCMあるなこれあるかもな英語でだいぶおしゃべってるやつね

  • はいリスナーの皆さんもお付き合いいただきありがとうございました僕の要所読んでみたよっていう話すごすぎるわ頑張りましたお疲れ様です最後お知らせでハッシュタグひまじんプログラマーをつけてSNSでフィードバック募集してますおすすめ要所万が一知ってる人がいましたらぜひお願いしますハリボタン以外でお願いしますお願いします

  • であとは説明欄のGoogleフォームのリンクからお便り要望募集してますこちらもお気軽にお願いいたしますじゃんじゃん送ってください全部読めますよあと各種ボッドキャストプラットフォームで高評価コメントお待ちしてますので高評価ぜひお願いいたしますぼちぼちお待ちしておりますいいねボッドキャストアワード入るといいですねあれって今やってるのやってないかわかんないなんか年末のイメージあるなんか年始に見たときまだなんか募集してたんだよなそうなんだはいはいっていうのではい

  • また次回さようならバイバイ

0:00 36:20

#216 VSボブおじさん最終回。A Philosophy of Software Designに学ぶコメントの流儀