22

一般的なソフトウェア エンジニアリングについて考えているときに、コードの記述/文書化の方法に改善が見られないのはなぜかという疑問に遭遇しました。

考えてみてください: パンチ カードからテキスト編集に移行して以来、革新的な改善はありませんでした。私が見た最後の改善は、構文の強調表示と状況依存のヘルプ (Intellisense や ctags など) です。私が革命的と呼ぶものではありません。

なぜそうなのか?

私がひどく恋しいものから始めましょう:

  • 私のコードの多くはジオメトリを扱っています。幾何学的関係を説明するドキュメンテーションは、(ASCII での適切な方程式のタイプ設定がないため) 読みにくい数学的なものの山になってしまいます。ただし、コードに少しの図や落書きを埋め込むことができれば、すべてがはるかに簡単に、すっきりと理解しやすくなります。

コーディング/テキスト編集/文書化のタスクをより簡単にするために何が考えられますか?

4

35 に答える 35

30

No Silver Bulletについてまだ誰も言及していないことに驚いています。1986 年 (!)、フレデリック・ブルックスは次のように予測しました。

技術または管理手法のいずれにおいても、10 年以内に生産性、信頼性、および単純さにおいて 1 桁 [10 倍] の改善を約束する単一の開発はありません。[...] 2 年ごとに 2 倍の利益が見られるとは期待できません。」

そして23年で、彼の正しさが証明されました。シンタックス ハイライトやインテリセンスなど、生産性を大幅に向上させた多くの機能を開発しましたが、1 桁も向上したわけではありません。時間が経つにつれて、いくつかの段階的な改善を続けますが、実際には特効薬はありません。生産性を桁違いに向上させるコードの記述方法に魔法のような啓示が現れるわけではありません。

于 2009-06-12T16:03:06.567 に答える
15

Donald Knuth の画期的なLiterate Programmingについて言及した人が誰もいないことに驚いています。本や科学論文のようにコードを書いてください。

于 2009-06-12T15:42:43.493 に答える
13

パンチカードからテキスト編集に移行して以来、革新的な改善はありません

行エディタを使用したことがありませんか?


しかし真剣に、テキスト (特に現代言語のために選択された表現) は

  1. 簡単に処理
  2. かなり簡単に指定できます
  3. 情報密度が高い
  4. 正確

それに代わるものはすべて、これら 4 つのプロパティすべてで純利益を上げなければなりません。簡単ではありません。

于 2009-06-12T15:21:48.443 に答える
11

同意しません。小さいながらも変化があります。

「for each」構造はどのくらい一般的ですか? 20年前と比べてみてください。ドメイン固有言語の動きはどうですか? レイヤーでコーディングする必要があるという考えはどうですか? ビヘイビア駆動開発はどうですか?仕様に準拠したコーディング...すべてが正常に実行されると、出力として素敵なドキュメントが書き込まれます。正規表現の標準化はどうですか?PCREAlan Kay のグループの"Moore's Law for Software" に関する DSL 関連の作業についてはどうでしょうか。これは Cairo のより高度な実装を調査し、RFC の図を使用して TCP/IP コードを生成しましたか?

ドキュメンテーションは双方向の対話です。コードがより理解しやすくなり、人々がこの特別な言語を学習するようになります。ドイツ語を知っていれば、ドイツ語にドキュメントが必要だとは言いません。自然言語がコンピューター言語とはかけ離れていることは知っていますが、コードをより表現力豊かにする動きがあります。新しいツールについてではなく、コーディング方法についてです。

于 2009-06-12T15:21:05.450 に答える
5

最近、アプリケーションの数学の多いセクションで行ったことの 1 つは、特定の方程式の LaTeX マークアップをコメント/ドキュメント文字列として含めることです。今のところ、オンラインの数式エディタにコピー アンド ペーストするだけですが、ASCII コードの集まりではなく、数式自体 (ギリシャ文字や下付き/上付き文字など) を確認すると非常に役立ちます。

于 2009-06-12T15:55:20.483 に答える
4

