共享之舟——代码规范、冲刺任务与计划

共享之舟 2024-05-05 21:54:39

这个作业属于哪个课程	软件工程实践-2023 学年-W 班
这个作业要求在哪里	团队作业——站立式会议+alpha冲刺
这个作业的目标	保存α冲刺阶段的所有博客链接
其他参考文献	Spring官方在github上确定的风格 Spring Framework 官方建议的 XML 风格 Google Java 代码风格指南

目录

代码规范
冲刺任务
开发计划
团队分工
OKR过程
预估计划
管理工具

代码规范

前端代码规范
 后端代码规范

冲刺任务

前端：在前台部分，设计登录，首页，交易、举报模块。完成用户界面部分的店铺内容。在后台管理方面，配置客服模块和审核模块。
后端：根据前端内容，设计对应的接口。
测试：根据对应的开发内容，进行自动化测试，撰写测试文档。

开发计划

每天进行讨论，根据预计任务和实际需求设计对应的OKR，设置详尽的、符合SMART原则的任务目标。

团队分工

成员	分工	内容
陈卓杨	项目经理	与开发人员沟通，确保用户界面符合需求协调团队工作，确保项目按时完成参与文档和ppt设计组织站立式会议，记录会议内容
戴聪	前端	负责用户和客服登录界面、后台界面和前台部分页面的前端开发与设计
谢凌云	前端	负责用户注册、前台页面的前端开发与设计
熊桂根	后端	负责用户界面、登陆、首页的后端开发与设计
蓝有润	后端	负责客服、审核模块、交易模块的后端开发与设计
陈智翔	测试	负责对前后端的测试，确保各项功能正常运作测试评价举报、登陆、首页、聊天等模块，报告错误和问题在项目前期，尽可能参与前后端的设计

OKR过程

在这里插入图片描述

预估计划

采用并行开发的方式进行开发，若成员感觉到一个模块进入瓶颈区，可以先着手开发另一个模块，等到会议时，集中解决问题。

时间	登陆模块	首页模块	用户界面	举报模块	审核模块	交易模块	客服模块
5月5日	✓				✓
5月6日	✓				✓
5月7日		✓			✓
5月8日		✓				✓
5月9日			✓			✓
5月10日			✓			✓
5月11日			✓				✓
5月12日				✓			✓
5月13日				✓			✓
5月14日

管理工具

本次作业的OKR采用worktile进行管理。
使用Worktile管理当天的OKR。

在这里插入图片描述

以Objective+Key Result的形式设置OKR。

在这里插入图片描述

...全文

206 回复打赏收藏转发到动态举报

写回复

回复

切换为时间正序

请发表友善的回复…

发表回复

这是我自己努力整理的外文翻译，中文字数有8760，英文字数有4774个！介绍极限编程。

编程专业英语.rar 编程专业英语.rar

期中项目小组成员乔恩·多米尼克·巴里萨坎（Jon Dominic Balisacan）|基特·埃文·马西拉（Kit Ervin Marcilla）

