「便利な使い捨て」スクリプトはどのように処理する必要がありますか？

あなたはそれがどのように行われるかを知っています：作業の95％を迅速に自動化する方法を見つけたいくつかの小さな反復的なタスクがあります。スクリプトを作成して実行し、出力を手動で修正すれば完了です。もちろん、スクリプトは会社の品質要件に適合しないため、コミットしません（ドキュメントもテストもないため）。

しばらくして、同じような作業をしている同僚がいます。あなたは「ねえ！そのためのスクリプトを作成しました。調べてみましょう。[見える]ああ、それは以前のラップトップに保管されていたので、もう持っていません。残念です。」

これらのスクリプトは多くの場合、多くの時間を節約することができ、チームのリーダーとして、バージョン管理に保存してほしいと思います。ただし、他のコードベースと同じ厳格な標準をこれらのスクリプトに課すと、ほとんどの開発者はそれらを自分たちに守ってくれると思います。

私が思い付くことができる他の唯一のオプションは、開発者がバージョン管理の特別な部分にスクリプトを保存できるようにすることです。バージョン管理の（GitHub Gistsのように）品質管理はありません。リスクは、他の人がコードを見つけたり理解したりできないためにコードを使用できないことです。

この問題はどのように解決できますか？それとも解決すべきではないのですか？

私が思い付くことができる他の唯一のオプションは、開発者がバージョン管理の特別な部分にスクリプトを保存できるようにすることです。バージョン管理の（GitHub Gistsのように）品質管理はありません。リスクは、他の人がコードを見つけたり理解したりできないためにコードを使用できないことです。

この問題はどのように解決できますか？それとも解決すべきではないのですか？

問題は解決できません。

同僚が特定の困難に直面していることを耳にしたときに口コミでコードを共有することと、すべての人がアクセスできるライブラリにコードを置くだけでコードを共有することには大きな違いがあります。

違いは、最初のケースでは、問題と暗黙的にそれを解決するコードについての知識を持つ作成者と司書の役割を演じているのに対し、2番目のケースでは、それらの役割は存在しないということです。

コードの一般的な標準は、社内での司書の役割を排除し、ライブラリがすべての参加者が自分でナビゲートできるように設計されている場合があります。

（ほとんどのコアソフトウェア製品の特徴である）長期間有効なコードの膨大なエディフィスにより、エディフィス全体で作業を続ける複数世代のワーカーの能力を維持するための時間と労力が正当化されます。従業員の離職率が高い会社では、従業員の「世代」は毎年1〜2人程度です。

しかし、もちろん、「ライブラリアンレス」の標準を達成するには、そもそもライブラリを作成する人たちにとって多大な時間と労力が犠牲になります。それでも、後でライブラリを使用して移動する人にはかなりの時間と労力が必要ですエディフィス全体を最初から再作成するのと同じ努力ではありません。

一方、これらの迅速で汚いスクリプトのほとんどは、簡単なことをすばやく行うために（おそらく1回限りで）作成されます。それらは複雑で堅牢な作品ではありません。

あなたは彼らが「時間を節約する」と言いますが、もちろんこれは彼らがはるかに高い司書なしの標準に書かれていない場合にのみ当てはまります。それらはそれらを作った人々の個人的な建設ジグです-一時的なてこと人間の努力の足場であり、最終的な耐久性のある製品ではありません。

それらをバージョン管理にチェックインして、作成者がそれらを体系的に保存して保存できるようにする必要があります。ただし、それらが作成者の監督下にある製品を表すことも明らかです。

あなたが彼らのコードを読んですぐにそれが何をするかを見ることができれば、はるかに良いです。しかし、それは作成者の個人的なライブラリであり、他の人々が作成者に関係なくそれが何をするかを見ることができなければならないという基準で保持されていません。

これはチームが負担する「リスク」ではありません。家にある私物を配置することは、借りることを希望する可能性のある人にとって「リスク」である以上です。それどころか、家の中身全体を索引付けし、それらを決められた方法で整理し、すべてのアイテムに取扱説明書を提供しなければならないことは、家の継続的な効率的な使用にとって深刻なリスクです。

