開発者のためのディープラーニング
kok202
実習よりも理論と文脈に集中し、ディープラーニングを深く整理して大きな絵を掴みたい方に役立つ講義です。ディープラーニングの根幹となる数学・統計的背景を分かりやすく理解でき、現代ディープラーニングの主要モデルであるAutoEncoder、GAN、Transformer、AlphaGoなどの原理を開発者の観点から直感的に解釈いたします。
중급이상
Machine Learning(ML), Deep Learning(DL), Statistics
Spring にテストを追加する方法を説明します。さらに、より自然なテストを行うために Spring の設計を変更する方法も学びます。

Spring にテストを追加する方法
テストに必要な概念
自然なテストを行う方法
Mockito なしでテストする方法
依存性とテスト可能性
ヘキサゴナル アーキテクチャ (Hexagonal Architecture) と設計
プロジェクト設計を進める
テストの本質をわかります!
テストに対する正しい意見を伝えるためには、結局アーキテクチャで終わらなければならないという考えをしたからです。
テストの基本的な概念を学び、Spring(スプリング)にテストを入れる方法を学びます。さらに、自然なテストができるようにスプリング設計を変更する方法を学びます。
テスト
必要な理由
テストについて
基本概念
Springへ
テストを入れる
方法
Springデザイン
進化させる
方法
クリーン
アーキテクチャ
ヘキサゴナル
アーキテクチャ
他の会社に通う友人は、時代のニーズに合わせてテストを着実に入れていきます。ところで、当社はテストを入れていません。遅れたくありません。勉強する意志もあります。ところで、とにかくこのレガシーシステムにテストコードをどのように入れなければならないか感がありません。
H2を使ったテストは遅すぎてDBに依存しすぎます。すべてのテストがH2を使用しています。テストを回すのは負担になり、テストがh2を共有しているので、データが混乱しているときはテストが成功し、またあるときは失敗します。
私たちのチームは、人がそれほど多くもなく、配布しながらもあまり不安を感じたことがありません。要件は時々変わります。しかし、TDDをどのようにしますか?テストは開発速度だけ遅れるだけだと思います。
市中に出ているテスト関連の本やセミナーを探してみると、ほとんどそのままテストの利点、テストコードの作り方、JUnit、Mockito程度だけ話して終わります。例はちょうど入門者の好みに合うほど簡単な例だけです。だから最後に行って本を覆う時はこんな気がします。
混乱しました。 H2を使ったJPAテスト...まあいいです。しかし、ElasticSearchやCassandraのようにテスト用のDBがない場合は、どのようにテストするのですか?さらに、H2を使ったテストは本当に致命的なほど遅かった。一日にも何度も回す負担でした。テストは頻繁に壊れてDBテーブルでも変更される日には関連するテストも芽生えて修正しなければならないので時間の無駄のようだと思います。
その間、私の悩みは、アーキテクチャとDDDの勉強を始めながら、すべて解決されます。知っています。 TDDは常にホットです。ところで、TDDは本当に魅力的でありながらも難しい方法論です。 TDDをやったことのない組織でTDDが流行っているので、これからTDDとして開発しようとすればそれになるのでしょうか? TDDは、思ったより始める前に知っておくべき選手の知識と共感を必要とします。
したがって、TDDを勉強するには、TDDから勉強しないでください。テストを最初に勉強する必要があります。微積分をするには、方程式から扱うと知っておく必要があるようです。
テストの必要性が感じられない場合は、まだプロジェクトの規模がそれほど大きくないか、テストがなくても十分な開発能力と文化を備えているようです。テストは正解ではありません!テストがなかった時代にも素晴らしいプロジェクトがたくさん開発されました。テストは良いソフトウェアを得るためのツールなので、それ自体が目標ではありません。
テストをする方法だけに重すぎて勉強していたようです。 JUnitの使い方、Mockitoの使い方、h2を連動する方法を勉強することは明らかに意味のある勉強ですが、それがテストの本質ではありません。なぜテストをしなければならず、どのような目標があり、その目標を達成するためにどのように実践するべきかを学ぶ必要があります
テストフレームワークに関する質問も以前の質問と同じ答えです。もしあなたがTypescript + Nest.jsを書く環境にいるなら、どうやってテストしますか? Mockito、H2などのテストフレームワークなしでテストする方法を学ぶ必要があります。
この原理に基づいた知識は、他のフレームワークでも一般的な知識です。 Nest.jsを使っていた、Swing UIを使っていた、Ginを使っていた…どこでも適用できる知識だと思います。
終章に行くと、設計に関する講義につながります。テストの価値を最大限に説明していただくためには設計についての内容が抜けてはいけないと考えたからです。
少なくとも私がブラウズ論国内のスプリングにテストを入れる方法を教えてくれる本や講義は見られないようです。すべて@Mock 、 @Spyこれらのアノテーションを利用してmockingと依存性注入を受けてテストを作成します。しかし、もしこのようなMockライブラリが存在しない環境なら、どのようにテストするのでしょうか?本質的に、これらのアノテーションがなくてもテストする方法を知る必要があります!そして、テストすべき対象が何であるかを区別できる必要があります。
テストの必要性がわかります。
フレームワークなしでスプリングにテストを入れる方法がわかります。
スプリングを使用するより良い方法がわかります。
レイヤードアーキテクチャからヘキサゴナルアーキテクチャへの移行方法を理解します。
オリエンテーション
テストを追加したい組織でTDDを導入するときに失敗する理由を見てください。一般的に、私がしているTDDはなぜ失敗するのかを見ています。テストを正しく理解することなく、テストをランダムに挿入し始めたときに発生する問題をまとめます。
テストの理論
基本的なテスト知識を勉強します。テストの必要性を共感し、テストと設計の相関関係を特定します。テストを作成しながら、開発者はどのような悩みをすべきかを理解します。最後に、自然なテストのためにTestabilityを向上させることについて説明します。
パート1 - トイプロジェクトベースのテストを適用
今後使用するトイプロジェクトを見てみましょう。そして、トイプロジェクトにうんざりしてテストを入れて、できるだけテストを入れてカバレッジ100%を達成してみます。このプロセスでは、h2、MockMvc、PowerMockなどの外部ライブラリを使用します。
最終的に作成されたテストを一緒に見て、回帰のバグだけをカバーするためのテストにはどのような問題があるかを見てください。
方向性ナビゲーション
私たちのトイプロジェクトにテストを入れたのがあまり良い方向ではない理由を一緒に見てみましょう。さらに、従来のレイヤードアーキテクチャの問題点についてまとめてみましょう。そしてどのように改善するか、講演者の意見を聞きます。
1部実機で無作為テストを入れるために苦労していたら、2部ではMockitoのような外部ライブラリなしで自然にMockする方法を身につけます。パート2の実践のために、事前にどのようにコードを変更するのかを見てみましょう。
パート2 - トイプロジェクト構造設計の改善
先進の方向性ナビゲーションを通じて得られたインサイトを当社のトイプロジェクトに導入します。この過程で構造的な変化を与え、設計を改善します。そしてこの過程で以下のような技法が使われます。
進化するアーキテクチャ
テストと設計の相関関係を介してアーキテクチャを進化させる方法について説明します。レイヤードアーキテクチャがヘキサゴナルアーキテクチャにどのように変わるかを見てください。関心を分離しながら、開発者がドメインに集中する方法を学びます。
現在カカオで働いていて、作るのが好きなので、退勤後も常に何かを開発しています。 「巨人の肩の上に立った小人」という言葉があります。私もやはり小さな小人だけですが、上がった巨人の成長に役立つように知識の対峙に努めています。多くのジュニア開発者の方々を指導した経験があり、皆様の成長をお手伝いできます。
Q. JUnitやMockitoの使い方は教えていただけませんか?
はい。理由は以下の通りです。
コンテキスト) 受講生の個人ごとにとどまる状況が異なります。すでに数回テストをした人がいる場合は、ライブラリを扱う熟練度が異なる場合があります。会社で使用しているライブラリがJUnitやMockitoではないかもしれない。バージョンが異なるため、提供しないインターフェイスが存在する可能性があります。代表的な例として、JUnit4は@ParameterizedTestをサポートしていません。さらに、前述のライブラリの使い方はそれほど難しくなく、関連する良い資料がすでに多すぎます。とにかく、Github READMEファイルを読んだり、公式ガイドを読んだりするだけで十分な使い方を学ぶことができると思います。したがって、使用法は重要な内容ではないと思いました。
テストデザイン) 特定のライブラリが提供する特定の機能を使ってテストする方法を学ぶことは、そのライブラリがなければそのテストを行うことができないということです。ツールやフレームワークよりテストをどのように設計し、どのようにテスト可能な構造に変えるかがより重要です。したがって、この講義はツールに集中しません。テストは開発プロセスの一部です。したがって、要件の分析、設計、配置、メンテナンスなどの文脈で考慮すべき点を確認することがより重要であると考えました。
Q. 以前の講義との違いは何がありますか?
カリキュラムを見ればわかりますが、以前の講義と重複する内容が多少あります。こうする必要があるということだけを説明するには説得力も不足して文脈を理解させてくれないので、独立して該当講義も受講できるよう講義を構成しました。だから必ず目次を確認してみて、重なる内容があるか確認してみてください。
率直な話で以前の講義をしっかり理解していたら、あえて重複して受講する必要はないと思います。以前のレッスンが構造的になぜこれを行うべきかを説明するレッスンであれば、今回のレッスンは実際にコードレベルでどのように解かれるかを扱うレッスンと見なすことができます。
Q. 受講前に知っておくべきことはありますか?
この講義は、スプリングやJPAを教えてくれる講義ではありません。受講者がおおよそのSpringとJPAに対処できることを前提に講義を行います。また、スプリングにテストを入れる方法をお知らせしていますが、本質的には依存性をどのように解放するかについて焦点を当てて進んでおり、必ずしも言語やフレームワークにこだわる内容ではないと思います。なお、専攻知識は必要ありません :)
💾受講前に確認してください!
学習対象は
誰でしょう?
Springにテストを入れたい方
Spring にテストをどのように入れるべきか分からない方
私が開発したSpringプロジェクトが正しい設計構造であるか混乱している人
テストを入れてみたけど失敗した方
H2のようなテストDBがないNoSQLにテストを入れたい方
前提知識、
必要でしょうか?
Java コードを理解できる方
Spring の基本 (Controller / Service / Repository について知っている方)
JPA を使用したことがある人
3,612
受講生
270
受講レビュー
47
回答
4.9
講座評価
3
講座
현재 카카오에서 일하고 있고, 만드는 것을 좋아해서, 퇴근 후에도 항상 무언가를 개발하고 있습니다.
"거인의 어깨 위에 선 난쟁이"라는 말이 있습니다. 저 역시 한낱 작은 난쟁이일 뿐이지만, 올라탄 거인의 성장에 도움이 될 수 있도록 지식의 대물림을 위해 노력하고 있습니다. 다수의 주니어 개발자분들을 멘토링 한 경험이 있어서 여러분의 성장을 도와줄 수 있을 거예요.
깃허브 > https://github.com/kok202
블로그 > https://kok202.tistory.com
全体
25件 ∙ (6時間 20分)
講座資料(こうぎしりょう):
3. テストの概要と開発者がすべき悩み
10:05
4. テストの必要性とテストの3分類
10:42
5. テストに必要な概念
09:13
6. 依存性とテスト性(1)
06:10
7. 依存性とテスト性(2)
10:35
8. 実技前の事前探索
13:00
全体
187件
4.9
187件の受講レビュー
受講レビュー 2
∙
平均評価 3.0
5
私がインフラで決済したすべての講義をまとめて最高の講義だと断言する。 本からコピーせずに頭を掴んで作ったオリジナルカリキュラム構成、講義ごとにギュッと詰まっている卵爺たち、御影浮栄横説手説なし、すっきりしたコメントと文章、適切なスピードと明確な発火、テストという具現化された実践方法を通じて設計という大きな絵をそして、再設計という土台の下でテストを引き出す。悩み、繰り返し、改善し、開発をしてきたのか見えなくても見える。 インフラで講義した二つ聞いたわけではないが、この講義ほどA/Sをスタイリッシュにしたことも見られなかった。何かを見せたいという欲求も強いだろうが、そのような部分は加減なくスタイリッシュに修正しておいた。 講師様が間違いや「言ったら良かったのに」という部分では画面が灰色に変わりながら音声だけ出てくる区間がある。講師様もいただいたりもしたり、とにかくこんなA/S映像もまるで編まれた脚本のように教育ツールで見事に役割を果たしておいた。 テストを買ったのに設計が付いてきた。 しかし、その設計はテストよりも高価でした。 こんなクレイジーな立派な講義に受講坪54個だけなのを見てきて受講坪初めて使ってみるww 内容、声、オーディオ、映像、分量。 +9,999人になっているネームド講義よりキム・ウグン講師の講義がはるかによかった。
おお…
受講レビュー 5
∙
平均評価 5.0
5
この講義は単なるテスト講義ではありません。 私はテストを作成するためのJUnit、Mockitoなどの使い方を学んで適用しています。 それから、単にテストツールを使用する方法を超えて、良いテストコード、よく作られたテストコードについて疑問があり、このレッスンを見つけました。 講師様の1編講義を楽しく見たので基本的に信頼度が高く、目次の内容も興味深く見えました。 講義をすべて受講し、後期を残します。この講義は単なるテスト講義ではなく、 良いアーキテクチャとOOPについて心配するのに役立つ非常に素晴らしい講義です。 テストをする目的が単純な回帰防止だった私にとって、 テストと設計は相補的な関係であり、既存のレイヤードアーキテクチャの問題と、 レイヤードアーキテクチャで作成するテストの制限点を教えてください。 自然に良いデザインに悩んでくれました。 問題点を理論だけにしてくれるのではなく、コードをリファクタリングする過程を通じて、より良い構造とテストコードの記述を提示します。 先日、Mockitoを初めて学び、Stubbingを使ったテストに感心していた私に、 Mocktioが必要としたテストを外部ライブラリなしで純粋なJavaでテストする素晴らしい経験を与えました。 結局、すべてはOOPという1本の言葉がそのまま続く良い講義です。 それ以外にも、テストに必要な概念と講師の個人的な悩みが込められた意見を話していただくのも良かったです。開発分野に対する誠実さと態度を間接的に感じることができ、たくさん学びました。 良い講義ありがとうございます。
受講レビュー 48
∙
平均評価 5.0
受講レビュー 4
∙
平均評価 5.0
5
最後に、スプリングを勉強し、テストを書くためのコードを見ると、何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何かを見ていました。 それで、なぜこのような反復的なテストを書くのか疑問に思いました。最後に、インフラストラクチャで新しい講義で、なぜSpring Test Developerが書くのに失敗するのかという新しいレッスンを見ました。 ちょうど私のための講義だ!して大胆に決済をしました。 頑強をした後、やはり後悔のない選択をしたようです。 10分講義を一時停止を押して一つ一つ講師様が話している部分が何なのかクマが考えたようです。それで、講義時間は6時間ですが、60時間ほどのクオリティがあると感じました。 ソフトウェア工学について視野を広げてくれた講師に感謝します。
受講レビュー 6
∙
平均評価 4.3
期間限定セール、あと8日日で終了
¥41,580
30%
¥7,494
知識共有者の他の講座を見てみましょう!
同じ分野の他の講座を見てみましょう!