注意：本项目使用android studio开发，eclipse可能无法使用。豆芽的名字取自“Douban, Yet Another”的缩写和中文词语“豆芽”的拼音正好相同的巧合。取名之后，我才得知豆瓣的 Windows Phone 客户端的名字也叫做“豆芽”。所以相对于豆瓣官方应用“一个叫‘豆瓣’的App”，也正好将这个应用称为“另一个叫豆芽的应用”了。为什么要有豆芽？直接访问豆瓣的所有人里，最普遍而一致的用法是围绕电影、电视、书、唱片、活动(我们叫做”条目”的东西)的评分评论、发现和讨论。我们会把和网站同步的评分评论作为一个起点和基础，在手机上重新构建围绕个人兴趣的发现和讨论。一个叫“豆瓣”的App——豆瓣日志豆瓣从来不是一个单一的网站，而对于豆瓣的用法自然不尽相同。使用豆瓣是为了获取信息，但信息的获取是基于条目和算法，还是基于友邻和人，这个问题在豆瓣的多次改版中大概一直悬而未决。这次，一个叫“豆瓣”的应用选择的是基于条目的推荐。但我个人作为一个重度豆瓣用户，重视的却恰好是基于人的推荐，喜欢的是友邻间的鸡犬相闻，以及闲逛时从条目评论、广播、日记中发现新友邻的惊喜。正如我在某次“还我旧版”运动中听到的声音，“不管怎么改版，只要友邻们还在就好”，改版是豆瓣不断良好发展的必经之路，但这句话中对友邻的珍重又令我感受到了豆瓣最宝贵的特质。豆瓣作为一个工具的价值可以通过条目很好体现，但豆瓣作为一个独一无二的社区，只能通过它独有的、克制的、以人为本的方式才能维系。作为一个普通但也深爱豆瓣的用户，我希望豆瓣在这个方向上也不要失落，因为一个只有工具属性的网站对我而言将再也没有这样的归属感。我在这一点上与豆瓣应用有了不同的追求，并且恰好有一些这方面的能力，又恰好豆瓣提供了开放的 API，于是就想要将这个想法实现出来了。选择开始豆芽这个项目，还有一个原因是我希望在豆瓣继续看到平台原生的设计。豆瓣广播在几年前就已经是国内少有的几个 Android Design 的应用，这一点一直令我钦佩和喜爱。在豆瓣应用最开始的版本中，也曾有过 Material Design 的尝试，但随着和 iOS 风格设计的杂糅，逐渐显得不合时宜，以至于最终选择了完全的 iOS 风格。我对此一直感到有些遗憾，况且 Material Design 也是一款更加优秀的设计语言。所以，我希望实现未能见到的另一种可能性。部分特性 Material Design 首页友邻广播启动速度优化界面动画支持屏幕旋转平板多列视图支持使用 Custom Tabs 打开网页支持切换长/短链接显示关于名字指导原则豆芽的最终目标是为豆瓣中基于友邻的信息获取方式提供在移动端的便利。为了优雅地实现这个目标，豆芽将主要遵循以下的原则：遵循 Material Design 规范，且指导思想优先于细节规定。像素完美，但更注重以人为本。实现精确，代码可以自我辩护。行为合格，支持屏幕旋转和平板布局。功能崇尚简约，不打扰用户。行为默认值合理，且用户可调节。积极表现豆瓣特性，如广播、友邻、豆邮等。通过细节设计，提倡用心、考虑到他人的内容。规则可以被打破，但前提是理解规则。功能架构豆芽的架构将与当前网站的设计十分类似。你可能会问，难道豆芽只是要做一个豆瓣网站的移动端界面么？并非如此。豆芽的最终目标是为基于友邻的信息获取方式提供便利，所以架构设计也是为此服务。而架构与当前网页端设计基本相同，则是因为现在网页端正是一个符合这个目标的设计，并且与移动端的导航也可以很好地契合。让我们详细地规划一下豆芽吧。导航采用抽屉一级导航选项卡二级导航的方式。工具栏上将显示全局的动作。工具栏提醒：所有类别的提醒，可以查看历史提醒豆邮：用户间的邮件往来，希望鼓励郑重而非聊天。搜索：立即访问想要的内容。用户：点击后显示个人页面，相当于“我的豆瓣”。首页友邻广播：友邻互动、友邻推荐、系统定制的推荐。九点：友邻的日记、博客文章等，有深度的内容。一刻：全站范围的热门内容推荐。同城：基于地理位置的内容。线上活动：基于共同兴趣的内容。读书分类浏览、首页推荐：入口，以及最有可能发现新内容的地方。我读：管理自己的读书标记、创造内容。动态：查看友邻的阅读动态，互动、获得推荐。豆瓣猜：基于算法的推荐。电影类似读书。音乐类似读书。设置：提供应用设置等。在子页面设计中，豆芽将尽量鼓励长内容和用心的互动。因为我相信只有豆瓣值得这样尝试。实现状况我在最初的二十天内冲刺实现了应用的网络层、账户系统等基础架构，和查看友邻广播需要的大部分功能，大约 8000 行代码。在接下来的八十天中，由于课业、其他事情和速度瓶颈，实现过程有所减慢。但是，应用的细节功能和界面交互都正在不断地被实现和优化。代码量达到了 14000 行，同时为此应用而写作的多个开源库的数千行代码并没有被计入。此后项目经历了大型的重构，以适应代码复用和支持屏幕旋转的需求。在此之后，我得以实现了一个较为美观的个人资料页，并且对应用的许多细节进行了完善。目前实现了原“豆瓣广播”应用的大部分功能。剩下的工作也正在继续进行中。实现架构数据层面应用除了对少数内容进行缓存，其他内容均直接从网络获取。基于 Android 账户系统提供用户账户和身份认证。使用 Volley 及部分自定义增强处理网络请求。使用 Gson 自动填充数据模型。使用 Glide 加载图片。使用 DiskLRUCache 及自定义增强对首页数据进行缓存。使用 EventBus 同步不同页面间对象状态。界面层面使用 Support Library 中的 AppCompat、Design、CardView、RecyclerView 进行 Material Design 实现，在必要时引入/自己写作第三方库以实现部分界面元素和效果。使用框架的 Shared Element Transition 实现在 Android 5.0 以上的界面过渡动画。界面实现一般分为 Activity、Fragment、Adapter 三个模块，分别负责作为容器，发起请求、展示数据和用户交互，以及数据/交互绑定。实现难点网络请求 Volley 本身是一个不算十分完备的库，对于请求参数、重试、认证等方面都需要开发者自己实现。在豆芽中，应用对 Volley 进行了包装，增加了以上功能，并且尽力做到了通用，为之后 API 层建立提供了很多方便。磁盘缓存 DiskLRUCache 是一个只实现了同步读取写入的库，因此豆芽对其进行了包装，提供了异步读写的 API，正确实现，提高了应用的响应速度。状态同步由于各个界面独自获取数据，数据本身与常规的 ContentProvider 机制中不同，是去中心化的，即可能遇到状态不同步的问题。具体地说，即有可能用户在广播详情界面中点赞后，回到主界面列表视图，发现并未更新状态。而豆芽解决方案则是使用 EventBus，在请求完成后通知所有界面刷新同一数据。界面动画 Android 5.0 以上提供了 SharedElementTransition，然而默认情况下共享的界面元素在动画时却会被放置在其他界面元素之上，导致其突然越过 AppBar 或 StatusBar 的情况。通过大量的文档阅读、源代码分析和调试，经过大约一周的时间，最终实现了较为理想的效果。屏幕旋转 Android 在屏幕旋转时，会销毁视图和 Activity 并重建，此时如何保存视图状态和已加载的数据、正在进行的网络请求即是问题。 Android 对部分视图状态提供了自动保存恢复，而豆芽对于其他需要保存的状态则通过自定义的 onSaveViewState() 和 onRestoreViewState()。对于数据，豆芽通过自定义的一个无界面的 RetainDataFragment 进行数据保留，并且接口十分简单易用。同时，由于网络请求的异步特性，豆芽通过自定义的一个 RequestFragment 实现了网络请求在 Activity 重建期间的保留，并且能够在 Activity 重建完成后将请求前的状态和请求结果回调至新的 Activity。平板适配 Android 本身的资源系统提供了对不同配置的很好支持，通过建立不同的资源文件，即可在手机和平板上使用不同的界面设定。此外，由于采用了 RecyclerView，通过在运行时判断当前设备配置，可以动态给界面设置为 1、2、3 列视图，充分利用屏幕空间。启动速度 Android 默认在冷启动应用进程至能够调用 Activity.onCreate() 前会加载应用主题中的背景作为预览，而默认背景是白色，与应用在上部拥有绿色 AppBar 的效果不相匹配。为了生成适应于不同屏幕大小、系统版本的图片，我使用 bash 编写了一系列脚本，并实现了一个通用的模板化 SVG 格式，详情见 MaterialColdStart 和 AndroidSVGScripts。经过自定义窗口背景和其他优化，应用在手机上已经可以达到立即启动的视觉效果。派生开源库为此项目诞生的五个开源库： MaterialColdStart，800 Stars MaterialProgressBar，500 Stars CustomTabsHelper，200 Stars MaterialEditText SystemUiHelper 第三方库 PhotoView Glide Gson ButterKnife DiskLruCache ThreeTenABP Volley EventBus CustomTabsHelper MaterialEditText MaterialProgressBar SystemUiHelper MaterialColdStart 构建 APK 文件可以在本项目的 Releases 中找到。至于手动构建本项目的基本步骤：创建 signing.properties： storeFile=YOUR_STORE_FILE storePassword= keyAlias= keyPassword= 执行 ./gradlew build。使用安装应用后，请安装豆芽 API Key 设置向导以设置 API Key。暂时没有内置的更新渠道，请关注本项目的 Release。请不要安装从不可靠的来源获取的 APK，以免泄漏您的用户名和密码。本项目git地址：https://github.com/DreaminginCodeZH/Douya

前端代码规范后端代码规范5.3：确定技术栈，明确原型需求，准备好项目所需icon等素材 5.4：项目框架搭建完毕，引入必要的依赖以及资源 5.5：进行页面搭建 5.6：完善并优化页面 5.7：处理基本事件 5.8：测试页面显示以及事件，修改bug 5.9：封装请求axios信息，便于统一处理后端接口 5.10：对接后端api，获取数据库信息，完善网站 5.11：测试网站，发布1.0版本5.3：后端框架搭建和数据库修改5.4：数据库搭建和AI接口初步开发5.5：跨域处理和Token验证框架集

软件工程实践-2023学年-W班

315

社区成员

832

社区内容

发帖

与我相关

我的任务

软件工程需求分析结对编程高校福建省·福州市

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章