コードの可読性を向上させる
開発者は、コードを書く時間よりも、コードを読むことに多くの時間を費やす必要があります。私がここで話している読み物には、コードのデバッグ、他の人から提出されたコードのチェック、新しいコードベースの学習などのタスクが含まれています。
したがって、名前を長くしたり、コードを増やしたり、「ちょっとした賢さ」をあきらめたりする必要がある場合でも、コードが読みやすいことを確認する必要があります。
たとえば、変数名timeInMillisは時間より長く、より多くの文字を入力する必要がありますが、開発者は他のコードを見なくても、この変数がどのような時間を計算するかを理解できます。
別の例を挙げると、インターネット上には多くの1行のコードソリューションがあります。たとえば、次の回文数の判断方法は非常に賢いです（注：回文数は14641のような「対称」数を指します。つまり、この数を逆の順序に並べ替えると、次のようになります。オリジナルと同じ同じ番号）：
def isPalindrome(self, x: int) -> bool:
a=list(str(x))
return a==a[::-1]しかし、理解するのは非常に難しいです。1行のコードソリューションは非常に困難であり、複数の人が管理するコードベースでこのような記述方法を使用することはお勧めしません。
復興の価値
リファクタリングがあなたとあなたのチームメンバーがリファクタリングに費やした時間よりも多くの時間を節約するのに役立つ場合にのみ、投資する価値があります。コードを頻繁に読み書きすることにエネルギーを集中する必要があります。
新しいチームメンバーに緊急ではないリファクタリングを割り当てて手を練習することを検討できます。そうすることで、チームメンバーは学ぶ機会を得るだけでなく、価値を提供することもできます。
技術的負債を金融負債として扱い、いくらか余裕があります
ビジネスの観点から、価値のある機能をできるだけ早く提供することで、より大きなメリットが得られる場合があります。たとえば、競合他社が同様の機能をリリースする前に、現時点で機能が完全でなくてもかまいません。計画を立て、債務が高く「利子」が圧倒される前に、タイムリーにコードを改善します。
技術的負債の累積が返済能力を超えると、問題が発生し、コードベースの処理がますます困難になります。
たとえば、タイムクリティカルな状況では、テストが完了する前に機能をリリースすることがビジネス上の正しい決定である場合がありますが、その直後にテストを構成する必要があります。テストを遅らせると、これらのテストされていないコードの上に新しいコードがすぐに表示され、テストなしでリリースされた機能も次々に表示されます。その後、技術的負債のこの部分を返済することがますます困難になります。チームに手入れの行き届いたコードベース。
驚きをしないでください
チームメンバーは、コードが一般的な規則に従っていると想定するため、これらの規則から逸脱したり、驚いたりしないでください。
たとえば、関数isButtonEnabled（）を作成すると、チームメンバーは、関数がボタンをチェックしていると確実に想定し、これらの関数名のほとんどが「is-」で始まるため、ブール値を返します。関数が他の処理を行う場合は、名前で明確にする必要があります。
名前の長さはスコープによって異なります
たとえば、iやjなどの変数名はforループで使用できますが、グローバル定数の名前はその意図をより正確に表す必要があります。
関数は、重複を避けるためだけでなく、読み取り可能である必要もあります
一般に、3回以上繰り返されるコードは関数として記述する必要があるとよく言われますが、関数として記述する必要がある状況をさらに2つ追加したいと思います。
1）このコードの目的を説明するためにコメントを追加する必要がある場合。
2）入れ子が3レベルを超えた場合。
たとえば、次のUI関数を作成したとします。
fun setupViews() {
// set up textView
textView.isVisible = …
textView.text = …
…more textView setup…
// set up imageView
imageView.image = …
imageView.backgroundColor = …
…more imageView setup…
}重複するコードが含まれていない場合でも、対応するコードを他の2つの関数setupTextView（）とsetupImageView（）に配置する必要があります。
このように記述されたコード自体をドキュメントとして使用できます。imageViewを変更またはデバッグする必要がある場合は、すべてのコードを読み取らずに、setupImageView（）に直接移動できます。
もう1つの一般的な状況は、関数のコードの最大行数に関するものです。この値の設定は非常に任意であり、通常は5〜100の範囲です。個人的には、関数を読むときにページをめくる必要がないというのが基本的な基準だと思います。
繰り返しには多くの形式があります
DRY（自分を繰り返さないでください、自分を繰り返さないでください）は、よく知られているソフトウェアエンジニアリングの原則です。最も一般的な複製はまったく同じコードですが、実装の複製など、それほど明白ではない複製の形式もいくつかあります。
たとえば、次のように定義されたクラスの場合：
class TreeNode {
val value: String
var children: List<TreeNode>
val isLeaf: Boolean
fun addChild(node: TreeNode) {
children.add(node)
isLeaf = false
}
fun removeChild(node: TreeNode) {
children.remove(node)
if (children.isEmpty()) isLeaf = true
}
}子が更新されるたびにisLeafを設定する必要はありません。funisLeaf（）= children.isEmpty（）を追加できます。このように、このクラスを更新するときに、isLeafが更新されているかどうかを確認する必要はありません。
他の人の仕事を繰り返さないでください
機能を実装する前に、コードベースに既製の実装があるかどうかを最初に確認する必要があります。
たとえば、時間を処理する必要がある場合、定数SECONDS_PER_MINUTEがすでに存在している可能性があり、同じコードベースでこの定数を複数回定義する代わりに、直接再利用できます。
プロジェクトのプログラミングスタイルを学び、それに従う
統一された開発ガイドは、チームメンバーがお互いのコードを理解するのを容易にし、新しいメンバーを容易にすることもできます。通常、実際のルールは重要ではありません。重要なのは、これらのルールが確実に実装されるようにする必要があるということです。たとえば、Kotlinを見たことがあります。拡張子関数を含むすべてのファイル名は「-Ext」で終わり、他のファイルは「-s」で終わります。実際の選択は重要ではありません。重要なのは、全員の選択を統一する必要があるということです。この方法でのみ、プログラマーはFooの拡張機能の場所を知ることができます。FooExt.ktまたはFoos.ktのどちらにありますか？
lintルールを通じてコードのクリーン度を向上させる
プロジェクトでlintツールを使用していて、フォーマットを手動で調整することが多い場合、またはコードレビュー中に誰かがフォーマットを提案することが多い場合は、新しいlintルールの追加を検討する必要があります。
IDEの使い方を学ぶ
最新のIDE（Android StudioやVSCodeなど）は非常に強力です。IDEのさまざまなガジェット（デバッガーなど）とキーボードショートカットの使用方法を学ぶ必要があります。これにはある程度の時間の投資が必要ですが、長期的には多くの時間を節約できます。
ワークフローを最適化するには、設定とキーボードショートカットをカスタマイズする必要があります。たとえば、JetBrains IDEはデフォルトで「エディタタブの分割」ショートカットキーを提供していません（[ウィンドウ]→[エディタタブ]→[垂直に分割]をクリックする必要があります）が、頻繁に使用するため、カスタムショートカットキーを追加しました。
コメントは、方法ではなく理由を説明する必要があります
理想的には、コードは自明であり、コメントは必要ありません。プログラマーがコードを変更するとき、更新コメントを無視することがよくあります。長い間、コメントは不正確になり、実際のコードとは大きく異なります。コードの機能を説明するコメントを書く場合は、コードをリファクタリングして、コードをわかりやすくすることを検討してください。
ただし、コードだけでは、このアプローチを選択する理由を説明するのに十分ではありません。注釈は、意思決定、システム制限、または効率の考慮に役立つ製品要件などのコンテキストを提供できます。
テストコードを二級市民として扱わないでください
本番コードを作成する場合、機能がリリースされる前に高品質を確保するためにコードの計画に時間を費やす必要があるかもしれませんが、プログラマーは通常、正常に実行される限り、テストコードを無視します。ただし、テストコードも保守する必要があり、コードがわかりにくい場合は保守の負担が大きくなります。
問題の一部は、テストコードは一般的に厳密なレビューを受ける必要がないということです。誰もが製品コードのレビューに多くの時間を費やしていますが、結局のところ、テストに合格しているため、テストコードは不要だと感じています。
フォーム駆動型テスト
数か月前、私はJunitのパラメーター化されたテストを発見しました。これは、より徹底的なテストを作成するのに役立ちました。
従来の単体テストでは、通常、入力ごとに1つのテスト機能しかありません。結局、多くの関数には重複したコードがあり、一部の入力を見逃しがちです。テーブル駆動型テストには、個別のテスト関数と、すべての可能な入力と期待される出力を含むテーブルがあります。すべての入力をテストするために必要なテスト関数は1つだけです。
新しいライブラリを採用するのは危険です
各ライブラリにはプレリリースバージョンがあり、既存の機能を壊す可能性があります。
新しくリリースされたライブラリでは、テストの容易さが二次的な考慮事項になる場合があります。大規模なプロジェクトで新しいライブラリを使用する場合は、これらのライブラリがテストコードに合格し、本番コードと互換性があるかどうかを事前に確認する必要があります。
ライブラリがコミュニティに広く採用されるまで、問題が発生したときにリソースを見つけることは困難です。そして多分このライブラリは決して広く採用されることはなく、プロジェクト自体はメンテナによって忘れられるでしょう。
一部のライブラリでは、誰もがそれらを使用しているようですが、これらのライブラリは実際のプロジェクトで使用されていますか？それとも、デモプログラムに表示されるだけですか？
チームメンバーに助けを求めるときは、解決策だけでなく、彼らの方法にも注意を払ってください
チームメンバーが使用するリソースとツールに注意してください。将来同様の問題が発生した場合は、自分で武装して問題を自分で解決することができます。ドキュメントリソース、Gitコマンド、キーボードショートカットなど、新しいリソースやツールを見つけることは貴重です。
レビューアがコードの変更について混乱したり誤解したりしたと感じた場合は、コードに問題があることを意味します
レビューコメントへの返信に加えて、明確にするためにリファクタリングまたはコメントの追加を検討する必要があります。これにより、将来このコードを読むときに他の人が同じ混乱に遭遇することがなくなります。
コードレビューコメントを読む
特定のコードを理解するのが難しい場合は、コードレビューのコメントを注意深く読む必要があります。コードレビューコメントから、同時に変更された他のコードを確認できます。したがって、これらのレビューコメントを読むことは価値があり、コードの背後にある決定の説明が含まれている場合もあります。
実装している関数が既存の関数と非常に類似している場合は、類似した関数のコードレビューコメントを読むと、独自の実装を計画するのに役立ちます。たとえば、特定のAndroid機能を追加したいが、iOSまたはWebにすでにこの機能がある場合は、他のプラットフォームに実装する方法を確認すると便利です。
好きなように勉強する
大学にいるとき、あなたの知識は、クラスで勉強することに加えて、主にあなた自身のサイドプロジェクトから来ます。仕事を探すとき、これらの経験はあなたが目立つのを助けます。しかし、将来の仕事で、自分のサイドプロジェクトと比較して転職したい場合は、実際の仕事プロジェクトの経験が面接官の支持を得る可能性があります。
サイドプロジェクトでは、やりたいことができますし、もちろん楽しみ続けることもできます！ただし、ブログを読む、講義を見る、オンラインコースを受講する、ポッドキャストを聞くなど、学ぶ方法は他にもたくさんあります。好きな方法を見つけたり、仕事以外の時間を使って他の趣味を開発したりできます。
オンラインリソースの品質は不均一です
誰でもインターネット経由で技術的なブログ投稿を公開できます。ブログ投稿を通じて新しいテクノロジーを学ぶことを計画しているが、内容が不合理であることがわかった場合は、記事自体がうまく書かれていない可能性があります。ここで諦める必要はありませんが、他のリソースを試す必要があります。 。
公式のリソースとチュートリアルは通常、良いエントリポイントです。会議のスピーチや会社の技術ブログの品質は、これらのリソースが厳密にレビューされているため、一般的に比較的高いです。
やっと
学習リソースと言えば、私がよくアクセスするWebサイトの一部を以下に示します。この記事に記載されているガイドラインの多くも、これらのリソースから派生しています。
- リファクタリングの達人：クリーンなコードを記述してリファクタリングする方法を説明するWebサイト。
- クリーンコード：古典的なソフトウェアエンジニアリングの本。一部のコンテンツは少し古く、リファクタリングの達人と重複していますが、それでも読む価値があります。
- Martin FowlerのWebサイト：著者はソフトウェア開発に関する多くの本を書いています。また、彼のWebサイトには、ソフトウェアアーキテクチャとリファクタリングに関する多くの情報があります。
- Androidウィークリーニュースレター：多くの技術記事、ポッドキャスト、スピーチを特集する週刊誌。Androidに限定されていますが、他のプラットフォームにも同様の週刊誌があります。
- Yelp Androidスクール：テクノロジー講義のGitHubリポジトリ。それらの半分はAndroidベースであり、半分はソフトウェアエンジニアリングについて議論しています。
今日のビデオ：C / C ++エントリーゲーム開発-2048（リンクを含む）