ソフトウェアの再利用はプロセスの再現性を妨げますか

問題としてのコードの再利用

私が考えていたこの質問ソフトウェア・デリバリーに、私は問題に戻って来るまま再現性および/または再現。プロジェクトを繰り返さないと、プロジェクトのビルドに使用したプロセスを改善することが難しくなるためです。エンジニアリングでは、高品質のプロジェクトを作成するために、設計と建設に関連するプロセスを絶えず改善する必要があります。

ソフトウェアは、そのデジタル形式のために再利用に大きく依存できます。モジュールを書き換える代わりに、もう一度呼び出すか、他のシステムにコピーします。いくつかの例は、認証/ログインまたはおそらくロギング機能です。これらのカテゴリには多くのよく知られた例があります。そして、従来の知恵は、あなた自身のものを転がす代わりに存在するものを再利用することです。

他の分野とのいくつかの比較

建設

対照的に、物理システム（建物、橋）の建設は、再利用できるほど近くはありません。家の設計図を何度も再利用して同じ家のコピーを作成できることは事実ですが、そのたびに建設を実行する必要があります。アナログの世界では、カットアンドペーストはそのようには機能しません。橋の設計図は、サイトの条件が異なるため、住宅よりも再利用性が低くなります。

マスタービルダーは、その地域で数十、数百、または数千のものを設計および/または構築したことで知られる専門家です。たとえば、世界的に有名な建築家およびデザイナーであるフランク・ロイド・ライトdesigned more than 1,000 structures and completed 532 works。「ちょうど」5つの言語（Turbo Pascal、Delphi、J ++、C＃、Typescript）を設計したAnders Hejlsbergとは対照的です。ドメインが異なるため、多くの点で不公平な比較です。しかし、大まかに言って、2人の非常に知的な人からの定量化可能な作品は大きく異なります。

武道

武道家は、動きの習得は数千の繰り返しからのみ来ると言うでしょう。これらの繰り返しのかなりの部分が投入された後、多くの武道家は、以前は複雑な型または形であると認識されていたことが単純になったことに驚いています。それらの学生のインストラクターは、動きがより流動的で意図的であり、動きが経済的であることにも気付くでしょう。同様に、経験豊富な武道家は、経験の少ない学生よりも複雑なカタをより速く拾うことができます。繰り返しの経験から、より迅速に学習できるフレームワークまたはプロセスが得られました。

木工

木工労働者も同様の変化を経験します。趣味の木材職人は、多くの引き出しを必要とする最初のプロジェクトを常に参照しています。彼らがプロジェクトを完了すると、彼らは組立ラインが生み出す効率性に新たな評価を得ることができます。木材を最大限に活用するために、シートストックに引き出し部品をレイアウトする方法をよりよく理解するなど、他の利点もあります。愛好家と比較して、プロの木材労働者は、以前に何度も作ったアイテムをより迅速に設計、開始、および構築することができます。彼らはまた、他の誰かの設計に内在する問題を自分の仕事でその間違いを犯したことを見る能力を得ます。

それで、ソフトウェアの再利用はソフトウェア開発者がより熟練するのを妨げますか？

多くの点で、ソフトウェアの設計と構築は常に新しいものです。モジュール、ライブラリ、またはシステムを再利用できる場合は、再利用できるため、過去の作業を繰り返すことはありません。ゼロから全体を書き換える前に、既存のシステムを優先的に拡張します。しかし、繰り返しにより、設計と構造の効率を見つけることができます。スポーツや身体活動を実践したことがある人なら誰でも、繰り返しが良い開業医になるための鍵であることを教えてくれます。

私の質問：ソフトウェアの再利用能力は、プロジェクトを繰り返すことから生じる必要なプロセスの改善と効率を妨げますか？

ソフトウェアを再利用する機能は、プロセスの改善を妨げません。

ソフトウェアの構築に必要なプロセスについて考える場合-要件の開発、システムの設計、システムの実装、システムの展開、要件の管理、構成の管理、作業成果物の検証と検証、変更の追跡、その他多数ソフトウェア開発の主要なアクティビティの内訳として考えられるCMMIプロセス領域）-これらは、再利用の程度に関係なく、すべてのプロジェクトで繰り返されます。さらに、それぞれには、特定のプロセスまたはアクティビティがどれだけ優れているか、その結果として開発プロセス全体がどれだけ優れているかを判断するために使用できる何らかの定量的および定性的な手段があります。

