(余裕がある時に分類整理します。)
目次（書きかけ）
-
- オブジェクト指向言語
- 関数の戻り値以外で、値を返す方法
- 「オブジェクト指向言語」「クラスの継承」項目は、Java,kotlinの実装で共通で使えるモノ、考え方に移植
- 「kotlin」項目は、kotlinについての個人的メモに移植
- └実装、レビューで気を付けること
🔍：調べる事
設計
UML
ステートマシン図
ここのメモを書いた経緯
UMLの公式レファレンスには、ステートマシン図での例外処理の表し方は特に記載が無い。
しかし、例外処理の考慮が必要なため、例外処理をステートマシン図中に表したい時が実際にあった。
そんな中で、私が唯一見つけたステートマシン図で例外処理の記載方法が書かれていたのが、「図解即戦力 UMLのしくみと実装がこれ1冊でしっかりわかる教科書」だった。
- 遷移の関連線の書き方
- 遷移の関連線の使い方
- 例外処理による遷移
- ギザギザの線で表記する
- 例外処理による遷移
参考書
- 図解即戦力 UMLのしくみと実装がこれ1冊でしっかりわかる教科書
- 2022年6月25日紙版発売 出版社：技術評論社 著者：株式会社フルネス 尾崎惇史（おざき あつし） ページ：126-127
- UML公式レファレンス
- 公式サイト：https://www.omg.org/spec/UML/
- UML/2.5.1/PDF：chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://www.omg.org/spec/UML/2.5.1/PDF
環境構築、設定
- 設定とかを弄る時は、必ず元の状態のバックアップを取ってから弄るようにする。
- 設定ファイル
→弄る前のファイルのコピーを取っておく - コマンドで変える
→元の状態のダンプやキャプチャをとっておく
(戻し方が分からなくなっても、最終的なゴール(この設定にればいい)が分かるようにするため)
- 設定ファイル
- ライブラリとかが非推奨であっても絶対ダメというわけではない
厳密さはそこまで求めないから、とりあえずで簡単にこの機能が使いたい！！という場合であれば、あえて非推奨になっている今まで使ったことがあるライブラリを使うというのも一つの手段 - 仮想環境とかを作った際に、tmp直下に色々と置くのはやめた方がいい（散らかるので）
- 消してはいけないデータやファイルなどは、適切な場所に配置する
→一時フォルダの中に入れてしまうと、あくまで「一時的なファイル置き場」であるため、消されてしまうことが考えられる- 一時ファイルに使われるファイル名の一つに 「tmp」 がある
-
https://wa3.i-3-i.info/word13640.html
-
「tmp」は多分「temporary（テンポラリ）」の略です。
「temporary（テンポラリ）」の意味は「一時の」とか「一時的な」とか「仮の」とかです。
-
vagrant、VM
- vagrant fileは、さくらエディタで開きっぱなしでVMの起動シャットダウンをしてもok!!
(閉じたり開いたりを繰り返さない方がいい)
設計？実装？にて
- URIは、ソースコード上に埋め込む（直書きする）のではなく別ファイル（設定ファイル系？）で、管理する
設計
画面設計
- 入力欄は、
数値：右寄せ
それ以外：左寄せ
にするのが一般的
↑Excelが参考になるよ
結合試験
- 画面にこのシナリオで操作をしたら、どうなりますか？を確認する
(このパターンで入力したら、画面の動きはどうなりますか？的なの) - 第三者から見た時に、分かる内容になっているか？
- その手順でできるか？
- テストをするための前提条件の状態にするために、必要な条件はないか？
- ↑「これ、試験できなくね？」っていうパターンが無いか？(あった場合は、備考欄にできない理由を書いてドロップアウト)
- 結合試験=
- シナリオ(動かした時の一連の流れ)が上手くいくかを確認する
- 全体の流れ。機能として見た時にこの流れあるよねっていうのを確認する
- パーツ毎ではなく、シナリオのパターンごとにどういった意図したことができるのか？
webアプリ
Cookieの確認箇所
ブラウザの開発者ツール
- アプリケーションタブ：ブラウザが覚えているCookieの情報が確認できる
- ネットワークタブ：ブラウザの通信が見れる
そのため、cookieが送信されたり、リクエストヘッダやレスポンスヘッダでset-Cookieされているかが確認できる
実装
オブジェクト指向言語
用語
- オーバーロード
- 仮引数の個数か型が異なれば、同じ名前のメソッドを複数定義できること
ただし、引数が同じで、戻り値の型だけが異なるものは定義できない
- 仮引数の個数か型が異なれば、同じ名前のメソッドを複数定義できること
- シグネチャ（signature）
- 以下のようなメソッド宣言の「
save(int hoge, int huga)」の部分 - メソッド宣言に記述するメソッド名や引数の個数や型とその並び順の情報のことをメソッドのシグネチャと呼ぶ
- 戻り値の型は含まれない
- オーバーロードは、シグネチャが重複しない場合のみ許される
- 以下のようなメソッド宣言の「
public static int save(int hoge, int huga) { // 以下略
シグネチャ（signature）の日本語訳
著名、サイン、著名すること、（調子、拍子）、記号
エラー
-
よく出るエラーの場合
↓
なんとなく原因の予想が付く
↓
まず、そこを確認しに行く
↓
で、そこがエラーの原因ではなかったら、ログの中身を詳しく見てみる -
🔍syslog とは、他のlogとの違い
バグが起きた時
デバッグできるソースコードが手元にあって、落ちる範囲をなんとなく特定できた場合
try-catchで囲んでエラーバンドリングしてログでも出せば、何が理由で落ちているのかが分かるかも！！！
（↑私個人、この方法でエラー理由を特定した実績あり）
log
logger
loggerを見れば以下のことが分かる
- logの吐き出し場所
- logのフォーマット
- logのファイルのローテートの仕方
- よくあるのが、ファイルのメモリがこれくらいいったら、ファイル名の後ろに日付を付けて保存していき、日付を跨いだらファイルを新しくする
logの実装方法
関数の戻り値以外で、値を返す方法
- try-chtchで捕まえて、throwする
- 別ファイルとかに出力して、出力したものを、別なやつで読み込む
UnitTest
- テスト対象関数のI/Oのみをチェックする
- 正直中のロジックはどうでもいい
- 「〇〇の処理を通ることを確認して・・・」「この時は〇〇の処理が呼ばれないことを確認して・・・」とか、中のロジックに依存するテストを書いてしまうと、バージョンが変わってライブラリの仕様が多少変わった場合テストが壊れてしまう
- 関数のI/Oだけをチェックするテストを作ると、I/Oはそのままで中のロジックが多少変わった場合でもテストが壊れない = 堅牢なテストになる
JavaScript
ファイル名
- 小文字のケバブで統一するのが無難
- ファイル名に大文字を混ぜると、OSによって挙動が変わることがある。
- gitでも大文字、小文字の区別をする設定があるが、知らないと結構ハマる
定数名
- 具体的な数値や文字列を表す定数
→大文字と「_」(アンダースコア)を組み合わせた名前を付けるのが一般的
こうすることで、コード内で見つけやすくなり、値を変えてはいけないことが一目でわかる
参考文献
Ethan Brown. 初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発（武舎 広幸・武舎 るみ訳）. 株式会社オライリー・ジャパン, 2017, p.26.
実装、レビューで気を付けること
- List形式のデータを扱う機能に触れる場合は、並び順に注意する
- 表示するときに並び順があるデータは、表示結果がどこのデータと合っている必要があるのかを抑えて、表示結果が合っているかを確認する
- データを画面に表示させるようなものは、複数回操作を試してみて操作をする毎に結果が変わるかどうかも確認を行う
Markdown
- ローカル環境でMarkdownの編集がしたい場合、VScodeで編集すれば、プレビューができる(VScodeの機能で、Markdownのプレビューが可能)
フレームワーク
- 枠組
- 仕組みそのものを提供する(←ライブラリは「機能だけ」を提供する)
- 簡単に高速な処理を実現できるように提供されるソフトウェア
- Spring Bootは、SpringMVCを元にできた
作業
- （あまり良くはないけど）もし時間に余裕が無かった場合は、最悪UnitTestはチケット化してテスターさんにフルリグレッションテストをしてもらっている間にやるってのも1つの手段
- この時、UnitTestがコンパイルエラーとかで走らなくなる場合もあるので、FIXMEコメントを付けて、@Ignoreアノテーションを付けてテストヲスキップするようにしておく
教訓
- GithubActionsで設定しているCIのエラーは、ブラウザで文字列検索とかもできなくて凄い見づらい。
しかし、上から虱潰しに根気強く読んでいけば、エラー原因が書かれている（ことが多い）。
↑詳しく読んでいたつもりになっていたが、自分が見ていた2行下に原因が書かれているのに気づかず、先輩がエラー原因を見つけてくださった・・・（2回くらいこれをやらかした・・・次は根気強く確認しよう・・・）
作業の進め方について
- アジャイル開発で設計と実装を一つのタスクとして見積もっていた。
しかし、実際に作業をやってみたところ、設計において考慮すべきことが見積をした時に想定していた以上にあり、見積もったストーリーポイントよりも時間がかかった。
また、設計をした結果、ファイルの変量がかなり多くなった。- 教訓：設計と実装はタスク（チケット）を分ける（実装の前段階の整理をするようなチケットとかでも、チケットを分ける）
リモートデスクトップが固まるポイント（3つ）
- 自分のPC（描画が遅いとか）
- ネットワーク
- 相手のPC
GitHubのブランチ名参考
- refactor/xxxxx_〇〇-migrate-△△
- リファクタリングで、〇〇を△△へ移行する（作業）
- migrate：移行する
- 例：refactor/xxxxx_android-view-migrate-compose
- リファクタリングで、AndroidViewをComposeに移行する（置き換える）
- チケット番号がない場合は、チケット番号の箇所を「xxxxx」にしてしまうのもあり
- sandbox/xxx_〇〇-demo
Githubで起きた珍事件（？）
事象
ローカル環境で作業ブランチにdevelopブランチをマージしてコミットした。
すると、developに既に取り込まれていたはずの差分が、Github上のPRで差分として出てしまっていた。
（本当なら、developに既に取り込まていたはずの差分は、GithubのPRで差分として出てこないはず・・・）
（恐らく）原因
たぶんローカル環境で作業ブランチにdevelopブランチをマージした際に、フェッチをしていない状態でマージをしてそれをコミットしていた。（←記憶があいまいで定かではないが・・・）
そのため、マージされたdevelopブランチの情報が古くなっていたのではないか。
UTF-8 BOM
javaの単体テストにて、文字列が一致しているのにも関わらず、asssertで失敗する事象が起きた。
原因：CSVファイル側の文字コードがUTF-8 with BOMになっている
対策：文字コードを変更して、BOMが付与されないようにする
参考
※以下のBOMは違うよ！
Gitでstashを使う時の例
①ブランチでコードを更新した
②①の途中で、developブランチを今のブランチにマージしようとしたが、①の変更のせいでマージできないって言われた
③stashで、①のコードを退避
④改めてdevelopブランチを今のブランチにマージ
⑤③でstashで退避したコードを元に戻す
有効数字
★0以外の数字の桁が何桁で固まっているかが、有効数字
0.012←有効数字2桁
↓これらも全部有効数字2桁
12
1.2
0.12
0.012
0.0012
豆知識
時報の音
- ラ・ラ・ラ ラー
↑ 440Hz ↑880Hz
DDD
例示／実験用として利用できるドメイン名
商用利用OKのイラスト類
- SILHOUETTE ILLUST（シルエットイラスト）
- https://www.silhouette-illust.com/policy
- 2025/08/17調べ
- 加工OK、アカウント登録不要、個数制限無し
- 使用可能な例：広告媒体、お便り、プレゼン資料、お知らせや告知の張り紙、HPなどのWebサービス内のアイコンとして、Youtubeなどの動画配信サービス内のコンテンツ、無料のアプリ、テレビ番組での放送、等