誰も言及していないことに驚いています.javadocは基本的にHTMLであるため、コードに画像(またはその他のもの)を埋め込むことを妨げるものは何もありません。シンプルで、効果的で、ユビキタスで、Java が正しく行ったことの 1 つです。

于 2009-06-12T18:44:12.873 に答える
4

データベース内のソース コード。簡単に言えば、ソース コードが解析され、データベースに入れられます。コードを表示および編集するには、統合された IDE が必要になりますが、この時点では、構文は形式から切り離されています。あなたの IDE は、あなたが取り組んでいるタスクに合わせて調整された、他の誰かのものとはまったく異なる方法でプログラムを表示する可能性があります。具体的な例をいくつか挙げたいと思いますが、その記事はほとんどすべてをカバーしています。

于 2009-06-12T15:25:52.257 に答える
3

これは、 Doxygenやその他のドキュメンテーション システムが役立つところだと思います。次のような他の情報にリンクする小さくて個別のコメントを埋め込むことができれば:

/* help: fooimg.png */

そして、外部のドキュメンテーション システムにそれを行わせます。

テキスト エディタでこれらを外部ドキュメントへのハイパーリンクとして扱えるようにするとさらに良いでしょう。

于 2009-06-12T15:16:01.373 に答える
3

DrScheme では、これらのことを実行できます。PLT Web サイトから挿入できるものは次のとおりです。

http://docs.plt-scheme.org/drscheme/Menus.html#(part._.Insert)

3.1.6 挿入

  • Insert Comment Box : DrScheme によって無視されるボックスを挿入します。あなたのプログラムを読む人のためにコメントを書くためにそれを使ってください。
  • 画像を挿入... : GIF、BMP、XBM、XPM、PNG、または JPG 形式の画像ファイルを選択するためのファイル検索ダイアログを開きます。画像は値として扱われます。
  • 分数を挿入... : 混合表記分数のダイアログを開き、指定された分数を現在のエディターに挿入します。
  • 大きい文字を挿入... : テキスト行のダイアログを開き、大きいバージョンのテキストを (セミコロンとスペースを使用して) 挿入します。
  • Insert λ : シンボル λ を (Unicode 文字として) プログラムに挿入します。λ シンボルは通常、ラムダと同じようにバインドされます。
  • Insert Java Comment Box : DrScheme が無視するボックスを挿入します。Insert Comment Box メニュー項目とは異なり、ProfessorJ 言語レベル用に設計されています。教授Jを参照してください。
  • Insert Java Interactions Box : Scheme プログラム内で Java 式とステートメントを許可するボックスを挿入します。ボックスの結果は、Java 式の結果に対応するスキーム値です。現時点では、Scheme 値はボックスに入力できません。このボックスは、1 行に 1 つの Java ステートメントまたは式を受け入れます。
  • Insert XML Box : XML を挿入します。詳細については、XML ボックスとスキーム ボックスを参照してください。
  • Insert Scheme Box : 通常は XML ボックス内で使用される、Scheme コードを含むボックスを挿入します。XML ボックスとスキーム ボックスを参照してください。
  • Insert Scheme Splice Box : 通常は XML ボックス内で使用される、Scheme コードを含むボックスを挿入します。XML ボックスとスキーム ボックスも参照してください。
  • Insert Pict Box : スライドショー画像を生成するためのボックスを作成します。pict ボックス内に、pict 値を生成する Scheme ボックスを挿入して配置します。

また、テストするコードを使用して単体テストを挿入します。かなりきちんとしたもの。

于 2009-06-12T15:19:09.107 に答える
3

バージョン管理は、私たちの仕事のやり方を大きく飛躍させたと思います。だれかがコードベースに加えたすべての変更を完全に記録し、必要に応じて変更を元に戻す機能は、大きな違いをもたらしました。

于 2009-06-13T12:13:33.410 に答える
3

セマンティック ハイライトと **セマンティックに制約された提案* (la IDEA または Eclipse) を備えた統合 IDE は大きな進歩だと思います。

しかし、それは8〜10年前に起こりました。

