タグ付けされた質問 「clean-code」

私はコンピュータサイエンスを研究し、ほぼ1年間、非常にアジャイルなJavaプロジェクトで単一の開発者として会社で働いています。プロジェクトはまもなく成功します（少なくとも私はそう願っています！）。 コア機能...は機能しており、start-requirementsに含まれていなかった他の機能も機能しています。不要な新機能についてはたくさんのアイデアがありますが、プログラムの使いやすさと機能性には役立ちます。 プログラムのいくつかの部分は非常にうまく機能しますが、他の部分には私があまり誇りに思っていないコードがあります... プロジェクトの開始以来、私は多くのことを学んだので、理論的にそれらの部分でより良いコードを書く方法を知っています。 問題：プロジェクトの後、何かをする時間があまりないため、ゼロから書き直すことは不可能です。そして、悪い部分だけを書き直すには、コア機能に深く入り込む必要があります->時間がかかります！ 私の過ちから学び、次のプロジェクトをさらに良くする方法/戦略はありますか？ プロジェクトの完了後、次のプロジェクトに進む前に他にすべきことはありますか？

8 agile  clean-code  solo-development  retrospective 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 私は数年間、大規模なRuby on Railsアプリケーションに取り組んできました。それは貧しい状態で受け継がれましたが、生産バグのほとんどは時間とともに解決されました。支払い処理コードなど、変更されていないセクションがあります。このコードはほとんどの部分で機能しますが、支払い処理業者によって請求が拒否された場合は常に、ユーザーに役立つメッセージではなく500エラーが表示されます。保守を容易にするためにコードをリファクタリングしたいと思います。それがどのように機能するかの簡単な概要を提供します。 次のスニペットからすべてのエラー処理コードを削除しました。 迷路はコントローラーで始まります： def submit_credit_card ... @credit_card = CreditCard.new(params[:credit_card].merge(:user => @user)) @credit_card.save ... @submission.do_initial_charge(@user) ... end 次に、Submissionモデルで： def do_initial_charge(user) ... self.initial_charge = self.charges.create(:charge_type => ChargeType.find(1), :user => user) self.initial_charge.process! self.initial_charge.settled? end ではChargeモデル： aasm column: 'state' do ... event :process do transitions :from => [:created, :failed], …

8 testing  refactoring  clean-code  complexity  budget 

私が取り組んでいるプロジェクトの依存関係の一部として、いくつかのコアサービスを使用しています。私たちが大きな変更を加えることができないこれらのサービスは、大きな混乱です。呼び出すメソッドに応じて、パラメーター（および戻り値）を別のエンコーディング、ロケール、タイムゾーンに変換する必要があります。 これらのパラメーターは独自のコードの複数の場所で生成されるため、これらの変換は複数の場所で実行されます。私たちがそれらを私たちの側に渡す前に、それらを生成するときがあります。コアサービスでメソッドを呼び出す直前。混乱がコード全体に広がっているので、それを分離するためのレイヤーを導入したいと思います。 私の質問は、そのための最良のアプローチは何ですか。最初は、使用する必要がある各サービス/メソッドに対応するサービス/メソッドを作成することを考えました。これらのメソッドは、単に変換を実行し、コアサービスに委任し、戻り値の変換を実行します。しかし、これはどういうわけか扱いにくいようです。 その後、アノテーションを使用することを考えましたが、使用方法は完全にはわかりません。そして、私が理解しているように、理想的には、呼び出されたメソッドに注釈を付ける必要があります。たとえば、パラメーターを@converToUtcで注釈し、注釈の実装で変換を行うことができます。これは正しいです？もちろん、これは私たちのコードではなく、現在私たち以外のプロジェクトでこれらのメソッドを使用しているコードを壊すので、これは難しいことです。 この状況に最適なアプローチは何ですか？

8 java  clean-code  layers 

