継続的に変更する必要のないソフトウェアを書くことは可能ですか？

私は多くの異なる言語で多くのソフトウェアを書きました。また、VerilogとVHDLを使用してFPGAで使用するハードウェアを「書きました」。

私はソフトウェアよりもハードウェアを書くことを楽しむ傾向があり、主な理由の1つは、「完了」して変更する必要のないハードウェアを書くことができるからだと思います。インターフェイスと機能を定義し、テストベンチを書く、ハードウェアモジュールを実装してから、シミュレータを使用してそれをテストします。次に、そのハードウェアモジュールをビルディングブロックとして使用して、より大きくより良いものを作成できます。そのモジュールに機能を追加する必要がある場合は、2番目のモジュールを作成し、そこに機能を追加します。元のモジュールは問題なく機能し、引き続き有用であるため、元のモジュールを捨てることはありません。

ソフトウェアに関する私の主な不満の1つは、「完了」しないことです。追加する別の機能が常にあります。多くの場合、機能を追加すると、以前は正常に機能していた別の場所にバグが発生します。これは、インターフェイスに違反していない限り、ハードウェアでは発生しません。

明確にするために、機能のリストを使用して何かの1つのバージョンを構築することを支持していません。それは永遠です。左側のコードを突いて右側のバグを見つけたくないのですが、これは新しい機能を追加した後に起こるようです。

ハードウェアが「書き込まれる」のと同様の方法でソフトウェアを書くことは可能ですか？既存のコードを書き直したり新しいバグを導入したりすることなく、常に前進を続け、新しい機能を追加できる優れたソフトウェア開発方法論はありますか？

たぶん、ハードウェアのように、明確に定義されたインターフェースとテストに関係があるのでしょうか？

まさに私の考え！

明確なインターフェースを備えた適切に設計されたモジュールは、本質的に完璧である傾向があります。StringJavaのクラスのようなものを考えてください。これはコンピュータープログラムですが、非常に明確なインターフェイスを備えています。既知のバグはありません。それは、本来行うべきことを完璧に行います。確かに、過去15年間に広範囲にテストされており、事実上すべてのプログラムがString基本的な構成要素としてsを使用しているため、バグはすぐに気付かれます。どれ「癖」 -厳密にはバグが、デザインは価値を意識することの詳細-ここに記載されているものなどをhttp://www.jwz.org/doc/java.htmlは、今ではよく知られており、ひいてはに取り込むことができますアカウント。

バグの多いソフトウェアは部分的に文化的な問題です。人々はバグのあるソフトウェアに慣れており、ハードウェアとは異なり、ソフトウェアは通常簡単に後で修正できるため、最初に（または今まで出荷する必要があるので、今すぐ修正する必要があります）次のバージョンで）。しかし、大部分は、実際の複雑さの問題です。ソフトウェアの複雑さは過去50年ほど着実に増加していますが、人間の脳は同じです。完璧を達成することの難しさの増大と、後から修正することの容易さ（高速、自動ビルド、インターネット配信）が、スケジュールのプレッシャーと規律の欠如と組み合わされると、結果はその通りになります。

既存のコードを書き直したり新しいバグを導入したりすることなく、常に前進を続け、新しい機能を追加できる優れたソフトウェア開発方法論はありますか？

おそらく特効薬はありませんが、ベストプラクティスの適切な組み合わせです。

• シンプルな自律モジュール。言い換えれば、低い結合と高い凝集性。
• 不変性。並行性が高まると特に重要です。

両方のポイントが複雑さを軽減することを目的としていることは注目に値します。それが重要なポイントです。エントロピーは常に増加する傾向があり、それと戦わなければ、すぐに複雑さにcomplexityれます。また、ここ数年の間に、プログラミング言語が上記の慣行を奨励または強制する方向へと進化しているのを見るのも興味深いです。特に、関数型言語の台頭は、純粋な関数が同じ入力に対して常に同じ値を返し、状態が存在しないということだけです。次に、不変の値を取得して返す純粋な関数を作成し、不可避な可変性を、全体に広げるのではなく、明確に定義された小さな場所に制限します。これをチェックしてください：http : //clojure.org/state

違いは、ハードウェアと比較してソフトウェアを変更する方がはるかに簡単で安価なことです。ハードウェアが簡単かつ安価に変更して顧客に出荷できれば、彼らはそうするでしょう。