極端な場合、堅牢なソフトウェア製品ラインを想定できます。。他方では、グリーンフィールド開発を想定できます。これらのプロセスはすべて、さまざまな程度で実行する必要がありますが、それらは異なる速度で、またはおそらく異なるシーケンスで発生する可能性があります。たとえば、大量の再利用では、割り当てられた時間の大部分がシステムレベルでの統合および検証/検証アクティビティに費やされる可能性があります（要件V＆V、統合テスト、システムテスト、受け入れテスト）。新しい開発努力により、設計と実装に必要な時間の割合が大きくなる可能性があります。プロジェクトの過程で少なくとも1回プロセスを実行する限り、それを（定量的および定性的に）測定できます。調整を行い、それらの調整がプロセス領域またはソフトウェアを提供する全体的な能力のいずれかの尺度に与える影響を確認したら、

プロセス改善の鍵は、アクティビティとプロセスの何らかの論理的内訳を持ち、それらを測定する方法を（できれば一貫して）決定し、それらの測定値を理解して、何らかの方法でプロセスを変更することです。プロジェクトを繰り返すことではなく、プロセスを繰り返す方法の一貫性についてです。

他の工学分野では再利用を利用しないという考えは間違っていると思います。建物/機械を設計する場合でも、他の多くのプロジェクトで使用されるコンポーネントがあります。たとえば、自分でネジを設計していますか？エンジン？ドアまたは窓？もちろん違います。それらは、多くの場合、異なる製品で使用される異なる人々によって設計されます。そして、それらは非常に頻繁に標準化され、さらに再利用が促進されます。

問題は複雑さにあると思います。最も複雑な建物の複雑さでも、複雑なソフトウェアと比較することはできません。ソフトウェアの複雑さがエンジニアリング側からのアプローチを難​​しくしているのは、一般的に受け入れられている考えです。許容できる品質のソフトウェアを作成できるプロセスを準備した瞬間、作成する必要があるソフトウェアの複雑さは桁違いに急上昇することがわかります。そのため、プロセスは使用できません。そのため、結果に満足するまでソフトウェアの一部を複数回繰り返す必要がある場合、そのソフトウェアを終了することはありません。

そのため、クリーンなコードが推奨されます。新しい経験に基づいて過去のコードを変更する機能は、設計の再利用の一種と言えます。そのため、異なるソフトウェアを何度も作成する代わりに、新しい経験を再利用して古い問題をデザインすることにより、単一のソフトウェアをリファクタリングおよび改良します。ソフトウェアに同じことをさせようとしている間。

ソフトウェアは他のほとんどの分野とは異なるため、私たちが最も時間を費やす場所の経済性はしばしば異なります。

建設では、青写真に一定の時間とお金を費やし（そしてソフトウェアは建物の建設よりも青写真の生産にはるかに近い）、大まかに言えば、実際に1回または複数回それを構築することに多くの時間を費やします。そのため、設計図を正しくするためにかなりの労力を費やすことは価値があります。より具体的には、最終製品を少し良くするためにゼロからやり直す努力を繰り返す価値があります。

ソフトウェアでは、設計図がある場合、設計図を作成するよりも製品を構築する方がはるかに安価です。少なくともほとんどの場合-ソフトウェアがペースメーカーに組み込まれると、何らかの形でブリッジビルダーの状況にずっと近くなります。ただし、一般的に、ソフトウェアを再利用すると、最大の予算項目のコストの90％を節約できる場合があります。したがって、再利用の方がはるかに頻繁に勝ちます。

生産性に関して言えば、橋を建設するとき、現実世界の大きな制約に直面します。建築家が建設費用が0に近く、制限が現実世界よりも大幅に少ない大規模なマルチプレイヤーオンラインゲームの橋を設計するために多額のお金を支払ったと想像してください。彼らは、実世界の橋の標準ではとてつもなく複雑な橋を設計します。ブループリントフェーズには少し時間がかかる場合があります。

