1

簡単に変更できるコードを作成するには、どのような方法がありますか?

私が経験から学んだことは、ほとんどの場合、捨てるために書く必要があるということです。そうすることで、実際のアプリケーションをコーディングする前に必要なドメイン知識とプログラム構造の感覚を養うことができました。

4

6 に答える 6

5

一般的なガイドラインはオフコースです

  • 高凝集性、低カップリング
  • 繰り返さないで
  • 設計パターンを認識して実装する
  • 既存または必要のない設計パターンを認識しない
  • コーディング標準を使用し、それに固執する
  • 疑わしい場合は、コメントする必要があるすべてのことをコメントしてください : コメント
  • 単体テストを使用する
  • 実装前にコメントとテストを書くことで、何をしたいのかを正確に知ることができます
  • そしてうまくいかないときは、リファクタリング、リファクタリング、リファクタリング。優れたテストにより、何も壊れないことを確認できます

そしてそうそう:

これを読んでください:http://www.pragprog.com/the-pragmatic-programmer

上記のすべて(と思います)が含まれています

于 2009-05-15T17:11:11.907 に答える
1

読みやすさよりも、変更可能性を重視することが重要だと思います。読みやすくするのは難しいことではありませんが、要件の変化に応じて他の誰か(またはあなた)がそれを変更しなければならないときに、それがどれだけよく理解されているかを実際にテストします。

私がやろうとしているのは、変更が必要になると想定することです。変更の方法が明確でない場合は、コードに明示的な指示を残してください。

コードを適切に変更する方法を彼または彼女に知ってもらうために、コードの読者を教育する必要があるかもしれないと思います。これには私の側のエネルギーが必要であり、コードを読む人の側のエネルギーも必要です。

ですから、私は文芸的プログラミングのアイデアを賞賛していますが、それは簡単に読んで理解することができますが、時にはそれは数学のようなものであり、それを行う唯一の方法は、読者が腰を下ろし、細心の注意を払い、それをいくつか読み直すことです時間を、そして彼らが理解していることを確認してください。

于 2009-05-15T17:17:28.897 に答える
1

コードを DRY にぶら下げる

Web インターフェイスの外観を変更するタスクを割り当てられたとき、私はこれを早い段階で学びました。コードは私が嫌いだった C で書かれており、CGI 実行可能ファイルにコンパイルされていました。さらに悪いことに、それは放棄されたライブラリに基づいて構築されていました。更新もサポートも行われず、変更するのに多大な工数が費やされました。フレームワークの上には、さまざまなフォームと要素のビルダー、カスタム文字列の実装、およびその他のさまざまな不可解なもの (非 C プログラマーが自殺するためのもの) で構成されるコードの無秩序な Web がありました。

私が行った変更ごとに、出力 HTML にいくつか、時には多くの例外がありました。これらの例外のそれぞれに、フォーム ビルダーの小さな変更または改善が必要でした。言語のおかげで、継承がなく、関数と構造体しかないため、チームに時間を費やす代わりに、これらの例外を頻繁に作成しました。

私の経験不足では、改善されたフォームビルダーで変更を統合するのではなく、各例外の出力を変更することを余儀なくされました. しかし、効果のない変更を行った後、15,000 行のコードを数時間調べ続けると、コード バーンが発生し、霧がかかった状態になり、一晩寝ないと治りませんでした。

コードは常に DRY-er を介して実行してください。

于 2009-05-15T17:40:12.853 に答える
0

これが私の現在の経験です:私は頻繁に変更される可能性のある一種のデータベーススキーマ(フィールドの追加/削除、データ型の変更)で作業しています(Java)。私の戦略は、このスキーマを解析し、apachevelocityを使用してコードを生成することです。BaseClass生成されたものは、プログラマーによって変更されることはありません。それ以外の場合は、aMyClass extends BaseClassが作成され、このクラスの論理コンポーネント(toString()!など)は、スーパークラスの「getters」と「setters」を使用して実装されます。

于 2009-05-15T17:16:01.757 に答える
0

読みやすさは大いに役立ちます。自明でないことをしたり、近道をしたりする場合は、コメントしてください。コメントは、後で時間があれば戻ってリファクタリングできる場所です。すべてにわかりやすい名前を使用すると、何が起こっているのかを理解しやすくなります。

継続的な改訂により、(多すぎる)作業を捨てることなく、最初のドラフトからより良いドラフトに移行できます。ゼロから書き直すときはいつでも、学んだ教訓を失う可能性があります。コードを作成するときは、リファクタリングツールを使用して、不要になった探索領域を表すコードを削除し、あいまいなものを明確にします。最初のものはあなたが維持する必要がある量を減らします。2つ目は、1平方フィートあたりの労力を削減します。(Sqftは、実際にはコード行と同じくらい意味があります。)

適切にモジュール化し、モジュール間のロジックのカプセル化と分離を実施します。コードのいずれかの部分への依存関係が多すぎないようにする必要があります。そうしないと、その部分が本質的に理解しにくくなります。

最先端の方法よりも、実証済みの真の方法を使用することを検討してください。あなたは予測可能性のためにいくつかの機能をあきらめます。

最後に、これが変更の前後に人々が使用するコードである場合は、コードを自分のコードから分離する適切なAPIを用意する必要があります。強力なAPIを使用すると、すべての消費者に警告することなく、舞台裏で物事を変えることができます。これについては、コーディングホラーに関するまともな記事があると思います。

于 2009-05-15T17:17:54.543 に答える
0

コードを変更する最も簡単な方法は、コードを書かないことです。アルゴだけでなく、よくわからない場合はコードをどのように構造化するかについても疑似コードを記述してください。

コードを書きながらデザインすることは決してうまくいきません...私にとっては:-)

于 2009-05-15T17:08:02.383 に答える