順平に届けアドバイス for junior developers でございます今日も不在でーす今日も不在でーすはいー

たまたま体調崩しちゃったということでねいやーほんとね久しく出てないねはいそうなんですよ僕らも忙しく撮れなくてっていうので今日はデイリー.デブで見つけた英語の記事ですねでもアドバイス for junior developerっていうねこの番組のコンセプトそのまま読めばええやんっていうブログ見つけたので手抜きじゃんいやいやいや手抜きじゃないですか探す労力ありましたよ手抜きじゃないですか毎日見てるんですからちゃんと

読んで読んだ中の10個2個ぐらいかな話せるのようやくしてるちゃんとまとめてるじゃないですかそこはねこのブログはまんまいくんですけどねまんまいくんかいまあというのでちょっとこの記事紹介するんですけどこの記事ですねもう本当に文字通り

ジュニアデベロッパー向けのアドバイスが書いている記事でして大きく分けると汎用的なアドバイスっていうんですかね技術的じゃないアドバイスと技術的なアドバイスの大きく2つに分かれているのでそれらどっちも紹介しようかなと思いますそれぞれの主力の1個出してくるみたいな感じですかいやー2個ずつぐらいかな主力の2個2,3個かな2,3個主力の2,3個出します主力じゃなくなってきた主力ですよこれはうんうん

まず汎用的なアドバイスがいきますねこちら3つありますはいこれはちょっとのりさんに話すのもね若干気まずいところであるんですけど2人でやんやん言いましょう知らない手で行くね知ってる手で行きましょう1つ目コードを点として見るなっていうアドバイスですね面として見ろってことですか面として見ろってことなんですけどなんならコードを書くことが全てではないということが書いてたところから捉えましたあ

開発者である私たちはコードを書くのが好きですと楽しいですよねずっとコードを書いてコードを書くのって結構パズル的でこういうのをやるにはこういう実装がいいかなこうやった方が読みやすいとかこうやった方がワクレス書けそうだみたいないろいろあるかと思うんですけどありますねただそれをやってるだけだとえっとまあ

どんどん成長はできていけないというかそれ以外にもコードを勉強するためにいいコードを書くためにはコードだけやってればいいわけじゃないとわかるわかります?ありどんな感じですか?わかるって最近ちょっと思ってたのは

なんかこうやっぱ今のいる会社結構ジュニアエンジニアというかその層が多いんですよまさしくはいでやっぱ最初あるなーって思ったのはコードとかはいに集中しすぎてるなーって思うんですけどはいはいはいでも実際に仕事で役に立つのってなんかコードよりもなんか

コードも役に立つんだけどそれって全体の3割ぐらいだなっていう感覚あるんですよね今僕の中で実際にビジネスとしてお金を生むためには他の7割あるなって思ってますその7割が例えばクライアントとのセッションの部分であったりとか

マネジメントする人だったらチームメンバーの働きを1.1倍にするようなマインドであったりとかあとは設計とコーディングちょっと違うかなって気がするんで設計スキル大事だなって思いますね確かにあとは設計を伝える力とかも必要かもしれないですね本当にそういう話も書いていて究極結局エンジニアってユーザーとかに対してビジネスがうまくいくようにする

本当に究極のゴールでその中でコードなのかもしくはコードを書かないで出来合いのものを組み合わせて出すのかとかいろんな選択肢の中でベストな選択をするエンジニアだろうというところが思想としてあるんですけども

なので究極コードを書くのがベストじゃないこともあると確かにっていうのを相手のためになるのはなんだろうなっていうところを考えながらやることでさっきのりさんが言ってたような価値あるエンジニアになれるなっていうのがありますねわかる同じことできるけどこっち使った方がお安く済みますよとかそういうのもありますしねあとちょっと一個面白いなと思って見た言葉を紹介するんですけどはい

エンジニアです我々もっと言うとプログラマーだとしますプログラマーコード書いてます仕事の進捗どうやって測るかというと安易に思いつくのはコード行数かなとかプッシュの数かなとかあると思うんですけどコードの行数で進捗を測るのは愚かであるとそれはな愚かノリさんわかるかもしれないですけどどういうことかというと書いたコードの行数で進捗を測るのは

本質じゃなくて例えばリハクタリングとかもあるわけですよはいはい

