悠然乱弹：软件开发杂谈

2019独角兽企业重金招聘Python工程师标准>>>

杂谈之一：技术只是成功的一点点基础条件，真正还是得靠做人

话说，有位lianzi同学，水平不错，思想超前，签约阿里现在在百度实习，以前因为喷我的贴又没有啥理由，因此告诉他离我远一点，但是最近他又回到我群里了，一直伸个大拇指，我说啥他都是大拇指，觉得怪怪的，总不是那么个感觉，终于憋了一段时间，又恢复了正常的沟通方式，聊天实录：

【传说】杭州-悠然 18:31:13 
lianzi本色终于出来了。
【传说】杭州-悠然 18:31:30 
我学得这样才是你自己，你天天伸个大拇指，我都觉得不像你了。
【活跃】lianzi(756215798) 18:32:17 
哈哈哈，还好，还好
【传说】杭州-悠然 18:32:52 
活个本性挺好的，有时碰一下大家也理解的。
碰完了继续哥儿俩好不就可以了。
【活跃】lianzi(756215798) 18:37:22 
是的

杂谈之二：让谁“爽”的问题

看产品经理的ppt，里面有下面的一段话：

做“产品”，不外乎“要想自己爽，先让别人爽”。 
永远站在用户的角度考虑问题。 细节、细节、还是细节。 根据实际情况排定优先级比确定功能更重要。

聊天实录：

【活跃】长沙-Sept() 19:22:56 
做产品 必须站在重度用户的角度考虑
只有自己亲自去使用体会才找到 每个功能该具体怎么做 该怎么做
【传说】杭州-悠然 19:29:57 
呵呵，说白了就是如何让客户“爽”了
【吐槽】杭州-江南无名 19:43:05 
怎么样才算爽呢？
【活跃】长沙-Sept() 19:43:32 
就是所谓的 好用
【传说】杭州-悠然 19:43:36 
呵呵，如果用户用了要骂人的，说明就不爽了。
比如：一个很少用的功能，麻烦多点，他也不会叫。
一个经常用的功能要，哪怕麻烦一点儿，他都骂娘
【吐槽】杭州-江南无名 19:44:21 
爽是个主观感受
过个三五年之后，现在用的爽的产品，一样挨骂
【传说】杭州-悠然 19:44:43 
第一次做得不爽就不爽了，第二次不爽的时候就会说，这个程序员太差了，每次干这事儿都不爽。
第三次之后...第N次之后，他已经不爽之极了。
【吐槽】杭州-江南无名 19:45:28 
然后他就从了。
【传说】杭州-悠然 19:45:39 
如果不爽且没有替换的时候，他会骂你且用你。
如果不爽且有了替代的时候，马上换你，并继续骂你，而且会在别人前面传播着骂你。
【吐槽】杭州-江南无名 19:46:22
在骂声中发展，并升华
这是互联网产品这些年走过的路
【传说】杭州-悠然 19:46:47
那你要改得快呀。
人家骂你一次的时候，第二天一天骂点没了，他还是比较爽的。
再找个骂点，你又马上改了，他又爽了。
这个时候他就骂并快乐着，而且不会换你，而且还会在别人前面赞美你。
【吐槽】杭州-江南无名 19:47:29
 说得是这个理
用户扮演需求的直接提供者
同时由是不专业的产品设计者
so,可以得个片段结论了。
好坏是个相对词，它是主观感受。时代的不同，环境的不同，产品的好坏也随着变化打上对应的标签。
【传说】杭州-悠然 19:51:38 
这种东西没有好坏的。
只有爽不爽的问题。
而且这个爽不爽要从所有参与者之间进行考虑。
从框架开发者来说：架构设计->组件扩展->业务开发
有可能这个角色爽了，那个角色不爽了，
这个时候，越在末端，这个不爽权重越大。
也就是要照顾最接近末端角色的情绪。
只有在末端角色的情绪得到满足的前提下，才考虑自己的情绪。
【吐槽】杭州-江南无名 19:57:29
说的太好了

深以为然，在做Tiny框架中，框架组做Eclipse插件的同学其中做一个功能是执行器，他的方案是：开个首选项，然后由开发人员在里面配置啥种类型的文件由哪个类去执行。于是我问，如果有好多个执行器，开发人员不就配死了？于是他做了个功能扩展，增加一个批量导入功能，可以批量导致了。于是我问如果有100个项目，100个开发人员，有100种 执行器，不同的项目需要的执行器又不一样，是不是就得配100次配置文件，然后花大量的成本去分发这个配置文件，还得让程序员花大量的时间去导入这个配置文件？？关键是随着项目的不断变化，用的执行器是可变的，那么上面的这个过程就得不断进行，还涉及到一个版本维护的问题，比如有的人导入了新的，而有的人还是旧的。这样综合起来得投多少人力物力和管理成本？

