Skip to content

Latest commit

 

History

History
94 lines (67 loc) · 2.53 KB

README.md

File metadata and controls

94 lines (67 loc) · 2.53 KB

cheatsheet(always β)

日々

  • 考えるまでの距離を最短にする
    • 常時ブラウザに固定する: Scrapbox、一時メモ、スプシ
    • Slackにて、自分へのDMは、最上部に固定する
    • ノートは開いておく

見積り

手順

  1. スプシを開く
  2. タスクを洗い出す
    • 1つが1日以内で終わるレベルを目安に砕く
  3. 不確実性を書き出す
  4. 不確実性を減らす
    • 比較する(同規模の既存機能)
    • 数える(行数、機能数、ファイル数)
    • レビューしてもらう
  5. ptをつける

注意

  • 再見積もりタイミングを入れる
  • 不具合改修 = 実装工数 * 0.2~0.3 とする
  • レビュー工数を考慮する
  • 設計や実装の前に、仕様確認 or テスト設計の時間と取る
    • 決めきれていない仕様があることを前提とする

Standup 時の問い

  • 伝えたほうが多分いいことは何か?

KPT / Planning 時の問い

  • 今日(今週、このpjtが)失敗するとしたら、どういうことが起きた場合か?
  • 誰かに協力してもらうことができる範囲はどこか?
    • 例えば、毎日15分でも話す時間をブロックさせてもらうという方法がある
  • 助けてもらいたい人はいるか?
  • 2倍速で終わるためにできることは何か?
  • 一番時間がかかりそうなことは何か?
  • 一番価値があることは何か?
  • 今週のMVPは誰か?(目立つ、ではなく、価値がある)

設計時に特定していくもの

  • 業務ロジック
  • 値オブジェクト
  • ユビキタス言語
  • コアドメイン
  • 集約
  • 複雑な業務ロジック

レビュー観点

コーディング

  • インスタンス変数はnilになりうるか?(nilかつレシーバとなる箇所はないか?)
    • ぼっち演算子をつけなくて大丈夫か?
  • 継承について
    • 継承を用いて責務を分離できないか
    • 継承していた場合、想定外のオーバーライドをしている箇所はないか
  • 可視性が適切か
  • 定数化できる余地と、している場合に freezeしているか

勉強

結局、手書きノートと本があってる

チューニング

手順

  1. 対象機能を選定
  2. 現状分析
  3. 目標設定
  4. 原因究明
  5. チューニングの方針決定
  6. チューニング
  7. 結果測定

データ要件

TODO: 決め方

セキュリティ

DDD

システムデザインパターン

GCP