猫妖的软件工程乱谈（I）

答应大家写的乱谈，显然还没写到啥干货，大家凑合着看吧。本来是想写摄影或者Ukulele的。...



（图文均为大猫原创，转载注明出处。）

我原本以为，每一个工程师都会善于在反思和分析中进步，直到面试了一位我们对其所报期望颇高的求职者。我才意识到，也许，工程心的缺乏，并不是时间和工作经验可以弥补的。——（觉得用引用会增加故事带入感的）大猫

工程心

没有枝干的花与叶拼凑出的繁华，只是枯萎的起点。

软件工程也有自己的枝干，回首学习的道路，似乎从第一堂编程课开始，就跳过了工程的本质。

模糊的记忆里，栀子花大约已开败时，一个个闷热湿腻的上午，或者下午，一个个音容笑貌早已不复被记起的老师，对着一个个满眼疑惑与渴望的学生，讲述着冯·诺依曼，讲述着原码反码补码，讲述着位运算、寄存器，讲述着基础数据类型，讲述着指针，指向指针的指针，指向指向指针的指针的指针，老师哈哈笑，学生哈哈笑，下课……老师默默念，学生呼呼睡，下课……老师对着在台下自习的寥寥数人默默念，其他学生在寝室呼呼睡，下课……

在禁止新生携带电脑的学校，编程成了一门尴尬的理论课程。人生能有几多愁，恰似一群太监上青楼。在大部分人尚未有能力去思考，编程学懂后是满腹经纶的学究，还是一身技法的劳奴时，面向对象语言来了，网络原理来了，数据库设计来了，嵌入式来了……军备竞赛一样，自己脑内的武器库不断扩建，旧的枪炮甚至还未擦亮，就已被尘封。

终于“软件工程”这门实战心法课来了，这门蕴含了从远古时期的流氓斗殴一直到现代化大规模协同作战的课程，成功利用石器时代传承下来的，一个标记着“瀑布模型”的马桶开关，将大部分老油条哗哗冲进了香甜的梦里。

等工作后，已身在工程中时，铺天盖地的规范、文档、流程，让本就满负荷运转的人形代码仿写器们疲惫不堪。无法理解工程精髓的前辈遵从着先贤、大神留下的教条，管教出更加奴化的年轻人。

以至于如今，当年小伙伴们把酒言欢时，基本调子就是“大神牛人多传奇，规章流程坏心情，项目管理宫心计，脱码混入上层去，设计模式好玄妙，敏捷开发有怪招，产品经理土鳖多，甲方有钱闷声烧，技术高贵算个屁，市场营销有钱捞。……”越发浮躁，越发偏离。

对于溺亡的恐惧与惋惜，并不足以将溺水归罪于大海太深。

如果时间回到那一个个闷热湿腻的上午，或者下午，我希望我能叩开那一个个的心门，在一颗颗还没装进太多杂物的心里，埋下一颗种子，一颗工程心的种子。它并不是什么神奇的东西，只是一个简单的问题，一个需要反复被自己无数次问自己的简单问题——“目的，是什么？”。可不是么，工程学就是为了寻求问题的解决而存在的，连问问题的能力都没了，学一堆傻把式，不过是高级奴隶。

目的不一定多复杂，可以慢慢积累：

“我想先让两个整数加起来！”

“哦，这该死的编译器怎么装在电脑上呢？”

……

“我想实时知道最火的微博消息”

……

知道目的，才会去思考怎么办，才会去寻求解决途径，理论、方法、经验都在这样的探索中堆积；而毫无目的的，匆匆陷入复杂技法和繁冗教条，是人生最大的投资失败，的开始。

工程心的种子，是工程师的原点。

请认真对待，这个种子上，发出的每一个枝，让它们不断成长，在追寻目的的路上，那些长出的绿叶、花朵、果实、分支、伤疤，都是真实的生命力，不再随风飘零。

最关键的是，自己的这棵树上，也许装不下太多东西，但每一样都那么的平淡从容，不夸张掩饰，不为拿出去作为谈资——没有奇谭怪论的方法，也没有那么多荒诞的教条。

各种具体技术里，工程心的存在会让学习变得有趣，知识变得生动，然而无法逐一演示，因为其实我也不懂很多技术，所以就扯点无论什么技术都绕不开的话题，工程学——一门可以承载所有技术的主干。

路人和非机动车驾驶员也应和机动车驾驶员一样学习道法，并自觉严格遵守道法，这样交通才会有序。否则整个街道就会充斥着呆头鹅而混乱不堪，就像如今中国的大多数街道一样，低效低能。软件工程也是如此，如果以工作只负责其中一个环节为理由，放弃理解工程和工程管理，整个工程就会混乱不堪。

