面接テストがどのようにオープンソース ライブラリに変わったか

JavaRush コミュニティの皆さん、こんにちは! 私自身について少し説明します。私は 2016 年の春から Java ソフトウェア エンジニアとして働いています。ここに来て、在学中に解決できなかった問題を解決するのが大好きです。今回はライブラリ「画像比較」についてお話します。これは、 GitHubで公開されているオープン ソース ライブラリです。 この記事の目的は、オープンソース製品の作成は単なる時間の無駄ではない、ということを伝えることです。これは、開発プロセス全体を制御できる場合や、あらゆる詳細を掘り下げる必要がある場合に、さまざまな側面から得られる豊かな経験です。オープンソースはあなたの周りの世界です。冗談ではなく、この図書館が存在していた間、私はアメリカ、インド、中国、エジプト、ロシア、ドイツ、ウクライナ、スウェーデン、ニュージーランド、ノルウェーなど、さまざまな国の人々とコミュニケーションをとりました。つまり、これは共同開発、妥協点の発見、コードのチェックなどにおける実際の経験です。前置きは以上でした。次の順序で始めましょう。

テスト。2017年8月初旬

それはすべて、ある企業との面接を受けたという事実から始まりました。そこでの最初のステップはテストタスクを書くことでした。このタスクは、同じサイズの 2 つの画像を比較し、それらの違いを見つけてグループ化し、その周りに四角形を描くコードを記述することでした。最初の写真があります: 2番目の写真があります: 以下に示すように、相違点を見つけて丸で囲む必要がありました。 ご覧のとおり、赤い三角形で囲まれた[ユーザー名]フィールドに違いがあります。タスクの詳細な説明。機能的に正しいだけではなく、恥ずかしくないように美しく仕上げたいと思いました。これを行うために、これをGitHub上のプロジェクトとして公開することにしました。私は長い間、GitHub を勉強して、GitHub での作業経験を積みたいと思っていました。ざっと調べた結果、コード品質の分析やテストによるコードカバレッジの生成などのためにサードパーティのサービスを追加するとよいことがわかりました。次のツールを追加しました。

• コード性- コードの品質。本当に注目に値します。

• Travis CI は、プロジェクトを構築し、テストを実行し、プロジェクトが正常に構築されたかどうかを確認する CI (継続的インテグレーション) ツールです。たとえば、新しい変更の結果としてテストの 1 つが合格しなかった場合、プロジェクトのビルドが失敗したことが示され、赤色で表示されます。

• Coveralls は、コードの何パーセントがテストでカバーされているかを示すツールです。

• BetterCode Hub は、コードの品質を分析するためのもう 1 つのツールです。これは、何が問題なのかを伝えるだけでなく、その理由を説明し、それに関する知識を得ることができる書籍へのリンクも提供してくれる非常に便利なものです。

これらの各サービスには、コード カバレッジ プロジェクトなどのデータ結果を示す独自のバッジがあります。そして、このバッジはプロジェクトのメインの説明である README ファイルに追加できます。タスクの準備ができました。レビューのために送信しました。レビュー後、記憶が新しいので、私はすぐにコメントごとにGithub Issue を作成しました。これは、このプロジェクトの改善に役立ちます。雇用主からの改善課題もなかったので、しばらくプロジェクトのことを忘れていました…。

図書館の道。2018年7月

ロゴ

ある時点で、人々が私のプロジェクトを頻繁に訪問し、それが毎日起こっていることに気づきました。私はこれに驚きましたが、約 1 年後に彼らが ISSUE を作成したという事実にはさらに驚きました。そこには、あるグラフィック デザイナーが私に私のプロジェクトのロゴの作成をオファーしていると書かれていました。彼らは、彼がオープンソース製品のためにこれを行うのが大好きで、それを完全に無料で行うつもりだと言いました。コラボレーションを始めました。いくつかの選択肢が提案されましたが、最終的にはこれに落ち着きました。 当時私はまだ若く、オープンソース コミュニティに馴染みがなかったので、そのようなオファーがあったという事実自体が私にとって非常に驚き、なぜ彼はこんなことをしているのかと尋ねました。それに対して彼は、「笑った、オープンソース プロジェクトに貢献するのが大好きだからね。人生の目標のようなもの…」と答えました (問題自体はここにあります)。そのとき、オープンソース プロジェクトを通じてさまざまな人が自分を見つけて、このような興味深いものを提供してくれるのは素晴らしいことだと初めて感じました。

