看代碼

看代碼學會從業(yè)務角度去看

看一個類重點看它的public方法，那是對外的接口

private方法幫助理解類內部的工作

首先要把數(shù)據結構完全弄清楚，精確到類的每個屬性及成員，可以幫助更好的閱讀代碼

需求

需求不明確的話，需要找到特定的人來對齊，不能自作主張

eg:是否會有”speed camera”和”traffic signal camera”并列的情況

1.和團隊提出這種情況，小組內部討論，征求建議

2.和后端確認是否存在這種case的路段

3.和設計提出這種case在，等待反饋UI上的display

編碼

開發(fā)新Feature時，評估是否需要添加FF控制

關于“NonNull”注解

解析時字段不可缺，并且不能為空（null）

解析后端傳過來的協(xié)議字段

要考慮不存在的情況（前端還沒有相關定義）

避免發(fā)生問題

判空

時刻謹記“判空”（尤其是java），避免空指針異常，保證代碼健壯性?。?！

-源數(shù)據

-讀數(shù)據（“空指針異常”高發(fā)點）

-處理數(shù)據

線程安全

檢查線程安全問題，關注程序的讀寫操作?。?！

打印信息的敏捷性：

Log>Print>Toast

模塊之間的關聯(lián)依賴關系，哪些模塊的api可以使用

添加新的業(yè)務邏輯，盡量引入回調控制和輔助?。?！

關于request和reponse的處理

前端可以適當控制阻塞邏輯，避免頻繁的request

關注cancel()的方式方法

地圖顯示

重要思想：“l(fā)ayer”和“data”可以完全割裂開去處理，初始化時盡量不扯上關系，各得其所

單元測試

意義：幫助驗證代碼的邏輯是否正確，功能是否完善

本地自測

每更新完一版代碼

一定要本地自測驗證一下！

架構設計

多視角全面考慮問題：

1.需求對上游的影響，當前負責的模塊如何配合

2.需求對下游的影響，當前負責的模塊如何配合

3.業(yè)務模塊需要怎么修改

版本兼容

新版本的前后端修改不能影響發(fā)出去的版本