🟥
Rubyコーディング時に検討すること
概要
Ruby初心者でコーディング時に手戻りなどであまりにも時間がかかったため、簡単なコーディングの手順を検討しました。
随時更新予定。
コーディング手順
- コーディング前にフォーマットに記載
- タスクリスト作成し、手順と目標時間を検討
- 注意事項に従いコーディング
- タスクリストの目標時間内に終わらなかったら、理由を振り返り（もう一度同じことをして、もっと早く完成できるか検討する）
- コーディング後、push前に注意事項をチェック
- 共有用の簡単な説明のフォーマットに記載
コーディング前のフォーマット
コーディング前に以下のフォーマットを使用すると、どこから手をつけるか考えやすい。
## 仕様を分解する
1. 追加の仕様が必要となる背景を把握
- どういう立場のユーザーが
- いつ、どんな頻度でその機能を使い
- その機能を使ってどんなことをするのか
2. 現状を把握する（既存のコードがあれば、1に関係する機能を確認する）
3. 追加仕様を把握する
1. 追加仕様（あるべき姿）
2. 追加仕様を機能に分割化
3. 現状の機能との差分
4. 機能をタスク化して優先順位を決める
1. タスク一覧
2. タスクの作業時間見積もり
## コードの構成を考える
1. 追加機能に見合うコードの構成を検討
1. 入力と出力は何か？
2. データ構造はどうすればいいか？
2. テストの構成を検討（正常系、異常系、セキュリティ）
3. 検討したコード構成に合うライブラリは？
フォーマット詳細
タスクリスト作成
タスク作成時の注意事項
- 1タスクは30分以内にする
- 調査に時間がかかりそうなら、別タスクに切り分け、調査のステップごとにさらに切り分ける
- タスクリストは簡単に他の人にレビューしてもらうとなお良い
タスクにかかった時間の振り返り方
大体にして、見積もり時間をオーバーするので、簡単になぜ時間がかかったか振り返りやすい方法を検討しました。
- 今からやることを最小単位でメモ（◯◯検索、××のコードの修正など）
- 検索するなら検索結果をメモかブログに反映
- コーディングするなら、コード作成、デバッグ、メソッド検索などは分けて検討して、それぞれで学んだことをブログに反映
- タスク完了時にどこに時間がかかったか振り返る（ブラウザの履歴を見ると振り返りやすい）
コーディングの手順
- テストコードを書く
- 空のメソッドでメインのコードを書く
- テストして、パスすれば徐々にメソッドの中身を書いていき、テストを繰り返す
- メソッドをクラス化
- 清書
コーディング中の注意事項
- コーディング中に検索した内容は、検索結果で学んだことをメモする
- 15分ハマってChatGPTに聞いてもダメなら、他の人に聞く
- 原則
- Fake It(ロジックらしいロジックがない固定の値を返すような仮実装のこと(メソッドとテストコードがリンクしているかの疎通確認）)
- KISS原則（Keep it simple, stupid.）：必要性の曖昧な機能をいたずらに追加するのではなく、可能な限りシンプルにする（バカでも治せるコードに）
- YAGNI原則（You Ain't Gonna Need It）：将来必要になるかもという見込みや憶測で機能を追加することは戒めるべきである（無駄な工数削減やバグ回避に）
- DRY原則（Don't Repeat Yourself）：同じ情報は分散させずに、一箇所で管理すること
Rubyおまじない
#!/usr/bin/env ruby
#frozen_string_literal: true
コーディング後の注意事項（push前にチェックすること）
- [ ] rubocopをパスしているか？
- [ ] 組み込み・標準添付ライブラリの単語を使っているか？
- [ ] クラスは名詞、メソッドは動詞か？
- [ ] 引数のないメソッドは可読性のためインスタンス変数っぽく名詞の名前をつけているか？
- [ ] 1メソッドは五行以内に収めるているか？
- [ ] 頻出名詞をクラスに抜き出しているか？
- [ ] ハッシュテーブルによる分岐数削減しているか？
- [ ] 3つの原則(KISS, YAGNI, DRY)に従っているか？
- [ ] push先とpushするbranchは正しいか？
- [ ] PR先は正しいか？
commitメッセージは以下のフォーマットを使用
追加/変更/削除内容：
理由：
参考：コミットメッセージの書き方. 適切な情報を残そう | by risacan | Medium
共有用の簡単な説明フォーマット
- 追加した機能の目的
- 機能の概要
- 非追加機能
- データ構造
Discussion