この質問では、Decoratorパターンを使用して、大きなクラスのオブジェクトにほとんど機能を追加しないようにしています。 古典的なDecoratorパターンに従って、次のクラス構造を検討してください： たとえば、これがゲーム内で発生するとします。のインスタンスは、「ラッピング」しているConcreteCharacterDecorator機能に小さな機能を追加するためConcreteCharacterのものです。 たとえば、キャラクターが敵に与えるダメージを表す値をmethodA()返しますint。ConcreteCharacterDecorator単純にこの値に追加されます。したがって、必要なのはコードをに追加することだけmethodA()です。の機能はmethodB()変わりません。 ConcreteCharacterDecorator このようになります： class ConcreteCharacterDecorator extends AbstractCharacterDecorator{ ConcreteCharacter character; public ConcreteCharacterDecorator(ConcreteCharacter character){ this.character = character; } public int methodA(){ return 10 + character.methodA(); } public int methodB(){ character.methodB(); // simply delegate to the wrapped object. } } これは、2つのメソッドを含む小さなクラスでは問題ありません。 しかし、AbstractCharacter15のメソッドを定義するとどうなるでしょうか。 ConcreteCharacterDecorator少しの機能を追加することだけを目的としていますが、すべてを実装する必要があります。 少し機能を追加する1つのメソッドと、単純に内部オブジェクトに委譲する別の14のメソッドを含むクラスになります。 次のようになります。 class ConcreteCharacterDecorator extends AbstractCharacterDecorator{ ConcreteCharacter …

8 design-patterns  clean-code  composition 

私がブール値（プロパティ）を持っている場合shouldAutoLogin、ゲッターに名前を付けるのが良いのでしょうgetShouldAutoLoginか、それとも単にshouldAutoLogin英語のように読めるようにするのですか？ 例： if(shouldAutoLogin){ ... } または if(getShouldAutoLogin){ ... }

8 readability  clean-code 

私たちのソフトウェア環境では、おそらく良い習慣として、私たちはしばしばa / bテストを実行します。ただし、私たちの環境は、非常に短い時間で、コードがデッドテストで非常に壊れやすくなるように設定されています。テストレジストリは、内部wikiページのコレクションに過ぎません。 私は「デッドマンスイッチ」スタイルの機能しないコード管理を考えました。この用語に慣れていない場合は、何かがトリガーされないようにするために定期的にリセットする必要があるスイッチを指します。つまり、応答しない場合、スイッチがトリガーし、スイッチに何をしたいかを示します。トリガーが実行されます。 たとえば、いくつかのコードを記述し、何らかの方法でこのシステムに登録し、事前に選択した日付が循環すると、介入しない限り（手動で）このコードが削除される（自動的にクリーンアップされる）との通知を受け取りますクリーンアップ、またはスヌーズ）。 そのようなシステムを組み込むことの長所、短所、実行可能性は何ですか？それは可能ですか？腐敗に対してコードを管理するいくつかの代替方法は何でしょうか？

8 automation  parsing  clean-code 

環境： 最近、XSD.exeによって生成されたクラスファイルを処理する必要がありました。ばかばかしく冗長なクラス/変数名（someRidiculouslyLongPrefixThenMaybeOneThingUniqueAtTheEnd一見するとと比較するのは難しいと思いますsomeRidiculouslyLongPrefixThenMaybeOneOtherThingChanged）と注釈がいたるところにあり、長さが3500行でした。結論として、一体何が起こっているのかを理解するのに私は年齢を重ねました。私はそれを読んで、自分の名前を何かの隣に置くことは決してないと思ったので... 質問： 1）生成されたコードをいじる（つまり、クリーンにする）ことは悪い習慣ですか。 2）生成されたクラスを自分の素敵でクリーンなクラスにマップするマッパーを作成することをお勧めします（これで、とても楽しく作業できます）。 編集： すべてのコメントをありがとう。 実際に何か面白いことをするつもりだった場合（つまり、トランスポートオブジェクト以外のドメインオブジェクトがあった場合）、それらを「よりクリーンな」クラスにマップすると思います。それらのうちの一種の機能。この場合、クラスは事実上DTOであるため、おそらく名前が対応する要素と一致することは理にかなっています。述べたように、私はそれに触れる必要はありません-処理のためにデータを別のレイヤーに渡す前に、アクセサー/ミューテーターを呼び出すだけです。 今のところ、私はそれらを一人にしておくと思います。

8 refactoring  clean-code