上司、先輩からいただいたアドバイス


# 上司や先輩からいただいたアドバイス
- 引き継ぎの際に、コードを修正したブランチを、devdlopブランチから生やしたトピックブランチとして残しておいて、それの修正内容をソースコードのプロジェクトのreadmeにメモしておく
この際に、devdlopブランチのreadmeには引き継ぎ事項を書いておくが、トピックブランチのreadmeには記載不要
理由：
GitHubのリポジトリで初期表示されるのは、devdlopブランチのreadmeである
それに対して、トピックブランチは、GitHub上でブランチを切り替えないとreadmeが表示されない
このため、「こうゆう修正が入ってるよー！！」というのを他の人訴求するのに、すぐ見つけられる
また、readme変更のPRを残すことで、GitHub上に変更履歴を残すことが出来る(変更履歴をあとから追跡する一助になる)
情報を残す上で、様々な角度から残して網を広げておけば、そこに何も知らない人が引っかかり、見る確率が増える
devdlopブランチのreadmeに、トピックブランチの明記しておけば、わざわざトピックブランチのreadmeに同じことを書かなくても済む
- workの略=wk
(↑だいたいこれで略されてる。
wrとは略さない)
- 上司から
検索結果とかは、説得力のあるモノを出した方がいいよ

- Javadocは、メソッドとか、クラスを書いた時点で書いてしまった方がいいよ


- URLには、小文字のケバブケースが無難
(web開発の一般的な知識)
参考サイト：

https://www.switchitmaker2.com/web-production/capital-small-letter/


- 何かを決断・判断する
↓それがすぐにはできない場合
何が分かれば、決断・判断を自らできるのか？
切り口）
①「事前調査が必要だった」
　→「事前調査」とは、具体的に何をすれば事前調査として必要十分だったのか？
②「エラーの対処に時間がかかった」
　→・エラーの対処時間を短くする対策は？
　・そもそもエラーを起こさないようにするための対策は？
　を具体的に考える
 ③「事前に何をどこまでやればいいのかを決めておけばよかった」
　→・それを決めるためには、何が分かっていなければならなかったのか？
　　・限られた時間のなかで、それが全て出来ない場合、何を基準にして取捨選択すれば、大半をカバーできるのか？
- 環境構築の際の設定ファイルとかは、コピーして取っておくといい
みんなしょっちゅう環境構築し直したりしてるので
- 個人開発：
    - 個人開発するだけでは、コードの再利用良い、悪いに気づけない（自分の中でのベストなコードしか書けない）
まずは、ベースとなるような、良いお手本となるコードを探したり、コードや設計に関する本とかで知見を得て、それを個人開発のコードに当てはめてみる。ゆくゆくは、個人開発内のプロジェクトコード用にアレンジして、自分の中で良いコードを見出していくのが流れ的にいいのではないか。
    - ChatGPTと会話してより良いコードはどんなものかを出してもらったり、茶色にコードを見てもらったりするのも手ではある
    - KPTのような振り返りは、個人開発でも定期的にメモしておくと進捗を実感することができる

## 実装
- とりま最初は、全体を理解するために、コピペではなく手打ちで実装をした方がいい

## Android Studioのキャッシュ破棄
### DBのキャッシュ破棄をしたい場合
- DBのキャッシュは、プロジェクト単位で生成される
→ クリーンビルドをすれば消える！
-端末側のDBは、マイグレーションでもしない限り、アプリのアンインストールをしないとキャッシュは更新されない

結論：
DB周りのキャッシュを破棄(リセット)したい場合は、クリーンビルドと、アプリのアンインストールをすればいい

- クリーンビルドをすれば、DBのキャッシュ破棄は基本的にできるため、Android Studioのキャッシュ破棄による再起動まではしなくていい
→クリーンビルドと、アプリのアンインストールでも解決せず、キャッシュが溜まっていて変な動きをする場合は、最終手段として『Android Studioの「キャッシュの破棄」を行う必要がある』