テンプレートベースのプログラミングは便利だと感じているが、決して普及しているようには見えない。最近、メタプログラミング システムのデモに感銘を受けました。これは、IDE のインタラクティブな性質を利用して、テンプレートと (本質的に) 型認識マクロとは何かを記述するタスクを簡素化します。

メタプログラミングは、多数のコード行の代わりになるジオメトリ ベースのマクロを定義するのに役立つ場合があります。より読みやすい「数学言語」を Java 内に埋め込み、その内容を解析して機械で読み取り可能なものにする何かを想像できます。

于 2009-06-12T15:35:44.917 に答える
2

私はemacsを使用しましたが、テキストマクロが好きです。しかし、私が本当に欲しいのは解析マクロです。言語自体の解析ツリーに変換を記述できるように、エディターにリファクタリングの背後にある機構を公開してもらいたいと思います。

たとえば、Pythonは+=、私のコードに行が散らかっていたある時点で追加されましたx = x + 1。解析ツリーで機能する検索および置換コマンドを作成できれば、大量のソースコードをすばやくクリーンアップできたはずです。

したがって、標準の検索と置換が必要ですが、抽象構文ツリーで、コードの構造が意味を持つレベルでそれが必要です。

ReSharperを使用したことがある場合、そのリファクタリングと推奨事項はそれぞれ、私が説明する方法で記述されています。解析ツリーでパターンを見つけて置換を提案するか、リファクタリングの場合は既知の置換を適用します。私は自分の仕事のためにその機械にアクセスしたいです!

于 2009-06-18T14:47:41.000 に答える
2

コード ドキュメントの参照として図面を参照します。コードに脚注を入れることができない理由はわかりません。

于 2009-06-12T15:15:06.167 に答える
2

コードの文書化にDoxygenなどを使用したことがありますか? 画像へのリンクや、生成されたドキュメントに取り込まれる他のファイル タイプ (多くの場合、ソース コードと同じディレクトリに保存されます) を追加できます。これは、お気に入りのエディターで直接詳細を表示することから 1 つのステップを取り除くことになると思いますが、コードを文書化する方法が確実に改善されます。

于 2009-06-12T15:15:41.437 に答える
2

コードのセクションを読み取り専用にする機能は、私が望んでいたものです

于 2009-06-12T15:24:44.130 に答える
2

ジョナサン・エドワードの研究に興味があるようですね。たとえば、次を参照してください。

于 2009-06-12T15:38:14.503 に答える
2

私が見た最後の改善は、構文の強調表示と状況依存のヘルプです

それからあなたはあまり見ていません。最新の IDE は、コードのセマンティック構造 (継承階層など) を表示したり、それを操作 (自動リファクタリング) したり、外部データ (特定のコード行を最後に変更した人など) で強化したりすることもできます。 .

于 2009-06-12T15:42:30.780 に答える
2

写真の差分と検索は難しいです。差分と検索は、プログラマーにとって非常に重要です。テキストの代わりに画像を使用することは、多くの状況でわずかな改善にすぎず、いくつかの欠点があり、実際に実行する価値がある前に一般的に受け入れられる必要があります (読者があなたの内容を理解しなければ、物事をより理解しやすくすることはできないため)。終わり)。

さらに、プログラマーは、コードのテキスト表現に基づいて生活を楽にする何百万もの小さなトリックを持っていますが、テキスト以外で表現されたコードを読むように与えられたら、彼らはそれらを失うことになります。確かに、時間の経過とともにそれらのトリックを置き換えたり再実装したりするかもしれませんが、短期的にはそれらはなくなります.

弁護士が契約書で英語からナプキンの裏の小さな図表に切り替えるのも見当たりません (クリエイティブ コモンズ ライセンスは試みますが、写真を契約書の正式な表現にすることはできません)。おそらく同様の理由からです。

誰かがプログラミング言語と IDE を思いついた場合、全体としてテキストベースのものよりも優れています。そしてそれをうまく売り込む。そして、テキストから新しいフォーマットへの革命的なシフトの始まりを目にするでしょう。誰もそのようなことを思い付かない場合、私たちは逃していません. 誰かがより生産的なものを思いついたが、他のテクノロジーの独自の利点のためにそれが勢いを増さなかった場合、その損失は私たちが自由市場資本主義に対して支払う代償です. おそらく、アイデアは最終的にリサイクルされるでしょう...