最初の側面欠陥

中国の特定の開発者が私のために問題を作成したことに気付きました。その中で彼は、ライブラリの動作に欠陥が見つかり、大きな画像を使用するとStackOverflowErrorが発生する、と説明していました。男はそれを利用しようと考えたが、間違いに気づいた。そして、ただ見つけただけではありません。そして彼女についても書きました。これはライブラリ開発における新しいステップです。さらに、実際には解決策がありませんでした。ある時点で、ロシアのテスターの 1 人が解決策を提案しました。しかし、それは生であり、適切に作られていなかったので、私はそれを受け入れませんでした。そして、Maven Central でライブラリを公開するときは、この欠陥のある何かを解決する必要がありましたが、それと一緒に公開したくありませんでした。さらに、私が直さなかったもう一つの欠陥があり、それはまた多くの不便をもたらしました。

コマンドラインの使用法。2018年秋

開発の次の段階はスウェーデン人 (Renato Athaydes) とのコミュニケーションでした。スウェーデン人はコマンド ライン経由でライブラリを使用したいと考えており、そのためにいくつかの変更と追加を行う必要がありました。これにはまた驚きと驚きを感じました。グラフィックデザイナーが私に手紙を書いた後、私の驚きはいくらか和らぎましたが、それでも非常に大きかったです。誰かが本当に私のコードを必要としていると思うと、信じられないような気持ちでいっぱいになりました。彼は必要な変更を加えてコードを準備しました。コードレビューを実施しました。つまり、変更を確認しました。変更されたコメントがあり、変更はすでにライブラリにありました。これらの変更をバージョンv2.0として指定しました。 次のステップでは、ライブラリを Maven Central (中央リポジトリ) に追加し、そこから任意のプロジェクトにダウンロードして依存関係として使用できます。当時、たとえリモートであってもこれを行う方法がわからなかったので、私は忙しいと言って、プロジェクトのセットアップに必要なすべての手順を実行するように彼に頼みました。しかし、これではまったく不十分であることが判明し、最も興味深いのは Maven Central との接続をセットアップすることでした。これは非常に苦痛で、最初は実行できませんでしたが、Maven Central でプロジェクトを公開できたのは 4 月 15 日になってからでした。それは簡単ではありませんでしたが、他の人がよく言うように、「Java コードを公開したい人は皆、これを経験することになります」。ライブラリを公開する前に、長い間続いていた欠陥に何をどのように対処するかをついに見つけ、新しいバージョンv2.0.2をリリースしました。その中で、私を助けてくれたすべての人に感謝し、何をどのように行ったかについて説明しました。 。

Maven Central に公開します。2019年春

ライブラリを正しく公開するには、バージョン管理とバージョンを正しく設定する方法をよく理解する必要があります。私はこの計画に固執します:

• XX.YY.BBBB、XX は、以前のものと互換性のない変更を伴うメジャー バージョン アップデートです (たとえば、メソッドで返される結果の変更)。
• YYはマイナー アップデートです。BBBBを変更しない内部変更または拡張です。これらは修正された欠陥です。
• たとえば、バージョン2.0.2は、メジャー バージョンが 2 で、マイナー アップデートはなく、欠陥に対するアップデートが 2 つあることを意味します。

次に、 groupIdとartifactId を正しく設定する方法を理解することが重要でした。これらは一度選択して、さらに使用する必要がありました。そして、それらはコードが保存されるパッケージを構成します。以前: ua.comparison.image 現在: com.github.romankh3.image.comparison そして、これが GitHub のプロジェクトであり、romankh3 というニックネームを持つ人物から見つかることが誰もが知っているので、これは明らかに優れています。これらすべてを行った後、新しいバージョンv2.1.0をリリースしました。

スウェーデン人とのコミュニケーション。2019年5月

