Q&A
「キレイ」というのが主観的な評価なので客観的な回答が得られるとは思いませんが、「たくさん指摘」を受けた中にヒントはないんですか？なぜそのような指摘をされたのか、質問してみれば良いと思いますが。
既存実装の改修であれば、変更範囲やコストパフォーマンスを鑑みてコードレビューは簡単に通るのですが、新規開発では「既存実装のリファクタリングから新規実装を行う」ので、コードレビューでたくさん指摘されてしまいます。
根拠のないクラス分割は普段からやっているのですが、将来を見通した根拠をもってキレイなコードを書くことができていない状態です。
自分でも勉強しようとして、設計に関する本を読んでいても題材として取り上げているシステムへの理解が進まずイマイチ理解度はあがっていません。
キレイなコードを書く能力を鍛える方法は、がんばって本をたくさん読む、OSSをたくさん読む、たくさん仕事する、以外にないでしょうか？
コメントありがとうございます！レビューの中でヒントはたくさんあって、指摘という部分的な正解(のようなコメント)は提示してくれています。
対話するのよさそうです。ただ、たくさん指摘されてしまうと私が萎縮してしまうんですよね。。
回答2件
0
ベストアンサー
こんにちは。
経験を積むしかないですが、ひとつ、道筋を示すことはできます。
一言で言うと、
クラスやインターフェース、メソッドの「名前」を見ただけで、それが何なのか推測できるようになっているかを常に意識してください。
しっくりくる名前が付けられないときは、責務を持ちすぎか、分割すべきでない分割をしています。
例えば、「○○Manager」という名前が悪いと言われるのは、「○○を管理するモノ」と言われても何ができるものか伝わらないからです。
役割と性質をそれぞれの「モノ」に持たせることができていれば、それらは適切な「名前」を持ち、自ずとあなたの言う「キレイな」コードに近づきます。
投稿2020/08/12 07:20
総合スコア4105
0
Ericさんはこういううずまきのプロセスを推奨しています。
https://domainlanguage.com/ddd/whirlpool/
他にもTDDを活用する方法がありそうです。
理想のモデルには一足飛びに辿り付けないので、繰り返しのプロセスで改善を重ねていけばよいのではないでしょうか？
あと、実装(ドメインオブジェクト)をいくら素晴らしいものにしようとしても、仕様(ドメインモデル)が複雑であったり難解で手に負えないものだと意味がありません。必要に応じて仕様も変える必要あり、仕様を変えると業務の変更も必要だったりします。対象の問題をよく理解・分析することも「キレイな」コードを書くために必要な条件です。そういったコード外のコードに強い影響を与えるものに関心を向けることも必要だと思います。
投稿2020/08/11 17:09
総合スコア41
あなたの回答
tips
プレビュー
