这一周依旧是完成 API 服务。 = = 感觉过得好快，好像失忆了，做了什么都不太记得。 写一点还记得的东西。

从零开始写项目启示录 —— 我所犯的几个错误

现在在写的这个项目是从零开始的。boss 讲明白可以任我们发挥。采用什么框架，怎么设计都由我们来。

而实践过程也犯了不少错，在这里记录下来。

需求引发的案例

项目从上周三开始编写代码，其实那时候对需求还很模糊，当时想着跟我合作的同事对项目需求理解应该很清晰（因为他之前是负责 API 的）所以没继续询问 boss。 自己没对需求理解清楚就开始编码 这是我犯的最大的错。

之后发现我们两个对项目的理解都不算很清楚，走了不少弯路，也是其他错误的起点。

（具体情况在上一篇博文中已经有讲述，这里不赘述）

操之过急，效率的阻碍

开始编写代码的时候，没有做好代码设计，甚至连需要什么模块也是没有很明确的想过。开始编码有点急。分析原因，当时分配任务是周一，而到了周三都没有什么实际代码产出（心里发慌 - - ） 于是周三稍微明白之后就着急开始编码。项目需要有什么模块，数据表怎么设计，都没有设计就开始编码。

于是边写边想，然后又发现有一个细节没考虑到，之前写的部分返工修改。很明显的影响效率（掀桌！我的快男称号毁在这了TAT）

分工过粗，再次返工

除了急着写代码，我和另一个同事对项目也没做好足够的分工沟通，只是笼统地说，我负责这个，你负责那个。没有对两个人所负责的部分做功能分析，两个人虽实现不同的部分，但既然是同一个项目，必定会有一些通用的功能。最终结果就是，同样的功能有两个不同的版本。

一错再错

出现上面情况之后很容易想到将共同的部分抽离出来。

我们实现了两次分离。

我负责写后台管理部分，他实现转发服务器部分。 转发服务器只需要从数据库获取配置，根据配置做相应操作就可以。 而我实现一个管理数据的 UI 。两个确实可以分离。 因此做了第一次分离，开了一个仓库将 dashboard 分离出去。

之后发现上面我们提及的情况（两个人有重复功能的代码），于是同事提议再开一个库放 common 部分和配置部分。

当时我想当然地认为确实有道理。于是开了一个库。 这样一切都好似挺好的，也似乎确实应该这么做。

但，真的有必要开三个库么？有必要有必要有必要么？

这个项目其实复杂度并不大，整个代码量连 mooc 一半都没有，开三个库有必要吗？

好吧，每个仓库有不同作用也说得过去。

但我们来分析下三个库分别放什么。

  1. 转发服务器。就一个 handler 读配置，解析 url 转发。
  2. dashboard。后台，数据库操作，显示日志。
  3. common 库，几个函数，几个配置文件。

细想之后我觉得我们一个简单的项目开了三个库也算霸气了- - （真想摔桌子，

一切都源于对需求不理解（因为总觉得 “ummmm 会做到代码很多的情况”） 以及对系统没做设计（做了设计的话不会重复，更不需要开三个仓库增加维护成本）

（特别想吐槽最后开的仓库，common 实际上就几个函数几个函数啊！配置的部分，回到两个项目还是要读取载入到 app 里啊！

（其实一开始分离就是错误的抉择吧。好吧对不起黄老师和姚总，我想三个库还是会合并的对不起了。。TAT

磨合

最后是磨合。

如我在朋友圈里谈的，以前都是一个人 PR 一个人 Review 一个 Merge。

现在是跟别人合作，要接受不同的 Code Style。要争论哪种更好（而且只有两个人比较难决定，

（不过有点我实在无法接受，我可以吐槽吗- - 他还把我的 Code Style 改成他习惯的那种。。 （不过其他方面我同事还是很好的，特别技术是真心不错，人家才大一= = 感觉过一阵子会写一篇关于他的 blog 哈哈，题目就叫 来自二次元世界的大神

一个微不足道但困惑我很久的坑

这个项目转发部分是同事写的，但是我写测试的时候发现，如果转发的 URL 是非本地的话就会出错。

转发部分，同事使用了 tornado 实现的 http client。因为之前折腾过一下下，所以那时候感觉是 tornado http client 的问题。改用 requests 来转发请求（但没带 header），发现问题解决了。然后就 tornado http client 部分替换成 requests。

但完成这部分之后，发现问题依旧。

翻遍很多资料，最后抓包才发现，原来同事将 host 设置请求者的 IP。部分网站会验证 host 是否有效（比如百度）于是就返回 5xx 错误。

修复。

（PS：之前同事说带 header 之后就不行= = 自己给自己挖坑

关于 工程思维

从很久之前就被 tonyseek 教导设计好代码，写文档，写测试之类。flask-rbac 也试着编写好文档，写好测试。之后很多项目也努力写好文档跟测试。

一直很注重“工程”，也花了很多时间在这上面。大三看到很多大神都做出了很厉害的应用，但是就觉得是不是花太多时间在这上面，本末倒置了。

而近日发现，花时间是值得的。

先安慰下自己，代码风格，来创宇最开始的那个小模块被公司卓神夸写的好看，但是心里还是乐呵呵的。

其实我想强调的是写测试的重要性。

跟我合作的同事（怎么感觉老是在黑他，我再次强调，他本身真的是个大神，就是工程方面可能没有人指导）已经出现过不下 n 次低级错误 commit 到版本库里了。低级错误包括，逗号写成点好、变量名写错、导入包不存在等等。这些问题，就算没写测试，自己手动跑一边也能抛异常，可是他木有测试就 commit 了。每次被我找出来之后很羞愧地修改。

另外这周也花了很多时间写测试用例，虽然还没有因为重构发生测试不通过的情况，但至少让心里安心点，重构之后没出错，也算小有成就。最大感触就是测试用例不容易写，有的函数甚至不知道怎么做测试。（开始佩服真正的测试工程师。

KnownSec @ Github

忘记具体是哪天，姚总把 workin（一个 tornado 基础的框架网站）开源到 github 上。之后我就很激动啊，因为我很喜欢提 issue 提 PR 啊。马上补了一个 bug 加了一个 test 进去。成就感慢慢，也是那天，像是找回了写代码的感觉。

姚总还把我们几个加到 knownsec org 里。TAT 终于找到组织的感觉。

其他几个同事还有一些有趣的项目，到时候 fork 来 PR。。hiahiahia。

分享会

周四，我们 team 举行了一次分享会。

具体内容就不贴了，列举一些提纲：

分享#1

  1. 视频：幸福公开课
  2. 博客：Teahour & Tinyfool
  3. 书：幸福的方法、态度改变与社会影响、拆掉思维里的墙
  4. 应用：haroopad、Reeder、ohmystar、kindle

分享#2

SaltStack 自动化部署环境的工具柜

分享#3

  1. PyCharm
  2. 书：编码、暗时间、哥德尔埃舍尔巴赫、自私的基因、魔鬼出没的世界。