我给的方案是：在开发执行器时配置一个执行器xml定义文件，然后工程去扫描当前项目中的执行器xml定义文件，于是工具开发人员只开发一次，每个执行器开发人员只配置一次，真正的使用者，啥也不用管，随时都是最新可用，0工作量。

两个方案对比，工具开发者工作量小了，执行器开者工作量大了可以忽略的一点点，最终使用者，节省了大量的工作量，关键是不会让他们觉得使用麻烦，且不会出错。

杂谈之三：让程序抛错还是让程序“正确”执行？

龙振东同学，一直在使用TinyDbRouter，也发现了里面的一些BUG，也提了许多的改进建议。由于他是把代码拉到本地在本地改的，我建议他直接fork我们的代码，并在修改之后pull request给我们，这样，对两方都有好处。

其中涉及到一个问题，他在QQ上问我如何处置：有些非标准SQL，SQL解析器不支持，他建议（实际上他前期就是这么做的）在出现不支持的SQL异常的时候，改由读写分离方式去执行。

由于当时在开车，是在电话里和他沟通的，因此就没有聊天实录了，我直接敲字敲上来吧。

悠然：由于出现了SQL解析异常，说明这个时候SQL是不标准的，有可能是适用于读写分离，有可能适用于分库分表，你不管采用哪一种方式进行处理，总有一种情况是用“错误”的方式去执行的，这样就会导致出现非用户期望的结果--而且这个时候，用户得到了看起来正常的结果--因为没有异常和错误发生，但是实际上结果是不正确的。这种处理结果比抛异常直接告诉他不支持这个功能严重得多得多，会直接害死你、害死你的老板、害死你的客户。
所以，请直接抛异常，而不是改成前面的处置方式。如果这个SQL对你非常重要，那唯一正确的办法是扩展SQL解析器，使之支持。你觉得怎么样？
龙振东：然。

他很快就完成并提交给我，下面是沟通实录：

【传说】杭州-悠然 20:08:47 
非常感谢@龙振东 
【话唠】龙振东(593038106) 20:09:41 
:)
【传说】杭州-悠然 20:10:03 
以后就直接在我们工程上改吧。
这样就可以一起共享了。
今天我给你电话里讲的原则，在工作中一定注意了。
否则你给捅大搂子的要:)
【话唠】龙振东(593038106) 20:11:37 
一些有争议的地方我都会先提出来讨论
【传说】杭州-悠然 20:11:54 
嗯嗯，我给你讲个故事吧。
我们这边有个非常牛X的人。
看到另外一个人写的程序有个问题：就直接反编译然后改了就弄上去了，结果问题确实没有了。
他也不和别人说这个事儿，结果后来升级的时候一搞，这个修改丢失了。
结果出了非常大的乱子。
又有一次，他又和另外一个程序做对接，结果他想获得人家内部的数据。
【冒泡】杭州-cwl(150326161) 20:14:07 
我感觉说的是我。。。
【传说】杭州-悠然 20:14:16 
人家里面的数据是private的，他改改访问控制，然后就访问到了人家的private数据。
然后他得意的爽得不行。
【话唠】龙振东(593038106) 20:14:51 
后来呢
【传说】杭州-悠然 20:14:55 
结果过了一段时间，又他妈的出大问题了，原来人家把private的对象改名了。
还有一次，他又是修改访问设置，访问了人家的私有方法，这次啥也没改，结果又他妈的不行了。
死活无法跑，结果这牛叉人物到现场，跑北京搞了好几天，终于查清了，原来是在Oracle JDK可以突破安全访问私有方法，但是在AIX下的IBM JDK突破不了了。
所以：千万不要耍小聪明，会吃大亏的。
在计算机领域一定要严谨，要按常规的正常途径来解决问题。

杂谈之四：再论缓冲相关代码的演变

本人写过一篇关于缓冲方面的文章，可以通过点击上面的链接去查阅。有许多人回复，有些人觉得不错，有的人觉得不好，各说各有理。

其实计算机领域当中，解决一个问题，可以有N种方案，有时他们的差别非常小，这个时候就需要仔细斟酌了。