その高度の進捗を行数で測るのは航空機の製造の進捗を重量で測るようなものだといい例えするねこちらビル・ゲイツの言葉ですゲイツさんすごいゲイツさんいいねまさしく本当にそうなんですよね高度行数って取ってるプロジェクトあるかと思うんですけどそれは今週どのくらい仕事したかというよりはその行数に対してどのくらいテストケースがあるのがいいかとかかな

そういうのを測るのに使うものなのでおっしゃー今週300行増えた300行分し落としたぞっていうのはちょっと違うよっていうところですねなるほどねこれはあれですか料理人がどれだけ塩を入れたかで測ってるかみたいな感じですかくっそーかなー

どうなんでしょうね絶妙に違いそうな反応してる違うと思うんだよねそれは違いますよね料理人のKPIなんだか分かんないですけどまあそうだよね飛行機の例えが本当にこの上ないと思います確かにこれ一つ目コードだけじゃないぞって話ですね次二つ目ソフトウェアデザインマターっていうポイントなんですけどほう

これはソフトウェアデザインとかをちゃんと学びましょうというところなんですが僕もそうだったんですけど最初のキャリアの時はソフトウェアデザインってソフトウェアアーキテクトとか他の何かしらの偉い人のためのスキルなのかなという風にいろいろ思ってたことはあるんですけどもでも結構クリーンコード読んだじゃないですかクリーンコード読んでから

こういうなんか分かりやすいとか結局保守しやすいコードを書くためにはそういうソフトウェアデザイン大事なんだなと思ったわけなんですけどなるほどちなみに多分ですけどソフトウェアデザインと聞いて画面のデザインだと思ってしまう人がなんかいそうな気がしますねなるほどなんて言えばいいんでしょうデザインパターンって言えばいいんですかまあなんか日本語で訳すと設計だよねあれ結構

設計かドメイン駆動設計の設計ってデザインじゃないですかあー確かにあれ英語だとドメインドリブンデザインですよねあれ系のデザインだと思った方がいいですねじゃあ設計アーキテクチャ設計とかその辺なのかなって気がするんですけど良いじゃあそう言い換えますアーキテクチャデザインですねっていうのでその辺学んでいきましょうとでまあ最も

大事なところで言うと早く進むための唯一の方法はうまく進むことですおしゃーおりゃーってがむしゃらにやるんじゃなくて堅実に一歩一歩丁寧に作っていくのが結局一番早いとなるほどね出世するために社内政治するやつみたいなあーまあちょっと近いかもしれないなちょっと近いかもしれない器用に生きるまあそうですねちゃんとね周りを固めてってことですよねそうそうそう目回しちゃんとやってますよそうそうそう

ただ結構学ぶの大変ですよね言うても僕もまだああいうアーキテクチャ系って多分答えなくてそうねみんながこれめっちゃいいよっていうのをいっぱい考えててそれのうちに今のケースってどれが当てはまるんだろうっていうのを頑張って考えるみたいな世界そうですね今ちょうどあの

以前カイチ君が読んでたというはいソフトウェアアーキテクトの基礎はいはいはいを今読んでるんですけどあーはいはいはい前半それめっちゃ書いてますねそうですよねうんもう正しいものはないとない場合によるだ場合によるうん

一番読者としては嫌ですよねそれそうだ惜しいだろうしよ書いてるんですけど漢元記事みたいなねでもそうなんだろうなとも思うし場合によらずにこだわってる人いっぱいいそうだなって思うそれはそうですねそれはあるそれゆえの強さなのかなって思いましたねそうですねだから続編も出ましたしね結局出たねっていうのでなので時間トロールが結構必要なのでうん

長い目で学び続けるのは重要ですというのがソフトウェアの設計デザインアーキテクチャ設計アーキテクチャ設計をそれ主導で物を作ろうっていうのが2つ目の汎用的なアドバイスこちら技術アドバイスじゃないですこれは技術アドバイスじゃないです違います3つ目これめっちゃ重要これもまだあれだよね汎用的なやつですねはい

ベストプラクティスを使えとベストプラなんかこれでこうやった方がいいんじゃねえじゃねえとまず黙ってベストプラクティス使えとそっから判断しろとこれだけですこれはシンプルAWSとかも結構出してるじゃないですか公式のやつねあとは

他なんかあるかなライブラリとかってたまにありますけどねもうちょっとめちゃめちゃコアな話ですけど最近MongoDB触ることがあるのでそのMongoDBのMockの使い方っていうんですかねライブラリのドキュメントにこうやって使えみたいなのがあったりするので盲目的にというか

