JavaRush コミュニティの皆さん、こんにちは! 私自身について少し説明します。私は 2016 年の春から Java ソフトウェア エンジニアとして働いています。ここに来て、在学中に解決できなかった問題を解決するのが大好きです。今回はライブラリ「画像比較」についてお話します。これは、 GitHubで公開されているオープン ソース ライブラリです。 この記事の目的は、オープンソース製品の作成は単なる時間の無駄ではない、ということを伝えることです。これは、開発プロセス全体を制御できる場合や、あらゆる詳細を掘り下げる必要がある場合に、さまざまな側面から得られる豊かな経験です。オープンソースはあなたの周りの世界です。冗談ではなく、この図書館が存在していた間、私はアメリカ、インド、中国、エジプト、ロシア、ドイツ、ウクライナ、スウェーデン、ニュージーランド、ノルウェーなど、さまざまな国の人々とコミュニケーションをとりました。つまり、これは共同開発、妥協点の発見、コードのチェックなどにおける実際の経験です。前置きは以上でした。次の順序で始めましょう。
2番目の写真があります:
以下に示すように、相違点を見つけて丸で囲む必要がありました。
ご覧のとおり、赤い三角形で囲まれた[ユーザー名]フィールドに違いがあります。タスクの詳細な説明。機能的に正しいだけではなく、恥ずかしくないように美しく仕上げたいと思いました。これを行うために、これをGitHub上のプロジェクトとして公開することにしました。私は長い間、GitHub を勉強して、GitHub での作業経験を積みたいと思っていました。ざっと調べた結果、コード品質の分析やテストによるコードカバレッジの生成などのためにサードパーティのサービスを追加するとよいことがわかりました。次のツールを追加しました。
当時私はまだ若く、オープンソース コミュニティに馴染みがなかったので、そのようなオファーがあったという事実自体が私にとって非常に驚き、なぜ彼はこんなことをしているのかと尋ねました。それに対して彼は、「笑った、オープンソース プロジェクトに貢献するのが大好きだからね。人生の目標のようなもの…」と答えました (問題自体はここにあります)。そのとき、オープンソース プロジェクトを通じてさまざまな人が自分を見つけて、このような興味深いものを提供してくれるのは素晴らしいことだと初めて感じました。
テスト。2017年8月初旬
それはすべて、ある企業との面接を受けたという事実から始まりました。そこでの最初のステップはテストタスクを書くことでした。このタスクは、同じサイズの 2 つの画像を比較し、それらの違いを見つけてグループ化し、その周りに四角形を描くコードを記述することでした。最初の写真があります:-
コード性- コードの品質。本当に注目に値します。
-
Travis CI は、プロジェクトを構築し、テストを実行し、プロジェクトが正常に構築されたかどうかを確認する CI (継続的インテグレーション) ツールです。たとえば、新しい変更の結果としてテストの 1 つが合格しなかった場合、プロジェクトのビルドが失敗したことが示され、赤色で表示されます。
-
Coveralls は、コードの何パーセントがテストでカバーされているかを示すツールです。
-
BetterCode Hub は、コードの品質を分析するためのもう 1 つのツールです。これは、何が問題なのかを伝えるだけでなく、その理由を説明し、それに関する知識を得ることができる書籍へのリンクも提供してくれる非常に便利なものです。
図書館の道。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 つあることを意味します。
GO TO FULL VERSION