私がライブラリを公開した後、別のスウェーデン人 (Mika Kytöläinen) が私にメールを送ってきて、彼の友人に私のライブラリに変更を加えるように依頼しました。彼は、これが本当に必要で、私たちがそれをすぐに実行すれば、とても喜ぶだろうと言いました。もちろん、私は必要な変化に反対しませんでした。彼は、長方形を描く線の太さの設定を追加することを提案しました。同様に、視力の悪い人にとって、これは有益な変更となるでしょう。コードを準備しました。さらにいくつかの変更を加えて、バージョンv2.2.0をリリースしました。

ドイツ人とのコミュニケーション。2019年5月

その後、あるドイツ人が、テストに使用したいが機能が不足しているという問題を作成しました。彼は非常に興味深い多くの提案をしました。彼は、比較の結果として得られた画像だけを結果として返すのではなく、比較した内容、結果 (必要な場合)、およびその状態を含む一連のデータを返すことを提案しました。 MATCH、MISMATCH、SIZE_MISMATCH になります。変更も加えました。しかし、それらは以前のコードをまったく考慮しておらず、急いで作成されました。私はそれらを拒否し、自分が適切だと思うように実行することを申し出ました。それにもかかわらず、彼はさらに多くの反応を示したので、私は自分でやって新しいバージョンをリリースすることに決めました。同時に、Mika Kytöläinen は、比較に含まれない領域を追加するという別の興味深い機能を提案しました。これは実際のケースです。これらはすべてv3.0.0でリリースされました

実際のプロジェクトで使用する

5 月末、キエフの自動化テスターが私に手紙をくれました。彼はこのライブラリに興味を持ち、お金を生み出す実際のプロジェクトでそれを使いたいと考えていました。それは画期的なことでした！ペットプロジェクトのどこかでそれを使用することは別のことですが、実際のプロジェクトで使用することはまったく別の問題です。私たちはそれが何をどのように機能するかについて話し合いました。このアプリケーションは非常に興味深いものです。アプリケーションには印刷される小切手があり、その小切手が特定のテンプレートに従って作成され、変更されないことを確認する必要がありました。しかし、日付や時刻などのセクションは常に変更され、無視しなければならないという問題がありました。私たちはすでに一部の領域を無視する機能を追加していましたが、実際に使用するにはまだ未加工であることが判明し、それでも数週間にわたって協力して実りある作業を行いました。その結果、バージョンv3.1.1がリリースされました。

ニッチな分野を見つける

その後、自分のライブラリの本当のニッチな用途はテストでの使用であることに気づきました。これを行うために、テスター向けのフォーラムのようなものを見つけて、フィードバックを得て名声を高めるために、それについて手紙を書くことにしました。私はロシア語のフォーラムを見つけて、そこに記事を公開しました:テスト画像の構成 - 2 つの類似した画像の比較。その中でコードと機能に関する実際のフィードバックを受け取り、それを適用して新しいバージョンv3.2.0、そしてv.3.3.0をリリースしました。

今

現在、このライブラリには Github 上に 60 個のスターがあり、33 個のフォークがあります。オートメータ向けのフォーラムの記事以外にこれを宣伝しなかったことを考えると、これは非常に素晴らしいことだと思います。最後まで読んでくださった皆様、ありがとうございました。実際に書いてみると、思っていたよりもかなり長い記事になってしまいました。 Maven Central にライブラリを公開する方法に関する記事。 追加することがあれば、書いてください！ライブラリを改善するために何か提案がある場合は、書き込んでください。私はすべてを読み、それに適切な時間を費やします。 この記事が気に入って役に立ったと思った人は、評価してコメントに書き込んでください。 また、私の github アカウントromankh3を購読してください 。私の他の記事も参照してください。

• 面接中の技術的な質問
• 仕事を見つけるにはどうすればいいですか？履歴書を送るときのヒント
• プロフェッショナルな燃え尽き症候群。どのように抵抗するか？
• 成功の歴史。週に 20 時間のプログラミング、修士号と私生活
• 航空券価格監視システムの作成: ステップバイステップガイド [パート 1]
• Skyscanner API のクライアントを作成し、jCenter および Maven Central で公開するためのガイド [パート 1]
• ロギング: 何を、どのように、どこで、何を使って行うのか?
• Intellij IDEA でのデバッグ: 初心者向けガイド