2017年7月开始，在一家物联网公司工作
熟悉公司产品的业务，理清大致逻辑，负责数据库的设计
因为我们各自负责的角色不一样，所以为了使得各自的工作更容易一点
我们的数据库设计时，会故意设计一些冗余字段
后面，公司又来了个新同事，我们负责一起进行分析数据结构，约定开发规范
1.方法命名
viewXxxxx
getXxxxxx
postXxxxx
2.每个view都有一个专门的js文件专门用于处理
3.ajax使用的接口使用MyResponse简单封装
4.微信版、App暂用同一项目
5.把Const用起来，常用的状态、属性等都要用常量
6.Helper工具类使用
这个类似自己写的常用公共函数
7.参数验证规范，大致格式
required|string
required|integer
required|in:used,unused
required|integer|min:1|max:100
required|Numeric
required|Regex:/^1[34578][0-9]{9}$/
numeric|regex:/^1[34578][0-9]{9}$/
8.
每个条件都要加{},{}在条件同行
数组或其他形式太多时专门定义变量
9.注释标准 [依据apidoc]
/*
* @api {get} /v1/common/olconfig 在线参数
* @apiName olconfig
* @apiGroup 0Start
*
* @apiDescription 在线参数
*
* @apiVersion 4.0.0
* @apiSuccessExample Success-Response:
* HTTP/1.1 200 OK
* {
* "code": 200,
* "detail": "success",
* "data": {
* }
* }
*/
10.加盐存储、rsa加密传输
11.登录生成token
每次登录重新生成token
token存放到redis中
...
我一个人依据web移动端的思想做了第一版的用户端
不过我们老大，希望做成的类似app那种免登录的
所以在接下来的一周会进行改动
云天河是个喜欢设计页面，且对于美有追求的人
但一个人要做完一个成品，而且只花5个工作日
天天都不敢走神，后面功能又得完成，所以只能简化界面，先实现了功能以供展示
经过第一次成果检验，我发现产品公司的常态就是，你不要太想着实现所有功能
可能你现在做的大多功能，在后一次的需求讨论后，都会被新的需求替换掉
所以，老铁们，不用太急着做完所有功能了，可能老板看你做完了，很闲，还给你加任务呢
做产品要注意，将功能最简化，功能层级越少越好，得让你所面向的用户群体几乎都能轻松操作
这周主要是为了把业务拉通，注重功能的实现
微信公众号才拥有的那些接口权限，使用前请都去看看 是否需要配置!!! 很重要！
网页授权需要配置回调域名
授权的时候 unionid 只有在用户将公众号绑定到微信开放平台帐号后，才会出现该字段
微信浏览器，不能直接从服务器发 header 重定向页面
因为服务器发来的请求 都会经过微信服务器中转
所以我们跳转页面用的是 JS 的 window.location.href
这样就可以模拟用户点击 链接跳转
因此 cookie 不变 用户的session就有保障了
app接口没有cookie，所以我们用都是token，token是一个get参数，一个相当于session_id的东西
对于那种服务器内部跳转的页面，进行调试的时候，你可以通过写日志的方法去实现断点调试
顺便提一下：Linux 监控文件变化的命令
tail -f <filename>
我之前一直以为是微信浏览器的原因，我的session老是会丢失
写了好多日志断点，好不容易发现了问题
发现 laravel5.1 里面的 session 不够稳定，用原生就可以解决了
微信被动php回复文本的地方，想要是能换行的，千万别用单引号
$text = '这是第一行\n这是第二行'; // 这不会换行，因为php会把单引号内的，当成一个字符串。 \n 会被转移成 \\n
$text = "这是第一行\n这是第二行"; // 这就能换行了，因为php会解析它，不仅仅是当成普通的字符串了。
查找套接字地址 -> 备份时带上套接字参数
去微信支付官网配置好目录（发起微信支付的网页地址的上级地址）
云天河 放 码云 上的demo
用 React Native 写一个简版APP
做产品得考虑团队沟通、多端协作【你可以把做产品，当成是英雄联盟打一场比赛】
下面举一个沟通的成本问题案例 ，人的理解度，每层递减 10%
现在运营的想做一个充值送红包的活动 （理解度 100%）
运营的要把这个活动思路告诉老板，老板觉得这个点子不错 （理解度 90%）
让运营再去告诉其他相关部门，比如，技术部 （理解度 90%）
技术部的老大听完了这个点子后，觉得可以接下这次的活动 （理解度 81%）
技术部老大把思路传给下面的技术人员 （理解度 72.9%）
东西在测试了，后端人员发现前端做出来的页面跟他想的不太一样，跟前端讲讲，前端的再去跟UI聊聊 （理解度 81%）
一个新的 版本出来了，运营觉得还不够好，跟技术部老大交流（理解度90%）
技术部的老大跟UI聊了聊，结果UI界面直接变了
UI把新的图给前端人员了，他们得重新写页面
前端人员需要新的接口，跟后端人员交流
...
逻辑的状态处理，如红包的设计
为何，我们设计了红包的开始时间与结束时间之后，还要设置一个status呢
这种业务，我们为了统一，尽量让多端显示的时候，对于逻辑的检测变得简单一点，那么何为简单呢
相同的业务逻辑，尽量使用统一输出接口
统一的输出接口，尽量让其他地方少使用逻辑方面的判定【涉及沟通，就得考虑沟通成本】
如，App[IOS、Android]、前端 ... 甚至公司业务大了起来，每种应用，可能需要多个人去处理某一个逻辑
试想，如果你一个做后台的跟做App的沟通说这个逻辑要怎么怎么输出，再去跟前端人员做相同的事
那么沟通要花多少时间在这些上面
浏览器可以有cookie，但是App没有，通常会导致接口不可共用，而且cookie也算是token的一种存在形式
考虑多端数据接收，大家制定一个标准的接口请求规则，方便调用，如，token方式的接口
登录时服务器端，返回token参数，各段将token存入应用
如，Web端的localStorage， App直接把这个token字符串保存起来，作为登录的验证
下次请求的时候，链接上带上token这个GET参数去验证身份，获取用户相关信息
对于业务实时性要求不高的，我们尽量让他异步处理，实现 `订阅 - 发布 模式`
大V发了一次微博，可能要推送给百万乃至千万用户
关注了该大V的用户端，会定时询问服务器是否有消息推送到自己这里了
如果有，自己再决定是否把数据拉取下来
非本公司的主业务，尽量不要在自己服务器上弄
最主要的原因是，东西做了之后，需要不断的维护，维护就有个成本
在线客服 - 即时通讯 => 融云 [websocket]
缓存层热数据 => 阿里云[Redis]
滑动验证码 => 极验验证
用户行为统计 => 极光推送、百度统计...
短信下发 => 阿里大于(短信帐号没钱了，调用会失败)
部门之间时常会产生一些不同观点，这时候应该如果做
技术部的和销售部的对某个产品的功能的使用方式的想法产生了冲突
我们应考虑的是听取人家销售部的
首先因为他们是离客户最近的部门
而且如果到时候产品的销售额达不到预期
我们技术部也不会担太多责任
毕竟我们意见也提过了，绝定权在人家的手上，我们最后只算是听人家办事的
如果目前是个小公司，测试APP、web这些工作，是让大家共同参与
那么我们技术部无论人家提出的是否说的得对
我们都应该先把这些内容虚心收集起来
首先不会打击别人提问题的积极性
再者技术部只用选择性修改这些问题
势特别是创业公司这个东西很明显
比如，我们技术部一开始就表现得很强势
这个强势呢，是依靠我们东西做得快，bug出得少
技术部就能有底气参与公司的决策，简单的说，像加班的问题
很多情况体现在加班上
初期见得最多的就是销售部加班
一加就是晚上九点以后
但是我们技术部做得好，就可以到点就走
老板如果不懂技术，一旦有几天看不到我们的成果，那他可就以为我们在玩之类的了
但凡做事，要在一定周期内，有一定成果，那么久需要有短期、中期、长期目标
目前我们可以有多种方式来进行，如，通过 OKR
每月用OKR依据与公司近期计划推出的产品，根据技术部实际工作效率，制定本月任务大方向
每周用OKR制定一个任务方向（用于公司要求的可衡量标准）
每天早起的时候列出任务计划与各个任务的预估时间（用于技术部的领导层知道下属当天至少应完成的任务）
当然，OKR是针对的只是个大方向，这样才能让人前进
技术部的工作，通常来源于其他部门的需求
这时候我们就需要这么一个任务池功能，来体现我们OKR的实现的进度，代表工具为 Worktile、JIRA
任务分类可以分为，如：
销售部： 员工_张三的任务池、员工_李四的任务池、老板的需求池
技术部：云天河的任务池、沐临风的任务池、APP需求池、APP需求已完成池、APP问题反馈池、APP问题已解决池、H5问题反馈池、H5需求池、H5需求已完成池、H5问题已解决池、后台功能需求池、后台需求已完成池、后台问题反馈池 、后台问题已解决池
每个池子里的内容可以移动到另外一个池子中去
比如，云天河从APP需求池中移动了一个任务到自己的任务池中，
完成后，将任务移动到，APP需求已完成池，
等待提出需求的人来确认已完成或者评论指出未完善的部分
评论列表点此评论