会社開発における私自身の経験を共有します

このタイトルの原則という言葉が正しいかどうかはわかりませんが、原則と呼ぶことにします。コードを書く人にとっては、これを後で標準と呼びますが、よく考えてみると、他の側面については原則かもしれません。よし、絡めずに本題に直接行きましょう。

新しい会社に入社して 1 か月以上経ちますが、昨日まではバックエンドのバージョンがパブリック ネットワークに同期されていたため、少し遅れていました。が見直される予定ですが、内部テストも本格的に進行中です。別の環境に移行したばかりで、新しい環境での開発モデル、コードの仕様、コードの投稿モードなどすべてが新しいです。私にとって最も奥深いのは、当然のことながらコードの投稿方法です。ここに来て以前のコードレビュー方法に慣れてしまったので、そのような強制的な仕組みがなくなったので、少しだけリラックスしました。

サボることの代償は少し悲劇的です 多くのことに原則、ルール、基準が必要であることを、私が本当に理解したのは、バージョンのリリース前夜の昨日でした。ルールがなければサークルは存在しません。 . コードが標準化されていないと良い製品とは言えません I Android 向けに開発されたものであれば、当然良いアプリは作れません。まず規制について私の観点からお話しさせていただきます。プログラミング標準、特に Java プログラミング標準の観点から見ると、フィールドがバックグラウンドに追加されたが、APP バージョンが最初に古いバックグラウンドに接続して前後の関数を比較する場合、null ポインターが最も一般的な問題の 1 つになります。 、現時点ではこれは行われていません。パラメータを入力して判断すると、結果がどのようになるかは想像できると思いますが、アプリがクラッシュします。少なくともユーザーエクスペリエンスの観点から言えば、このアプリには致命的な問題はありません。ただし、パラメータの判定を入力するのは 1 ステップであり、null を判定しなくてもクラッシュを防ぐことができます。これは、判定の前提条件として定数を使用する、インターネット上にある裏技です。実際、私がこの段落を書いたとき、それを読んだクラスメートは、この小さな間違いで私が愚かだったことを意味します。これは私が昨日家に帰ってから初めて抱いた深い感情でもありました。どうしてかわからないとか理解できないのではなく、あなたが注意を払わなかったために些細なことが殺人を引き起こしたのです。

非 null 判定と配列範囲外例外は、Java と C の両方で共通の問題です。以前のプロジェクト チームでは、Java と C に関する軍事規制があったことを覚えています。これらの低レベルのエラーを排除する必要がありました。これを回避する良い方法は、Google のような優れた企業であってもコード レビューを行う必要があります。私が初めて杭州の会社に来たとき、同僚が私にレビューをするように頼んだのを覚えていますが、その後、私は徐々にプロセスに慣れ、レビューの前提条件としてよくある間違いをいくつか挙げました。インターネットでチキンスープの記事をたくさん読みましたが、他の人のコードを読むことも自分の能力を向上させる方法です。レビューの重要性については何度も言及されています。コード レビューは以前はプロジェクト チームにとって必須でしたが、現在は強制されていないためサボっており、新しいバージョンがオンラインになるとコードに問題が発生します。実際、バージョンの起動時にバックエンドでエラーが発生し、それを修正するのに 3 回のロールバックが必要でしたが、それでも設定されておらず、間違ったパラメータが取得されてしまいました。 APPによる。論理的に言えば、APPとバックエンドの関係が強い状況で、実際にバックエンドにも確認したことがありますが、理由がやむを得ないので、バックエンドの同僚が問題ないと言うわけではありませんが、この種の自己判断能力には、いつでもどこでも、自分自身のプログラミング基準と原則を厳密に遵守する必要があります。 APPを使用してユーザーエクスペリエンスを確保します。

新しい会社のバージョンの立ち上げに初めて参加したとき、入力パラメータが null ではないと判断されず、配列の長さが判断されなかったことによってクライアントがクラッシュに遭遇しました。実際、私は本当に罪悪感を感じました。これは以前は必要な操作でしたが、今回の問題は完全に私がそれに厳密に従わなかったことが原因でした。幸いなことに、問題は内部で解決されました。バックグラウンドの問題についてはよくわかりませんが、幸いにも制御範囲内にあり、ニアミスは発生しませんでした。私の知る限り、バックエンドの問題のほとんどは、構成が同期されていないことと、コードがオンラインで同期されていないことが原因です。突然、よくある問題を発見しました。私が遭遇したバージョンがリリースされた日、開発は常に重大な問題や軽微な問題に直面していました。誰かがこれを経験したなら、笑。

私も初めて経験して、そのルーチンを知りましたが、私が感じているものづくりはとても深刻なことです。新しい同僚数名と開発をしていたとき、その中の一人がサボっていたので、朝礼中にグループの上司がみんなの前でこう言ったのを今でも覚えています。はい、誰もが製品を認識する必要があります。以来、この一文を心に留めているのですが、残念ながら私自身、特にコードを書くことに関しては上手くできておらず、気休めの中でプロダクトに対する意識が薄れてしまいました。プロダクトを作るには、コードを書くだけではなく、ニーズ分析やニーズ評価、さらにはフローチャートなども必要になります。この3年間で学んだことを活かしてプロダクトをより良くしていきたいと思います。 。また、初めてバージョンをリリースしたときの経験を利用して、自分に警告しました。何を捨てるにしても、捨てるという原則を失わないでください。そうしないと、常に製品ではなく単なるアプリになってしまいます。

以上が会社開発における私自身の経験を共有しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。