とはいえ、コードとドキュメントの統合は明らかに改善される可能性があり、さまざまな手法を使用してさまざまな成功を収めている多くの取り組みが進行中です。繰り返しますが、問題は、特定の狡猾な計画は、実際には一度に 1 つまたはいくつかの言語と開発環境でしか実装できないため、実際に優れていることを証明するのが難しいことです。ドキュメントをコードに埋め込むことは、API の発明以来、おそらく唯一の普遍的な進歩です...

とはいえ、テキストでできることはまだたくさんあると思います。たとえば、デバッガー テクノロジは、特定の一般的な状況 (つまり、テストが失敗したり、その他の予期しないことが発生した場合) でプログラマーの生産性に大きな違いをもたらしますが、見ているコードの誤った仮定が何であるかは明らかではありません。プログラムを表現する実際のビジネスよりも、プログラミングをより良くするという点で、より簡単な成果があるかもしれません。

于 2009-06-12T17:08:14.350 に答える
1

これは他の人からも触れられており、プログラミングに革命を起こすことはありませんが、とにかく...

コードエディタがプレーンテキストエディタを少し超えたほうがいいと思います。構文の強調表示とコードの完成(これは非常に良いことだと思います)を使用しても、今日のエディター(少なくとも私が使用しているもの)は、ソースファイルにあるものとまったく同じASCIIテキスト(または使用されているエンコード)を表示します。たとえば、編集者が表示された場合にどれだけうまく機能するかを知りたいと思います(いくつかの例は他の例よりも冒険的です):

  • 背景が水色で、背景が表示されていない、//または/* ... */表示されていないテキストボックス内のコメント
  • Javadocコメントは(HTML Javadocコメントを行う人のために)セミリッチなテキスト編集サポートを持つことができます(真剣に、コードエディターがJavadocコメントをHTMLとしてレンダリングした場合、HTMLをプレーンテキストとしてスキミングするのは最も簡単ではないため、感謝します)。
  • 署名のみを表示するために折りたたむことができ(現在のエディターで折りたたむことができます)、ボックスとしてドラッグできるテキストボックス内の関数
  • 機能がどのように接続されているかを示す機能ボックス間の線
  • ズームアウトして、単一のソースファイル(多くの言語のクラス)を表示するのではなく、複数のファイルと相互接続方法を表示できるようにします(これにより、基本的にUMLのようなダイアグラムがコードエディターに直接構築されます)

これは(少なくとも私の考えでは)ソースファイルに追加のマークアップを必要とせずに機能するので、プレーンテキストエディタのユーザーは、この余分なマークアップがすべてファイルを乱雑にすることによって不利益を被ることはないと思います。

于 2009-06-13T14:04:32.163 に答える
1

脳からコンピューターへの翻訳者。タイピングは本当のボトルネックです。本当に必要なのは、私が考えたアルゴリズムを導き出し、それを機械語に変換することだけです。

新しい言語の多くは、アルゴリズムをすばやく作成するのに非常に優れていると言えます。改善は進化的であるため、現在はそれほど革新的ではありません。

于 2009-06-12T15:14:46.900 に答える
1

私は過去数年間、コーディングをより速く、より効率的にする方法について多くのことを考えてきました. これらは革新的なアイデアではありませんが、元のポスターがパンチング カードからコード入力への移行について話していたので、プログラムしたいものをコンピューターに伝える他の方法について話そうと思いました。

私のアイデアは、ビジュアルまたは音声プログラミングです。背後にある動機は、ループを効率的にプログラムできる方法はいくつかしかなく、認識している IDE は、入力されたコード行以外の入力に応じて、スマートなコード置換の決定を行うことができるということです。