あなたの痛みが分かります。おそらく、これらのスクリプトを格納するためのオプションは、リポジトリの別の部分を持つことだと思います。ただし、これは問題の一部しか解決しません。あなたはそれらをどこかに保管しましたが、同僚がそれらがそこにあることを知る良い方法はありません。

スクリプトが豊富でさまざまな顧客向けに書かれていて、通常は現場にいる会社のコンサルタントとしての私の経験では、すでに何が存在するかを見つけるのは難しいです！

あなたは自分が構築したものを共有する方法を見つける必要があります。

私たちの会社ではそれほど大きくないので、スクリプトなどをリポジトリにチェックインするだけでなく、新しい解決策を同僚に知らせるために全社的なメールを送信します。このように、少なくとも誰もがすでにそこに何があるか、そして彼らがそれを必要とするなら誰に連絡するべきかを知っています。

他の人は、「便利な使い捨て」スクリプトをレポに入れるのに十分なものにすることができるようにする方法と理由をすでに説明しています。私はお尻を突っ込むつもりだし、それを確実にすることも同じくらい重要だと言っている。

別の言い方をすれば、それらはレポに入るのに十分であるか、そうではなくて捨てられなければなりません。それらが捨てられない場合、それらは管理されない、そして最終的に管理できない、メンテナンスの負担になります。

まず、標準のために開発者がコードを提供することに消極的である場合、標準が厳しすぎるか、開発者の品質と作業倫理を改善する必要があると言います。これらが小さなスクリプトである場合、いくつかのコメントを入力するために余計な労力は必要ありません。開発者はデフォルトで読み取り可能なコードを書く必要があります。そうでない場合、本当の問題はスタッフの配置にあります。

あなたの質問に答えるには、いくつかのオプションがあります：

1. スクリプトが十分に汎用的である場合、スクリプトを別のリポジトリでホストできます。スクリプトが非常にプロジェクト中心である場合、これは機能しない可能性があります。
2. 独自のディレクトリにある同じリポジトリのスクリプトをホストします。たとえば、私の会社では通常、プロジェクトにcli/少数のコマンドラインスクリプトを含むディレクトリがあります。これは、通常、環境の初期化、特定のデータのインポートなどのために1回限り実行されることを目的としています。
3. これは、ニーズによっては不十分なオプションになる可能性がありますが、何らかの理由で標準に明確に準拠していないコードをコミットできない場合や、スクリプトを作成する意思がない開発者がいる場合これらの標準に従う必要がある場合は、ファイルを共有ドライブなどでホストできます。ソース管理のすべての利点が必要な場合、これは最高のソリューションではない可能性があります-ただし、状況によっては有益な場合があります（この編集についてDoc Brownに感謝）

最初の2つのオプションのいずれかを使用すると、他のリポジトリまたはディレクトリのいずれかに、より緩いコーディング標準を制定することができます。

プロセスの形式化を開始します。

これらのスクリプトが何のために使用されているかについての手がかりはあまりありませんが、さまざまな展開および保守タスク、または開発者に渡される一般的なデータ修正があり、それらは修正するのに十分な知識があるためです。物事？

あなたはこれについてより専門的になるように努めるべきです。

• これらのタスクとは何か、およびそれらを完了するための手順を書き留めます。
• そのドキュメントを内部のWebサイトまたはイントラネットで公開する
• タスクが実行される頻度と、チケット発行システムでの所要時間を記録します。
• プログラムで手動の手順を自動化しますが、ソース管理、テスト、サポートなどはスキップしないでください。適切な管理ツールを開発してください。
• 可能な場合は独自のソリューションを開発するのではなく、サードパーティのツールを使用してください。それは新入社員にとってより簡単になります

目標は、ドキュメントをフォローするか、ツールを実行することで誰でも実行できるプロセスを純粋に重要な機能にすることです。

次に、開発者を製品の機能の記述に戻し、日々の問題に対処するためにサポートスタッフを雇うことができます。

ほとんどすべてのスクリプトは、何らかの方法で再利用する可能性があります。しかし、その可能性は最初は明らかにならないでしょう-そのため、当時は使い捨てと見なされていました。

