人々はどのようにして非常に複雑で読みにくいコードをどのように書いて維持しますか?[閉まっている]


27

SQLiteのソースコードを読むことはIMOのミッションでは不可能です。ただし、他のコードからダウンロード、コンパイル、使用できる非常に複雑なソフトウェア(結局は本格的な組み込みデータベース)の使用可能な部分であり、常に更新されます。

このように非常に複雑で読みにくいコードを、どのように書いて維持するのでしょうか?


1
そうではないと思う
-D

2
@Pawka:「彼ら」にはSQLiteの人々は含まれていません。
フランクシェラー

11
コードが複雑で読みにくい場合でも、解決する問題の複雑さを考慮すると、比較的良いコードである可能性があります。困難な問題を解決するシンプルで簡単なコードを書くことは、「ベストプラクティス」にどれだけ忠実に従っても、ほとんど不可能です。それから、コードをできるだけシンプルで明確にすることがさらに重要です。
ジョナスプラッカ

1
読みやすい巨大なプロジェクトを見たことがありますか?
ジェフデイビス

2
...インターン、ポスドクなどを雇用し、彼らはそれを行う作る
DarenW

回答:


19

ComplexとComplicatedには大きな違いがあります。次のリンクについて要約します。:)

http://codebetter.com/blogs/dru.sellers/archive/2009/09/25/complex-vs-complicated.aspx

より個人的な注意として、私は100万行を超えるコードのコードベースに取り組んでいます。1行目から現在の状態に移行しました。農民が多いほど(コード内で長く読んでいるほど)簡単になります。すべての行が何をしているのかを説明することはできませんが、特定のタスクまたはバグの検索を開始することはできました。それは自然に来るだけです。

物語の教訓は、プログラミングの世界のあらゆるものと同様に時間がかかるということです。SQLiteを見て、それを知って、理解することを期待するなら、あなたは自分をからかっているでしょう。すべてがどのように連携するかを理解するには時間がかかります。良いコードと悪いコードの違いは、そのプロセスにかかる時間です。

最後に、一部の開発者はコードベースに飛び込んで理解を開始することができません。多くの人は、コードベースの大きさやアーキテクチャに圧倒されます。他の人はそれに飛び込むだけで問題ありません。それはすべて開発者の強さに依存します。


31

SQLiteの特定のケースでは、開発およびメンテナンスで使用するために選択した主なツールは自動テストです。彼らは、テストスイートで100%のカバレッジ(ステートメントカバレッジではなくブランチカバレッジ)に誇りを持っています。彼らによると、それは世界で最もテストされたソフトウェア製品の一つです。そのため、追加または変更したものがリグレッションを引き起こした場合、すぐに認識し、その結果として大胆に展開できます。

http://sqlite.org/testing.html

非常に驚異的な数です。テストコードの行数は、実稼働コードの約640 です。

編集:この質問は死者から提起されたようです!そして、1年を少し過ぎて、同じページが、本番のテストコードの1177倍の行を持っていると報告しています!


2
私以外の誰も、これを誇りではなく問題だと考えていますか?
スティーブン

1
本当にそうではない。まず、データベースは信頼できるものでなければなりません。
ts01

5
@Stephen、なぜ多くのテストケースが問題になるのでしょうか?

