この記事では、自己欺ofの結果としてプログラムを作成する条件を超えるという問題を考慮しています。まるでプログラミングが単純で、さらに単純であるかのように。 ソフトウェア開発分野の新技術の作成者は、彼らの技術が膨大な数の問題の解決に役立つことを保証し、ソフトウェア開発がこれまで以上に簡単かつ迅速になっていることを保証します。 しかし、練習は容赦ありません。 次のプログラムプロジェクトを完了するための期限は何度も中断されます。
はじめに
ソフトウェア開発の失敗は、ソフトウェア製品を作成する際によくあることです。 この現象は、非常事態で働くことを余儀なくされる一般的な開発者から、ラグや追加費用に耐えることを余儀なくされる管理者や顧客で終わるプロセスのすべての参加者にとって有害です。
これには多くの理由がありますが、この記事では、ソフトウェア開発は単純であると広く信じられていることが主な要素であるという意見を表明したいと思います。 すぐに興味深い点を強調します。 一般に、プログラムの作成は資格と時間を必要とする労働集約的なプロセスであると誰もが理解していますが、議論やプレゼンテーションになるとすぐに、誰もが自分の興味を追求し、すべての困難は過去と現在にあり、新しい技術を使用していると言い始めます/プログラミング言語/方法論、すべてが簡単でシンプルになります。 これは長年にわたって繰り返されてきました。 一般に、改善はなく、期限はまだ決まっています。 この記事で説明するのは、これらの現象の原因とその結果です。
なぜこれらの問題について考えたのですか
一般的な推論ではなく、個人的な経験から進めます。 プログラマーPVS-Studio用のツールを作成しています。 これは、64ビットシステム用に作成されたプログラムまたはOpenMPテクノロジーを使用して作成されたプログラムをチェックするための静的なC / C ++コードアナライザーです。 このようなプログラムでは、多くのエラーパターンが発生しますが、ソースコードを分析することで簡単に診断できます。 しかし、それはポイントではありません。 実際、これらのツールのプロモーションに参加している間に、64ビットテクノロジーとOpenMPの使用が非常に単純なものとして提示されているという事実に起因する多くの抵抗に遭遇しました。 この自信の結果として、問題はなく、あり得ないと信じる人々の大きな抵抗を克服する必要があります。 私は彼らの穏やかな世界の敵のようでした。 もちろん、他のテクノロジーでも同様の状況が見られますが、この記事では、OpenMPテクノロジーと64ビットプログラムについて、最も馴染みのある分野として説明します。
すべてが単純であるという信念は驚くことではありません。 あらゆる点で、プログラムをいかに簡単に64ビットにできるかを説明し、すぐにパフォーマンスを向上させ、大量のメモリを使用できるようにします。 OpenMPを使用して、コードを簡単に並列化する方法を説明しています。 「アプリケーションを再コンパイルするだけ」、「OpenMPディレクティブの単純な配置」の精神でこれらを含む記事について。 そして、この素晴らしい人生の休日に、「C ++コードを64ビットプラットフォームに移植する20の落とし穴」、「C ++でプログラミングするときのOpenMPの32の落とし穴」という記事の大きな見出しを付けたポスターを取り上げます。 同時に、私はすべてに不満であり、常にすべてに不平を言う有害な厄介な老人のように感じます。 この不思議な感覚と「単純さの伝道者」への抵抗が、私にこのテキストを考えさせ、書いたのです。
たぶん私は実際に間違っているという考えを熟考した瞬間がありました。 私たちは、それがどれほど簡単であるかをみんなと話す必要があります。 そして、私たちのツールを使用すると、すべてがまったく簡単になります。 しかし、何かが間違っています。 矛盾があります。 私は状況をよく理解しており、並列技術と大量のメモリを備えた64ビットシステムを習得するのにプログラマを待つのは難しいと確信しています。 この単純さはありません。 これはデマです。 そして、欺ceptionは有害です。 自分のツールを宣伝することに興味がある人として、それは私にとって有害です。 タイミングを正しく予測できないリーダーにとって有害です。 そして、もちろん、それはプログラマーにとって有害です。プログラマーは、新しいテクノロジーと残業への失望を待っています。 したがって、私は自分の立場に留まり、あなたの視点も変えようとすることにしました。
難しさはどこから来るのか
64ビットプログラムの作成はそれほど難しくなく、多くのプログラムを修正せずに64ビットシステム用に再構築できることを、私に納得させることができます。 また、さまざまな手法を使用してエラーを自動的に検出および修正できます。 これは簡単ではありませんが、これらのプロセスの複雑さや、期限を数回間違えるのがどれほど簡単かを説明した経験があるので。
しかし、並列プログラミングも提示されている場合、これは現実との完全な矛盾です。 並列プログラミングは、ループの周りにOpenMPディレクティブを配置したり、何らかのライブラリを使用したりするだけでは解決できない、複雑で複雑なタスクです。 しかし、それはそれが提示される方法です。 並列アルゴリズムの作成についてまだ研究していない多くの開発者は、それについて考える必要はなく、OpenMPまたは他のテクノロジーが状況を修正すると言っています。 そのような記事から、プログラムを並列化する方法は簡単で理解しやすいようです。 しかし、読者ができないことや事前に確認できないことの普及は、理解の幻想だけを生み出します。 おそらくそれは彼の語彙を豊かにし、どういうわけか彼の思考を広げますが、同時にそれは本当の理解と知識がないところに不必要な理解の幻想を作り出します。
これは、OpenMPまたは他の技術が悪いことを意味するものではありません。 彼らは素晴らしいです。 しかし、あなたは彼らができることとそうでないことを理解する必要があります。 既存のプログラムを簡単に並列化しようとは思わないでください。 ほとんどの場合、これには新しいアルゴリズムの作成と、データ構造とそれらを操作するためのメカニズムの変換が必要になります。 OpenMPを既存のコードに簡単に組み込むことができるため、この統合により、他のテクノロジを使用する場合よりも変更が少なくなることを理解してください。 そのため、MPIテクノロジーを使用すると、APIやネットワークプロトコルを直接使用して同じ機能を実装するのに比べて、分散システムを簡単に構築できます。 同様に、MPIは共有メモリを備えたマルチコアシステムでは不必要に複雑であり、コードの大幅な変更が必要です。 それに比べて、OpenMPは非常に簡単に統合できます。 しかし、比較と特定のクラスのタスクでのみです！
使用されているテクノロジーに関係なく、並列プログラミングの単純さについて話すことは不可能です。 この領域はそれ自体が複雑です。 確認したい場合は、すぐに座って、誰もが学校や研究所で書いた配列ソートアルゴリズムを並列化してみてください。 それがうまくいかない場合は、Butcherの並列ソートを見てください。 すぐに想像できますか？ 想像できません。 この例は、プログラムで使用される通常のアルゴリズムを使用した場合でも、どのような困難が予想されるかを示すために作成されています。 しかし、他にもたくさんの側面があります。
おそらく、C ++プログラムのループでイテレーターを使用しますか？ OpenMPに関する一般的な記事で、並列化の例を示しているときに、イテレータを使用できないことを警告するのを忘れていることを知っていますか？ インデックスは単純なデータ型（intなど）でなければなりません。 つまり、アルゴリズムの変更の時間を計画するときは、データ構造とそれらを操作する方法も変更する必要がある場合があることに留意してください。 そして、これはすべて余分な時間と労力です。 はい、OpenMP 3.0にはイテレーターを使用する機能があります。 OpenMP 3.0の出現前の記事は、その使用のトピックを回避しました。 新しい記事は、「イテレータを使用できるようになったため、OpenMP 3.0でプログラムを作成しやすくなりました」というスタイルで書かれています。 はい、今はそのような機会があるのは良いことです。 しかし今、存在するニュアンスと困難の数を想像してください。しかし同時に、実際にはどこにも記述されておらず、あなたは自分自身に直面しなければなりません。
すべてが複雑な場合、なぜそれが単純であると言うのですか？
あなたをだまして、すべてが単純であることをあなたに納得させたい悪党はいません。 しかし、相互欺ceptionにつながるさまざまな利益があります。 64ビットハードウェアプラットフォームとオペレーティングシステムを宣伝する人は、当然、アプリケーションをそれらに転送することは非常に簡単であると確信することに興味があります。 これは理解できます。 64ビットシステムへの移行はすでに進んでおり、困難があると言えば、これにより移行がさらに数年延長される可能性があります。
並列システムのメーカーは、さまざまなソフトウェアテクノロジとライブラリを宣伝し、すべてがほぼ単独で並列になることを確信しています。 これらのライブラリ/テクノロジーを作成する人は、自分のライブラリ/テクノロジーが最も簡単であるため、それが最良であるとプログラマーを説得しようとします。 そして、ここで悲しい混乱があります。 ライブラリがシンプルで便利であるという事実（たとえば、私の意見では、OpenMPはシンプルで便利です）は、並列プログラムの作成もシンプルであることを意味しません。
プログラマーは、64ビットおよびパラレルの世界ですべてがうまくいくことについて多くの記事を読んで、まだ練習をしていないので、締め切りについて管理者自身を欺きます。 管理は顧客をだます。 また、管理者自身はすべてをシンプルにすることを好みます。なぜなら、これにより開発者を節約できるように思えるからです。 その結果、加害者はいませんが、全員がお互いを欺いています。
結論
すでにこのテキストを書いている過程で、ダイクストラの注目すべき記事「プログラミングに関する2つの見解」[1]を見つけました。これは多くの点でこの記事と意味が交差しています。 上記のすべてを非常によく要約した小さな抜粋を引用します。「基本的に、これは単純な製品を販売しているようにビジネスを行いたいコンピューターメーカーのせいではありません。 プログラマーの活動を単純で予測可能なプロセスと見なすことを好むソフトウェアプロジェクトマネージャーの責任ではありません。 保証された成功のために学生を準備したいのは教育機関のせいではありません。 これは、人間は複雑なオートマトンに過ぎないという錯覚の結果であり、麻薬のように、犠牲者に責任の負担から明らかな解放をもたらす幻想です。 プログラミングが知性に対する重大な課題であると認識すれば、この負担の重さを肩に戻すことになるでしょう。」
しかし、重荷は目を閉じたままにしておくべき理由ではありません。 誰もがこれに負けます。 複雑さをそのまま受け入れる必要があります。
これらすべてからの結論は、最新のテクノロジーの能力をより批判的に見ることです。 新しいツールとテクニックは便利ですが、多くの段階と要素で構成されるソフトウェア開発プロセス自体を置き換えることは不可能であり、不可能です。 まず第一に、開発プロセスを学び、改善する必要があります。その後、プロジェクトに便利な新しいテクノロジーを選択します。
円形の「単純さの欺 "」から抜け出すのに不可欠なヘルパーは、スティーブマッコネルの素晴らしい本「ソフトウェアプロジェクトはいくらですか」[2]と[完全なコード] [3]です。 そして、もちろん、フレデリックブルックスの象徴的な本である「神話上の人間の月、またはソフトウェアセットの作成方法」[4]。
書誌リスト
1. Edsger Dijkstra。 プログラミングに関する2つの見解。 URL http://www.inr.ac.ru/~info21/pdf/dijkstra.pdf2. McConnellS。ソフトウェアプロジェクトはいくらですか。 -M .:「ロシア語版」、サンクトペテルブルク：ピーター、2007。-297 pp。、Ill。
3. McConnell S. Perfect Code。 マスタークラス/あたり -M .: Publishing House "Russian Edition"、St. Petersburg：Peter、2007.- 896 pp。、ill。
4.フレデリックブルックス。 神話上のマンマンまたはソフトウェアシステムの作成方法。 -あたり 英語から -SPb。：Symbol-Plus、1999、-304 p。：病気。