コピペはしないにせよ同じような形で呼び出すとか大事これ結局これをやることによって後でね思わぬバグが出たりとかしないようになりますしそうですね結局そこですね結局世の中でいいって言われてるものはいいことの確率が高いよとそりゃそうだよねだからベストプラクティスになってるんだしねベストだしねベスト

ここからネクストステップあるとしたらベストプラクティスを覆すようないいアイディアって絶対あるだからそれを見つけられるように使いこなした後はちゃんと疑っていきましょうGoogleの人やGoogleの人それは

ベストプラクティスを超えるベストプラクティスを見つけてる集団って感じのイメージなるほどなるほどそれはそうですねまあでもそのベストプラクティスをベースにちょっとうちにこっちの方が合うよねみたいな変形させていくのがなんかいい気がするけどねそうですね

ただそれで謝らないように気を付けようというのは難しいところではあるんですけど確かにな以上3つコードを点で見るなというのとソフトウェアのアーキテクチャデザインを学びましょうというのとベストプラクティス使えというのが汎用的なアドバイスですね続いて技術的なアドバイスですきたはい

これは非常に強く言い続けたいんですが1つ目テストかけーですテストかけー俺テストかけー自動テストかけーとテスト駆動開発やれーとすいませんでしたこれマジでどこで何読んでも書いてるんですよねこれはねほんとすごい書いてるすごい書いてるけどそれやってる現場ほんとないあそうなんですかあでもそうかもしれないなこれテストって言ってんのは単体テストですね結合とかじゃなくてね

単体テストって前もいつも言ってるんですけど関数の動きをチェックするためのテストなんですけど十分に関数を小さくしていくとそりゃそうだよねっていうテストができあがるんですよねやっぱりねそりゃそうだよねっていうテストを書くぐらいの関数を書くために単体テストを書きましょうって話なんですよねなおかつそれを引き継いだ人がそのなんだろうね

ちゃんと分割された適切に分けられたメソッドを維持するためにも単体テスト書こうねって話なんですよねなんでテストってあんな書かないんだろうねそうでテスト書かないちなみになんでなんですかテスト書かないのっていやなんか見積もりの時にテスト入れてねえのかなもしかするとそれはあるかもしれないですねもしくは入れてたけどまぁだいたいああいうのって

伸びるじゃないですか伸びるああはいはい作業の作業時間が伸びると思ったように進まないっていうのがまあよく言われるじゃないですか僕全然進まないです僕もだからそれによって削られていくんじゃないかな優先で低いからつってまあ結局時間がないからとかっていうことになるんですかねまあそうねもしかしたらテスト書いたことによって時間が生まれるのかもしれないけどうん

それを実際に実感できないなぜならみんなテストを書く前に時間を奪われてるからっていう悪の循環そうですよねありえるなっていうここのブログ記事にも時間がないからテスト書けない人多いだろうみたいなことが書いてるんですけどそこに強い一言が書いててテストファーストでやるのが難しいまあいいよそれなら後からデバッグしなっていうのが

書いてましたね煽ってるね煽ってますねこれはだいぶ正直僕は単体テストが書かれてないことによって後からデバッグ大変になったなと思ったことはないですまだあんのかなまだあんま正直ないんですけどだからそんなにひどい行動運用というか個種というか公開した記憶がないからなのかもしれないですけどまあでも究極マジで好き勝手書けちゃうのでテストファーストじゃないと確かに

めちゃめちゃステートフルな関数書くやんみたいなグローバル変数こんな編集しまくるんだみたいな見たことないですよ見たことないんですけどそういうことできちゃうんで単体テストがかかないとっていうのもあって

書いてねっていう風に言ってるんだと思ってますなるほど本当に設計が良くなくなっちゃいますからねまあそうですねテスト書きやすいコードが良いコードっていうのもよく言われますからねでもそうなんですねひどい関数は本当になんかもう一個がスパゲッティだるまでコードのテストしようがないみたいなのがありますからね本当ですよねだけど最初からテストさえ書いておけば

その流度で書けるよねってことよねそうです分かってはいます実践にするだけですそこが難しいです

僕はたまたま最初のプロジェクトがテストマストのプロジェクトだったので癖づけようとしてて今プロジェクトとしてはマストじゃなくて努力目標なんですけど固くなにやってますね固くなにやってんだ仕事が若干遅れてまでも固くなにやってます素晴らしい