また、構築するブリッジの数は限られています。また、設計はコストのわずかな部分であるため、最高の費用を支払うことができ、少数の設計がほとんどの設計を実行できます。ソフトウェア開発者は何十万人もおり、基本的にすべての開発者には時間があればできることの膨大なバックログがあります。あなたはそのすべての大部分を行う一人の男を見つけるつもりはありません-本当に近づいてくるような人々がいるのは驚くべきことです。

あなたの本当のポイントは、物事を繰り返し改善しようとするのではなく、再利用することで何かを失う可能性があるということです。あなたにはポイントがあると思います。問題は、基本的なものの一部を書き直して改善しようとする方がグローバルに効率的である可能性が高いが、それを引き受ける人はすべてのリスクを獲得し、おそらくそれほど多くの報酬を受け取らないことです。（依存性地獄の巨大な実用的な問題もあります。それはおそらく物事を書き直すことからいくらかの勝利を奪いますが、それが価値がないだろうという点ではなく、少なくともグローバルな視点を見ると。提案されたリエンジニアリングの努力により、既存のコードの小さな部分をやり直すために、かなりの量の書き直し作業を強制します）。

繰り返しから学ぶという点では、すべての学問分野において、これは設計よりも建設よりも少なくなります。これは、繰り返しが少ないため、学ぶ機会が少なくなり、おそらく利益も少なくなるためです。また、設計のプロセスは、おそらくそれほど反復可能ではありません。小説を書くプロセスがあるようなものです。優れたプロセスはほぼ確実に役立ち、ソフトウェアは一般に小説よりもはるかに協調的ですが、目標が新しいものを発明することである場合にプロセスを繰り返すことには問題があります。小説家でさえ過去から学びますが、反復可能なプロセスは創造的な努力の二次的な要因です。また、ソフトウェア開発の一部が本当に再現性がある場合、コンピューターがそれを行わないのはなぜですか？

再利用できるソフトウェアの能力は、プロジェクトを繰り返すことから生じる必要なプロセスの改善と効率を妨げますか？

私は過去17年間、同じ大規模なプロジェクトでシステムおよびソフトウェアエンジニアとして働いていました。偶然（最初のリンクでエアバスA380の参考文献を考えて）、航空機業界で仕事をしていました。そのようなストーリーは基本的に純粋なフィクションであり、インサイダーの洞察を持っているときに実際に見るのは本当に面白いです。

しかし、簡潔で簡潔な質問：私の経験から、私はイエスとノーの両方を言います。

最初に、私はすべての形式のソフトウェアリサイクルに専念していると言いましょう（すべてではないかもしれませんが...）。カットアンドペーストのコードスニペットとアルゴリズムから、コードモジュールと関数ライブラリ全体に至るまで、ほぼすべてを再利用することの利点は、常に最初からやり直すよりも全体的にはるかに優れています（少しプッシュすること）。

マイナス面は、指摘するように（または少なくとも推測するように）、コンポーネントの特定のセットを単純に組み合わせて機能を追加する場合（そして、これを極端に単純化します）、実際には進化しませんプログラマー、エンジニア、その他何でも。

職場の私の周りのソフトウェアエンジニアを見るだけで、彼らの大半は知らない、さらに悪いことに、私たちが構築する製品について、学習することに興味がなく、生産に必要な最低限のもの以外は何も知らないことを長い経験から知っています文書またはコードが割り当てられているコード。

私はここでオフトピック少し動揺していますが、私のポイントは、プログラマがいないときということである必要がある、彼らが構築されているコードは本当にために使用されるかを学ぶために、としていない必要があるだけで彼らができるため、システムの内部の仕組みを学びますすでに作成され、テストされたコンポーネントを再利用すれば、それらのほとんどは気にすることはありません。

確かに、これは、私たちが構築している製品が信じられないほど複雑であり、一人がそのすべてを知ることは不可能だというような他の状況によるものですそれらの中で最も複雑なものですが、それでも）。