## Jetpack Compose
- UI、UXとかの、Composeの処理速度の確認は、リリースビルドを必ず使う
→デバッグビルドと、リリースビルドだと、目に見えるくらい速さに差が出る
- stateが変わるたびにJetpack Composeの処理が走る

## チケットの記載
- 対応ボリュームが大きくなるため、対応をしない場合、「対応ボリュームが大きくなる理由」も記載すると、引き継ぎの時に楽になる
- 作業難易度、作業規模が大きいため、対応を行わないと判断した場合はその理由が読み解けるように書く


NG例)
- また、〇〇の対応だけでも最低10日かかると予想し、費用対効果が低いことからも本チケットでは対処を行わないこととする。
- 1つづつデータの取得結果を確認して、取得した結果が膨大な量になるのかの確認が必要(確認対象箇所は100箇所以上ありそう)

↑最低でも10日かかる根拠として、括弧で記載されているところが、明確に「量」を示す箇所になっている。
先に理由の長い文書来ていて、その後ろに括弧で量を示す内容が書かれていると、読み手としては、先に知りたい「量」の内容が読まないと分からないため、速読すると「つまりどのくらいの量がかかるの？」と、なってしまう。
★量を示すなら、先に具体的な数字を出して、この後に理由付けする書き方だと分かりやすくなる


# 実務の際の心得的なの
- いま自分の中にあるモノ(知っている知識や技術)から、「こうすればいいのかな？？？」と考えたものは、あくまでも**「予想(思い込み)」**。
そのため、「**一般的には**どうやって実装・実現しているのか」をきちんと確認しよう！！
(↑これをやらないと、自分の知識も増えていかないよ。。。！)
- 「予想→確認→やってみる」を繰り返していく


## 報連相系
- 「ちょっと」と言っても、人によって「ちょっと」の感覚が違うため、具体的に数値(時間とか、コードの行数とか)を出した方がいい
### お悩み
ブレイクポイントで止まらない(´；ω；｀)
→ログを埋め込め！！
  ログが出なかった！！
  →出力するログレベルあってる？
    合ってるなら、多分そもそもその処理は通ってないのて、ソースコード見直せ！！

- countは、0から始めるのが普通
(↑1から始めててこのツッコミされた)
- Centos7のログの場所
大体はここにあるものが多いハズ……
/var/log

- DAO(Data Access Object)
↑リポジトリとは違う

- バックアップファイルはホームディレクトリに置く
→ログインしたらすぐ分かるほホームディレクトリに置く
最新の設定ファイルと同じ場所にバックアップファイルを置かない
  理由:最新の設定ファイルと同じ場所にバックアップファイルを置いておいたら、最新の設定ファイルではなく、バックアップファイルが読み込まれて実行時にエラーになったことがあった
# ビジネスメール
- 何かをお願いする時の「期日はこの日までにお願いします」を伝える際に、「3営業日」とかは書かなくていい
- 一般的に、特定の日付までに回答が欲しい場合は、「〇月×日までに」という言い方が普通
- 「n営業日以内に」と記述するのは、販売や営業系で使うことが多い表現で、受動的な回答を、回答する側が連絡する際によく使われる言葉
- ↑よく使われるのは、「ご質問を受け付けた場合わ弊社の3営業日以内で回答いたします」など
- 能動的に質問する側が期日わ切る際に、「弊社の3営業日以内で回答してくれ」となってしまうため、相手は「そんなん知るか」となってしまい、失礼に当たる
- 期日を木るさには、日付指定だけすれば良くて、n営業日以内は、心に留めておくのがべたー
- 営業日の話はお客さんの対応速度に応じて、5営業日などと余裕時分を変更したりするため、TPOに応じて使うのがいい

# DB
DB系の記載は以下の記事に切り出した

https://qiita.com/pe-pe-desu/items/2289492af266df081fb7

# ドキュメント系
ドキュメント系の記載は以下の記事に切り出した

https://qiita.com/pe-pe-desu/items/3835751487a56fddd6e4