1
時間の腰?テストが多すぎるとテストが少ない(
IMHO

9
コードが失敗する可能性のあるケースをカバーする場合、テストはどのように時間の無駄になりますか?
ラムハウンド

7
  • 機能は時間とともに進化します。
    • 新しい機能は、新しい顧客の要件によって推進されます。
    • 古いコードは、古いコードを壊すことなく、将来のまだ実装されていない機能を追加できるように書かれています。
  • ドメイン専門家(この場合、データベースはコンピューターサイエンスの有名なドメインです。)
  • コミュニティのフィードバック
  • 急な学習曲線は、よく準備された忍耐者にとっては問題ではありませんでした。快適になるには6か月、1年、さらにはそれ以上かかる場合があります。
  • 商業的動機。金銭的な支援がなければ、時間とエネルギーを急な学習曲線に投資できる人はほとんどいません。

4

プロジェクトを維持するために、プロジェクト全体をよく理解する必要はありません。通常、大規模で複雑なソフトウェアを使用する場合、人々は自分の面倒を見る独自の特定の「領域」を持ち、システムの残りの部分の「合格」知識しか持っていません。

SQLiteは、「大規模なソフトウェアプロジェクト」の規模で、実際には比較的小さいですが、あなたは、Windowsオペレーティングシステムのようなものを見れば、あなたは人誰でしょうただ、カーネル、人々誰の作業だけでシェル、人々誰の作業だけで仕事をInternet Explorerでは、ウィンドウマネージャーなどで作業するだけです。「シェル」で作業する人は、カーネルのバグをすぐに修正することはできません。

また、これらのプロジェクトは時間とともに進化するという利点もあります。常に複雑なプロジェクトから始まったわけではありません。つまり、新しい開発者は通常、経験豊富な開発者によって「トレーニング」を受けることができます。

大規模な開発者チームに参加すると、プロジェクトの特定の側面(バグまたは新機能の可能性があります)が与えられ、最初の数回の反復で別の開発者が「仲間」になります。あなたの仲間はあなたが働いている地域をよく理解していて、あなたがあなたの道を見つけるのを助けることができます。

SQLiteのようなオープンソースプロジェクトの場合、既存の開発者が新しい開発者を「トレーニング」する動機がないため、実際には少し難しくなります。それで、あなたはあなたがもう一人でいることに気付くでしょう。しかし、開発者フォーラムやメーリングリストで引き続きヘルプを見つけることができます(たとえば、「このような機能を実装したい」、「バグXYZを見つけました。どこから探し始めますか?」などの質問を投稿すると、何らかの形のヘルプ。


詳細を変更すると、これは私の現在の仕事によく似ています!この答えの最良の部分は、専門性と時間をかけて開発する必要性です。また、全体についてユーモアを少し加えます。
DarenW

4

読みにくいプロジェクトと複雑なプロジェクトには違いがあります。プロジェクトが書かれた言語やプロジェクトのドメインを人が深く理解していない場合、コードが不適切に書かれていることを意味しません。

私のアドバイス:

  • プロジェクトの言語を理解していることを確認してください。言語を知るだけでは十分ではありません。
  • コードを実際に試す前に、ドメインに関するすべての詳細を学んでください。

私にとって、SQLiteははるかに複雑であり、複雑なものではありません。このプロジェクトの領域では、幅広い概念について深く理解する必要があります。


3

他の回答で言及されていないことの1つは、「自然に彼らにやってくる」ことです。ほとんどの人は良いコードを書きたいと思っていますが、悪いコードを書くように調整されています。私が出会ったプログラマーの中には、当然のことながらLINEARの思想家+時々、非常に意図的に複雑なソリューションを考え出す人がいます。そのような人々のほとんどは、仕事が必要とするときに、学習する本を読んだり学習したりするのに時間を費やしません。


1
LOL、私はこのようなsoemoneを使用しました。何かを行う方法がいくつかある場合(常にあります)、彼は常に最も複雑で複雑なソリューションを選択します。彼はそれを知っていたとは思わない。
HLGEM

3

このように非常に複雑で読みにくいコードを、どのように書いて維持するのでしょうか?

彼らが元のコーダーであり、それを維持し続けている場合、彼らはそれを「複雑で読みにくい」とは見なしません。彼らは自分で書いたので、おそらく「シンプルで読みやすい」と考えています。

コードを理解するには時間がかかります。いくつかは他のものよりも時間がかかるというだけです:)


2

あなたが持っているなら、あなたはどんなコードベースにも頭を包むことができます-忍耐、忍耐、そして系統的なアプローチ-しかし、主に忍耐:-)


1

常に同じ方法で行われることがあれば、管理はずっと簡単になります。SQLiteコードはわかりませんが、複数のプロジェクトがある環境で作業しています。ビジネスケース(eqロジック)を理解することに加えて、すべては基本的にどこでも同じ方法(データベースアクセスなど)で行われるため、別のプロジェクトで作業を開始するのは比較的簡単です。短いテキスト:コーディングガイドライン-適切な方法で-生活とそのようなコードをはるかに簡単にします。これは、SQLiteコーダーのヘルパーの1つです。


1
  • あなたがソフトウェアの最初の作者であり、10年以上にわたってそのソフトウェアを使用し、天才であれば、すべてを理解できる可能性があります。複雑なソフトウェア(SQLiteやLinuxカーネルなど)の大きな部分には、他の人が貢献した場合でも、通常、完全に深い理解を持つ元の著者が1人だけいます。
  • ソフトウェアアーキテクチャが正しければ(高凝集度、低結合度)、全体を理解することは、それに有用な追加や変更を行うための前提条件ではありません。
  • RDBMSまたはOSを理解することはやや特殊なケースであり、基礎となるCSの原則を深く理解する必要があります。「通常の」ソフトウェアアプリケーションではそうではありません。

1

彼らは単純な方法でそれを書き込もうとしますが、単純な方法では書きません。

できる限りシンプルにすれば、時間がかかりますが、物事をより早く理解/読めるようになります。


1

実装されているアルゴリズムは、実装のコードがどれだけ単純であるかに下限を設定します。実装するアルゴリズムの抽象的な記述が非常に複雑で、大量の異なるデータを相互に結合する必要がある場合、そのアルゴリズムを実装するコードは誰が書いても簡単ではありません。

言い換えれば、私が時々不可解なコードを書く理由の1つは、実装したいアルゴリズムを考えると、選択の余地がないからです。

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