チームをさらに発展させるための優れた開発習慣
コードの仕様
Java
I. カスタム識別子
識別子の詳細
識別子の構成要素は、文字、数字、アンダースコア、ドル記号などです。
識別子は数字で始まることはできません。
識別子は大文字と小文字を区別します。
識別子の長さに制限はありません。
識別子の命名は一般的に意味のあるものでなければなりません。
(vi) キーワードおよび予約語はカスタム識別子に使用できません。
識別子の仕様
クラス名とインターフェース名の単語の最初の文字を大文字にし、その他の単語を小文字にします。
変数名とメソッド名の最初の単語はすべて小文字、その他の単語の最初の文字は大文字、その他の単語はすべて小文字 [ doCook() ]。
パッケージ名の単語はすべて小文字にします。
定数はすべて大文字、単語はアンダースコアで区切ります。
3.準拠しているものの識別子を判定します。
12abc_ [合法ではありません。から始まる数字は不可]。
12abc【合法
③ $ab12# [合法ではありません。記号は識別子の構成要素ではありません]。
abc@123 [不正です。記号は識別子の構成要素ではありません]。
次に、ノート
注釈のカテゴリ
、複数行注釈と文書注釈の違い
、javadoc開発ツールの使用は、開発者ドキュメントを生成することができます。
書式：javadoc -d ドキュメントが格納されているパスを指定 -version -author （オプション） 対象ファイル
細部へのこだわり：
クラスが javadoc ツールを使ってソフトウェアの開発者向けドキュメントを生成する必要がある場合、そのクラスは public 修飾子を使わなければなりません。
paramメソッドのパラメータ @return戻り値
Android
I. 開発に関する考慮事項
: 再利用するコード、再利用するコード、重複するコードを書かないようにするコード
: プロジェクト・コード内でネイティブ・ログを印刷しない
Androidリソースファイルの命名と使用
推奨リソースファイルにはモジュール接頭辞が必要です。
レイアウトファイルの推奨命名規則
Activity モジュールのレイアウトは、モジュール_activity
Fragment モジュールのレイアウトは、モジュール_fragment
Dialog モジュールのレイアウトは、モジュール_dialog
include モジュールのレイアウトは、モジュール_include
ListView モジュールの行のレイアウトは、モジュール_list_item
RecyclerView モジュールの項目レイアウトは、モジュール_recycle_item
GridView モジュールの行のレイアウトは、モジュール_grid_item
描画可能リソース名は、解像度に応じて小文字の単語＋アンダースコアで命名することを推奨します。
異なるmipmapは異なるmipmapディレクトリに存在するので、例えばmipmap-xhdpiのように1つのセットだけを使うことをお勧めします。
module_name_business_function_control_description_control_state_qualifiersのようなルールの採用 例: module_login_btn_pressed、module_tabs_icon_home_normal
アニメーションリソースの名前は、小文字にアンダースコアを付けることを推奨します。
モジュールブロック名 [方向|シーケンス番号]。
tween アニメーション・リソース：可能な限り、一般的なアニメーション名を使用すること。，
如 module_fade_imodule_fade_out , module_push_down_in ( +Directions)を使用している；
frame アニメーションのリソース：可能な限りモジュール化する+関数の命名+シリアル番号。例：モジュール_loading_grey_0
カラーリソースには#AARRGGBBフォーマットを推奨します。
module_colors.xmlを次のファイル名で書きます。module_logic_name_colour 例: #33b5e5e5
dimenリソースには、小文字の単語＋アンダースコアで名前を付けることを推奨します。
module_dimens.xmlファイルを以下のルールで記述します。
推奨スタイルのリソースには、小文字の単語＋アンダースコアで名前を付けます。
module_styles.xmlファイルに以下のルールで書き込みます。親スタイル名
...
推奨される文字列リソースファイルまたはテキストを使用する文字をすべて書き込む必要があります。
module_strings.xmlファイルの文字列は、小文字の単語とアンダースコアで以下のルールで命名されます: module_name_logic_name 例: moudule_login_tips,module_homepage_notice_desc
Id資源は原則としてラクダ法で命名することを推奨。
ビューコンポーネントのリソース ID には、View の略語を先頭に付ける必要があります。一般的な略語の一覧は以下の通りです： Control 略語
LinearLayout ll
RelativeLayout rl
ConstraintLayout cl
ListView lv
ScollView sv
TextView tv
Button btn
ImageView iv
CheckBox cb
RadioButton rb
EditText et
Androidリソースファイルの命名と使用
その他のコントロールには、小文字を使用し、アンダースコアで区切ることをお勧めします。例えば、ProgressBarにはprogress_bar、DatePickerにはdate_pickerを使用します。
推奨される大きな解像度のイメージ大きな解像度のイメージは、xxhdpiで均一に配置することを推奨します。
そうしないと、メモリ使用量が指数関数的に増加します。 注：さまざまな画面サイズと密度をサポートするために、Androidは、異なるビットマップ描画可能なオブジェクトを提供するために、異なる画面密度に適応するために、さまざまな画面用の異なるリソースカタログを提供し、密度固有のリソース構成の修飾子で使用することができます以下に詳述）、ldpi、mdpi、hdpi、xhdpi、xxhdpi超高）、およびxxxhdpiを含む。 例えば、高密度画面のビットマップは、現在のデバイスの画面サイズと密度に基づいてmipmap-hdを使用する必要があり、低密度に高解像度のイメージの場合、最も一致するリソースを探します）。たとえば、高密度の画面のビットマップは、デバイスの現在の画面サイズと密度に応じてmipmap - hdを使用する必要があります、最も一致するリソースを探しますが、低密度のカタログに高解像度のイメージは、ローエンドのマシンが大きすぎるイメージリソースをロードする原因となり、OOMを引き起こす可能性がありますだけでなく、廃棄物の源は、ローエンドのマシンで大きなイメージを使用する必要はありません。 例：144144個のアプリケーションアイコンPNGファイルをmipmap-mhdpiディレクトリに置きます。
第三：その他の規範
スペーシング仕様
1カラム上マージン24dp
普通のラージピッチ16dp
スプリット・ライン 0.5dp
センターフレーム左右マージン16dp
テキストの上下マージン 4dp
左右の余白 8dp
デフォルトの表示高さ 48dp
リージョン・ディバイダー 8dp
フォントのタイプセット
大きなタイトル 34sp
タイトル 20sp
サブタイトル 16sp
主な記事 14sp
補助情報 12sp
ヒントテキスト 7sp
ボタンテキスト 14sp
一般的なフォントサイズ：
12sp: 小さな印刷のヒント
14sp(デスクトップ 13sp): テキスト/ボタンテキスト
16sp(デスクトップ13sp): 小見出し
20sp: AppBar
24sp:
34sp/45sp/56sp/112sp/特大テキスト
すべてのアクション可能な要素の最小クリック可能領域サイズ：48dp*48dp
ラスターシステムの最小単位は8dpであり、すべての距離、サイズは8dpの整数倍でなければなりません、以下はいくつかの一般的なサイズと距離である：
·トップステータスバーの高さ：24dp
·AppBar最低高さ：56dp
·下部のナビゲーションバーの高さ：48dp
·ホバーボタンのサイズ：56*56dp/40*40dp
·ユーザーアバターサイズ：64*64dp/40*40dp
·小さなアイコンクリックエリア：48*48dp
·サイドドロワーから画面右側までの距離：56dp
·カード間隔：8dp
·分割線の上下に空白：8dp
·ほとんどの要素のホワイトスペース：16dp
·画面左右のアライメントベースライン：16dp
·テキスト左揃えベースライン：72dp
チームワーク開発規定
I: 事前合意
合意は、チームワークを向上させる最も有効な方法のひとつです。一連のルールに合意し、それに従って仕事を進める方がはるかに効率的です。 たとえば、 分岐戦略、コードスタイル、インターフェイスの文書化などです。
: ツールとバージョンの調和
"良い仕事をするには、まず道具を研ぐ必要があります"、統一されたチームメンバーがツールを開発し、プラグインのバージョンに依存することは非常に重要なことです、あなたは後のプロジェクトの合併問題の多くを避けることができます。プロジェクトの開発サイクルを短縮します。
命名規則
名前付けの衝突は、開発プロセス、特に複数人の共同開発プロジェクトでよくある問題です。共同チーム開発は、一般的にモジュールに分割され、命名では、接頭辞または接尾辞としてモジュール名を追加することができます、あなたは名前の競合の問題のほとんどを回避することができ、大幅にチーム開発の効率を向上させます。
第2回：統合管理
: コード・バージョニング・ツールの有効活用
チーム開発プロセスでは、コードのアップロードとマージを毎日行うこと、各チームメンバーが開発用に別のブランチを作成し、セルフテストに合格した後にメインブランチにマージすること、トラブルシューティングや問題解決に多くの時間を費やさないようにすること、などが取り決められなければなりません。
この記事は、ブロガーが複数の記事を投稿するためのプラットフォームやその他の運用ツールである 公開されています。
