个人 final report

final report

github: karl-jm-huang

自我总结

这次我犯了很严重的错误，因为有参与API设计，但是没有先和前端详细协商好就写了API文档，导致前后端分离不成功，经常需要修改，辛苦了编码的同学。所以，API文档要清楚知道前端想要通过什么方式以及参数请求，需要哪种数据的什么属性，以及需要哪种数据结构格式，否则后端需要经常改代码，就没起到什么前后端分离的作用了。

感悟就是，需求分析和设计比编码更重要，清晰完备的文档可以很好降低沟通成本。

PSP 2.1 统计表

PSP 2.1	Personal Software Process Stages	Time/h
Planning	计划	5
-　Estimate	-　估计这个任务需要多少时间	5
Development	开发	65
-　Analysis	-　需求分析（包括学习新技术）	16
-　Design Spec	-　生成设计文档	4
-　Design Review	-　设计复审（和同学审核设计文档）	0
-　Coding Standard	-　代码规范（为目前的开发制定合适的规范）	0
-　Design	-　具体设计	8
-　Coding	-　具体编码	21
-　Code Review	-　代码复审	0
-　Test	测试（自我测试，修改代码，提交修改）	16
Report	报告	7
-　Test Report	-　测试报告	4
-　Size Measurement	-　计算工作量	1
-　Postmortem & Process Improvement Plan	-　事后总结，并提出过程改进计划	2

个人GITt统计报告

设计文档贡献

初版的小程序客户端贡献

二版的小程序客户端贡献
后来小程序前端交给zheever专门负责了

商家管理系统前端贡献

服务端贡献

最得意/或有价值/或有苦劳的工作清单

最有价值的工作	简短说明
文档设计	记录项目进程与会议记录，需求分析报告，领域模型，参与用例设计，参与API设计
前端初版	参与编码前端demo
后端测试	单元，压力，集成测试用例的设计与代码编写
服务器环境部署	申请https，云主机，设置nginx

个人的技术类、项目管理类博客清单

技术博客
微信web开发工具的七大主要调试功能模块
go test 单元测试与压力测试简单使用
利用 Travis CI 对 go项目 持续集成，涉及数据库操作