软件工程管理的核心，就是分析各种“因果”与付出相应“代价”

几乎能想到的所有的工程里的乱象，都是源自于两种天真的想法——无视“因果”，不肯付出“代价”。

以上一通大道理，想必已经让能睡着都关闭本文了（我的沉睡魔咒等级应该比我那些老师低很多吧），接下来清清静静的与有耐心的读者（以及我自己）分享一些更为散乱无序的想法。

先聊聊工程时间管理吧

关于上班打卡和弹性工作制的争论，几乎不绝于耳。

虽然我是彻底的主张无工作时限，想什么时候工作就什么时候工作，但绝对要做到最好——这也许会导致更多的时间或隐形的时间付出。

但从工程的角度上说，没有什么制度是完美的，制度就是一种方法，关键要看目的是什么。

对于软件工程项目，不能以准时下班为前提，就别要求员工准时上班。对于需要和外部协同时间的岗位，按照需求制定打卡时间。减少同步的事件，尤其是会议。

如果想要员工有足够的创造力，就不建议喊鼓励加班的口号，奴役中不会有创造力，只会有变本加厉的扭曲的争权逐利，务实专研变得轻贱，务虚偷懒都去追求。

对于有创造力会自我驱动的员工，应该提倡加班工作罚款，如果提前赶出了结点，自由安排。学习也好，玩耍也好，放空也好，鼓励但不强求把多余的时间投入技术储备中——长远来开，自由灵动的工程师不会生锈。

花钱雇的一堆需要让人不停紧发条的冰冷机器，还再额外付出更多的成本去保证他们动起来。远不如聚集一堆值得信赖有血有肉的战友来得有成就感和节约——至少节约办公工位。

当然，从软件工程，技术研发这块儿来说，时间管理最头疼的还不是人员到岗时间管理，是项目本身进度管理——这其实是更加接近工程本质的东西。

听过无数同学诉苦，一到deadline管理人员就发狂了一样，一边拿鞭子抽打苦力，一边分锅让人去背。早干嘛去了呢？

项目管理时间控制最重要的两个因素，第一是足够充分的预见到耗时项，第二是及时准确的发现风险并制定变化。项目越大，团队越大，软件规模越大，牵涉人员越多，风险越难在早期预估。

实话实说，能准确控制的进度，都是用谎言和水分组成的。

我所听闻过的，无论大小公司，在项目初期定时间时，就忘记了把各种行政化干预、流程审批、新员工培训等等计入项目需要的时间。然后在最后警报响了“代码混淆还要半天！”“打印还需要花一天！”“甲方代表生病了！”“研发小哥车祸住院了！”……

而更火上焦油的是在项目进度中，一遇到什么问题就忙着分锅追责，导致各岗位的工作都瞒报，各种风险根本无法及时反馈。

让大家敢说真实情况，不停的狼来了拉假警报就好了么——是的，想要“进度准确把控动态预估”的“果”，过量及时的信息是必要的“因”。

但是，这里就有“但是”来了，这样“额外”的管理工作，是要付出“代价”的，如果没有合理的人力、时间、配套跟上，这样一个群体技能是放不出来的。

所以，项目进度乱了点，不要大惊小怪借题发挥，管理没投入，就想出效果哪有这么便宜的事？要真有，估计技术人员全解散了，浇点水，项目也会自己从计算机里长出来吧？再最后，项目组干脆都别成立了，自己幻想一切都会有条不紊顺利完成的好了。

对于硬要守的时间线，就算守下了，也必然需要付出额外的代价，是工程师的健康，是产品的质量，还是团队的和谐。一将功成万骨枯，太多的牺牲不提，只提最后时间线保住了，不过是表面的胜利，实际的败局。最后便又回到了工程心的话题，问一下，时间管理，真的是目的么？谈到最后，也便又回到了以经济建设为中心是否能成为个人的价值观，这个话题就无需多想了——勿忘初心，如果有那种东西的话，做自己就好，也没有啥优劣可言。只是记住，做工程，最好和做人的想法接近的人一起，才有机会成为事业。

都聊到人生了，也是时候打住这乱谈的节奏了。

下回预告，如果有下回的话，就聊聊

项目研发流程——那些繁文缛节的研发规范八股文究竟想说个啥道理？新技术研发里，设计和实现的永恒的鸡蛋矛盾。

    关注 猫妖的闲聊时间