ランダムなコードスニペットを見ることは、プロジェクトの品質をすばやく判断するのに役立ちますか?


8

今まで見たことのないプロジェクト(通常、使用するかどうかを検討しているオープンソースプロジェクト)の品質を把握するために、ランダムファイルを開いてコードの細部を見ることから始めることがよくあります。

私は次のものを探します:

  • スタイル(言語で認められている規則に従っていますか、一貫していますか)
  • コメントの品質と一貫性
  • 共通言語固有の落とし穴(たとえば、一貫し===てJavaScriptで使用しない)
  • 論理的に構造化されているように見えますか

これにより、コードの目的がまったく分からなくても、コードを書いた開発者のスキルがよくわかります。

これは便利だと人々は思いますか?実際にどのように機能するかについての知識がないと仮定して、プロジェクトのコードベースの品質を迅速に評価するために何を考慮する必要がありますか?


+1:すばらしい質問です。会社を買収すると、ソフトウェア資産がこのように評価/評価されることがあります。
ジムG.

1
確かに役立ちますが、全体的な品質を決定するものではありません。愚かなマネージャーの下で働く優秀なプログラマーは、プロジェクトのひどいアーキテクチャのための素晴らしいコードを書くでしょう。各モジュールは素晴らしいものになりますが、それらが相互作用する方法は、修正不可能なボトルネックになります。コードの品質をチェックする以外に、より広い外観が必要です。
SF。

@SF。あなたのコメント+10に賛成票を投じたいと思います。私はそのようなソフトウェアで作業する「喜び」を持っています。個々の関数/モジュールは問題ないように見えますが、それらが相互作用する方法にいくつかの厄介なバグがありました(主に非同期のものが処理されていたためです)。
ポール

回答:


8

このコードのバグを修正するのは簡単ですか?

新しいコードベースに遭遇したときはいつでも、私は自分自身にその質問をします。

コードにすばやく慣れることで、コードを作成した開発者との共通点を特定できます。以下を探す傾向があります(順不同)。

  • 命名規則の一貫した使用
  • コードを複雑にすることへの嫌悪感-KISS原則の遵守
  • すぐに使える単体テスト
  • 理解に役立つヒントとともにプロジェクトを説明する短いreadmeファイル
  • 良いコメント
  • 必要に応じてデザインパターンを使用する
  • コメントとコードレイアウトの一貫したスタイル
  • 有名で尊敬されているサポートライブラリ(Boost、Guavaなど)の使用
  • 言語イディオムの存在

上記の多くが存在するほど、私が開発者のスキルと経験に自信を持つようになるので、必然的なWTFはいつですか?瞬間が発生する私は、元の開発者がエラーを犯したと想定するよりも、問題の領域を理解していないことを自分で見る傾向があります。


+1ライブラリに関する情報を含めるのを忘れたので、それも探します。
フラッシュ

3

1つだけ選択すると、間違っている可能性があります。:)それ以外は、これは本質的にランダムサンプリングであり、あなたが説明するような場合に情報を収集するかなり立派なアプローチです。これがどのように行われるかについてのより科学的な詳細については、モンテカルロ法について研究してください。

探すべきことについては、特定のニーズを見つけ、調査し、調整して、実際に試したチェックリストをしてください。


プロジェクトを評価するときに考慮する価値のある他のいくつかの側面を以下に示します(私の過去の経験から要約したチェックリスト):

  • (変更履歴と一緒に)リリース、規律をバージョン管理し、公開
    それは1を伝えることができたときに問題を調査するために、一般的にはるかに簡単だバグがでダウンロード盛、リリース1.2.3で発見されたsome URLよりも、誰かが添付バイナリで私にメールを送った二年前ああ

  • 開発者用ドキュメント、APIリファレンス、およびコード例は
    、試行錯誤によってホイールの再発明と基本の学習に費やされる労力を回避するのに役立ちます。
    これらは、簡単な調査のためにランダムにサンプリングすることもできます。

  • バグ追跡追跡
    がまったくない場合、それは巨大な赤旗です。ソースコードがある場合は、ソースコードと同じランダムサンプリングアプローチを使用してすばやく確認することを検討してください。

  • 肯定的なフィードバック
    プロジェクトユーザーについて調べ、フィードバックのランダムサンプリング調査を試みます。


1

この方法は、スタイリングのスキルとコードを読みやすくする能力を明らかにするものだと思いますが、コードに取り組んでいる開発者の論理的、分析的、問題解決スキルについては何もわかりません。

したがって、この方法でコードを分析すると、コードがどの程度「見栄え」がよく、読み取り可能かどうかについての情報しか得られません。ただし、コードが最適化されているか、うまく機能しているか、うまく構造化されているかなどはまだわかりません。

あなたが注目する特性は非常に重要です。それらは、コードが読み取り可能で保守可能かどうかを示します。しかし、優れたソリューションを提供しているが、コメントやスタイル設定にはあまり注意を払っていないプログラマがたくさんいます(プログラミング自体よりもはるかに簡単に習得できると思います)。


0

はい、それは良い考えだと思います。不十分に書かれたプロジェクトは、放棄される可能性が高くなります。

しかし、それだけで判断を下すことはしないでください。imhoソースコードの履歴とコミッターの数は、はるかに重要な要素です。


0

コードの小さなセクションを見るのは素晴らしい方法だと思います。適切にコーディングされていれば、変数/クラス/メソッドに適切な名前が付けられ、よくコメントされているので、小さなセクションの機能とその目的が簡単に理解できます。小さなブロック(ブレーストゥブレースのようなもの)を理解するのが非常に難しい場合は、おそらくそれほどうまくコーディングされていません。


-1

サンプルが多くて大きくない限り、コードベースの適切な断面が得られない可能性が非常に高くなります。あなたは、非常に簡単にいくつかの良い部分またはいくつかの悪いりんごで終わるかもしれません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.