Q.現在Webサービス開発を進めています。詳細設計に関してアドバイス頂けると嬉しく思います。

Googleで登録して続きをみる

clear

会員登録

ご登録の前に、以下を同意ください。

check_box_outline_blank check_box JobQ Town利用規約・ 個人情報の取り扱いについてに同意する。

ソーシャルアカウントで会員登録

メールアドレスで会員登録

メールアドレス メールアドレスで登録する

ログインはこちら

LINEで登録して続きをみる

clear

会員登録

ご登録の前に、以下を同意ください。

check_box_outline_blank check_box JobQ Town利用規約・ 個人情報の取り扱いについてに同意する。

ソーシャルアカウントで会員登録

メールアドレスで会員登録

メールアドレス メールアドレスで登録する

ログインはこちら

メールアドレス・別アカウントで登録

clear

会員登録

ご登録の前に、以下を同意ください。

check_box_outline_blank check_box JobQ Town利用規約・ 個人情報の取り扱いについてに同意する。

ソーシャルアカウントで会員登録

メールアドレスで会員登録

メールアドレス メールアドレスで登録する

ログインはこちら

ログインはこちら

結論、詳細設計は、大事だと思うぺこ。 ただ、チームの大きさと、そのシステムの保守計画によって、書き方を変えるべきだと思うぺこ。 ▼ ハスラーってことは自社サービスで、しかも、担当範囲から考えて、（少なくとも初期フェイズについては）そんなに大きなサービスではないようにお見受けするぺこ。 それなら、詳細設計は、クラス名とその関係、メソッド名をつけて、中にロジックをコメントで書くところまでやる。 みたいな感じで、詳細設計としていいですか？って上司に確認してみたらいいぺこ。 もっとドキュメントっぽいのほしいって言われたら、そうしてぺこ。 class question // 削除されてない質問を返す def index // 未削除の質問を、投稿日順に並べてぺこ。 // 一度の取得件数は、peco.ymlにまとめようかな。 end end これ書いてるうちに、ほぼ出来上がったようなもんぺこ。 リファクタリングもこの時点でできるぺこ。 ▼ ただ、 お客さんに納品とか、 運用・保守チームと開発チームが別のチーム の場合とかは、ちゃんとドキュメントとして残してあげるのがいいぺこなー よく、コードを見ればわかるとか偉そうぶるエンジニアさんいるけどぺこ、そもそも現状のコードが、ビジネスサイドの意図した仕様になってるかをチェックするために、ドキュメントとコードの両方が必要ぺこ。 そうじゃないと、エンジニアさんが、ビジネスサイドのことも全部把握してないといけなくて、そんなの限界があるぺこよな。 なので、責任範囲の交差領域として、詳細設計があるぺこー