不十分に表現された質問をまとめることができれば、「作業中のコードにバグを導入せず、常に前進し続けることで、ソフトウェアを書くことをもっと楽しくすることができますか？」たぶん、ハードウェアのように、明確に定義されたインターフェースとテストに関係があるのでしょうか？

テスト駆動開発を必ず確認してください。

これらのコメントから答えが得られることを願って、私はあなたの発言のいくつかにコメントします。

ソフトウェアに関する私の主な不満の1つは、「完了」しないことです。

これは、ソリューションの仕様が不完全であるか、拡張機能を提供する計画が正確でないためです。これは、プロジェクトソフトウェア、ハードウェア、またはその他のプロジェクトで発生する可能性があります。

既存のコードを書き直したり新しいバグを導入したりすることなく、常に前進を続け、新しい機能を追加できる優れたソフトウェア開発方法論はありますか？

もちろん、独立したモジュールを作成すると、依存関係が大幅に減少します。これは、ソフトウェアを設計するときに考慮する必要があります。懸念事項、レイヤー、層、コントローラーオブジェクト、インターフェースなどの分離を考慮する必要があります。

「バグを作業中のコードに導入せずに常に前進させることで、ソフトウェアをより楽しく書くことができますか？」

1-要件を注意深く理解します。設計前に要件を閉じることを検討する必要があるかもしれません。反復開発を行う場合、これを行う可能性はありません。いくつかの方法論がこれを奨励していますが、個人的には、これはすべてのプロジェクトタイプに適しているとは思いません。堅実な要件に基づいてソフトウェアを構築することで、設計を改善できます。

2-ユーザーにこの長期的な哲学を理解させます。

3-慎重に実装を計画する

コードの前の4-Design。

5-適切な場合は、一般的なデザインを使用します。

6-プロトタイプを設計確認ツールとして使用します。

通常、人々はすぐに指摘するように、ソフトウェアの利点の1つは、ハードウェアに比べて変更が簡単で比較的安価であると想定されていることです。これは、根本的に何かが間違っていることに気づいたときに特に重要です。ハードウェアでも同じことをすると、100万ドルを失うので、あなたが言ったように、シミュレーターなどを使用して、そこからバジンガをテストします。これは、ソフトウェアに移行したときにパラダイムがいくらか失敗するところだと思います。

平均的なソフトウェア開発者の頭の中に入りましょう。あなたが持っているのは、非常に忙しい人で、締め切りは非常に厳しいです。彼のマネージャーは、後からいつでも修正できるので、いくつかのバグを残しても大丈夫だと言っています。多くの場合、テストは再考されますが、テスト駆動シナリオでも、テストは最小限に抑えられ、コードは最小限のテストに書き込まれ、多くの場合、境界ケースの多くが見落とされるようにショートカットが使用されます。システムは完全にユニットテストされますが、全体として厳密にテストされることはまれであり、ストレステストは非常にまれです。これに加えて、ソフトウェアをゼロから作成します。ソフトウェアを作成する前に、ソフトウェアをシミュレートする機会はほとんどありません。これは主に、ハードウェアにあるようなきめ細かいビルディングブロックからソフトウェアを作成することはめったにないからです。

OPの質問に戻ります。すべてのソフトウェアの派生元となるビルディングブロックのシステムを定義できますか？おそらく。費用対効果は非常に高いでしょうか？おそらくそうではないでしょう。なぜなら、この理想をサポートするのに十分な堅牢なコンポーネント、テスト、およびその他の道具のシステムを開発するまでには、プログラミングシステムでは、競争がすでに市場に打ち勝っていることに気付くでしょうし、さらに悪いことに、平均的なプログラマーの観点からすると、おそらく「クッキーカッター」スタイルのプログラミングシステムは非常に制限的であり、非常に可能性が高いでしょう退屈な。私は個人的にAPIに取り組んでおり、モジュールコードの大部分が完全に洗練されて標準化されているため、コードテンプレートを生成して空白を埋めるだけです。私の時間の大部分は、単純なコネクタコードを記述し、できるだけ早くモジュールをドアから取り出すことに費やすことができます。それは真剣に心を落ち着かせる。同じ種類のものを何度もコーディングする以上のことを行う機会はほとんどないので、別のプロジェクトの機会が来たとき、私は他のことをする機会に飛びつきます。