这不，周末大家又问了：

【活跃】lianzi(756215798) 10:03:18 
早，现在不知道看什么技术文章啦，昨晚睡觉前看了篇悠然和hasor的博客
就是那篇缓存重构调优的
逻辑是很清楚的，至于最优解，鬼知道
【传说】杭州-悠然 10:05:45 
下面不是被喷了么:)
【活跃】lianzi(756215798) 10:07:19 
好吧，那最后的优化方案是什么呢？实际效果如何呢？
【传说】杭州-悠然 10:07:40 
实际，我们用得感觉还不错。
maven插件？
【传说】杭州-悠然 10:07:58 
关键是避免程序员参与缓冲方面的事情。
由于通过Maven插件动态嵌入代码，因此性能方面也非常有保障。
【活跃】lianzi(756215798) 10:08:52 
这个说法，我觉得，要看场景
如果小弟不怎么给力是好事，但是程序员在调试代码的时候怎么办？至少内置个http server 有个缓存的dashboard
你觉得呢？
【传说】杭州-悠然 10:09:46 
其实你可以理解成一种AOP处理。
程序调试代码，就是全部从真实数据库取数据呀。
又没有任何影响，用Maven命令处理过，只是通过缓冲加速了而已。
【活跃】lianzi(756215798) 10:10:57 
我的意思是这样子的，缓存应不应该对程序员透明
【传说】杭州-悠然 10:11:28 
我们的选择是透明。
【活跃】lianzi(756215798) 10:11:39 
认同
【传说】杭州-悠然 10:11:48 
文章中说了诸多好处，尤其是一种缓冲方案换成另外一种缓冲方案的时候。
关键是避免程序员参与缓冲方面的事情。
【活跃】lianzi(756215798) 10:12:02 
是，逻辑清晰
【传说】杭州-悠然 10:12:07 
选择透明的方式，只要架构师或高程完成就好了，原有代码不用做修改。
【活跃】lianzi(756215798) 10:12:19 
我们老大也经常骂我，说要把故事讲完整
【传说】杭州-悠然 10:12:25 
上次我们从MC->Redis，那代码改得，都吐血了。
【活跃】lianzi(756215798) 10:12:53 
没做抽象层？
【传说】杭州-悠然 10:13:01 
如果再从Redis->另外的方案，不是又要吐血了？
【潜水】上海-云卷江南(25269626) 10:13:08 
改个实现类不就行了
【传说】杭州-悠然 10:13:31 
如果你做了抽象层，使用的就一定是KV的。
如果要深层次使用，就麻烦了，有的支持有的不支持。
但是技术肯定是双刃剑，有好处也有坏处。
【活跃】lianzi(756215798) 10:14:53 
这个我理解
【传说】杭州-悠然 10:15:06 
如何发挥好处，避免坏处了。
即使是搞了抽象层，我在文中也写了，到处是处理缓冲逻辑的代码，也是不好的。
【潜水】上海-云卷江南(25269626) 10:15:43 
简单用
【传说】杭州-悠然 10:15:53 
所以，比较好的办法就是采用面向切面的方式进行处理。
【活跃】lianzi(756215798) 10:17:25 
这个我认可，一开始设计的就有问题

这里，又是我经常说的一个话，好软件是“品”出来的，当一个问题有N种解决方案的时候，就要把各种方案仔细品味。

杂谈之五：新人心态的问题

