【今日学んだこと】未経験からエンジニアで転職「3週間目その3」
今日やったこと
できなかったこと
明日やること
今週やること
買ったJavaの本を進めるdoneもう1冊ポチったのでその本も進めるdone- javaでの開発の流れを調べる
- Javaでできてるサービス探してみてみる
- 必要な機能、要素を書き出す
- Eclipseの設定いじる、デフォルト少しみづらい
来週やること
めも
あとでJUnit触ってみる
JUnitをmacのEclipseで使う方法 - Qiita
EclipseでJUnitを使う方法（JUnit）：技術空間
Java Silverとは？ 試験の概要から必要となる知識まで解説！ | TechAcademyマガジン
やってみる Java Silver 練習問題１ | TECH Projin
・
【2019年最新】Javaの資格試験の種類と出題内容を知ろう！
【2019年最新】Javaの資格試験の種類と出題内容を知ろう！
Javaでできてるサービス ・楽天 ・Evernote ・Jira ・Minecraft、マイクラ！
・Javaって私より年下だった ・C言語をモチーフとした高級言語で、高度なオブジェクト指向の言語 ・OSに依存しない
いまさら聞けないRESTの基礎知識、JAX-RSを使ったREST APIの作り方と使い方 (1/3)：3つのフレームワークで学ぶエンタープライズJava開発入門（3） - ＠IT
Java Servlet（サーブレット）とは？超初心者向けに優しく解説 | 侍エンジニア塾ブログ（Samurai Blog） - プログラミング入門者向けサイト
基礎から理解しよう！サーブレット（Servlet）/JSPとは | TechAcademyマガジン
「Apache Tomcat」Java Servletを動かすソフト https://wa3.i-3-i.info/word12843.html
【社内勉強会】ApacheとTomcat(2017/03/09) - Qiita
Javaサーバーサイド環境構築(Mac版) Tomcatの設定 | ITエンジニア"が作るメディア Tech Fun Magazine
Javaのこと
【スッキリわかるJava入門実践編 第2版】
14章、単体テストとアサーション
・テストや納品に関する2つの原則 →1文字でも少ない稼働コードが理想、本番稼働に不要なものは、本番稼働用のクラスの中に含めるべきではない →1文字でも修正したら再検証、
・良いテストケース →全ての可能性の範囲をカバーできているもの。やろうと思えばいくらでも出てくるけど、時間が無限にないと無理。これに似ている場合は確認してないけど多分大丈夫、な感じでカバーする
・テストケースを作るのに困ったら →正常系（正常に動作することを確認する）と異常系（想定される異常な利用時に、きちんとエラー処理がなされるかを確認する）というテストケースの分類を使う。
・優れたテストケースを見つけるための方法論 →同値分割（equivalence partitioning） →境界値分析（boundary value analysis）
・JUnit：Java用のテスティングフレームワーク、オープンソース
・JUnitテストクラスの書き方のルール
→おきまりのimport文を記述
import org.junit.Test; import static org.junit.Assert.*;
→テストクラスの中に複数のテストメソッド。1つのテストメソッドで、1つのことを確認する
→mainメソッドは記述しない
→テストメソッドには「@Test」のアノテーションを記述する。つけ忘れると、そのメソッドがテストメソッドであると認識されない
→値の確認には専用のメソッドを使う、返される値が正しいものか？など。想定した値ではない場合AssertionErrorを発生させる
・テストの実行 →テストクラスはmainメソッドを持ってない→JUnitが内臓しているテスト実行プログラム「JUnitCore」をりゆしてテストする →JVMが見つけられるよう、「JUnitのJARファイル」「テストクラス」「稼働クラス」3つの全てにクラスパスが通っていないといけない
・テストスイート（Test Suite）：テストクラスの数がかなり多くなった場合の仕組み
・アサーション：簡易なテストケースを稼働コードのソースコード内に直接記述できる仕組み
構文1 assert 評価式 構文2 assert 評価式:エラーメッセージ;
・アサーションの注意点 →アサーションのOFF時に問題になるコートを書かない、本来の動作ロジックに影響を与える式をassert文で利用すべきでない →単体テストに代わるものではない
15章、メトリクスとリファクタリング
・品質について安心するために必要なこと →プログラムやクラスの使われ方には全部でどれだけのパターンがあって、テストで試したのはそのうち何パターンか？（カバー率）数値として見える化する
・メトリクス：開発に関する把握しにくい様々な事柄を数値指標として見える化したもの
・テストカバレッジ（網羅率）：テストによるカバー率
・コートカバレッジ：命令網羅率、分岐網羅率
・Cobertura：コードカバレッジを計測してくれるツールの一つ
・プロジェクトにおけるメトリクス基準の例 →命令網羅は100%、分岐網羅は90%を達成すること →テストケース数は、テスト対象クラスの行数の1/5以上であること
・LOC（Lines of Code）：プログラムの行数のこと、規模を大まかに捉えるための道具
・CC（Cyclomatic Complexity）：マッケーブの循環的複雑度とも呼ぶ、ある特定のメソッドの中身がどれだけ複雑かを表す1以上の数値、大きいほど複雑であることを示す
・WMC（Weighted Method Per Class）：あるクラスに含まれる全メソッドのCCを合計した値であり、クラスの複雑度をします
・リファクタリング：コードを見直して改善すること、外部から見た動作仕様は変えずに、内部構造を改善すること →重複部分を1箇所にまとめる →メソッドやクラスを分割する →外部ライブラリや新しいJavaのバージョンの文法を利用する →コメントなどを適正に付ける
・リグレッションテスト：何らかの修正作業を行なった後に、再度同じテストを行うこと、リファクタリング後すぐリグレッションテストを行う
・リファクタリングの注意点 →納期直前はリファクタリングのメリットが得られにくい →むやみにやらない、やりすぎない
・静的コード解析：ソースコードの中身を解析して問題がある箇所をあぶり出したり、評価材料となる情報を集めること、ツールを用いて行われることが多い →FindBugs、オープンソース、クラスファイルを解析してくれるツール →checkstyle、オープンソース、コーディングスタイルに関するルール違反を検出するためのツール
16章、コードとタスクの共有
・コンフリクトの解決方法 →強制的にコミット（自分を優先） →アップデート＆再編集（相手を優先） →マージ（自分と相手の修正を混ぜる）
・コンフリクトを防ぐ方法 →ファイルの分担を決める、声をかける →他の開発者が編集できなくする（ロック） →頻繁なアップデートとコミット
・バグ追跡システム（BTS：Bug Tracking System） →不具合や作業項目の共有を行う、Bugzilla、Trac、Redmineなど
17章、アジャイルな開発
・UML（Unified Modeling Language）：モデリング言語（設計図の書き方のルール） →クラス図やシーケンス図など
・ウォーターフォール型：前行程の成果物に誤りが含まれていないことを前提とする →前行程が完璧という前提が崩れると大きな手戻りが発生する
・スパイラル型：最初から完璧なものを作ろうとせず、ある一部についてのみ要件定義、設計、実装、テストを進め、完成した時点で依頼主に見せてフィードバックをもらう、こまめに確認を取りながら軌道修正ができる →安易な作業の後回しや、顧客の要求が過度に膨らむというデメリットも
・アジャイル開発：人とコードと変化への対応を重視する価値観に基づき、機敏に反復を繰り返す開発手法
・XP(Extreme Programming)：5つの価値を定めている →シンプルさ →コミュニケーション →フィードバック →相互尊重 →勇気
・ペアプログラミング：2人の開発者がペアになって1つのコードの開発を進める メリット →常にコードを他人に見られるため品質向上を意識しやすい →コードに対して客観的な立場から即時にフィードバックが得られる →コーディングを通じて、相手の持つ知識やテクニックを学べる
スクラムとか詳しいところは改めて帰ってくる
・ビルドの自動化：コンパイルやテストなどの一連の開発作業（ビルド）を1回のコマンド実行で自動的に行えるようなしくみを準備すること
コマンドを連続して実行する機能を使う：コマンドプロンプトで入力する一連のコマンドをテキストエディタで書いて、1会のコマンド実行でビルドが完了する →バッチファイル（windows） →シェルスクリプト（Linux、MacOS）
ビルドエージェント：常時（定期的に）リポジトリを監視しているプログラムで、レポジトリに変化があった場合に自動的にビルドを試みる →Jenkinsなど
4部、18章、設計の原則とデザインパターン
・優れた設計原則、6つ コード記述全般について DRY：同じことを何度もやらない PIE：意図や意味がわかりやすい記述
クラス設計について SRP：クラスの役割は1つだけ（単一責任原則） OCP：修正なしで拡張可能で（開放閉鎖原則）
クラス間の関係について SDP：安定なものに依存する ADP：環境依存、相互依存を避ける
デザインパターン：設計原則やノウハウを取り入れたプログラミングに利用する設計の定石やお手本のこと メリット→開発者間のコミュニケーションが円滑になる、オブジェクト指向や設計原則の理解が深まる
・GoFパターン ・lterator ・Facade ・Singleto(1回しかnewできなくする) ・Strategy ・TemplateMethod
4部、19章、スレッドによる並列処理
・Java実行の大原則 →JVMは、命令を1つずつ順番に実行する、ある命令を完全に実行し終えてから次の命令を実行する
？？ってなったところ
【スッキリわかるJava入門 第3版】
・P209~
・JDKがつまりどれのことなのかわかってない
・javac
・6章だいたいわかってない
8章 ・インスタンスを型に入れて名前つけて作ると、たくさん作れば作るほど名前は増えるってことなら、ポケモンとかってなんて名前がついてるんだろう
11章以降は飛ばし気味、また戻ってくる ・インタフェースがビミョい
staticの付け所
15章、16章は使う時にまた戻ってきて確認する。時間のところあたりとか
16章もめっちゃさらっと流し見
17章はなんとなくわかるけどちゃんと戻ってくる
18章 ・UI、GUIあたり、書いてみたけどいまいち動かない、importができなかった
【スッキリわかるJava入門実践編 第2版】
5章 ジェネリクス？
紹介ばっかりで面白くない、使いたいときに辞書として戻ってこよ
6章 ・Stream API
11章は改めてちゃんと読む
18章、19章 あたりはまた戻ってくる
