プログラミングの生態学
ブラジルの森林が電子文書管理に切り替えたり、Numロックをオフにしてエネルギーを節約したりすることの利点については話していません。 「エコロジー」については、より広い（または逆に、より専門化された）概念として、開発者と開発環境との最も広い意味での相互作用としてお話したいと思います。
残念なことに、私はとても怠け者です。 2番目のネガティブな品質は焦りです。 私は部屋のコンピューターに行ってフォルダーを共有するのが面倒です-RDPで行った方がいいです。コンピューターの電源が入るまで待つのは非常に面倒です-夜は電源を入れたままにしておく方がいいです。 ただし、結局のところ、これらの品質はどちらも開発者にとって非常に有用です。
私が最初に取り組んだプロジェクトは、世界中のWebサービスに完全に依存していました。 毎日、私は遅いVPN（私が仕事に来たときにすでに高速なVPNが忙しかったため）に接続することから始めなければなりませんでした。 Webサービスは遠く離れていたため、デバッグ用のプロジェクトの起動ごとに最大5分かかりました。 プロジェクトはかなり大規模でした-完全なアセンブリには約3分かかり、さらに2分（サービスは遠く離れています）の起動にかかりました-結局、5分待って行の1文字を正しく変更したかどうかを確認しました...
私はVPNに接続するのが面倒で、プロジェクトの立ち上げの速さにイライラしていました。
これらすべての中で最も不快なのは、他の人がこれに対して非常に寛容であり、「何をすべきか」と言っていることです。 それは文字通り私を驚かせました-毎日さえも私を改善しようとすることさえできません-毎分仕事。 私はこれほど長く耐えられませんでした-VPNと外部サービスの両方から私を解き放ち、できるだけ早くデバッグを開始できる「キャッシングプロキシ」を書くというアイデアが思い浮かびました。 結論-私の「プロキシ」は顧客に販売され、現在は本番環境でほとんど使用されており、VPNに接続する必要はありません-顧客はサイト間VPNにgeneしみませんでした） 残念ながら、アイデアから実装まで多くの時間が経過し、「プロキシ」は決して思い浮かびませんでした...
私の次の大きな仕事は、ビルドを収集し、それらをサービスとほぼ同じ世界のリモートマシンに配置することでした。 繰り返しますが、このレッスンは退屈で長く、すべてが手作業で行われなければなりませんでした。 丸1日、私はなんとか4つのビルドを収集して配置しました。ビルドには2時間かかりました。 繰り返しになりますが、管理者はそれが悪いことを認識しませんでした（または表示しませんでした）。明らかに、通常のビルドプロセスを設定するよりも安価でした。 私は上司に説得してビルドスクリプトを作成する時間を与えました。 その結果、スクリプトは、すべてがソースに問題がない場合、ビルドを20分で組み立て、リモートマシンでインストールを開始するだけでした。 これで、このスクリプトは少なくとも2つのプロジェクトのビルドプロセスの基礎になります...
また、リポジトリを整理したことを思い出すことができます。その前に、5つのブランチでプロジェクトにコミットしなければなりませんでした。 また、開発者ツールの小さな修正により、毎回ユーザー名を入力する必要がなくなりました。 そして、生のテキストの代わりにフォーマットされた形式でXMLを見る機能、およびスタジオ用のマクロにより、特定のプロジェクトリソースなどを簡単に見つけることができます。
そして正直に言うと、2つのことがいつも私を驚かせてきました。 1つ目は同僚の謙虚さです。同僚はほとんどの場合、毎日の行動の煩わしい、不快で、ゆっくりとしたルーチンを変更しようとしませんでした。 そうです-開発者は怠け者でなければなりません。 私は簡単に機械化および単純化できることを毎日行うのが面倒です。
2番目の理解できないことは、プロジェクトのエコロジーの変化を顧客や管理者に「販売」することがどれほど難しいかです。 一方、もちろん、それらは非常に理解しやすいです。環境への貢献は、「何も起こらない」というリスクに関連する非常に長期的な投資です。 しかし、私自身の経験から、これらの変更は通常、チームの各開発者の日々の時間と労力に比べて非常に安価であると言えます。
今、私は新しいプロジェクトに切り替えました。そこでは、「環境」問題の束と、データベースを稼働状態に維持するためのスクリプト地獄、パフォーマンステスト専用のサーバーの不足、サーバーを起動するための構成と魔法のパスの不足、リポジトリの混乱があります、およびチームの新しい人々のキックオフの欠如。 繰り返しますが、「はい、どうですか」という感嘆の声が聞こえるのは、「いつもこんな感じ」だけです。すぐに上司が本当に何かを変えたいと思っても、何度も何度も頭を壁にぶつけて、顧客に証明しようとする必要がありますこれはすべて必要であり、変更できること。
残念なことに、私はとても怠け者です。 2番目のネガティブな品質は焦りです。 私は部屋のコンピューターに行ってフォルダーを共有するのが面倒です-RDPで行った方がいいです。コンピューターの電源が入るまで待つのは非常に面倒です-夜は電源を入れたままにしておく方がいいです。 ただし、結局のところ、これらの品質はどちらも開発者にとって非常に有用です。
私が最初に取り組んだプロジェクトは、世界中のWebサービスに完全に依存していました。 毎日、私は遅いVPN（私が仕事に来たときにすでに高速なVPNが忙しかったため）に接続することから始めなければなりませんでした。 Webサービスは遠く離れていたため、デバッグ用のプロジェクトの起動ごとに最大5分かかりました。 プロジェクトはかなり大規模でした-完全なアセンブリには約3分かかり、さらに2分（サービスは遠く離れています）の起動にかかりました-結局、5分待って行の1文字を正しく変更したかどうかを確認しました...
私はVPNに接続するのが面倒で、プロジェクトの立ち上げの速さにイライラしていました。
これらすべての中で最も不快なのは、他の人がこれに対して非常に寛容であり、「何をすべきか」と言っていることです。 それは文字通り私を驚かせました-毎日さえも私を改善しようとすることさえできません-毎分仕事。 私はこれほど長く耐えられませんでした-VPNと外部サービスの両方から私を解き放ち、できるだけ早くデバッグを開始できる「キャッシングプロキシ」を書くというアイデアが思い浮かびました。 結論-私の「プロキシ」は顧客に販売され、現在は本番環境でほとんど使用されており、VPNに接続する必要はありません-顧客はサイト間VPNにgeneしみませんでした） 残念ながら、アイデアから実装まで多くの時間が経過し、「プロキシ」は決して思い浮かびませんでした...
私の次の大きな仕事は、ビルドを収集し、それらをサービスとほぼ同じ世界のリモートマシンに配置することでした。 繰り返しますが、このレッスンは退屈で長く、すべてが手作業で行われなければなりませんでした。 丸1日、私はなんとか4つのビルドを収集して配置しました。ビルドには2時間かかりました。 繰り返しになりますが、管理者はそれが悪いことを認識しませんでした（または表示しませんでした）。明らかに、通常のビルドプロセスを設定するよりも安価でした。 私は上司に説得してビルドスクリプトを作成する時間を与えました。 その結果、スクリプトは、すべてがソースに問題がない場合、ビルドを20分で組み立て、リモートマシンでインストールを開始するだけでした。 これで、このスクリプトは少なくとも2つのプロジェクトのビルドプロセスの基礎になります...
また、リポジトリを整理したことを思い出すことができます。その前に、5つのブランチでプロジェクトにコミットしなければなりませんでした。 また、開発者ツールの小さな修正により、毎回ユーザー名を入力する必要がなくなりました。 そして、生のテキストの代わりにフォーマットされた形式でXMLを見る機能、およびスタジオ用のマクロにより、特定のプロジェクトリソースなどを簡単に見つけることができます。
そして正直に言うと、2つのことがいつも私を驚かせてきました。 1つ目は同僚の謙虚さです。同僚はほとんどの場合、毎日の行動の煩わしい、不快で、ゆっくりとしたルーチンを変更しようとしませんでした。 そうです-開発者は怠け者でなければなりません。 私は簡単に機械化および単純化できることを毎日行うのが面倒です。
2番目の理解できないことは、プロジェクトのエコロジーの変化を顧客や管理者に「販売」することがどれほど難しいかです。 一方、もちろん、それらは非常に理解しやすいです。環境への貢献は、「何も起こらない」というリスクに関連する非常に長期的な投資です。 しかし、私自身の経験から、これらの変更は通常、チームの各開発者の日々の時間と労力に比べて非常に安価であると言えます。
今、私は新しいプロジェクトに切り替えました。そこでは、「環境」問題の束と、データベースを稼働状態に維持するためのスクリプト地獄、パフォーマンステスト専用のサーバーの不足、サーバーを起動するための構成と魔法のパスの不足、リポジトリの混乱があります、およびチームの新しい人々のキックオフの欠如。 繰り返しますが、「はい、どうですか」という感嘆の声が聞こえるのは、「いつもこんな感じ」だけです。すぐに上司が本当に何かを変えたいと思っても、何度も何度も頭を壁にぶつけて、顧客に証明しようとする必要がありますこれはすべて必要であり、変更できること。
All Articles