序文
これは確かに困難な作業であり、カバーすべき多くの根拠があります。そのため、適切なツールと教材へのポインタを使用して、これをあなたのチームにとっていくらか包括的なガイドとして謙虚に提案します。
覚えておいてください：これらはガイドラインであり、それ自体は状況に基づいて採用、適応、または削除されることを意図しています。
注意：これらすべてを一度にチームにダンプすると、ほとんどの場合失敗します。汗をかくのに最適な要素をチェリーピックして、一度に1つずつゆっくりと紹介してください。
注：このすべてがG2などのビジュアルプログラミングシステムに直接適用されるわけではありません。これらに対処する方法の詳細については、最後の付録セクションを参照してください。
せっかちな人のためのエグゼクティブサマリー
- リジッドプロジェクト構造を定義します：
- プロジェクトテンプレート、
- コーディング規則、
- おなじみのビルドシステム、
- インフラストラクチャとツールの使用ガイドラインのセット。
- 優れたSCMをインストールし、使用方法を知っていることを確認します。
- それらのテクノロジーに適したIDEを示し、それらの使用方法を確実に理解させます。
- ビルドシステムにコード品質チェッカーと自動レポートを実装します。
- ビルドシステムを継続的な統合および継続的な検査システムに結合します。
- 上記の助けを借りて、コード品質の「ホットスポット」を特定し、リファクタリングします。
長いバージョンについては...注意してください。
剛性は（しばしば）良い
剛性はしばしばあなたに反抗する力とみなされるため、これは議論の余地がある意見です。いくつかのプロジェクトのいくつかのフェーズについても同様です。ただし、構造的なサポート、つまり当て推量を排除するフレームワークと見なすと、無駄な時間と労力が大幅に削減されます。それはあなたのためではなく、あなたのために働きます。
剛性 = プロセス / 手順。
ソフトウェア開発には、化学プラントや工場にマニュアル、手順、ドリル、緊急時のガイドラインがあるのとまったく同じ理由で、優れたプロセスと手順が必要です：悪い結果の防止、予測可能性の向上、生産性の最大化...
ただし、剛性は中程度です。
プロジェクト構造の剛性
各プロジェクトに独自の構造が付属している場合、ユーザー（および新規ユーザー）は失われ、プロジェクトを開くたびに最初からやり直す必要があります。プロのソフトウェアショップでこれを望んでおらず、ラボでもこれを望んでいません。
ビルドシステムの剛性
各プロジェクトが異なって見える場合、彼らも異なって構築する可能性が高い
です。ビルドには、あまり多くの研究や当て推量は必要ありません。あなたは、標準的なことを行うと、詳細を心配する必要はありませんできるようにしたい：configure; make install、ant、
mvn install、等...
同じビルドシステムを再利用し、時間の経過とともに進化させることで、一貫した品質レベルを確保することもできます。
READMEプロジェクトの詳細をすばやく指摘し、ユーザー/開発者/研究者がいる場合は優雅にガイドする必要があります。
これにより、ビルドインフラストラクチャの他の部分、つまり次のことも大幅に促進されます。
したがって、ビルド（プロジェクトなど）を最新の状態に保ちますが、時間の経過とともに厳しくし、違反や悪い慣行の報告をより効率的にします。
車輪を再発明せず、すでに行ったことを再利用しないでください。
推奨読書：
プログラミング言語の選択における剛性
特に研究環境では、すべてのチーム（さらに少ない開発者）が同じ言語と技術スタックを使用することは期待できません。ただし、「公式にサポートされている」ツールのセットを特定し、それらの使用を奨励することができます。良い理論的根拠のない残りの部分は（プロトタイプを超えて）許可されるべきではありません。
技術スタックをシンプルに保ち、必要なスキルの維持と幅を最小限に抑えます：強力なコア。
コーディング規約とガイドラインの厳格さ
コーディング規約とガイドラインは、チームとしてのアイデンティティと共有用語の両方を開発できるようにするものです。ソースファイルを開くたびにterra incognitaにエラーが発生するのは望ましくありません。
単一の単純な違反に基づいてコミットが拒否される程度まで、人生をより困難にするか、アクションを明示的に禁止する無意味なルールは負担です。しかしながら：
個人的なアプローチ：コーディング規約に関しては積極的です。一部の人はナチとも言います。私は、チームにとって認識できるスタイルである共通語を持つことを信じているから
です。がらくたコードがチェックインされると、ハリウッドスターの顔のヘルペスのように目立ちます。レビューとアクションが自動的にトリガーされます。実際、不適合のコミットを拒否するために、事前コミットフックの使用を提唱することもあります。既に述べたように、それは過度に狂ってはならず、生産性の邪魔になるべきではありません。特に最初は、これらをゆっくりと紹介してください。しかし、実際の問題に取り組むことができないように、欠陥のあるコードを修正するのに多くの時間を費やすよりもはるかに望ましい方法です。
一部の言語では、これを設計上強制しています：
コードの腐敗がすり抜けられないことを確認してください。コードの慣習、継続的インテグレーションと継続的インスペクション、ペアプログラミングとコードレビューは、この悪魔に対する武器です。
さらに、以下で説明するように、コードはドキュメントです。これは、規則が読みやすさと明確さを促進する別の領域です。
ドキュメントの剛性
ドキュメントはコードと密接に関連しています。コード自体はドキュメントです。しかし、物事を構築、使用、保守する方法について明確な指示が必要です。
（WikiWikiやDMSのような）単一のコントロールポイントをドキュメントに使用するのは良いことです。プロジェクト用のスペース、よりランダムな冗談と実験用のスペースを作成します。すべてのスペースに共通の規則と規則を再利用させます。それをチーム精神の一部にしてください。
コードとツールに適用されるアドバイスのほとんどは、ドキュメントにも適用されます。
コードコメントの剛性
上記のコードコメントもドキュメントです。開発者は、自分のコードに対する感情を表明するのが好きです（私に尋ねると、ほとんどがプライドとフラストレーションです）。したがって、より正式なテキストがより少ないexp語やドラマで同じ意味を伝えることができた場合、コメント（またはコード）で不確実な用語でこれらを表現することは彼らにとって珍しいことではありません。楽しさと歴史的な理由でいくつかをすり抜けても構いません。それは、チーム文化の発展の一部でもあります。しかし、誰もが受け入れられるものと受け入れられないものを知っていることが非常に重要であり、コメントノイズはそれだけです：
noise。
コミットログの剛性
コミットログは、SCMのライフサイクルの面倒で役に立たない「ステップ」ではありません。時間どおりに家に帰ったり、次のタスクに取り掛かったり、ランチに出かけた仲間に追いつくためにスキップしないでください。それらは重要であり、（ほとんどの）良いワインのように、時間が経過するほど価値が高くなります。だから彼らは正しくやる。同僚が巨大なコミットや非自明なハックのためにワンライナーを書いているのを見ると、びっくりします。
コミットは理由のために行われますが、その理由は、コードと入力した1行のコミットログによって常に明確に表現されていません。それだけではありません。
コードの各行には、ストーリーと履歴があります。差分はその歴史を伝えることができますが、そのストーリーを書く必要があります。
なぜこの行を更新したのですか？->インターフェイスが変更されたため。
インターフェースが変更されたのはなぜですか？->それを定義するライブラリL1が更新されたため。
ライブラリが更新されたのはなぜですか？->機能Fに必要なライブラリL2は、ライブラリL1に依存していたためです。
そして、機能Xとは何ですか？->課題追跡のタスク3456を参照してください。
これは私のSCMの選択ではなく、あなたのラボにとっても最良の選択ではないかもしれません。しかしGit、これを正しく行い、とを使用short logsして
、他のほとんどのSCMシステムよりも適切なログを書き込むように強制しますlong logs。タスクID（はい、必要です）をリンクし、の一般的な要約を残してshortlog、長いログで展開します：変更セットのストーリーを書きます。
これはログです。更新を追跡および記録するためにここにあります。
経験則：後でこの変更について何かを探していた場合、あなたのログはあなたの質問に答えそうですか？
プロジェクト、ドキュメント、およびコードは生きています
それらを同期させてください。そうしないと、それらはもはやその共生エンティティを形成しません。あなたが持っているとき、それは驚異的に動作します：
- SCMのコミットログをクリアし、課題トラッカーのタスクIDへのリンクを追加します。
- このトラッカーのチケット自体がSCMのチェンジセット（および場合によってはCIシステムのビルド）にリンクする場所
- そして、これらすべてにリンクするドキュメントシステム。
コードとドキュメントはまとまりが必要です。
テストの剛性
経験則：
- 新しいコードには、（少なくとも）単体テストが付属します。
- リファクタリングされたレガシーコードには、ユニットテストが付属します。
もちろん、これらには以下が必要です。
- 貴重なものを実際にテストする（または時間とエネルギーの浪費）
- よく書かれ、コメントされている（チェックインする他のコードと同じように）。
これらはドキュメントでもあり、コードの契約の概要を説明するのに役立ちます。特にTDDを使用する場合。あなたがそうしなくても、あなたはあなたの心の平和のためにそれらを必要とします。これらは、新しいコード（メンテナンスまたは機能）を組み込むときのセーフティネットと、コードの腐敗や環境障害から保護するための望楼です。
もちろん、さらに先に進み、修正する再現可能なバグごとに統合テストと
回帰テストを行う必要があります。
ツールの使用における剛性
ときどき開発者/科学者がソースで新しい静的チェッカーを試したり、別のものを使用してグラフやモデルを生成したり、DSLを使用して新しいモジュールを実装したりすることは問題ありません。しかし、すべてのチームメンバーが知って使用することが期待される標準的なツールセットがあれば最適です。
それを超えて、メンバーがすべてである限り、メンバーが望むものを使用できるようにします。
- 生産的、
- 定期的に支援を必要としない
- 一般的なインフラストラクチャに定期的に調整しない、
- （コード、ビルドシステム、ドキュメントなどの一般的な領域を変更することにより）インフラストラクチャを中断しないでください。
- 他人の仕事に影響しない
- 要求されたタスクをタイムリーに実行できます。
そうでない場合は、デフォルトにフォールバックするように強制します。
剛性vs汎用性、適応性、プロトタイピングおよび緊急事態
柔軟性が良い場合があります。誰かに時折ハック、クイックアンドダーティアプローチ、またはお気に入りのペットツールを使用して仕事を終わらせること
は問題ありません。決してそれが習慣になってみましょうしないと、絶対にこのコードをサポートするために、実際のコードベースになってみましょうありません。
チーム精神の問題
コードベースの誇りを育む
- コードに対するプライド意識を養う
- ウォールボードを使用する
- 継続的インテグレーションゲームのリーダーボード
- 問題管理と欠陥カウント用のウォールボード
- 課題追跡 / バグ追跡を使用する
非難ゲームを避ける
- 継続的インテグレーション/継続的検査ゲームを使用してください：それは、良心的で生産的な競争を促進します。
- 欠陥を追跡すること：それはちょうど良いハウスキーピングです。
- DO 根本原因を特定する：それはちょうど、将来のプルーフプロセスです。
- しかし、非難を割り当てないでください：それは逆効果です。
開発者ではなく、コードについてです
開発者にコードの品質を意識させますが、コードを、批判することのできない自分自身の拡張ではなく、独立したエンティティと見なします。
それは矛盾です：健康な職場では自我のないプログラミングを奨励する必要がありますが、動機付けの目的は自我に頼る必要があります。
科学者からプログラマーへ
コードを高く評価してプライドを持たない人は、良いコードを生成しません。このプロパティが出現するには、それがどれほど価値があり、楽しいかを発見する必要があります。純粋なプロフェッショナリズムと良いことをしたいという欲求だけでは十分ではありません。情熱が必要です。そのため、科学者をプログラマーに変える必要があります
（広い意味で）。
誰かがコメントで、プロジェクトとそのコードで10〜20年経った後、誰もが愛着を感じるだろうと主張しました。多分私は間違っているかもしれませんが、彼らはコードの結果や仕事とその遺産に誇りを持っていると思います。コード自体やそれを書く行為についてではありません。
経験から、ほとんどの研究者はコーディングを必要と考えているか、せいぜい楽しい気晴らしと考えています。彼らはただそれが機能することを望んでいます。すでにそのことに精通しており、プログラミングに興味がある人は、ベストプラクティスの採用とテクノロジの切り替えを簡単に説得できます。それらを途中で取得する必要があります。
コードのメンテナンスは研究作業の一部です
誰もがくだらない研究論文を読むことはありません。そのため、出版の準備ができたとみなされるまで、何度もピアレビュー、校正、洗練、書き換え、承認されています。同じことが論文とコードベースにも当てはまります！
コードベースの絶え間ないリファクタリングとリフレッシュは、コードの腐敗を防ぎ、技術的な負債を減らし、他のプロジェクトの作業の将来の再利用と適応を促進することを明確にします。
なぜこれ??！
上記のすべてに煩わされるのはなぜですか？以下のためのコードの品質。それとも
品質コードですか...？
これらのガイドラインは、チームをこの目標に向けることを目的としています。いくつかの側面は、単に彼らに道を見せてそれをさせることでそれを行い（これははるかに優れています）、他のものは手でそれらを取ります（しかし、それはあなたが人々を教育し習慣を発達させる方法です）。
目標がいつ到達できるかをどのように知るのですか？
品質は測定可能です
常に定量的にではありませんが、測定可能です。前述のように、チームに誇りを持たせる必要があり、進歩と良い結果を示すことが重要です。コードの品質を定期的に測定し、間隔の間の進捗状況とその重要性を示します。何が行われたか、そしてそれがどのように物事を改善したか、または悪化させたかを振り返るレトロスペクティブを行います。
継続的な検査に最適なツールがあります。ソナーはJavaの世界で人気のあるソナーですが、どのテクノロジーにも適応できます。他にもたくさんあります。コードを顕微鏡下に置き、これらの厄介な迷惑なバグや微生物を探します。
しかし、私のコードが既にCrapである場合はどうなりますか？
上記のすべては、Never Landへの旅行のように楽しくてかわいいですが、既に（蒸し暑い臭いの山）がらくたコードがあり、チームが変更を嫌がっているときは、それほど簡単ではありません。
ここに秘密があります：どこかから始める必要があります。
個人的な逸話：プロジェクトでは、元々650,000以上のJava LOC、200,000以上のJSP行、40,000以上のJavaScript LOC、および400 MB以上のバイナリ依存関係のあるコードベースを使用しました。
約18か月後、500,000 Java LOC （MOSTLY CLEAN）、150,000行のJSP、および38,000 JavaScript LOCになり、依存関係はわずか100 MBになります（これらはSCMにはもうありません！）。
どうやってやったの？ 上記のすべてを実行しました。または頑張った。
それはチームの努力ですが、私たちはゆっくり注入急いでいる間、私たちの製品の心拍数を監視するために、当社のプロセスの規制やツールに斬撃「脂肪」離れて：私たちはへのすべての開発を停止していない...がらくたコード、無用の依存関係をこれを行う：比較的平穏で静かな時期があり、コードベースに夢中になって自由に解体することができますが、ほとんどの場合、すべての機会を得るためにデフォルトで「レビューとリファクタリング」モードに設定します。 ：ビルド中、ランチ中、バグ修正スプリント中、金曜日の午後中...
大きな「作業」がありました... 8500+ XML LOCの巨大なAntビルドからマルチモジュールMavenビルドにビルドシステムを切り替えることもその1つでした。その後、
- 明確なモジュール（または少なくともそれはすでにはるかに優れていた、と私たちはまだ将来の大きな計画があります）、
- 自動依存関係管理（メンテナンスと更新を簡単にし、不要な依存関係を削除するため）
- より速く、簡単で、再現可能なビルド、
- 品質に関する毎日のレポート。
あなたのコードダウングーグルグァバとApache Commonsのは、スリムでとのバグのために表面を減らす：もう一つは、私たちが依存関係を削減しようとしていたにもかかわらず、「ユーティリティツールベルト」の注入したあなたのコードたくさん。
また、新しいツール（JIRA、Fisheye、Crucible、Confluence、Jenkins）を使用する方が既存のツールよりも優れているとIT部門を説得しました。私たちはまだ軽視したもの（QC、Sharepoint、およびSupportWorks ...）に対処する必要がありましたが、全体的に改善されたエクスペリエンスであり、さらに余裕がありました。
そして、毎日、物事の修正とリファクタリングのみを扱う1から数十のコミットのトリクルがあります。私たちは時々ものを壊します（ユニットテストが必要です、そしてリファクタリングする前にそれらを書く方が良いでしょう）が、私たちの士気と製品の全体的な利益は莫大です。一度にコード品質の割合のほんの一部を取得します。そして、それが増加するのを見るのは楽しいです!!!
注：繰り返しになりますが、新しくより良いもののためのスペースを確保するには、剛性を振る必要があります。私の逸話では、私たちのIT部門は、私たちにいくつかのことを押し付けようとすることと、他の人には間違ったことをしようとすることに部分的に正しいです。または多分彼らは正しかった。物事は変わります。生産性を高めるより良い方法であることを証明してください。このための試用版とプロトタイプがここにあります。
素晴らしい品質のための極秘インクリメンタルスパゲッティコードリファクタリングサイクル
+-----------------+ +-----------------+
| A N A L Y Z E +----->| I D E N T I F Y |
+-----------------+ +---------+-------+
^ |
| v
+--------+--------+ +-----------------+
| C L E A N +<-----| F I X |
+-----------------+ +-----------------+
ツールベルトにいくつかの高品質ツールを用意したら：
コード品質チェッカーを使用してコードを分析します。
リンター、静的アナライザー、またはあなたが持っているもの。
重要なホットスポットとぶら下がっている果物を特定します。
違反には重大度レベルがあり、重大度の高いクラスが多数含まれる大規模なクラスは大きな赤い旗です。したがって、ラジエーター/ヒートマップタイプのビューでは「ホットスポット」として表示されます。
最初にホットスポットを修正します。
ビジネス価値が最も高いため、短期間でインパクトを最大化します。理想的には、重大な違反は潜在的なセキュリティの脆弱性またはクラッシュの原因であり、責任を誘発するリスクが高い（そして、場合によってはラボのパフォーマンスが低下する）ため、出現するとすぐに対処する必要があります。
自動化されたコードベーススイープで低レベルの違反をクリーンアップします。
S / N比が向上するため、レーダーで重大な違反が発生したときに確認できます。多くの場合、最初は軽微な違反の大群があり、それらが処理されず、コードベースが荒らされたままになっている場合です。本当の「リスク」はありませんが、コードの可読性と保守性を損ないます。タスクの作業中に会ったときに修正するか、可能であれば自動コードスイープを使用した大規模なクリーニングクエストで修正します。適切なテストスイートと統合システムがない場合は、大きな自動スイープに注意してください。煩わしさを最小限に抑えるために、適切なタイミングで同僚に同意してください。
満足するまで繰り返します。
これがまだアクティブな製品である場合、理想的には決してそうであってはなりません。進化し続けます。
良い家を保つための簡単なヒント
ファイルからファイルに1週間を費やして、複数の機能やモジュールにまたがる数千の修正の大規模な変更セットで終わることを避けてはいけません-それは将来の追跡を困難にします。コードの1つの問題=トラッカーの1つのチケット。時々、チェンジセットは複数のチケットに影響を与える可能性があります。しかし、頻繁に発生する場合は、おそらく何か間違ったことをしていることになります。
補遺：ビジュアルプログラミング環境の管理
オーダーメイドのプログラミングシステムの壁に囲まれた庭園
OPのG2のような複数のプログラミングシステムは異なる獣です...
ソース「コード」なし
多くの場合、ソース「コード」のテキスト表現へのアクセスは許可されません。独自のバイナリ形式で保存される場合もあれば、テキスト形式で保存されますが、それらを隠してしまう場合もあります。オーダーメイドのグラフィカルプログラミングシステムは、反復的なデータ処理ワークフローの自動化を簡素化するため、実際には研究所では珍しいことではありません。
ツーリングなし
それはさておき、それは。多くの場合、プログラミング環境、独自のデバッガー、独自のインタープリター、独自のドキュメント作成ツールおよび形式に制約されます。彼らは最終的に彼らのフォーマットをリバースエンジニアリングし、外部ツールを構築するのに十分な動機づけられた誰かの興味をキャプチャする場合を除き、それらは
壁に囲まれた庭です-ライセンスが許可する場合。
ドキュメントの欠如
多くの場合、これらはニッチなプログラミングシステムであり、かなり閉鎖的な環境で使用されます。それらを使用する人々は頻繁にNDAに署名し、彼らが何をするかについて決して話しません。彼らのためのプログラミングコミュニティはまれです。そのため、リソースが不足しています。あなたは公式のリファレンスにこだわっています、そしてそれだけです。
皮肉な（そしてしばしばイライラする）ビットは、これらのシステムが行うすべてのことは、主流および汎用プログラミング言語を使用することで、そしておそらくより効率的に達成できることです。しかし、それはプログラミングのより深い知識を必要としますが、あなたの生物学者、化学者、または物理学者が（少し例を挙げると）プログラミングについて十分に知っていること、そして実装する（そして維持する）時間（そして欲求）を持つことをさらに期待することはできません複雑なシステム。長寿命であってもなくてもかまいません。DSLを使用するのと同じ理由で、これらの特注プログラミングシステムがあります。
個人的な逸話2：実際、私はこれらの1つに自分で取り組みました。OPのリクエストとはリンクしませんでしたが、私のプロジェクトは相互接続された大きなデータ処理およびデータストレージソフトウェアのセットでした（主にバイオインフォマティクス研究、ヘルスケア、化粧品、さらにはビジネス用）インテリジェンス、またはあらゆる種類の大量の研究データの追跡とデータ処理ワークフローとETLの準備を意味する任意のドメイン）。これらのアプリケーションの1つは、ドラッグアンドドロップインターフェイス、バージョン化されたプロジェクトワークスペース（メタデータストレージにテキストファイルとXMLファイルを使用）、異種データソースへの多数のプラグイン可能なドライバー、ビジュアルN個のデータソースからのデータを処理し、最終的にM個の変換された出力を生成するパイプラインを設計するキャンバス 可能な光沢のある視覚化と複雑な（およびインタラクティブな）オンラインレポート。ユーザーのニーズに合わせてシステムを設計するふりをして、NIH症候群に少し悩まされている、あなたの典型的な特注ビジュアルプログラミングシステム。
そして、あなたが期待するように、それは素晴らしいシステムであり、そのニーズに対して非常に柔軟ですが、「コマンドラインツールを代わりに使用しないのはなぜですか？」さまざまな「ベスト」プラクティスでそれを使用する多くのさまざまな人々に大規模なプロジェクトに取り組んでいるチーム。
素晴らしい、私たちは運命だ！-私たちはそれについて何をしますか？
まあ、結局のところ、上記のすべてがまだ保持されます。このシステムからほとんどのプログラミングを抽出して、より多くの主流のツールと言語を使用できない場合、システムの制約に適合させる必要があります。
バージョン管理とストレージについて
最終的には、最も制約があり壁に囲まれた環境であっても、ほとんどいつでもバージョン管理を行うことができます。ほとんどの場合、これらのシステムには依然として独自のバージョン管理機能があります（残念ながら多くの場合、これはかなり基本的なものであり、以前のスナップショットを保持するだけで、あまり可視性のない以前のバージョンに戻すことができます）。選択したSCMのように差分チェンジセットを正確に使用していないため、複数のユーザーが同時に変更を送信するのにはおそらく適していません。
それでも、もしそれらがそのような機能を提供するのであれば、おそらくあなたの解決策は、上記の私たちの愛される業界標準のガイドラインに従い、それらをこのプログラミングシステムに置き換えることです!!
ストレージシステムがデータベースの場合、おそらくエクスポート機能を公開するか、ファイルシステムレベルでバックアップできます。カスタムバイナリ形式を使用している場合は、バイナリデータを適切にサポートするVCSを使用してバージョン管理を試みることができます。きめ細かな制御はできませんが、少なくとも大惨事に対して背中を覆うことができ、ある程度の災害復旧のコンプライアンスがあります。
テストについて
プラットフォーム自体にテストを実装し、外部ツールとバックグラウンドジョブを使用して定期的なバックアップを設定します。おそらく、これらのテストは、このプログラミングシステムで開発されたプログラムを起動するのと同じように起動します。
確かに、それはハックの仕事であり、「通常の」プログラミングの一般的な基準には決して達していませんが、アイデアはプロのソフトウェア開発プロセスの外観を維持しようとしながらシステムに適応することです。
道は長くて険しい...
いつものようにニッチな環境とオーダーメイドのプログラミングシステムで、そして上で公開したように、あなたは奇妙なフォーマット、限られた（またはまったく存在しない）おそらく不格好なツールのセット、そしてコミュニティの代わりのボイドに対処します。
推奨事項：可能な限り、上記のガイドラインをカスタムプログラミングシステムの外部で実装するようにしてください。これにより、適切なサポートとコミュニティドライブを備えた「一般的な」ツールを使用できます。
回避策：これがオプションでない場合、このグローバルフレームワークを「ボックス」に後付けしてみてください。アイデアは、この業界標準のベストプラクティスの青写真をプログラミングシステムの上に重ね、それを最大限に活用することです。アドバイスは引き続き適用されます。構造とベストプラクティスを定義し、適合を促進します。
残念ながら、これはあなたが飛び込み、膨大な量の脚の仕事をする必要があるかもしれないことを意味します。そう...
有名な最後の言葉と謙虚な要求：
- あなたが行うすべてを文書化します。
- あなたの経験を共有してください。
- あなたの書いたツールをオープンソースにしてください。
これをすべて行うことで、次のことができます。
- 同様の状況の人々からサポートを受けるチャンスを増やすだけでなく、
- また、他の人々に助けを提供し、テクノロジースタックに関する議論を促進します。
ご存知のとおり、あなたはObscure Language Xの新しい活気のあるコミュニティのまさに始まりにいる可能性があります。ない場合は、開始してください！
おそらく内部は美しいかもしれませんが、これまでのところ誰も手がかりを持っていないので、このい壁を壊し、他の人が覗き見できるようにしてください！