それでは、どのようにして高品質で十分にファクタリングされたソフトウェアを提供し、実際にそれを楽しんでいるのでしょうか？これは、ツールと方法論の選択に帰着すると考えています。私にとって、答えは、優れたBDD APIの使用を採用することでした。なぜなら、非常に読みやすく、しかも非常にきめ細かいコードを作成できるからです。最小限の再利用可能なメソッドから一連のテストを構築し、仕様の言語でテストを記述することができます。このようにして、ビルディングブロックの設計とチェックを担当するという事実を除き、よりコンポーネント化された開発アプローチに近づきます。さらに、テスト出力は、障害が発生したテストの正確な部分を特定するため、障害がセットアップにあるのかアサーションにあるのかを推測する必要がありません。

方法論の調整も役立ちます。私は、無駄のない開発プリンシパルを適用し、アジャイル運動が長年にわたって強打してきた他の多くのテクニックやプリンシパルと組み合わせることを強く支持しています。私がこれまでイライラすることが多かった無駄な慣行のほとんどを排除したことは、開発をより楽しい活動にするために大いに役立ちました。バグがコードに表示されることがありますが、あまり頻繁ではないことを願っていますが、今ではより多くの時間を費やし、より堅牢なテストを作成し、100テスト範囲の割合。さらに良いことに、これらの緑色のライトがすべて私の一日の終わりに表示されるのを見るのは本当に素晴らしい気分です。

ソフトウェアに関する私の主な不満の1つは、「完了」しないことです。追加する別の機能が常にあります。

それがあなたをイライラさせるなら、別のキャリアを考えてください。真剣に。

ソフトウェアのポイントは、機能を追加できることです。そもそも「ソフトウェア」を発明した理由は、機能を追加できるようにするためでした。

多くの場合、機能を追加すると、以前は正常に機能していた別の場所にバグが発生します。

これはQAの問題です。

これは、インターフェイスに違反していない限り、ハードウェアでは発生しません。

それはソフトウェアにも当てはまります。

既存のコードを書き直したり新しいバグを導入したりすることなく、常に前進を続け、新しい機能を追加できる優れたソフトウェア開発方法論はありますか？

はい。実際に品質保証を実践する必要があります。

ハードウェアが「書き込まれる」のと同様の方法でソフトウェアを書くことは可能ですか？既存のコードを書き直したり新しいバグを導入したりすることなく、常に前進を続け、新しい機能を追加できる優れたソフトウェア開発方法論はありますか？

設計とソフトウェアの正確性を検証するための「正式な方法」を検討することをお勧めします。ハードウェア設計に使用するシミュレーターツールは、何か近いことをしようとしています。現時点では、正式な方法のツールは業界で有用であるとは思わず、欠陥のないインセンティブが強い業界はアビオニクスと医療だけです（興味深いことに、FDAは「ソフトウェアは異なるそのリンクの「ハードウェアから」）。さらに、Verilog / VHDLを使用して開発している場合、バイナリロジックに固執しています。これにより、複雑さが大幅に軽減されます。Y2Kの問題に相当するハードウェアは存在しません。

大きな問題は、物事が複雑であることです。そして、複雑さを排除することはできず、動かすことしかできません。

「完了」し、決して変更する必要のないハードウェアを作成することができます。インターフェイスと機能を定義し、テストベンチを作成し、ハードウェアモジュールを実装し、シミュレータを使用してテストします。次に、そのハードウェアモジュールをビルディングブロックとして使用して、より大きくより良いものを作成できます。そのモジュールに機能を追加する必要がある場合は、2番目のモジュールを作成し、そこに機能を追加します。元のモジュールは問題なく機能し、引き続き有用であるため、元のモジュールを捨てることはありません。

ソフトウェアの世界では、この「モジュール」をライブラリと呼び、同じように使用します。多くのライブラリは、それらがうまく機能するまで構築され、その後、重要な何かが次の改訂につながるまで、変更なしで満足して仕事をします。それらをエポキシで埋められたソフトウェアと考えてください:-)

ソフトウェアに関する私の主な不満の1つは、「完了」しないことです。追加する別の機能が常にあります。多くの場合、機能を追加すると、以前は正常に機能していた別の場所にバグが発生します。これは、インターフェイスに違反していない限り、ハードウェアでは発生しません。

ホグウォッシュ。たぶん、あなたは他の多くのはんだごてでない「ハードウェア」の人々よりも個人的には優れているかもしれませんが、私は多くの悪い回路設計、失敗したチップ（例えば、有名なIntelの「f00f」問題）を見てきましたが、そうではありません全体としてフィールドに話します。そして、偽物のハードウェアが「柔らかくなる」につれて、問題を防ぐのが難しくなります。