私たちのソフトウェアエンジニアが、できるだけ多くのコードを再利用するオプションを持っていなかった場合、私は彼らが一般的に彼らの職業でより良くなり、具体的にはプロジェクトにより多くのより大きな資産になると確信しています。

ああ、あなたは私が彼らについてここでたくさん話していることに気づいたかもしれません。もちろん、これらのソフトウェアエンジニアにも含まれています。例外は、私が他の人よりも新しいことに興味を持ち、新しいことを学ぶことに熱心であるように見えることです:-)事実の形式とソースコードを研究することによって（そう、私も実際にそれを楽しんでいます）。

ああ-再び、追跡された...私の言い訳は、私が32時間寝ていなかったので、私の集中力は少しです...私は何を言っていましたか？

まだ読んでいる人がいるなら、私の結論は次のとおりです。

はい、ソフトウェアの再利用が多すぎると、知識の少ないソフトウェアエンジニアにとっては非常に効率が悪くなります。問題分析は良い例であり、提案された設計ソリューションが実行可能かどうかを判断することさえできます。そしてもちろん、あなたが何をしているかを本当に知らない場合、プロセスの改善を達成することはより困難です:-)

そして、はありませんが、ソフトウェアの再利用の注意を払って、潜在的にあなたの予備検討する時間と計画プロセス改善の多くを与えます。

別のプログラマーの質問で受け入れられた答えで指摘されているように、構造との類似性は注意してとられるべきです。

これに関する推奨読書は、Software Construction Analogy is Brokenです。

ソフトウェアはしばしば建設に例えられます。残念ながら、この類推には欠陥があり、建設業界から学んだ教訓は疑わしい...

私が観察したのは、優れたソフトウェアプロジェクトは多くの再現性を品質保証に「シフト」することです。

私が1。5年のプロジェクトでテスターだったとき、私たちは毎週「チェックポイント」リリースでテストサイクルを実行します。これはプロジェクト全体で約70回です。それは...かなり再現性があり、穏やかに言えば（1週間であまり変化はありません）。ナイトリービルドのテストは、当然のことながら、プロジェクト全体で約500回繰り返し可能です（面白いショーストッパーバグはほとんどありませんでした）。

さて、その「疑わしい」アナロジーに続いて、同じチームで500の橋を建設した建設会社を教えてください。

• それに続いて、新しいブリッジのそれぞれでほとんど同じレンガと鉄を使用している会社を教えてください（ここでは、テストしたリリースが毎日同じコードのビットをほぼ毎日持っていたという事実を参照します週-「あまり変化はありません」）。
  

マスタービルダーは、その地域で数十、数百、または数千ものものを設計および/または構築したことで知られる専門家です。

上に引用した再現性の説明に続いて、私はそう言うことができますか？当時、私たちの小さな、それほど特別ではないテスターのグループが検証しました。上記（「約500」）を参照してください。

プロジェクト開発者に関しては、文字通りビルドされています（「ナイトリービルド」）-見て、単語は同じで、このコンテキストでは意味が正しい-彼らの分野で何百もの。

「疑わしい」アナロジーをさらに「数千もの」まで続けたい場合、これらの量は、正しいものを見たときのソフトウェア開発においても目を見張るものはありません。

• 例として、私の過去のプロジェクトのもう1つ（ここでも、目を見張るようなものではなく、通常のプロジェクト）、今回はdevの役割で、5年以上（メジャーリリース8、マイナープロジェクト数十）続けられています。同様の毎週のチェックポイント（5x52~=250それらの）、同様の夜間のリリース（5x365~=1800それらの）、同様にこれらに取り組んでいる同じ開発/ QAチームがありました。毎日、毎週、毎月、ほとんど繰り返しのあるもの（2つのナイトリービルド間で大きな変化はありません）-約束どおり、数千回（1800）の範囲。

WindowsやJava、AutoCADなどの長寿命のプロジェクトは10、20、30年に及ぶことがあり、「数千」のナイトリービルドとナイトリーテストを簡単に繰り返します。

QAへの再現性シフトの概念は、継続的インテグレーションによりさらに顕著になります...

すべての開発者作業コピーを共有メインラインに 1日に数回マージする慣習... CIは、定期的な統合の慣行の強化と見なすことができます。

