1.格式描述
2.NABCD模型
3.原型设计
4.结对讨论过程
5.效能分析与PSP
6.困难与解决
7.心得与总结
8.PDF以及花絮程序员
墨刀连接
阶段一数据库
阶段二编程
阶段三后端
界面设计缓存
登陆界面
服务器
论文搜索界面
app
热词搜索界面
框架
论文列表界面
编辑器
收藏夹界面
工具
折线图界面
条形图界面
热词图界面
与3月4日(星期一)组成小组。过程以下
目前还没生产出软件实例,经咱们估计数据库访问语句和服务器的访问压力是比较耗费资源和耗时最多的,应该对此进行优化,如:
- 服务器: - 使用内存数据库(仅对热词,访问量较高的文章) - 增长缓存 - 选择合适的IO模型 - ... - 数据库: - 对查询进行优化,要尽可能避免全表扫描 - 对于多张大数据量的表JOIN,要先分页再JOIN,不然逻辑读会很高,性能不好。 - ...
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分 钟) |
Planning | 计划 | ||
• Estimate | • 估计这个任务须要多少时间 | 180 | 350 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 150 |
• Design Spec | • ⽣生成设计⽂文档 | 30 | 40 |
• Design Review | • 设计复审 | 20 | 10 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 20 | 20 |
• Design | • 具体设计 | 120 | 250 |
• Coding | • 具体编码 | 120* | 250* |
• Code Review | • 代码复审 | 20 | 10 |
• Test | • 测试(自我测试,修改代码,提交修改) | 20 | 20 |
Reporting | 报告 | ||
• Test Repor | • 测试报告 | 30 | 15 |
• Size Measurement | • 计算工做量 | 15 | 10 |
• Postmortem & Process Improvement Plan | • 过后总结, 并提出过程改进计划 | 30 | 25 |
合计 | 435 | 800 |
A:求同存异,取其优者
A:只能多看说明多使用
A:多看参考精美UI设计
A:多交流多讨论,向对方提供合理的建议
以往咱们编程时都是一股脑使劲写,想到什么写什么,就像在希尔顿的屋子里那个外国人同样,会写中文缺不理解中文的意思。经过这次任务,我明白了编程只是很小的一个方面,要赋予软件生命绝对不能机械生硬的把代码从一边搬运到另外一边。要去了解需求,体会用户,把软件带入到咱们生活中,以对人的态度对软件,也就是对用户的尊重。但我仍是会有一些疑惑,咱们这种的方法挺好的,可是不是全部公司都在使用这种方法(计划),若是将来赶上了某种公司不认真地对待软件设计,把程序员只当成代码生产机器,咱们应该怎么办呢?
经过此次的原型设计,让我受益不浅。以往我并不把需求分析当作一回事,以为大概就好,可是当咱们互相讨论时,我发现不能只是经过本身的角度看待问题,有时候须要听取别人的意见。本身考虑问题时,不免会出现考虑不周全等问题,与人交流讨论,互相求同存异,更能解决问题。还有就是,经过原型设计,我学会了如何使用墨刀这款工具,这是我第一次使用这样的工具设计界面,对于我之后的UI设计仍是颇有帮助的。尽管当中不免会碰到难以解决的问题,但对于我而言都是一种锻炼。当设计原型时,我发现,有个大体的草稿图,对于后期的UI设计能提升很好的开发效率,固然,有时候咱们也须要去借鉴一些优秀的UI模板,不只能够从中体会一些好看的UI设计,并且能让本身更好的借鉴经验。总的来讲,原型设计的实验,于我获益多多。
此次任务看似比较轻松,没有编程任务。实际上分析设计和合做才是咱们须要锻炼的,做为一个大学生,在大学的课程都是在学习编程,不多学习分析设计,从上学期的UML才算是软件设计技术的初略门道,做为软件设计者来讲,用户需求才是咱们最关心的。咱们必须站在用户角度考虑问题。还有合做,在将来工做的时候,本身单干的几乎不多,都是你们一块儿分工搭配,我以为合做中,信息与信任是最重要的。在工做中,信息必须平等流通,不然会致使设计或代码对接失败,成为木桶的短板。信任为合做的核心,有着事倍功半的效果。
草稿图
结对第一次—原型设计PDF