問題タブ [maintainability]

drupal インストールと drupal モジュールを更新しましたが、admin/reports/updates によると、Drupal のバージョンはまだ 6.12 です。drupal を更新するために、 drush updatecode - drush updatedbを実行し ました (これはモジュールのみを更新し、コードはまだ手動で更新する必要があります)。次に、コアをアップロードして解凍し、古いバージョンを上書きできるようにして、再度実行しました - drush updatedb で変更を有効にしました。それでも、admin/reports/status は期待どおりの 6.13 バージョンではなく、6.12 を示しており、コアが安全ではないと言っています。最後に update.php スクリプトも実行しましたが、それでもコアは赤で表示され、admin/reports/updates にあるモジュールも表示されます。

drupal シェル (drush) を使用することは、更新に適していますか? ステータスがまだ未更新として表示されるのはなぜですか?

私は仕事でResharperを使用しています。私の同僚の何人かはそうしません。

書かれていない人が書いたコードを開くと、画面上のオレンジ色の量からすぐにわかります。

私が確信していないのは、無意識のうちに残した混乱をどの程度まで自由に片付けるべきかということです。私が見ているもののほとんどで、それはずさんですが無害であり、私がResharperを使用したことがなければ、実際に私に飛びつくことはありません。

私は自分の選択肢を広く見ていると思います

1）ソースコードの変更履歴はメンテナンスに欠かせません。変更をできるだけ少なくしないと、次の人は何が変更されたかを理解することを望んでいません。とにかく到達不能コード、.ToString（）の不必要な使用などを気にする人。

2）インクルードなどの無意味なものを変更し、メソッドドキュメントのコメントなどを修正します。それを書いた人は自分のコードがこのように見えるのが好きなので、文句を言わない状態のままにしておきますが、不要なオレンジの一部を取り除きます

3）オレンジは赤だけですが、明るいです。F12、次にAlt+Enterを緑になります。

4）オレンジを忘れて、そのモンスター700ライン機能を見てください。この1997年は何ですか？忙しくする時間です...そして時間があれば、同僚を私たちの親友でありメンターであるファウラー氏に紹介してください。

私は、自分がどれだけの時間を持っているか、コードをどの程度担当しているか、コードがどれほど複雑に見えるか（通常は1または4に行くことができます）に応じて、オプション間を行き来する傾向があります。

4つの選択肢のうちの1つは私が目指しているもののようですが、どれが私にはわかりません

私のプロジェクトはゆっくりとJavaアノテーションを実装しています。開発者の半数（私も含めて）は、アノテーションを使用して複雑なことを行うと、全体的なメンテナンスの負担が増えるように思われることに気付きました。チームの残りの半分は、彼らがミツバチの膝だと思っています。

注釈付きコードを維持できる開発者のチームでの実際の経験は何ですか？

私は、少なくとも 6 年の有効期間を持つことを目的とした Web ベースのアプリケーションに取り組んでいます。アプリケーションが配信されると、その期間中は変更されない可能性があります。

asp.net MVC フレームワークと jQuery を使用することを検討していますが、それが良い選択かどうか疑問に思っています。JavaScript やブラウザの標準などが変更されたため、顧客は今後さらに時間とお金を費やすことを望まないでしょう。

今後 6 年間でアプリケーションのメンテナンスが必要になる可能性を最小限に抑えるための最適なオプションは何ですか?

Java の巨大な正規表現を見て、正規表現全般の保守性について少し考えさせられました。ほとんどの人は (一部の悪意のある perl モンガーを除いて)、正規表現はほとんど保守できないことに同意すると思います。

どうすればこの状況を改善できるかを考えていました。これまでのところ、私が持っている最も有望なアイデアは流暢なインターフェイスを使用することです。例を挙げると、次の代わりに:

このようなものを書くことができます

この非常に短い例では、正規表現を作成する一般的な方法は、凡庸な才能のある開発者なら誰でも理解できるものです。ただし、それぞれ 80 文字で 2 行以上を埋める不気味な表現について考えてみてください。確かに、(冗長な) 流暢なインターフェースには 2 行だけではなく数行が必要ですが、はるかに読みやすい (したがって保守しやすい) と確信しています。

今私の質問：

1. 正規表現に対する同様のアプローチを知っていますか?

2. このアプローチは、単純な文字列を使用するよりも優れていることに同意しますか?

3. API をどのように設計しますか?

4. あなたのプロジェクトでそのようなきちんとしたユーティリティを使用しますか?

5. これを実装するのは楽しいと思いますか? ;)

編集: 単純な構造よりも高いレベルにあるメソッドが存在する可能性があると想像してください。たとえば、正規表現にはありません。

編集 - コメントの短い要約:

• .NET 用の流暢な正規表現ライブラリ

• RegexBuddy - あなたのコードを読みやすくするために 30 ユーロを費やしてください (なんてこった?! そのような製品の純粋な存在は私の論文が正しいことを証明します - 私たちが今日知っている正規表現は悪いことです (tm))

• Martin Fowler のアプローチ(まだ完璧にはほど遠い)

ほとんどの人が正規表現は定着すると考えているのは興味深いことですが、正規表現を読むにはツールが必要であり、正規表現を保守可能にする方法を考えるには賢い人が必要です。流暢なインターフェイスが最善の方法であるかどうかはわかりませんが、賢明なエンジニアがいると確信しています-私たち? ;) - 正規表現を過去のものにするために時間を費やす必要があります - 50 年間私たちと一緒にいるだけで十分だと思いませんか?

懸賞金を開く

報奨金は、正規表現への新しいアプローチの最良のアイデア (コードは不要) に授与されます。

編集 - 良い例:

これが私が話しているパターンの種類です-最初に翻訳できた人への追加の称賛-RegexBuddiesが許可されました（これはApacheプロジェクトからのものです）chiiとmezに与えられた追加の称賛：これはRFC準拠の電子メールアドレス検証パターンです-ただし、RFC822 ( ex-parrot.comを参照) であり、5322ではありません - 違いがあるかどうかはわかりません - もしそうなら、5322 に適合するパッチに次の追加の称賛を与えます ;)

改行を追加する必要はありません。読みやすいものを追加するだけです。

これより良いものはありますか？

私が取り組んでいるプロジェクト（約80K LOC）があり、何も壊さないように注意している限り、リリース前にほぼ1か月の贅沢なリファクタリングと機能追加の時間があります。そうは言っても、保守性を向上させるために何ができるでしょうか。このプロジェクトでは単体テストが実施されておらず、これに単体テストを追加する予定はありませんが、それが共通のコンセンサスである場合は、検討します。

ソフトウェアの保守性と品質を向上させるために、私が探し、改訂またはリファクタリングを検討する必要がある重要なことは何ですか？

編集：ユニットテストが必要であることが明らかになりました。これは私が実際に行ったことではありません。ユニットテストを初めて使用する開発者にとって、（できればVS2008のユニットテストフレームワークを介して）優れたリソースは何ですか？

しばらく前に書いたコード標準ドキュメントの一部として、「ループや条件付きコードブロックには、（特に）1行しかない場合でも、常に中括弧を使用する必要があります」と強制します。

例：

1行を中括弧で囲まずに、誰かがそれをコメントアウトすると、問題が発生します。1行を中括弧で囲まず、インデントが他の人のマシンで同じように表示されない場合は、問題が発生しています。

それで、質問：これが誤った、またはそうでなければ不合理な基準になる理由はありますか？それについてはいくつかの議論がありましたが、「醜い」よりも良い反論を私に提供できる人は誰もいません。