ビジュアル プログラミング vs コーディング: コードを (文字通り) 入力と出力を持つ「ボックス」にカプセル化し、それらを水平のタイムライン全体で接続します。これは、複数の行またはスレッドを同時に発生させることができるため、マルチスレッド開発にとって本質的に興味深い高レベルの概念です。どの工程も、どう見ても「箱」に分けることができます。最も基本的な形式での電子メールの送信は、電子メールを入力として受け取り、成功/失敗の信号を出力するボックスです。ボックスとラインはタイムライン全体に分散されているため、時間とイベントの年表の概念が失われず、フィードバック ラインが可能です。

音声プログラミングとコーディング: この手法の有効性は、コードを作成してカーソルを移動することを決定した音声構文の有効性を中心に展開します。たとえば、マイクに向かって「for variable 0 to 10」と言うと、システムはカーソルを内部に配置する次のコードを自動的に生成します。

for (x=0;x<10;x++){
  // Cursor would be there after after the call
}

使いやすさの点では、音声認識に悪影響を与える可能性のある他の音を最小限に抑えるために、比較的静かな部屋にいる必要があるため、このテクノロジーは主に特殊な環境で使用できます.

これは、さまざまなハードウェアとプログラミング言語を使用した私の広範なプログラミング経験の結果です。皆さんのご意見をお聞かせください。それについて建設的な議論をしたいと思っています。

于 2009-06-12T15:46:03.707 に答える
1

次の 2 つの引用がすぐに思い浮かびます。

「壊れていないなら直すな。」「仕事に最適なツールを使用してください。」

もちろん、コア コードは依然としてテキストとして記述されていますが、すべてのツールとライブラリはパンチ カードの時代から大幅に変更されています。

于 2009-06-13T12:32:41.697 に答える
1

プログラミング言語は数学的に表現できるため、プログラミング言語は特殊な形式の数学表記です。記法はゆっくりと変化するため、私たちの言語は急速に進歩しません。ほとんどの場合、i を使用して負の 1 の平方根を参照するなど、表記法に適合する新しいものを思いついたときに前進します。

テキスト以外のものを埋め込むことができるドキュメント スキームがあります。少なくとも 1 つのプログラミング スキーム、Donald Knuth の Web がありました。これにより、プログラムのプレゼンテーションと実行バージョンを作成できました (残念ながら、実際にハッキングするベース ソース コードはかなり厄介でした)。

コメントを HTML として処理できるテキスト エディタを簡単に作成できます。

于 2009-06-12T15:26:36.873 に答える
1

これらの代替プログラミング「言語」に興味があるかもしれません。

