参与创业公司两年多了, 在寻仟绝对是各种白手起家, 自食其力, 啥都得干的典范. 问题自然是多多, 有不少不规范的情况, 所以写点小总结平常多提醒提醒自己.

团队开发是个不容易处理的情况, 做老板的自然以为人越多, 效率应该越高(那是韩信), 当然做软件开发的都知道这不现实, 参考人月神话:

向进度落后的项目追加人力，只会使进度更加落后。

自己写代码再飘逸也都能hold住修改的需求, 但若是他人写的就很麻烦, 一来不清楚需求全貌, 二来代码还得重读理解. 因此好的个人代码是团队合作的基础, 可以减少问题从底层出现的概率.

个人代码的质量要由规范的流程来保证, 不能让随意写的代码签入代码库.

流程规范约束了产出的程序必须要有必要的注释和必要的单测, 这样在代码更改的时候就降低了疼痛感.

不过仅仅优化个人代码产出是不够的, 从分工的角度来说, 每个人只要做好自己的部分, 这样效率就是最高的, 然后任务的拆分由代码项目的管理者来负责, 保证整体效率最优. 但这事摆在制造行业上容易, 流水线上一道道工序就好了. 搁在软件项目里面就是另一回事情了, 工期紧, 需求不稳定, 老模块耦合度高, 这些都是很考验人的活, 所以对小公司来说有个靠谱,厉害的架构师是一件幸福的事情, 可遇而不可求~

罗里吧嗦了一通, 下面些小心得.

流程

• 尽早参与到产品的设计阶段, 一是避免出现太开脑洞的需求, 二是了解真正的原始需求.
• 对于想要做大还没做大的公司, 产品最核心的资产并不是代码, 而是详细的业务流程, 有了详细的流程描述, 代码的局部调整就算是彻底重写也不会太疼. 当然如果老版本的代码中有很多可以复用的方法和组件, 那就更好了.
• 容易评估的是结果, 不易评估的是过程
• UML 可以减少沟通成本, 不是做大了才需要, 凡是频繁迭代修改的项目都很需要.
• 磨刀不误砍柴工， 开发先画流程图(UML 更好)
• 注释中留下开发者的名字 :)
• 说明性的东西, 需要能就近找到 (比如注释中记录相关流程的跳转链接)
• 一个上了规模的项目需要有个配套的简化版 playground (或者说demo) 项目, 辅助尝试各种解决方案
• 修业务 bug 最大的成本来自于重新理解逻辑的成本. 有两个选择: 一开始考虑周到, 仔细编码(减少出 bug 的概率, 单测覆盖), 或者留下详细注释(节省重读的开销). 遇到写业务代码很随性的人, 友谊的小船说翻就翻.
• 产品设计和开发的时候, 核心流程, 即主业务, 核心功能是必须设计成容易测试和容易做线上调试的.

心态

• 承受太多细节实现压力的时候, 是不容易有什么好心情来天马行空的.
• 学习一个新技术的时候, 要带着’这个东西能解决现在哪些问题’ 的角度来思考.
• 学习编程的最初目的, 是为了让生活变得更高效.
• 如果生活没有变的高效, 那就要反思了.
• 改自己的代码比改别人的代码要容易很多, 心情也会好很多.

提升

• 编程经验最好的体现是模块的积累 ★
• 好的代码风格是延年益寿的! 好的代码组件是能长久复用的!
• 简单的规则, 加上整齐的结构, 那么代码的味道就不会太差
• 如何以最低的成本实现需要的功能, 这个是经验的体现
• 修改代码的成本和风险数倍于新功能开发, 倍数视老代码质量和单测覆盖程度而定.
• 那些有重复的, 平铺的代码容易优化. 反而是过早抽象, 优化了的代码不太好阅读和优化.
• 上班时候的学习应该挑一些简短精炼的内容, 比如一个命令的参数怎么用啦, 学一点新的 linux 命令啦, 注意, 做好笔记. 这里的学习是指开发过程中需要用到的东西的整理.
• 不要让自己的代码(片段)随风飘走, 放在一起统一管理
• 别太相信自己的记性, 找个工具帮助自己梳理清各个环节
• 遇到知识范围外的 bug 的时候, 尝试在相似的环境中复现它是最好的 debug 方法(排除法)
• 大于两层嵌套的 if else 考虑抽出一个函数, 提供语义上的支持

内容不定期更新.