ハードウェアが「書き込まれる」のと同様の方法でソフトウェアを書くことは可能ですか？既存のコードを書き直したり新しいバグを導入したりすることなく、常に前進を続け、新しい機能を追加できる優れたソフトウェア開発方法論はありますか？

はい。これらの方法論はあまり使用しません。それらは操作するのに非常に高価になる傾向があり、ほとんどのプログラマーは制限内で作業することを楽しみません。しかし、人間の生命が関与している場合、たとえば、ええ、ユーザーを殺さないようにします。

最後のポイント：ソフトウェアには、ハードウェアとは異なる財務モデルがあり、プログラムされたハードウェアもあります。ほとんどの非消費者ソフトウェア、および一部の消費者ソフトウェアも、変化を促す方法で販売されています。「今すぐ$ 10,000を支払うと年間18％支払う」というビジネスを伝えることができれば、数年ごとに製品を再販売することができます。しかし、その料金を正当化するには、顧客が望む変更を提供する必要があります。うーん... Appleのハードウェア廃止曲線を考えると、おそらくこれは結局のところ違いではないでしょう-ハードウェアはあなたにそれを本当に再購入させます！

動作中のコードにバグを導入せず、常に前進を続けることで、ソフトウェアをより楽しく書くにはどうしたらいいですか

あなたの質問に対する最終的な答えを見つけたいです。しかし、現実にはそれを行う簡単な方法はないため、極端なプログラミングとTDD技術が非常に人気を博しています。変化が起こるため、変化を受け入れる必要があります。このように面白いのかどうかはわかりませんが、確かにストレスが少ないです;-)

http://en.wikipedia.org/wiki/Extreme_Programming

ハードウェアとやり取りするとき、ハードウェアにはxの値とそれがすべて（理論的に）必要ですが、今日の人々とやり取りするときはxが必要であり、明日はyが必要な場合があります。 。Persons！=マシンであるため、ほとんどの場合に変更しないコードは不可能です。

また、以前の/削除された答えで述べたように、コーディングを開始する前に人々に考えさせることにより、重要ではない変更を避けるようにしてください。意思決定などにより多くのユーザーを巻き込みます。変更のコストを明確にし、より多くの計画を立てます。これらは「コーディングの方法」ではなく、「コーディングしない」方法です。

同様の方法でソフトウェアを書くことは可能ですか？

はい、そうです。ハードウェアを開発している場合と同じように注意して、できる限りすべてをテストしてください。そうすれば、ソフトウェアの品質は同等になります。

ところで、HWのバグを聞いたことはありませんか？ソフトウェアのバグだけでなく、ソフトウェアのアップグレードだけでなく、修正が難しい

また、ハードウェアのソフトウェアバグがしばしば人を殺す可能性があることを指摘します。そのため、要件を徹底的に決定し、それらを事前に広範囲にテストするためにさらに注意が払われます。そして、これらの要件は、ハードウェアが変更されるまで変更する必要はありません。そして、新しいハードウェアは書き直しを必要とするかもしれないので、私はクラフトもそれほど蓄積しないと思います。

一方、ビジネス要件は絶えず変化しており、変更が要求される前に1つの要件を本番環境に取り込むことができない場合があります。時々、実稼働に入る前に要件を複数回変更しました。これはいくつかの結果です。まず、ビジネス側のプロジェクト関係者は、「忙しく」「重要」であり、人々が死なず、家族が彼を訴えるか、刑務所に入れられるので、彼が望むものを徹底的に定義するのに時間を費やすことにあまり興味がありません彼はプロセスの一部を吹き飛ばします。第二に、プロジェクトの利害関係者は、ハードウェアが抽象的ではないため、ハードウェアに何をさせたいかを実際によく知っている傾向があります。彼らはそれを見るまで本当に欲しいものを知りません。これはハードウェアの問題ではありません。

「ブリック」と呼ばれる完成した多くの高レベルのツールがあり、それらを組み合わせてアプリケーションに組み込むことができます。レンガはあなたが使用するための完成品であり、あなたはそれらを一緒に組み合わせる必要があります。たぶんそれは簡単だと思うかもしれません...顧客が奇妙で予期しない変更を要求するまで。