[はしご][1]、リレー ロジック スキームが機能する方法を模倣するように設計されています。恐ろしいIMOですが、棒と石で論理を作った老人にとっては理解しやすい. [ http://www.amci.com/tutorials/images/ladder-diagram.gif][2]

[SFC、シーケンシャル ファンクション チャート][3]、並列プログラミングを簡素化するように設計されています。コードはボックスに書き込まれ、これらのボックスは互いに平行に配置できるため、同時に実行されます。複数のボックスの端を接続することで、イベントを同期できます。自動化アプリケーションでは非常に一般的です。

[Mathematica][5]!!!, 最高のプログラミング言語ではないかもしれませんが、構文の強調表示 (それと呼べるなら) は素晴らしいです! たとえば、巨大な double[][] の代わりに適切に配置されたマトリックスを確認することで、マトリックスを入力できます。グラフをコードに挿入することができ、数式の書式設定は、紙に書いたときと同じように見えます。括弧の狂気や、実際には 1 文字しか必要としない長い Math.PI 式はもう必要ありません。そして何よりも、エディターで適切にレンダリングされたとしても、ファイルは単なるプレーン テキストです。

デバッガーも、多くの改善が行われた領域です。リプレイを備えたデバッガーや、データをリアルタイムで変更できるビジュアル デバッガーも登場し始めています。エディット・アンド・コンティニューもまた、これなしでは生きていけない機能です。

WTF 「新規ユーザーは最大 1 つのハイパーリンクしか投稿できません」、最初にこの投稿に追加したものをググる必要があります >:(

于 2009-06-17T20:50:07.163 に答える
1

数週間前、「意図的なソフトウェア」は彼らの新しい言語についてかなりの話題を巻き起こしました。プレゼンテーションはまだ見ていませんが、Martin Fowler によるレビューからの引用を次に示します。

彼らは心配そうに、いつものパワーポイントを公開せずに始めましたが、作業台の表示に切り替え、ついに幕が開きました。反応を測るには、Twitter を見てください。

  • @pandemonial とても感動しました!これは甘いです!複数のドメイン、複数の言語、答えられない質問はありません
  • @csells OK、レンダリングされたライブの電気回路を見て、C#ファイルで作業するのはとてもクールです。
  • @jolson Intentional Software の Electronics デモについて一言: HOLY CRAPOLA。それだけです、私の脳はついに爆発しました。
  • @gblock これはおしゃれなデモではなく、私たちが知っている世界を完全に変えることです。
  • @twleungわかりました、保険数理式のインテリセンスは素晴らしいです
  • @lobrien これは、100 mpg のキャブレターを見るようなものです。
于 2009-06-12T16:17:53.393 に答える
1

問題の一部は、コーディングをしない場合、それをプログラミングと呼ばないという事実に起因する可能性があります。たとえば、GUI を使用してモジュラー コンポーネントを組み立てることです。

于 2009-06-14T20:01:09.003 に答える
0

サブテキスト。エドワーズのアイデアと論文は非常にやる気を起こさせます。これが何であるかを自分で確認する必要があります。

説明ビデオ

于 2009-06-18T07:10:08.723 に答える
0

何か出てきても、とにかく誰も使わない。GUI クエリ ビルドを使用することで多くの入力を省くことができましたが、通常の GUI ツールが処理できるよりもクエリが複雑になる可能性があることを知っているため、他の人と同じようにコントロールが必要です。

フォームや Web ページにデータ コントロールを落とした人はいますか? ハイエンド ユーザーについてはそのとおりですが、過去 20 年間でソフトウェアを作成する能力が飛躍的に向上したプログラマー以外の何百万人ものユーザーがいます。

それはすべて 1 と 0 として終わるので、何を期待しますか。

于 2009-06-17T21:02:32.550 に答える
0

自動化されたセマンティック ソース コード変換。基になるセマンティクスを認識している抽象的なインターフェイス/フロントエンドを使用して、プログラムを確実に検査および操作できます。

そのため、ソース コードをクエリして、SQL データベースとほとんど同じように扱うことができます。

次の行に沿って何かを実行することで、ソース コードの静的分析を実行し、複雑なソース コードでもリファクタリングできるようにします。

FIND CALLERS OF FUNCTION "foo" WHERE SIGNATURE("int","int","char*") AND RETURN_TYPE("bool");
...
RENAME MACRO "max" TO "maximum" IN FILE "macros.hxx";
RENAME NAMESPACE "prj" TO "project";
RENAME SYMBOL "OLDFOO" IN NAMESPACE "project";
RENAME FUNCTION "log" TO "show_log";
RENAME CLASS "FOO" TO "OLDFOO";
RENAME METHOD "FOO::inc" TO "FOO::increment"; 
...
CHANGE SIGNATURE IN FUNCTION "foo" WHERE SIGNATURE("int","int") TO SIGNATURE("double","double");
CHANGE SIGNATURE IN METHOD "myClass::handle" WHERE SIGNATURE("char") TO SIGNATURE("unsigned char")
MOVE FUNCTION "foo" in FILE "stuff.cc" TO "foo_funcs.cc";
于 2009-06-12T18:21:54.750 に答える
0

プロセス全体の基本的な欠陥は、コンパイルできるようにするためにソース コードをテキスト ファイルに入れるという概念です。

これは、コンパイラが要求する一種の入力であるため、テキスト ファイルに入れられます。これは再考されるべき 50 年前の考えです。

コンパイラ/リンカは IDE と統合する必要があります。これにより、プログラマは、どのモジュールにどのコードを入れるか、このコードを向こうに見えるようにするために何をしなければならないかについて心配する必要がなくなります。グローバル?外部?#include ファイル、ライブラリ パス...それらを窓の外に放り投げます。

IDE を開いて、プロジェクトのリストを表示できる必要があります。それらの 1 つを開きます。デザイナーの場合は、デザイン ドキュメントが表示されます。開発者であれば、コードが表示されます。ユーザーの場合は、wiki が表示されます。

設計ドキュメントはコードにハイパーリンクされており、コードはドキュメントに戻り、ユーザー ガイドに戻るので、必要なレベルに到達できます。つまり、あなたは何らかの役割を担っており、「一体なぜ彼らはそのようにしたのだろうか?」と疑問に思います。その理由を確認するには、設計仕様へのリンクをたどってください。そこから要件ドキュメントに進みます。要件としてそれを提案した人の名前に続いてください。

すべてのファイル管理が行きます。それはIDEの内部に任されています。

于 2009-06-12T15:48:00.517 に答える
0

あえて言えば、実際には新しい開発言語 (おそらく新しいパラダイムでさえあるかもしれません) が、私たちをそのような革命に導きます。

于 2009-06-12T15:48:05.993 に答える
0

さて、医学と土木工学を見てください。うまくやらないと人は怪我をするので、これらは興味深いものです。これらの分野には、誰もが従う標準とライセンス手順があります。ある日目を覚まして、痛みを伴う儀式(学校、免許、見習い、その他のタスク)を経ずにこれらの分野で働き始めることはできません。不正行為は軽視されません。彼らは次のことについては話しません。彼らはそれらを持っており、誰もが追放の危険を冒して彼らに従います。

さて、ソフトウェアについて話しましょう。あなたの質問は本の基礎となっています。しかし、ベストプラクティスはどこにあるのでしょうか? ロバート・マーティンは咳払いをし、ジョエル・スポルスキーは侮辱と暴行の点で彼を嘲笑した. 少なくともマーティンは、いくつかの基準を提示しようとしました。トム、ディック、ハリー、サリー、スーは誰でもソフトウェア開発の練習を始めることができます。くだらないことをしたら、会社を辞めて(または解雇されて)、他の場所でくだらないことをしてください。誰もあなたを叱りません。ライセンス?IEEEはそれを試しましたが、誰が気にしますか? 米国テキサス州が試してみましたが、誰が気にしますか? 認定について話せば、あなたの仕事は台無しになります (Steve McConnel の本の 1 つ、Software Professionalism のように)。

これは大騒ぎでした。しかし、私はあなたに物事の状態を伝えるためにそれを経験しました. ソフトウェアは成熟するのに時間が必要であり、政府を巻き込むのに失敗し、土木工学のように成熟するため、大きな広告の有力者が転がり始めます。それがすぐに実現するかどうかは疑問です。しかし、それは遠い将来のことであるはずです。

于 2009-09-24T16:35:00.573 に答える
0

Leoを見てみたいと思うかもしれません。これは、あなたが尋ねていることに答えようとする試みの 1 つです。私はまだ VIM の頭を個人的に包み込むことはできませんが、他の人はすぐにそれを受け入れます。これは単なるプログラミング IDE ではなく、情報オーガナイザーです。これは Python で書かれていますが、他の言語でコーディングできない理由がわかりません。レオの力は、言語というよりも、コード、図、画像、または図のいずれであっても、自分の考えを表現して整理する能力にあります。チュートリアルと例を見て、その感触をつかんでください。あなたはそれが好きかもしれません。

于 2009-06-12T17:27:18.797 に答える
0

コーディング/テキスト編集/文書化のタスクをより簡単にするために何が考えられますか?

正しさの強調。

代替テキスト

更新:これは自明だと思いますが、明らかにそうではありません。これは、画像の注釈付きバージョンです。基本的に、これはおもちゃの言語ですが、概念は実際の言語や IDE に拡張できます。この言語にはインライン テストがあり、キーストロークごとにテストが実行されます。合格したテスト、および 100% のカバレッジを持ち、すべてのテストに合格した関数は青色で表示されます。失敗したテストと失敗した関数はピンク色で表示されます。カバーされていないコードは黄色です。つまり、上で述べたように、「正確性の強調表示」です。色を見て、どの関数が正しいか (テストで定義されているとおり) をすぐに知ることができます。

于 2009-06-17T19:38:15.637 に答える