自動化された単体テストに加えて、CIを使用する組織は通常、ビルドサーバーを使用して、一般的に品質管理を適用する継続的なプロセスを実装します。ユニットおよび統合テストの実行に加えて、このようなプロセスは追加の静的および動的テストを実行し、パフォーマンスを測定およびプロファイルし、ソースコードからドキュメントを抽出してフォーマットし、手動QAプロセスを容易にします。品質管理の目的のこの連続的応用改善するためのソフトウェアの品質を、そして適用する品質管理の伝統的な慣行を交換することにより、それを実現するのにかかる時間を短縮するために、後にすべての開発を完了します。これは、より頻繁に統合して統合を容易にするという元のアイデアに非常に似ており、QAプロセスにのみ適用されます...

再現性？それはまさにそこにあり、考えられる限り多くのものです。

頻繁/継続的なQAにより、失敗したテストは、失敗したテストが成功するまでそれを試行し続けることを余儀なくされる開発者にすぐに戻ります。ある意味では、パスするまで繰り返すというサイクルは、コードカタに似ています。

プログラマーが練習と繰り返しを通してスキルを磨くのに役立つプログラミングの練習...

たとえば、ライブラリは、機械語コードでは解決できない問題を解決するアセンブリでは解決できない問題を解決する高レベル言語では解決されない関数を解決します。javaでSystem.out.println（）を呼び出すと、CPUがデバイスに出力する方法を見失うことになります。

そう、あなたは何かを失っています。あなたが得るものは、未解決の問題に集中する能力です。問題を解決するために、テクノロジーの他の側面（ネットワークの機能など）に没頭する必要があるかもしれません。ただし、Webページを作成するだけであれば、機械語を読む専門家になる必要はありません。

同様に、橋の建設者は毎回わずかに異なる問題を解決しています（その川は異なります）。特定の引張強度の鉄骨梁を作成する方法や、ボルトを特定の許容範囲に加工する方法については心配していません。彼らはその問題を解決した専門家にそれを任せます。

よく見ると、社会全体とインフラストラクチャが99％の再利用と1％の真の進歩で構築されていることがわかります。ほとんどの新しいものは、古いものに少し余分なものを追加または削除したものです。それは人間の知識の蓄積です。誰かがこの点に到達するのに必要な驚くほど複雑なものをすべて見つけたので、適切なライブラリを使用して高水準言語でコードを書くことができます。新しい興味深い問題を解決できます。

これをすべて結び付けてコメントに応答するには：習熟度を高めるためにすでに解決済みの問題を解決する必要はありません。さらに、あなたがしていることの多くは、車輪の再発明です。要するに、答えはノーです-熟練するためにライブラリの機能を再実装する必要はありません。たくさんの機会があり、そのいくつかは暗記され、いくつかは創造性を磨くために創造的です。

リソースがすべてです。数年前、大規模なメインフレームコンピューター用のソフトウェアプロジェクトを開発した場合、静的な開発環境で15年程度使用されていました。給与計算またはCOBOLプログラムを計算するために作成されたFORTRANプログラムは、常に使用されていたため、数十年にわたって完成しました。これをどのように改善できるかを知るためのリソースがありました。特定のプロジェクトのスキルを微調整して磨くために、そのような遅い環境はもうありません。しかし、私たちはスキルを取り入れ、許可された次のプロジェクトリソースにそれらを適応させます。しかし、最終的には、仕事をするために、または大量の金メッキで新しい仕事をするために、新しいプロジェクトに費やされるお金の選択肢になります。プロジェクトの金メッキとは、プロジェクトをn番目の程度まで改善し、ユーザーが追加しなかったとしても大量の付加機能を追加することを意味します。

私たちにできる最善のことは、新しいプロジェクトの全体的なデザインを見て、チームの過去の経験に基づいてどのように改善できるかを確認することです。しかし、実際に経験を積んだソフトウェアアーキテクトは、アジャイル、OOPなどの開発における最新の流行語を単にケーシングするのではなく、実際にスキルを向上させるために設計を改善すると考えられるものについてビジョンを持つ必要があります。