【活跃】lianzi(756215798) 10:20:14 
每每看到oscer说刚毕业的学生会什么的时候，我都在思考，应该多向前辈学习，但心里总有点不爽
哈哈，也许是初生牛犊不怕虎吧
【传说】杭州-悠然 10:23:25 
不知我的故事，有没有给你讲过。
我刚毕业的时候，第一个网名起的是叫高手来着。
【活跃】lianzi(756215798) 10:23:48 
没呢，然后呢
【传说】杭州-悠然 10:24:03 
当时心态估计和你差不多，总觉得你毕业多几年有个啥用，我照样比你强。
后来过了一段时间，默默改成：学习中的高手
又过了一段时间，默默改成：学习中的低手
到现在，哥已经不敢说哪一块是NB的了，觉得啥也了解不够深入。
【潜水】上海-云卷江南(25269626) 10:25:15 
我也毕业不久
【活跃】lianzi(756215798) 10:25:23 
悠然，我觉得我还算虚心好学
【传说】杭州-悠然 10:25:43 
嗯嗯，不错的苗子。
【潜水】上海-云卷江南(25269626) 10:25:44 
事实就是很多人经验根本和能力没什么正相关
【传说】杭州-悠然 10:26:18 
你要知道，在战场中打得猛的，打得准的，都已经死掉了。
【潜水】上海-云卷江南(25269626) 10:26:34 
越来越谦虚是因为自己无知，而不是队友强大
【传说】杭州-悠然 10:26:57 
偶尔有几个活下来的，那就英雄了。
活下来的，都已经不再标榜自己打得准，躲得好，只是说：运气好一点而已。
所以，年轻人么，适当藏一下锋芒是有益于发展的。
【活跃】lianzi(756215798) 10:28:48 
悠然说的很对啊
【传说】杭州-悠然 10:29:23 
你看看所有获奖感言当中，没有哪一个说：因为我ＮＢ所以，我才...
而感谢这个，感谢那个，感谢边边角角的人物。
【活跃】lianzi(756215798) 10:29:39 
浸染了奋斗的泪泉，腮边了牺牲的血雨
【传说】杭州-悠然 10:30:04 
一个用来展示自己的感恩之心，二来是因为这些人的成功不一定主要是边边角角人的功劳。
但是如果让他们不爽了，他们一个小小的“失误”就可以废了你的大好前程。
你再NB，做的东西，也不可能一点瑕疵也没有。
【潜水】上海-云卷江南(25269626) 10:31:18 
 好高深的样子
【传说】杭州-悠然 10:31:19 
当你有一点瑕疵，就会被人攻击致死。
【活跃】lianzi(756215798) 10:31:22 
山水有相逢，悠然的却是管理者的心态，悠然悠然啊
【传说】杭州-悠然 10:31:32 
我再给你讲一个例子。
有一个以前阿里的架构师，水平，那是一个高。
用他的话来说：除了看我感觉顺眼点，其他没有一个他会看在眼里的。
【活跃】lianzi(756215798) 10:32:55 
很高的评价，这个人有问题，我觉得
【传说】杭州-悠然 10:33:06 
但是因为锋芒太盛，被剥得人无一个，枪无一条，完了还让人家说他水平太差。
所以，别标榜自己水平多好，能力多强，扎扎实实做事，老老实实做人才是正点。

杂谈之六：工作年限与水平的关系

【活跃】lianzi(756215798) 10:37:47 
这个我觉得和经验关系更大 【吐槽】上海 浩子(120195645) 10:38:49 
什么事情，都应该与实际进行权衡
【传说】杭州-悠然 10:39:02 
所以比较拽的架构师，可以把工作并行起来。
就是说大家各做做的，到时可以组到一起来，又不费什么工作量。
【活跃】lianzi(756215798) 10:39:29 
为什么呢？因为踩过的坑比较多是吧双击查看原图
【传说】杭州-悠然 10:39:36 
当然，这个层次就有点高了。
【活跃】lianzi(756215798) 10:43:05 
这个我认，现在还是学习阶段，多踩坑吧
【传说】杭州-悠然 10:43:49 
当然，这里的经验，不等同于工作年限。
但是同样努力用心的两个人，工作三年和工作一年，差别还是非常大的。
【活跃】长沙-Sept() 10:45:13 
体系是自底向上构建出来是 最终的表现 始终受到基础影响
基础构造决定啦 最终的极限与瓶颈
【活跃】lianzi(756215798) 10:46:12 
恩恩，说得好
【传说】杭州-悠然 10:46:16 
所以，我有个说法，就是工作3，5年说做一个多么先进的框架还是为时尚早的，当然试验性的没有问题。
【活跃】长沙-Sept() 10:46:22 
@lianzi 基础构造的限制 可以说已经决定 结果最高极限 了
【传说】杭州-悠然 10:47:11 
因为，你局部的实践能力和技术的应用能力应该是有的，但是整体宏观视野肯定是有不足的。
这个你去看人家的框架，也只是看得外部，内在的一些因果关系，根本不清楚的，有一定理解也是不完备的。
用Sept的话来说，你的起点决定了你的终点。
你期望说后面再去补充，这个成本是非常高的。
就好象你想盖个大楼，前面没太想好，就直接上手盖，期望中间进行不断修正就可以盖出大楼来。
但是到最后的时候，发现根本没有办法进行调整好让它转向正确的方向。

转载于:https://my.oschina.net/tinyframework/blog/342538