それじゃないですか強制ちょっと怒られるかな分かんないけど僕のやり方なんですいませんっていう感じですけどはい次これは抜粋しますがちょっと途中を飛ばして2つ目オブジェクト思考のコードを書きましょうこれじゅんぺいくんちゃんとやってると素晴らしいと思うんですけど僕は若干やりきれてないのでやんなきゃなと思いました取り上げられたのがソリッド原則ですね

よく聞くやつなんすかソリッドとボブおじさんのやつ簡単に紹介するとS

シングルレスポンシビリティですねシングルレスポンシビリティ単一責任の原則です難しいですねクラスは単一の責任を持つべきですとクラスは一つのことだけやりましょうってのが言いたいことですけど複数持っちゃったらちゃんと分けてちゃんと分けないと複雑なクラスになっちゃうからバグ生んじゃうよってのが一つ目これね難しいのはね一つのことをやるって何なんだろうっていうその流度が分かんない説があるんだよね

それは確かにむずそうだなこれはですね

クリーンアーキテクチャかなとかでも出てくるんですけどユースケース図を書くとね非常にねクリアになりますねあーなるほどそうやって整理すると確かに思考は変わるかもなでこの単一責任原則ってその一個のことをやるもそうだしその一個のクラスが一つの一人のアクターのためにあるべきみたいな感じなんですよはいはい

その一人のアクターのためになってるかどうかっていうのがユースケース図を書くとめっちゃわかりやすくなる

わーこれそれちょっと一つで話したいなそれ一つで話しましょうちょっとユースケース図の話をラジオに載せるかマジで分かんないですけどまあそうですね調べればこの図かってならないと思うんですけどこんな図があるんだってなると思います調べてみましょう次オープンクローズドの原則ですこれはどういうことかというとこれはクラス関連の話でクラスは拡張にはオープンで変更にはクローズドであるべきだと言ってみれば分かんないなって感じですけどどういうことかというと

クラスに変更を加える場合は既存の関数を変えるんじゃなくて新しく追加しましょうとそうすると本当に遠い将来というか今後その関数変更しようって変更した時に思いもやらぬところが被弾してしまうと本当にミノクドウさんの動画でよく見るやつですけどこういうのをなくすために

関数どんどん追加していくのが理想ですというところがオープンプロジェクトの原則ですねこれはですねヘッドファーストデザインパターンのデコレーターパターンの章に分かりやすい例がありますね楽しみにしてます次リスコフの置換原則ですこれ名前が厄介だね名前が厄介全く何で何というか分からないですけど

これはクラスって親子がいて親と子子クラスは親クラスと同じものを実行できるようにしましょうねっていうのがこれですなのでそうしないと子クラスと親クラスの機能が全然違うことになって一貫性が保てなくなってコードが複雑に煩雑になっちゃうよっていうので分かりやすく保っておきましょうっていうのがリースコフの知観原則です親クラスと子クラスを入れ替えても大丈夫にしましょう子クラスは親クラスと同じものを

実行できるように同じものを返すようにしましょうってやつですねインターフェース揃えろよってことね相応かな相応かな次インターフェース分離の原則ですねソリッドのiですねこれはクライアントが使用しないメソッドへの依存を強制すべきではないクラスが実行に必要なものだけ実行する必要があると無駄なことを動かすなと必要最低限に公開しろと

例えばですよこの関数とこの関数似てるなじゃあこれ一個まとめにしちゃおうみたいなことをすると呼び出さなくていいDBのセレクトとか入ってるけどこの結果後で捨てるからとりあえず取っとこうみたいなっていう風なものをやっていくと後々バグになったりするから必要最低限のものを呼び出せるようにインターフェースをちゃんと分けておきましょうねという

これむずいよねオブジェクト思考ってさ繰り返しの重複をなくすために作られたみたいなところあるじゃないですか繰り返しの重複インターフェース分離の原則によると似てるからって気軽にまとめちゃいけないよっていうことだよね

そうですねインターネットのときもそうですねここもオブジェクト思考のメリットを享受する部分と分けるべき部分のさじ加減がめっちゃむずいところな気がしますねそれちょっと思うんですよオブジェクト思考を勉強しててそれは別の話にしましょう簡単に紹介なんで最後DソリッドのD依存性逆転の法則ですねこれは上位モジュールは下位モジュールに依存しちゃダメよっていうお話ですん?うん