チームにGithub Gistのようなリポジトリソリューションを提供します。品質管理は一切行わず、その使用を奨励し、その可能性の損失を防ぎます。

ただし、適切な品質管理が行われている共有ツール/ユーティリティ用の1つ以上のリポジトリも持っています。

その使い捨てリポジトリに格納されたスクリプトが参照された場合にのみ、再利用の可能性が明らかになります。正式な再利用が必要になるのはこのときであり、個々の開発者がその可能性を認識するか、参照がチームコンテキストで発生するかどうかによって開始されます。これは、チームの能力、スケジュール、負荷などに応じて、最初の参照で発生する可能性があり、または後続の参照で発生する可能性があります（つまり、再利用の可能性が高いことが確認された場合）。

リスクは、他の人がコードを見つけたり理解したりできないためにコードを使用できないことです。

参照自体がfind問題を処理します。スクリプトの作成者やリファレンスを作成する人が問題を解決できる可能性がありunderstandます。そうでない場合-再利用の可能性が実際にないか、コードを理解することは、正式な再利用の取り組み/コストの一部にすぎません。

いったん開始されると、正式な再利用の取り組みはチームのレーダー画面に表示され、結果は最終的に共有ツール/ユーティリティリポジトリに配置されます。これは、再利用の元になった同等の使い捨てスクリプトを削除できる場合です（それらの可能性がなくなった場合）。

特に不適切に書かれたが機能的なコードに焦点を当てます。これらをリポジトリに置かないようにする非常に強い議論があります。

個人のDropboxフォルダにスニペットのコレクションがあります。それは私が役立つと思うものを含んでいます：

• 一般的なEFリポジトリの例
• シンプルなシリアライザー/デシリアライザー
• 2つのCSVファイルをクロス結合して新しいCSVファイルを出力する小さなアプリケーション。

しかしながら：

• EFの例には作業単位の実装がなく、最も基本的なCRUDオプションしか含まれていません。
• シリアライザーは古いXmlSerializerに基づいており、他のものと交換することは不可能に近いです。また、大量の循環参照の問題があります。
• アプリケーションは、アプリケーションディレクトリでa.csvとb.csvを探すようにハードコードされ、同じディレクトリにハードコードされたab.csvを出力します。ファイルが存在するかどうかのチェックはなく、null参照の処理もありません。

迅速に実装する必要がある場合でも、これらのスニペットを定期的に使用していますが、再利用や構築は簡単ではありません。これを弊社のバージョン管理に入れられない理由はたくさんあります：

• 自己文書化しない。
• 私自身のハックスタイル以外のコーディングスタイルはほとんどありません。
• エラー処理はありません。
• すべての落とし穴が明らかであるとは限りません（例：シリアライザーの循環参照）

しかし、これらすべてのスニペットの最も一般的に共有される特性：

• ドキュメントを作成したとしても、自分で作成するよりも、読んで理解するまでに時間がかかるでしょう。

これらのスニペットは、使用目的、使用方法、および遭遇した落とし穴を個人的に覚えているため、使用するのに適しています。
しかし、私がいなくても他の人にこれらのスニペットへのアクセスを許可した場合、彼らはこれらのスニペットが何らかの形で役立つとは思わないでしょう。

スニペットは、開発者としての私の経験の延長にすぎません。私がいなければ、これらのスニペットはゴミです。クラスの構文全体を最後の文字まで覚えられないため、スニペットのみを使用しています。しかし、私は最後にスニペットを使用した後でも、意図と落とし穴を覚えています。

このように考えてください：

ダクトテープは非常に用途が広く、多くの問題を解決できます。ただし、ダクトテープを使用して解決されたものは一般的に見苦しいと見なされます。イケアがすべてのフラットパックにダクトテープを含めるとしたら、実際にそれを必要とする一部の人に役立つかもしれませんが、イケアが販売した家具の品質に対するイケアの信頼についても強く表明します。

同じ理由で、製品全体の品質に問題があるため、バージョン管理でハッキースニペットを許可しないでください。