摘要：
场景：数据量大、实时性强 传统方法：哈希表存储 Hash(id) % M: M大，冲突小，内存消耗大；M小，相反。 ID不断增长 服务器资源有限 Tensorflow服务不了大规模数据 提出方法1: Kraken (Memory-Efficient Continual Learning) For b 阅读全文
摘要：
第二十一章讲了衡量满意度。虽然我还没有接触过真正的用户，但是这个也是未来一定会遇到的，保证用户会对最终的设计感到满意的最简单和最可靠的方法就是始设计时测量他们的满意度。没有周期性的度量,很容易就造成一种后果,就如同美国人去到巴黎,并在三星级的餐馆里点一份大餐。当他看到在大盘子里小牛的圆滚滚的眼睛瞪着 阅读全文
摘要：
本周对项目进行视频录制，录制过程中出现很多问题，反而觉得录制视频是最难的，不过最终的成品我很满意。 阅读全文
摘要：
第二十章讲了技术复审。需要需求复审是因为没有人能够在稳定的基础上制作没有错误的求,同时也因为制作者是最不容易看到他们自己产品的错误的人。 通过阅读我了解到，无论何时你需要判断需求文档是否的确做了它被期望做的工作，都应该使用需求复审。 如何复审？ 1.有许多可以挑选的复审规则。都试一下,然后让它们满足 阅读全文
摘要：
本周进行项目归档，并开始撰写报告，同时完成javaEE大作业。 代码行：1000 阅读全文
摘要：
探索需求终于读到了第五篇：极大提高成功的可能。 第十九章讲述了含混性度量，使用含混性投票来估计需求中的含混性，能够测量目前还有多少作需要做,而且可能将注意力引导到什么地方需要做工作。 如何做？ 1,召集一组人,让其回答关于要测量含混性的文档的问题。2.确信不存在压力要求答案一致,或者不存在一个或其他 阅读全文
摘要：
这章讲的是期望。在探索需求中了解客户的期望是非常重要的。设计者需要跟客户关于对他们的期望的限制的问题上坦诚一些，因为如果事先诚实地表达过限制的问题,客户会更加容易地接受产品和系统。相反,当用户在成为事实后才发现限制会有被欺骗的感觉。同样，在设计过程的早期，制定和用文档记录限制条件的过程有助于揭示关于 阅读全文
摘要：
本周对软考进行了准备，我发现高级较中级来说，知识面更宽且问题的高度更高。论文也是一大难点。 阅读全文
摘要：
本周主要对安卓端进行手机适配以及界面调整，和项目的收尾工作。 代码行：500 阅读全文
摘要：
第十七章为偏好。上一章约束定义了解决方案空间中可接受的区域，而偏好引导在可接受区域中进行搜索。没有偏好,设计者可能在第一个可接受的解决方案就停下来(任何一个符合所有约束的方案),因为他们没有一个指南,告诉他们什么客户会认为“更好”。 什么时候做？ 偏好在约束已经确定解决方案的边界之后才开始制定。尽管 阅读全文