「便利な使い捨て」スクリプトはどのように処理する必要がありますか？
あなたはそれがどのように行われるかを知っています：作業の95％を迅速に自動化する方法を見つけたいくつかの小さな反復的なタスクがあります。スクリプトを作成して実行し、出力を手動で修正すれば完了です。もちろん、スクリプトは会社の品質要件に適合しないため、コミットしません（ドキュメントもテストもないため）。
しばらくして、同じような作業をしている同僚がいます。あなたは「ねえ！そのためのスクリプトを作成しました。調べてみましょう。[見える]ああ、それは以前のラップトップに保管されていたので、もう持っていません。残念です。」
これらのスクリプトは多くの場合、多くの時間を節約することができ、チームのリーダーとして、バージョン管理に保存してほしいと思います。ただし、他のコードベースと同じ厳格な標準をこれらのスクリプトに課すと、ほとんどの開発者はそれらを自分たちに守ってくれると思います。
私が思い付くことができる他の唯一のオプションは、開発者がバージョン管理の特別な部分にスクリプトを保存できるようにすることです。バージョン管理には、（GitHub Gistsのような）品質管理はありません。リスクは、他の人がコードを見つけたり理解したりできないためにコードを使用できないことです。
この問題をどのように解決できますか？それとも解決すべきではないのですか？
私が思い付くことができる他の唯一のオプションは、開発者がバージョン管理の特別な部分にスクリプトを保存できるようにすることです。バージョン管理には、（GitHub Gistsのような）品質管理はありません。リスクは、他の人がコードを見つけたり理解したりできないためにコードを使用できないことです。
この問題をどのように解決できますか？それとも解決すべきではないのですか？
問題は解決できません。
同僚が特定の困難に直面していることを耳にしたときに口コミでコードを共有することと、すべての人がアクセスできるライブラリにコードを置くだけで共有することには大きな違いがあります。
違いは、最初のケースでは、問題と暗黙的にそれを解決するコードについての知識を持つ作成者と司書の役割を演じているのに対し、2番目のケースでは、それらの役割は存在しないということです。
コードの一般的な基準は、社内での司書の役割を排除し、ライブラリがすべての参加者が自分でナビゲートできるように設計されている場合があります。
（ほとんどのコアソフトウェア製品の特徴である）長期間有効なコードの膨大なエディフィスにより、エディフィス全体で作業を続ける複数世代のワーカーの能力を維持するための時間と労力が正当化されます。従業員の離職率が高い企業では、従業員の「世代」は毎年1〜2人程度です。
しかしもちろん、これらの「ライブラリアンレス」標準を達成するには、そもそもライブラリを作成する人にとって多大な時間と労力が犠牲になり、後でライブラリを使用してナビゲートするようになる人々には依然としてかなりの時間と労力が必要です（ただし、エディフィス全体をゼロから再作成するのと同じ努力ではありません。
一方、これらの迅速で汚いスクリプトのほとんどは、簡単なことをすばやく、おそらく1回限りで実行できるように作成されます。それらは複雑で堅牢な作品ではありません。
あなたは彼らが「時間を節約する」と言いますが、もちろんこれは彼らがはるかに高い、司書なしの標準に書かれていない場合にのみ当てはまります。彼らはそれらを作った人々の個人的な建設ジグです-一時的なてこと人間の努力の足場であり、最終的な耐久性のある製品ではありません。
それらをバージョン管理にチェックインして、作成者がそれらを体系的に保存および保存できるようにする必要があります。ただし、それらはcreatorがまだ監視している製品を表していることも明らかです。
あなたが彼らのコードを読むことができればすぐに見るそれが何をするか、そんなに良いです。しかし、それは作成者の個人的なライブラリであり、他の人々が作成者に関係なくそれが何をするかを見ることができるという標準で保持されていませんmust。
これはチームが負担する「リスク」ではありません。家にある私物を配置することは、借りることを希望する可能性のある人々にとって「リスク」である以上です。それどころか、家の中身全体を索引付けし、それらを決められた方法で整理し、すべてのアイテムに取扱説明書を提供しなければならないことは、家の継続的な効率的な使用にとって深刻なリスクです。
あなたの痛みが分かります。おそらく、これらのスクリプトを格納するためのオプションは、リポジトリの別の部分を持つことだと思います。ただし、これは問題の一部しか解決しません。あなたはそれらをどこかに保管しましたが、同僚がそこにあることを知るための良い方法はありません。
スクリプトが豊富でさまざまな顧客向けに書かれていて、通常は現場にいる会社のコンサルタントとしての私の経験では、すでに何が存在するのかを見つけるのは大変です！
あなたは自分が構築したものを共有する方法を見つける必要があります。
私たちの会社では、私たちはそれほど大きくないので、スクリプトのようなものをリポジトリにチェックインしますが、新しい解決策を同僚に知らせるために全社的なメールを送信します。このように、少なくとも誰もがすでにそこに何があるか、そして彼らがそれを必要としたら誰に連絡するべきかを知っています。
他の人は、「便利な使い捨て」スクリプトをレポに入れるのに十分なものにすることができるようにする方法と理由をすでに説明しています。私はお尻を突っ込むつもりだし、それを確認することも同じくらい重要だと言っている。
別の言い方をすれば、それらはレポに入るのに十分であるか、そうではなくて捨てられなければなりません。それらが捨てられない場合、それらは管理されない、そして最終的に管理できない、メンテナンスの負担になります。
まず、標準のために開発者がコードを提供することに消極的である場合、標準が厳しすぎるか、開発者の品質と作業倫理を改善する必要があると言います。これらが小さなスクリプトである場合、コメントをいくつか入力するのにそれほど多くの労力は必要ありません。開発者はデフォルトで読み取り可能なコードを書く必要があります。そうでない場合、本当の問題はスタッフの配置にあります。
あなたの質問に答えるには、いくつかのオプションがあります：
- スクリプトが十分に汎用的である場合、別のリポジトリでホストすることができます。スクリプトが非常にプロジェクト中心である場合、これは機能しない可能性があります。
- スクリプトを同じリポジトリの独自のディレクトリにホストします。たとえば、私の会社では通常、プロジェクトに
cli/いくつかのコマンドラインスクリプトを含むディレクトリ。通常は、環境を初期化したり、特定のデータをインポートしたりするために1回限り実行されることを意図しています。 - これは、ニーズによっては不十分なオプションになる可能性がありますが、何らかの理由で、明示的に標準に準拠していないコードをコミットできない場合や、開発者がスクリプトを作成する意思がない場合は、これらの標準に従う必要がある場合は、共有ドライブまたは類似のものでファイルをホストできます。ソース管理のすべての利点が必要な場合、これは最高のソリューションではない可能性があります-ただし、状況によっては有益な場合があります（この編集についてDoc Brownに感謝）
最初の2つのオプションのいずれかを使用すると、他のリポジトリまたはディレクトリのいずれかに、より緩やかなコーディング標準を制定することができます。
プロセスの形式化を開始します。
これらのスクリプトが何のために使用されているかについての手がかりはあまりありませんが、さまざまな展開および保守タスク、または修正するのに十分な知識を持つものであるため、開発者に渡される一般的なデータ修正があると思います物事？
あなたはこれについてより専門的になるように努めるべきです。
- これらのタスクとは何か、およびそれらを完了するための手順を書き留めます。
- そのドキュメントを内部のWebサイトまたはイントラネットで公開する
- タスクが実行される頻度と、チケットシステムでかかる時間を記録します。
- プログラムで手動の手順を自動化しますが、ソース管理、テスト、サポートなどはスキップしないでください。適切な管理ツールを開発してください。
- 可能な場合は独自のソリューションを開発するのではなく、サードパーティのツールを使用してみてください。それは新入社員にとってより簡単になります
目標は、ドキュメントをフォローするか、ツールを実行することで誰でも実行できる純粋に重要なプロセスを作成することです。
次に、開発者を製品の機能の記述に戻し、日々の問題に対処するためにサポートスタッフを雇うことができます。
ほとんどすべてのスクリプトは、何らかの方法で再利用できる可能性があります。しかし、その可能性は最初は明らかにならないでしょう-そのため、当時は使い捨てと見なされていました。
チームにGithub Gistのようなリポジトリソリューションを提供します。品質管理は一切行わず、その使用を奨励し、その可能性の損失を防ぎます。
しかし、適切な品質管理が行われている共有ツール/ユーティリティ用の1つ以上のリポジトリも持っています。
その使い捨てリポジトリに格納されたスクリプトが参照された場合にのみ、再利用の可能性が明らかになります。正式な再利用が必要になるのはこのときであり、個々の開発者がその可能性を認識するか、参照がチームコンテキストで発生するかどうかによって開始されます。これは、チームの能力、スケジュール、負荷などに応じて、最初の参照で発生する可能性があります。
リスクは、他の人がコードを見つけたり理解したりできないためにコードを使用できないことです。
参照自体がfind問題を処理します。スクリプトの作成者やリファレンスを作成している人可能性がありますは、understandの問題を解決するのに役立ちます。そうでない場合-再利用の可能性が実際にないか、コードを理解することは、正式な再利用の取り組み/コストの一部にすぎません。
いったん開始されると、正式な再利用の取り組みはチームのレーダー画面に表示され、結果は最終的に共有ツール/ユーティリティリポジトリに配置されます。これは、再利用の元となった同等の使い捨てスクリプトを削除できる場合です（その可能性がなくなった場合）。
特に不適切に書かれたが機能的なコードに焦点を当てます。これらをリポジトリに置かないようにする非常に強い議論があります。
個人のDropboxフォルダにスニペットのコレクションがあります。それは私が便利だと思うものを含んでいます：
- 一般的なEFリポジトリの例
- シンプルなシリアライザー/デシリアライザー
- 2つのCSVファイルをクロス結合し、新しいCSVファイルを出力する小さなアプリケーション。
しかしながら：
- EFの例には作業単位の実装がなく、最も基本的なCRUDオプションしか含まれていません。
- シリアライザーは古いXmlSerializerに基づいており、他のものと交換することは不可能に近いです。また、大量の循環参照の問題もあります。
- アプリケーションはa.csvおよびb.csvを探すようにハードコードされていますアプリケーションディレクトリにあり、同じディレクトリにハードコードされたab.csvを出力します。ファイルが存在するかどうかのチェックはなく、null参照の処理もありません。
迅速に実装する必要がある場合でも、これらのスニペットを定期的に使用していますが、再利用や構築はできません。これが弊社のバージョン管理に入れられない理由はたくさんあります：
- 自己文書化しない。
- 私自身のハックスタイル以外のコーディングスタイルはほとんどありません。
- エラー処理はありません。
- すべての落とし穴が明らかであるとは限りません（例：シリアライザーの循環参照）
しかし、これらすべてのスニペットの最も一般的に共有される特性：
- 私がドキュメンテーションを作成したとしても、自分で作成するよりも、読んで理解するまでに時間がかかるでしょう！
これらのスニペットは、使用目的、使用方法、および遭遇した落とし穴を個人的に覚えているので、私が使用するのに適しています。
しかし、私がいなくても他の人にこれらのスニペットへのアクセスを許可した場合、彼らはこれらのスニペットが役立つとは思わないでしょう。
スニペットは、開発者としてのmyエクスペリエンスの拡張にすぎません。私がいなければ、これらのスニペットはゴミです。クラス全体の構文を最後の文字まで思い出せないため、スニペットのみを使用しています。しかし、私が最後にスニペットを使用した後でも、意図と落とし穴を覚えています。
このように考えてください：
ダクトテープは非常に用途が広く、多くの問題を解決できます。ただし、ダクトテープを使用して解決されたことは、一般的に見苦しいと見なされます。イケアがすべてのフラットパックにダクトテープを含めるとしたら、実際にそれを必要とする一部の人々に役立つかもしれませんが、イケアが販売した家具の品質に対するイケアの信頼についても強く表明します。
同じ理由で、企業は製品全体の品質に問題があるため、バージョン管理でハッキースニペットを許可しないでください。