これあれだよねインターフェース挟んで依存の向き逆転させるよみたいなやつよねそうですそうですインターフェース導入して上位レベルのクラスが下位レベルのクラスに依存するのを減らすちょっと詳しくはこの回ではやらないんですけど気になったらお手入れくださいこれを詳しく知りたい人はロバートマーチンさんのアジャイル開発なんちゃらかんちゃらの奥義がいいらしいですよちょっと載せておきましょう簡単に言うとオブジェクト思考のコードをちゃんと書いてねっていうのがこの2つ目ですよ

ちょっと面白いのがこれググっても出なかったんですけどブログ記事でスティーピットっていうソリッド原則の対応なす概念みたいなそんなのあるスティーピットSがシングルトンTが忘れたみたいなマジかこれちょっと紹介しようと思ったんですけど調べなかったので諦めましたこれもブログ記事元記事に載っておくので気になる人飛んでみてください次3つ目コードのコピペすんなよっていう

話ですコードちゃんと勉強してる人はねドライ原則読んでね2カ所にコード書かないみたいな同じことやんないっていうのがありますけどただ善意でドライを追求するとやりすぎあとは複雑さたまたま複雑になっちゃうことに繋がりますとそこでウェットの法則ドライからのウェットドライからのウェットおしゃれなんだっけ

2回まではOKっていう法則ですね2回までOKなの?これは2回まで許容するっていうことを言ってましたねそうなんだ3回目で重複を排除するここから学ぶべきは本当にコピフェしてはならないですとコピフェってねフィットしてない場合が結構多いのであと見ててねちょっとストレス振る確かにそういうのやらないようにしましょうね

そうねコピペしてる自分がいたら設計に何かあるんじゃないかと思えとその通りラスト見たらわかるコードを書きましょうおーDWコードTypes, Names, and Commentsっていう見出しついてるんですけどマジで言ってる意味わからなかったですがTypes, Names, and Commentsっていう型、名前、それとコメント区切られてるんだはい

まあでも言いたいことはそういうことででまあこれもよく言われる話ですよねリーダブルなコードを書きましょうじゃあリーダブルなコードを書くにはどうしたらいいか一つ単一機能にしましょう関数はそうすると命名も迷いませんと名前つけやすくなるよネームズじゃんネームズああそういうこと命名じゃないうんであとはもう関数もギリギリまで抽出しましょううんあの抽出っていうのはうん

最初なんだろうな例えばじゃあユーザーを作るっていうふわっとした関数をボーンってやったらそっからじゃあDBに書き込むっていうやつが抽出されるじゃないですかちっちゃくみたいなイメージで抽出って言ってるんですけどそっからなんか関数から雫を落としていって雫を落としていって雫を落としていってちっちゃくしましょうみたいなそういうオシャレな書き方してましたねなるほどねあとは状態つけないとかちゃんと活かしてタイプスそう

パラメーターの形が違ったらちゃんとこのパラメーターの型が違うからこの型に入れてねっていう丁寧なエラー返しましょうとかあといろんな型を返す関数を作るとかなるほどねミックスドにすんなよとミックスドにすんなあとテストかけって書いてましたねテストかけ2回目繰り返し2回目お前はこれあのウェットの法則に載ってますねこのブログは本当だねウェット来たよ2回目はい

っていうのが以上技術的なアドバイスですねこれは結構めちゃバス行っちゃったんで気になる方は読んでほしいんですけどそうねむずいのが多いねでもむずいこれね超初心者じゃないなと思ったのが最後にジュニアエンジニアこれ読めっていうのがあったんですけどクリーンコードとか

あと本ね他日本語の本がなかったんでクリーンコードだけ紹介させていただくんですけどあと一個気になったのがアプレンティスシップパターンズアプレンティスシップパターンズね本が紹介されててこれちょっと日本語の本ないんですけどアプレンティスシップって意味わかります?アプレンティスシップでしょちょっと待って俺の言語能力から推測していい?アプレンティスなんかこう見せるみたいな

見習いって意味なんですけど僕も分かんなくて見習いのパターンっていう本気になりませんどういうこと?何書いてるのかなと思ってオライリーのURL飛んだらオライリー出てきました英語の本なんですけど初級者向けのもっといいエンジニアになるためにっていうのがいろいろ書いてる本で別にコードのパターンとかじゃなくても本当にいろんなの含めてる本当に

ソフトスキルからソフトウェアスキルまでって感じな気がしましたね仕事に疲れた時はどうやってモチベーションを持ったらいいかとかあとちょっとキラーワードだったのがもし学習に詰まった時はあなたが最下位になれるようなコミュニティを探して入れとか

