牛顿说：“程序猿的开发效率问题，只能自己想办法解决。”
啥？牛顿真的这样说过么？
也许没有吧，但我觉得如果牛顿身处现代的话，很大概率是会这样说的。
因为大佬们在解决问题的时候，从来都不会寄希望于别人来帮忙，
而是，干脆自己发明一个理论算了。
牛顿为了描述运动的 “瞬间变化”，创造了微分、偏微分，
为了解决天体运动中直角坐标不方便的问题，创造了曲线坐标。
所以，到了现代，为了解决开发效率问题，牛顿也一定会创造一套自己的办法。
然而，毕竟牛顿大佬只有一个，我们也都不是牛顿，
所以迄今为止，这套办法还没有人能总结出来，
但是，“靠自己解决问题” 的思路，倒是传承下来了，并不断的发扬光大。
自己的课题
除了程序猿自己之外，似乎其他所有人也都很关心 “程序猿” 的开发效率问题。
真是 “受宠若惊”、“有负众望”，“不经一番寒彻骨，哪得梅花扑鼻香。”
然而不幸的是，很多 “好心人” 过来帮忙，似乎都没有帮在点子上，
反而让程序猿们更忙了，也没有解决根本问题。
比如，作为一个 “非程序猿”，我不写代码的，
我认为你们肯定像我一样不爱写代码吧，那么如果能让你们少写代码，
是不是就提高开发效率了？请叫我雷锋。
又例如，我虽然不写代码，但我知道，程序猿写出 bug 是能够理解的，
因此我提议，对程序猿的 bug 率进行考核，
程序猿们以后再也不会马虎犯错了，我上学时老师就是这么管我的。
类似的例子不胜枚举，也许还会得罪不少 “出发点是为你好” 的人，
但我觉得有些 “系统” 或者 “办法”，还真没帮到点子上，
开发辅助系统，或者执行额外的流程，反而让程序猿们身心俱疲。
真正的困难自己才懂
程序猿是靠卖字求生的职业，写多少字就给多少钱，
当然某几天偷懒不写字，也能搞到钱，只要我们声称自己在解决问题就好了。
然而，除了程序猿之外，
似乎没有任何人关心，怎样才能让程序猿更好的把字写出来。
毕竟写不出来，加班就好了嘛，
再写不出来，那就努努力。
如果还写不出来，就是能力问题了。
我想，这样以非程序猿的角度，来考虑程序猿的工作困境，
应是所有 “好心帮倒忙” “驴子用鞭子抽都不喝水” 的根本原因吧。
那么程序猿们的工作困难到底在哪里呢？
这还得从程序猿所处的环境，这个角度来进行考虑才行。
上下游得自己管理
首先，程序猿们虽然是在卖字，但这些字是在解决 “工程上” 的问题。
所谓 “工程”，简言之就是好多人一起做的，并且还得考虑性价比的大项目。
毕竟钱都不是大风刮来的，能做快点是一点。
因此，没有谁会比程序猿们自己更关心 “成效” 了，
不幸的是，这种 “赶紧做完” 的心情，总会与 “设计师” 们的精益求精，
或者 “质量管理团队” “安全第一” 的指导原则相违背。
所以有时候，并不是不想做完，而是别人不让啊。
这也就从侧面说明了，工程其实是一个权衡的结果，没有标准答案。
如果有朋友想从 “工程” 角度入手，解决程序猿的开发效率问题，
那么我觉得，切入点应该放在如何让程序猿更快的写入 “限制条件” 之内的代码，
而不仅仅是如何让程序猿写的更多更快这一方面了。
要这么考虑的话，就得对码字工作的上下游进行管理，
如果考试过程中，“考题” 总是变更，那就没有交卷的时候，
另外，都开始考试了，再严格要求不答满分不让交卷，我觉得也不太可能。
信息要自己同步
很多人一起干活，有一个大家都遵循的套路，是会省很多事的，
也能节省不少的 “管理成本”。
如果让程序猿们都自己发挥，那么就会，人人都是架构师，人人都是产品经理，
这是在说，制定一个不太好的决策，也比每个人都按自己办法解决问题，会更好一些。
程序猿们在同一个仓库中写代码，就好比一起写一本小说，
没有一个总的指导原则，故事就能乱得飞起。
负责任的程序猿们，不得不去了解其他所有人是怎么想的，
不然怎么能保证放到一起不会出现错误呢？
有的团队会专门设立一些人去协调这些信息，也有的团队不会。
但说到底，如果想要在架构层面解决效率问题的话，
沟通、信息同步以及边界划分才是最重要的点。
至于用了什么架构模式，以及用什么语言对架构进行描述，倒是次要的了。
考虑怎么让程序猿快速找到自己的坑位，开心的写代码吧。
环境问题还得自己解决
程序猿所处的环境，应该有利于他们把字赶紧写出来。
如果总是在他们码字的时候，打断他们，
或者，如果总是让他们花时间排查莫名其妙的不稳定性问题。
那么码字的速度就没法快得起来。
办公软件一会通知你一下，一会通知你一下，你能好好码字吗？
办公室嘈杂的像个菜市场，这边有 “考生” 在 “考试” 呢，能不能安静会？
当然，对于注定优秀的程序猿来说，这都不算什么，
中华民族也不乏有很多不惧干扰，最后果成大器的神话。
但我觉得，如果当时不干扰他们的话，也许能更好一些。
这样考虑的话，我不赞同 “大通铺” 更 “便于沟通”，
这更像是 “创造了一个新问题”，也没有解决 “原来的问题”。
除此之外，开发环境的不稳定性，近年来也变得严峻起来了。
搞着搞着忽然就有什么东西挂了，
吓得程序猿们还以为是自己的问题，停下来看的时候非常耽误时间。
写代码的权利须自己争取
我想大部分程序猿，跟典型 “非程序猿” 对待代码的态度是不一样的，
—— 我们喜欢写代码，写代码使人愉快，这就是生活的意义。
因此，我想很多援助，应该力求让程序猿们如何更愉快的码字，
而不是力求，如何避免程序猿们写码。
不让程序猿们写代码，而是让他们跑到某个系统上 “点点点”，
是谁想到了这么麻烦的 “与机器沟通” 的方法。
所以解决程序猿开发效率问题，我认为应该把工作重心放在 “开发辅助” 上来，
而不是放在 “辅助系统” 的建设上来。
应该考虑如何让字码得更快更方便，“直抒胸臆” “一码平川”。
最好自动帮我写代码，因为有些编程语言实在是太麻烦。
注意，程序猿想要的 “自动写代码”，跟典型 “非程序猿” 认为的非常不同，
这也是最容易造成误解的问题之一。
“帮我写代码” 并非 “我不想用写码的方式实现功能”，
而是 “不想重复键入”，
“用写码实现功能” 是极好的，求求你，让我这样工作吧。
山路再险也得自己走
有些程序猿是会有洁癖的，同时我也觉得有洁癖，是一个程序猿成长道路上所必须的。
毕竟码农靠卖字为生，字写的好一点，也没有什么不对的。
不过，只靠自己一个人，是无法把所有代码都写干净的，
“世之奇伟、瑰怪，非常之观，常在于险远” 而不知道这烂代码到底是谁写的。
所以，自己那块代码写的再好，贴在一块怪石上面，也会显得不伦不类。
稍乏经验的程序猿总会忍不住把 “怪石” 干掉，从而 “愚公移山”。
而有经验的程序猿，就不敢这么做了。
于是，最终代码的表现形式，自然就是 “怪石嶙峋” 了。
在 “怪石嶙峋” 的山路上行走，风险是很高的，
“常在山上走，哪有不掉下去” 的道理。
这是目前软件行业的常态，并没有特别有效的解决办法。
把路都铺平，是能解决问题，但同时也得付出代价，
天上不会掉馅饼，没有不付出代价就会受益终身的最佳实践。
所以，要想提高程序猿的开发效率，怎么解决 “怪石”，是非常值得考虑的，
而且，别人不走山路的，走的慢是程序猿自己的问题。
不行就催促程序猿们走快点，反正自己又不在山上。
质量是自己设立的关卡
要想发布一款 “能用” 的软件，撇开功能不说，最起码它得是 “能跑起来” 的。
所以软件质量方面，有一个下限，不能太烂。
很多典型的 “非程序猿” 经常把软件质量低下，归咎于程序猿的马虎和偷懒，
这就好比很多老师，认为考生做错了都是因为 “不认真” 所致。
是人就总会犯错的，所以问题的症结应在于，如何减少犯错的可能。
比如，我们所开发的功能，应当是 “利于” 自测的才行，
否则程序猿自己都不知道做错了没有。
很多功能难以自测，是 bug 率居高不下的重要原因。
此外，在时间紧急的情况下，有时候就顾不了那么多了，
所以，与其下意识的避险，不如一开始就考虑 “在仅有的时间内达成怎样质量” 的问题。
最后，什么样的问题，会被称为一个缺陷，在定义上容易产生分歧，
最好能平心而论，尽早达成共识。
失败要自己承担
常言道，“内行看门道，外行看热闹”，这句话并不适合软件行业。
这是因为在软件行业中，“外行” 才是给程序猿饭吃的贵人。
除此之外，编程虽然已经发展一些年了，但仍然是一个年轻的行业，
不然像我们这样的 “三无”（没钱没经验没地位） 年轻人，怎么能挤得这个行业呢？
全靠老前辈们，让着我们，也靠这个行业太缺人，只能降低标准了。
这样来看的话，目前很多 “项目” 的设计初衷，会是出于某些 “诡异” 的理由。
比如，我想让 “万物皆可配”，你们原来不是写代码才能出功能么？
我现在只需配置一下就行了，我为你节省了多少时间？
又比如，为了避免你接口偷偷变了，我起一个服务 “监控” 你的接口，
如果变了就发邮件通知到我，我好改代码。
当然，会出现以上这些 “项目” 可能背景并不像我们想的那么简单，
但是总会给人一种莫名其妙的 “违和感”。
我才工作了这么几年，当然不敢妄称 “内行”，只是担心接不住误了人家的好事。
不过，这也从另一个角度说明了，目前程序猿自己的问题，还在期待着别人来解决。
其实对别人来说，他们也不是特别清楚的。
所以，“求人不如求己”，自己都解决不了，听别人的兴许只是看起来更忙一些罢了。
结语
本文本来想写一下，都 2020 年了我们应该向哪些方面要 “效能”，
由于软件开发是一项涉及面比较广的工作，所以一时不知道从哪里写起。
涉及工程、管理、流程、架构、需求、环境、开发、测试、历史包袱，等一系列问题。
就算是从业者本身，对各个环节的认识，也很难做到完全掌握。
单单每一个领域，都有很多事情值得去挖掘，去做。
为了提高工程师的开发效率，人们真是穷尽了所有能想到的各种各样的办法，
踩坑当然是不可避免的了，这并不能说当初提出解决方案的人是 “脑抽” 了。
文中有些案例，可能有不太恰当之处，如果误伤了，希望能饶恕我的狂妄。
所以，本文的侧重点在于，把解决开发效率的责任拉回到开发者自己肩膀上来，
只有我们自己才最熟悉自己的开发困境，
有些问题，如果我们自己不面对，那么就会由别人替我们面对，而结果未必会更好。
“学习是自己的事”，“研发效能也是程序猿自己的课题”。