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

Last updated at 2025-07-31Posted at 2024-05-15

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

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

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

アジャイル開発でメモを取っているのに自分だけが認識間違えているということが多発してた時、先輩に相談させていただいた結果

相談する前まで

以前は見積会の前に資料やチケットを下見していたが、最近はそれを行っていなかった
見積会中に今までは自分の手元だけでメモをして誰にも見せていなかった＋そのメモがチケットの内容と齟齬が無いかの見直しは行っていなかった（見直すタイミングが無かった）

見積会の前に事前にチケットを確認しておく
- どれくらいのポイント数になりそうなのかも予想しておく→ここポイントを付けられなかったら、その理由が「不明点」ということ。その不明点を事前に自分の中で認知しておけるため、見積会のときに聞ける。
（今までは自分の手元だけでメモをして誰にも見せていなかったが、）見積会の時にチケットのコメント欄にメモをする
→他の人にも見える場所にメモを書くことになるため、もし認識を間違えていたら自分ではなくても誰かが気付く可能性が上がる
見積会の時に手元でメモしたものがある場合、その内容がチケットの内容と齟齬が無いか見直すタイミングを作る
- チェックポイント
  - チケットに書いてあることと、時分のメモ（認識）に差が出ていないか
    （自分のメモにだけ書かれていて、チケットに書かれていないものや、その逆のパターンなど）
    - ↑今回これでやらかした（チケットに書かれていないが、時分の方のメモには書いていないことをやった結果、それは不要なことだったため手戻りが起きた）
- 見直すタイミング
  - 見積会が終わった後
  - チケットに着手する前（←違和感があったら着手前に他の人に認識確認をお願いする）

アジャイル開発で、PRレビューに時間がかかってしまうことを相談した結果

レビューする時間が無い時は、動作確認だけでも行う（結局は動作が優先になるので）
- とりあえず、最低限受け入れ基準通りに動くかを確認する
GithubのPRのファイル差分だとAndroid Studioほどはコードに色が付かない＋差分の所しか表示されないため、修正した前後のコードが分からずに各ファイルの関係や、処理の全体の流れがより掴みにくくなっていそう
- →Android Studioで差分を見た方が見やすい＋コード全体が見れるため処理の繋がりが把握しやすいかもしれない（Android Studioで差分を見る方法を参照）
コードを読むときは、慌てず落ち着いて上から順番に見る（by aさん）
PRの差分が大きい場合は区切る
- domain（UseCaseとか）～Repositoryのバックエンド側だけ見ました
- UI側だけ見ました　
  とかができる
  - ＵseCaseであればファイル名から何をしているのかがぼんやり分かるハズ・・・
PRの内容を把握する順番
1. PRに日本語で書いてくれている「概要」で概要を把握
2. PRのファイルの差分画面でUI側の修正なのか、バックエンド側の修正なのかが分かる
  diで依存関係を注入している箇所の修正とかは、見なくていいコードだと分かるので「Viewedチェックボックス」で閉じてしまう
  
  閉じることで少しでも画面を見た時の圧迫感を減らす
3. そこから、それぞれのファイルを確認していく

Android Studioで差分を見る方法

説明	キャプチャ
Android Studioの右下を右クリックして「Git Branch」にチェックを入れる
右下にブランチが表示されるため、それを左クリック
差分を見たいブランチを選択して「Show Diff with Working Tree」を選択
こんな感じに差分が表示される

ファイルのフォルダ分けタスクでやらかした

ファイルの中身を1個ずつ確認した上で、フォルダ分けをしていて凄い時間がかかった
- →ファイル名から、何をしているファイルなのかがざっくりわかるので、「ファイル名を見てフォルダ分けをする」というのが、スピードと正確性を見た時に最適なタスクの進め方だったかも

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up