なんかパワーある感じの本だなっていうのを見てましたね日本語訳出てほしいなちょっと気になるんですけどね日本語訳あるのはクリーンコードだけだったんですけどクリーンコードむずくないですかクリーンコードむずいむずいっすよねでも学びは多い学びは多いですね2,3年目に読んでほしいぐらいですけどとか書いてたんでねこれもちょっと気になってましたブログも紹介されてたんですよブログちょっと見れてないんですけどはいはい

新たなネタの宝庫かなと思ってはいるのでマジか気になるところがあったら紹介しようかなと思いますいいね海外の情報を発信していくポッドキャストとしてはいちょっとね読みやすいんでねあと英語勉強のモチベーションがあるんで確かにねさすがにね常に3位にあるからね2位だけなので技術的な方で言うとテストかけーとオブジェクト思考でコードかけーとうん

コピペすんなと見たら分かるやつ書けとなるほどねこれはアドバイス for junior developerらしいですねそうねよく言われてるけどそこをどうするかっていうのは実践難いですねこの番組でサポートしていきたいと思います悩んでたら言ってください僕らも本当に手探りやりながらでもなんとか実践しようと頑張ってるところであるので本当それだよねっていうのが以上ですうん

たまになりますアフタートークいいですかはいあのーまず僕無事30歳になっておーおめでとうございますありがとうございますではいまあ30になっても意外に子供だなって思ってるんですけどほうはいまあただ今までこの30年でうん俺がなりたかった30歳とのギャップなんだって思った時にほううんうーんって考えてうんやっぱ英語だわと英語なんだ英語だな英語なんだあのーなんでしょう

将来もし子供を持った時に子供には1回海外旅行で楽しいっていう経験をさせたいと思ってるんですよそうすると今後Google翻訳とか優秀になるかもしれないですけど結局その英語の本とか別に読んだ方がいいと思うし海外の人と話す機会ってあった方がいいと思うんですよ日本人よりも面白い人いる確率増えるじゃないですか多分間違いない80倍?そうそう母数増えるからねだから

英語を勉強するっていうモチベーションを持ってほしいなと思い英語を勉強するモチベーションを持たせるにはどうしたらいいか海外旅行で楽しい経験をするしかないという結論に至ってるわけなんですよただ今俺が海外に連れて行ったとして俺はわたわたするとお父さんかっこ悪いとか嫌な経験されるのも嫌だなと思うので英会話したいっていうわけでもないんですけどギリギリ喋れればなんでもいいんでおー

もうちょっと英語やろうかなというところでちょっと英語記事を読むモチベーションが若干上がってますいいですねなんか1ヶ月ぐらい休み取って語学留学とか行けないんですかあーおもろいましたよフィリピンにマジっすかおもろいなそれ確かにその手間1ヶ月じゃないか2,3週間休みもらえたからみたいな感じではい

なんかフィリピンに語学留学で来てる40歳ぐらいの人がいましたねうわチャレンジャーチャレンジャーチャレンジャーですねうんいいそんな大人になった人はなりたいのでそんな大人になろうと思います実際に身を置いた方が多分はかどりますよいや絶対そうですよねうんいやマジでそう思いますそれははいはいっていうあの言ったら叶うだろうと思ってとりあえず言ってみました引き寄せの力だ引き寄せの力はい法則かはいうん

今後技術書とかもねマジで英語の本予約してね喋れると最高にいいんですけどねわかるだって読めないじゃんみんないや俺も読めないけど一応さオーディブルでオライリーとかの本が英語版ならあるんですよいややばすぎマジで1ミリもわからんリスニングがやばすぎるトイックの問題はいけるけど技術書はマジで無理文字でもきついのにですよねリスニングかみたいな知らん単語いっぱい

ありそうだし日本語と発音が違う単語もめっちゃあるだろうから聞き取れなさそうだなとりあえず日本語で読んだことある本を聞いてみたりしてますね本当にあれですね英語の勉強するためにディズニー映画見るみたいなノリですねオライリークみたいなめちゃめちゃ真面目だけどというので楽しく英語学べる方法があったら教えてくださいお願いします英語得意なリスナーの皆さん以上で終わりますまた次回バイ

ひまじんプログラマーではあなたのフィードバックを募集していますちょっとやりとりしたい人はメール気軽に送りたい人はGoogleフォームツイートお願いします詳細は説明欄を見てくださいポッドキャストのフォローコメント評価してくれるとバカ騒ぎしますそれではまた次回