day 2 - 先看清楚目标的样子再动手

画流程图是我的第一堂程序课内容，大学教授讲了很多话，我记得的寥寥无几，其中一句话是：你画的出来就写得出来。一直到现在流程图是仍我最常用的辅助思考工具，不管是需求流程、系统架构流程、专案开发流程、操作流程...等，画好之後可以协助自己梳理逻辑，也可以用在开会时确认大家对於系统的认知是否有落差，最後是可以协助接手系统的人快速进入状况。

画流程图的工具有很多，我自己还是习惯使用cacoo

初始流程图

一般收到需求之後，第一步要先厘清需求的目的、预期效益，了解缘由并确认PM想达到的效果跟提出来的需求是有相符的，再来评估可行性。同时要评估未来需求扩张的可能性和预留需求扩张的弹性。
这次我模拟的需求是『要能统计工作点数且不能让每个统计层的点数超收。』
单就这一句，可以先画个很大方向的流程示意图：

然後再慢慢发想每个步骤,
可以搭配一个查询API, 就算之後API没有外接, 也可以留作自己检查系统时的接口

限额设定的资料源从哪里来？此时我会调整改用虚线来表示跟资料源取得资料的动作, 才不会跟流程混在一起

虽然需求很简单，可是随之而来要考量的还有：统计项目全统计可能会有几项？有大量快速读写的需求吗？要使用什麽储存工具？对储存工具操作的频率会有多高？需要事先对储存工具压力测试吗？诸如此类等等的各式各样的问题都是在接收需求後要去思考的，所以有时候初始流程图跟最後完成的流程会相差甚远，我会在每个异动阶段再去调整流程图，让流程图可以符合程序开发的状况。

初始API列表

根据初步流程图可以先开两个API接口：

• 异动点数资讯 - 接收公司各厂区＆人员的当次统计点数, 再统计到统计池中
• 查询点数资讯 - 查询目前统计状况

API要使用的input/output参数会搭配上下游的资讯做参考，以这个需求来说，input要能收到可以明确切割统计项的资讯，output 要根据client端需要拿来应用的资讯设计，所以在开立spec之後，我会分别跟上下游端口确认彼此需要的资讯是否都能满足。

评估工作时程

在需求确认完成之後就要先评估这个专案会在我手上花费多少时间，开发时程是依照个人的进度评估，以这两支API来说我大概会这样估：
API接口上下游沟通确认2hr, 工具选用评估1hr, 程序开发4hr, API测试1hr, 缓冲2hr, 这个需求评估时程大约会是10hr, 同时要检视手上进行中的专案工时还有多少，以及可能会插件的项目可能有哪些，确认好各个优先顺序之後再一起回报上去，接下来就是准备开发的前置作业了。