Đầu tiên, nó phụ thuộc vào ứng dụng bạn đang làm.
bạn nên làm một mô tả bằng văn bản hoặc sơ đồ về cách người dùng sẽ làm việc với ứng dụng. Khắc phục mọi tình huống có thể xảy ra. Đặt các ví dụ sẽ được sử dụng sau này cho các bài kiểm tra.
Quyết định những gì thuộc về chức năng và những gì - với cấu hình có thể thay đổi. Trích xuất các chức năng và thực thể dữ liệu từ các kịch bản.
Từ các kịch bản đưa ra quyết định ứng dụng của bạn sẽ là gì. Là dịch vụ, hoạt động, tiện ích, thậm chí là nhà cung cấp nội dung hoặc hệ thống phức tạp, bao gồm một số thành phần khác nhau. Kiểm tra quyết định của bạn chống lại các kịch bản.
Trong trường hợp hệ thống phức tạp, phân phối các chức năng và thực thể dữ liệu giữa các thành phần ứng dụng. Lập danh sách các thành phần và chúng là gì (hoạt động hoặc smth khác).
Tạo danh sách các thành phần UI với mô tả những gì chúng làm (chưa phải CÁCH) Đây sẽ là các tiện ích và hoạt động hoặc các đoạn hoặc bố cục sau này.
Tạo bố cục dự thảo cho các thành phần UI. Thực hiện các bước đơn giản từ người này sang người khác. Nhìn vào giao diện người dùng. Quay trở lại các kịch bản và phát tất cả chúng với giao diện người dùng dự thảo của bạn. Tất cả các thành phần và lớp UI được đưa vào một hệ thống phân cấp của các gói hoặc gói.
Lập danh sách các thực thể dữ liệu. Quyết định những gì sẽ được trong những gì. Lập kế hoạch chúng dưới dạng các bộ sưu tập hoặc bảng trong DB hoặc các DB khác nhau. Biến chúng thành các lớp, đặt chúng vào một hệ thống phân cấp khác của các gói hoặc gói khác. Ở đây cũng đặt các trình trợ giúp DB - các lớp nói chuyện với DB bằng SQL.
Tạo một lớp thử nghiệm (JUNIT hoặc TestNG tốt hơn) để điền vào các thực thể UI và dữ liệu với dữ liệu thử nghiệm và khởi chạy chúng.
Bộ điều hợp không cần công khai, vì chúng chỉ được sử dụng trong GroupView gốc của chúng. Vì vậy, không có tập tin cho bộ điều hợp thường.
Đừng không đặt tất cả globals vào lớp tĩnh đặc biệt - đó là một thực tế xấu. Bạn đang trộn để mã và cấu hình. Sử dụng giải pháp rất thú vị này . Hiện tại, nó là thứ tốt nhất tôi biết cho Android.
Dữ liệu cấu hình nên được đưa vào tài nguyên. Nếu một số trong số chúng phức tạp, hãy sử dụng các nguồn và trình phân tích cú pháp XML. Làm cho người đọc dữ liệu tài nguyên thành các biến toàn cầu. Không phải tất cả trong số họ sẽ được tĩnh! Chúng có thể thuộc về ví dụ Hoạt động chính, ví dụ.
Không sử dụng hằng số không thể định cấu hình trong mã! Có thể, tên của bạn chỉ :-). Mọi hằng số đôi khi trở thành không đổi.
Mặt khác, nếu một số mã của bạn không phải là java bình thường, mà là các tập lệnh - kết hợp dữ liệu và ngôn ngữ, thì bạn có thể và phải trộn dữ liệu và mã.
Luôn luôn làm như vậy: viết một cái gì đó - kết nối một cái gì đó với một số lượng lớn - thêm (các) bài kiểm tra cho điều mới này - kiểm tra cái mới này - kiểm tra số lượng lớn - lặp lại. Bước nhỏ thôi!
Chỉnh sửa. Bạn cũng có thể sử dụng phát triển theo hướng kiểm tra - viết kiểm tra trước khi mã phù hợp. Bằng cách này, chạy thử nghiệm trước khi mã sẵn sàng, bạn có thử nghiệm kép - do đó bạn kiểm tra xem các thử nghiệm có thực sự phản ứng với mã không chính xác hay không.