10年間の休止後のITにおける私の復帰と生存



20年前はテクノロジーの分野で働いていましたが、10年後には管理職に就きましたが、今度はコンサルタントとして再びテクノロジーに戻りました。いくつかの変更は私をとても幸せにしましたが、他の変更は私を同じように驚かせました。以下では、人生の最盛期に私をほとんど殺した主なものについて簡単に話します。



最初はいいですね:Unixと開発者が再会しました



1980年代から1990年代初頭にかけて、ほとんどの専門的なソフトウェア開発は、SunSparcやNeXTなどの高価なUnixワークステーションで行われました。90年代に、市場はWinTelによって捕らえられ、誰もがMS Visual Studioのような大規模なサプライヤーのツール、またはEclipseのようないくつかの無料オプションを使用してWindowsでコーディングを始めました。当時のLinuxは、デスクトップの世界の愛好家にとってはまだまだ何かと考えられていました。



2001年、私はスタートアップで働きました。チーム全体でLinux開発者は1人しかいなかったため、バージョン管理ツールとOutlook電子メールクライアントへのアクセスを遮断するのに苦労しました。彼は通常私たちに手紙でコードを送って、それを記入するように頼みました。当時、私自身がXEmacsを使用していたことを覚えています。



現在に早送りします。Unixは、Unixカーネルを使用しているため、開発者、特にMacの開発者の間で非常に人気のあるプラットフォームになっています。また、Linux onWindowsのようなものもあります。この点で、他の多くの人とは異なり、ITへの復帰に問題はありませんでした。私の若い同僚の多くが今やWindowsをほとんど管理しておらず、Linuxでは彼らがはるかに自信を持っているのはおかしいです。



リリース管理はもはや職業ではありません



かつて、競合の分岐、マージ、および解決は、専任のリリーススペシャリストの介入を必要とすることが多い仕事の地獄でした。ClearCaseがバージョン管理市場で君臨していた時代には、大規模なチームにとって十分なフォーク、マージ、リリースの作業がありました。少なくとも2002年のHPでの私の経験ではそうです。



開発者が自分で変更要求を送信できるという考えは、実際にはかなり若いものです。どうやら、彼女はLinuxへの開発の移行の始まりと、分散バージョン管理システムの新しい波、BitKeeper、Gitなどを与えられたようです。ClearCase、CVS、SVN、PerForceなどのレガシーシステムには、ワークフローに関与するすべての人に反映されるように独自の変更を加える機能がありませんでした。リポジトリの所有者、リリース管理の責任者、または各開発者がすべてを自分で整理しました。これでプロセスが大幅に簡素化され、追加の参加者なしでチーム内で共同作業を確立できるようになりました。



QAチームはどこにありますか?ユニットテストと継続的インテグレーション



Agile Manifestoの作成者の1人であり、エクストリームプログラミング手法の作成者であるKent Beckから、ユニットテストと継続的インテグレーションについて最初に耳にしました 。 20年前、彼のアイデアは革命的でしたが、現在の開発における標準のステータスをすぐには達成しませんでした。



私の意見では、アジャイルとスクラムの継続的インテグレーションにこれ以上重点が置かれていないのは残念です。しかし、私はこの慣行が今日非常に人気になったことをすでに嬉しく思います。私はその会議に出席し、Javaコレクションの作者であるJoshua Blochがステージに足を踏み入れて継続的インテグレーションについて話し、「継続的インテグレーションに魅力を与えてくれてありがとう(アジャイルまたはJUnit)」と言ったのを覚えています。そして彼は正しかった。昔は、テストを書くのはつまらないと考えられていて、それをした人はほとんどいませんでした。そのため、上司は開発者のエラーを探していた特別な人、QAエンジニアを雇いました!クレイジーになりなさい、そのラファは...



単体テストと継続的インテグレーションにより、そのような人々の必要性はほとんどなくなりました。現在、開発者はテストを自分で作成する責任があり、継続的インテグレーションインフラストラクチャはすべてを時間どおりに起動し、エラーを報告します。これにより、ソフトウェアの信頼性が高まり、開発サイクルが短縮されます。また、イノベーションは、開発者が物事のより全体的な見方を獲得し、簡単にテストできるようにコードを書く方法を学ぶのに役立ちました。



Docker:本番環境への移行が煩雑になることはありません



コンテナー、つまりDockerは、パッケージ管理から不要なものをすべて削除し、コードがテストに合格して本番環境に移行するときに発生する環境問題を最小限に抑えました。ただし、以前は、Dockerエコシステムをセットアップするために優れたDevOpsエンジニアを取得する必要がありました。



昔は、システムが展開されるはずのまったく異なる環境で作成されていたことがありました(つまり、Windowsでコードを記述し、Unixで展開されていました)。これは必然的にバグを引き起こし、各テストリリースサイクルで追加の作業を積み上げました。



さらに、これまで、リリース、テスト、またはDevOpsのスペシャリストは、ソース管理のタグからコードを取得し、コンパイル、テスト、および移行をどうするかを決定していました。通常、これにより、ハードコードされたパスと変数の全体が明らかになり、適切に機能するために再加工または調整する必要のあるライブラリとファイルが欠落します。



Dockerはプロセスを簡素化し、継続的インテグレーションと継続的デプロイの条件を作成しました。これも、関連する関数をプログラマーの手に委ねることによって行われました。



オープンソース:可能性が多すぎる



オープンソースソフトウェアの世界では、率直に言って、選択肢は豊富にあります。ここでJenkinsをセットアップしていて、BitBucketと統合したいと思っていました。「bitbucket」のプラグインを検索すると、400以上の結果が得られ、その多くはオープンソースです。







これにより、2つの問題が発生します。



  1. 多数のオプションから選択するのはより困難です
  2. そのような豊富さで、いくつかの楽器は間違いなく消滅し、それらのサポートは停止します。


しかし、利点もあります。基本的なインフラストラクチャとツールを自分で作成する必要はほとんどありません。既製のものから必要なものを見つけて使用します。20年前は、最も一般的な操作のためにライブラリとデータ構造を作成する必要があり、どこかでさえ楽しかったです。今日、言語ごとに非常に多くの異なるライブラリとフレームワークが存在するため、開発者の99%は、単一のBツリー、ハッシュテーブル、またはOAuthコネクタを作成しなくても生活できます。



アジャイルとスクラムが世界を引き継いだ



20年前、アジャイルはすでに健在でしたが(アジャイルマニフェストは2001年にリリースされました)、その人気は後になって成長し始めました-外部ITを含め、時には歪んだ形で。彼は経営陣のお気に入りの格言なりました 。「ビジネスは機敏性を維持する必要があります。そうしないと、ビジネスは存続しません。」



リリースサイクルがかなり長い間(3か月、これはスタートアップの段階です)続いたときのことを覚えています。仕様を1行ずつ解析した会議から戻った後、開発者はテーブルに座って、状況を報告する必要があることを心配せずに、数週間静かにギャンブルをすることができました。そして今、毎日のスタンドアップラリー、2週間ごとのスプリント-あなたは本当にリラックスすることはできません!



アジャイルは管理機能も再配布しました。現在、開発者はユーザーまたは製品マネージャーと直接通信します。黙って座っても機能しなくなります。したがって、コミュニケーション能力は以前よりもはるかに価値のあるものになりました。



最後に、開発のペースはアジャイルによって加速しています。それは、スタンドアップミーティングや他のスクラムベンチャーについてでさえありません。Jiraのホワイトボード、変更リクエスト、継続的な開発とデプロイのためのツールなど、ツール自体が時間を節約し始めました。これらはすべて、より高速な作業を可能にします。これは日常の悩みを増す一方で、短期間で製品を展開し、包括的な方法でタスクを完了するという事実に見返りを感じます。



最後に



あなたもITを離れて、戻ることを考えているなら、私はあなたをサポートし、あなたに幸運を祈ります。個人的に、私は喜んで自分のスキルを更新しました(途中でほとんど死にましたが)。プログラミングの基本原則は変わらないので、なんとかやり遂げると思います。しかし、ツールキットは大きく変更されており、これは生産性に影響を与えます。



あなたはおそらくこの記事で繰り返しテーマを捉えました:現代の開発者は20年前よりもはるかに幅広いタスクを持っています。彼はコードを書いたり、バージョン管理をしたり、書いたものをテストしたり、コンテナーを操作したりします。もちろん、脳が沸騰することもありますが、リンクリストを自分で作成する必要はありません。



All Articles