悠然乱弹:软件开发杂谈

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

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

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

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

看产品经理的ppt,里面有下面的一段话:

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

聊天实录:

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

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

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

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

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

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

这不,周末大家又问了:

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

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

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

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

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

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

悠然乱弹:软件开发杂谈的相关文章

OSChina 周一乱弹 —— 软件开发的生命周期

Hello,周一,你来啦,听说你是 2014 年最后一个周一了,有什么感言吗? 小小编盼了好久,终于盼到了周一,我们正式搬家到南山区啦- @hosser:等了好久纵欲等到今天,盼了好久纵欲盼到周六... 在 2014 年里,你做了什么大事? @WuWarren : 昨天做了一件大事,把一新的大奔给撞了.今天正在定损.我表示我现在很低调.那么问题来了,程序员几年才能开上大奔? 说起钱的事情,程序猿的工资跨度非常大,那么 2014 你收获了几碗云吞? @永和 : 这就10块钱,你得写多少行代码才能换

软件开发杂谈之从需求到上线---valen

背景 IT已经成为当代企业必不可少的竞争手段,从无到有到标配,可以说以后不懂IT的就是文盲这句一点也不过,而软件开发是个复杂工程,零零碎碎各种理论工具和技巧,一言难尽. 本文意在言简意赅,简述软件开发流程当中重要的环节,以此思路作为明灯,以更好地思考和完成工作. 开始 IT业务系统的开发(APP.网站,大中小型业务系统等等)生命周期大致可用一张图简单概括下: 无论那个环节都互相影响,产品和开发相对更紧密一些,运营相对独立,不断迭代产品直到产品周期终结 需求 产品是来解决问题的,所以做产品之前要做

《开源框架那点事儿11》:软件开发杂谈

杂谈之中的一个:技术仅仅是成功的一点点基础条件.真正还是得靠做人 话说,有位lianzi同学.水平不错.思想超前,签约阿里如今在百度实习,曾经由于喷我的贴又没有啥理由,因此告诉他离我远一点.可是近期他又回到我群里了.一直伸个大拇指,我说啥他都是大拇指,认为怪怪的.总不是那么个感觉,最终憋了一段时间,又恢复了正常的沟通方式,聊天实录: [传说]杭州-悠然 18:31:13 lianzi本色最终出来了. [传说]杭州-悠然 18:31:30 我学得这样才是你自己.你天天伸个大拇指.我都认为不像你了.

KVM&amp;amp;Libvirt基本概念及开发杂谈

导读 大家好,本次肖力分享的主题是KVM&Libvirt基本概念及开发杂谈,内容有些凌乱松散,主要基于自己早期整理的笔记内容和实践感悟,有些内容难免有失偏颇,望见谅.前面先介绍下需要了解的基本知识,大部分内容在肖力著作中都有更详细的解释,可阅读参考. KVM包含: 1.内核模块kvm.ko,用于核心虚拟框架. 2.包含与处理器相关的模块kvm-intel.ko,kvm-amd.ko 3.kvm需要使用经过修改定制的qemu软件提供用户空间工具 *内核组件已经包含在Linux内核2.6.20中了

悠然乱弹:论“轮子党”的邪恶面

什么叫轮子党呢?这里给出一个泛泛的定义,轮子党,就是看到开源作者做的作品之后,干净利索的在后面附着两字:轮子.当然现在也有一些新的变体,比如:发一条"然并卵".但是不管现在怎么变,将来怎么变,其基本涵义就是说:你做的东西没有什么意义,或者说你做了也是重复人家的东西. 但是最要命的是,这些轮子党在给出这些结论之前,没有任何分析.没有任何研究,他特么一个结论丢在那里,让开源作者在那里心中产生千万个草泥马在奔腾. 所以今天我就写这篇乱弹,来正告那些轮子党,为啥不是"轮子"

悠然乱弹:云里雾里说Tiny

今天从杭州到重庆,登机时间晚了20分钟,又晚了20分钟,又晚了20分钟,尼玛,这和我们软件实现的进度有得一比,总是他妈的延迟.延迟再延迟. 终于登机了,可能是MH17的事情影响了我的心情,上了飞机先仔细观察了一下,嗯嗯,看到一个空姐,比较漂亮,心情好了一点:又看到一个空姐,更漂亮,心情更好了:又看到一个空姐,依然漂亮,心情舒畅多了. 往窗外看看,发现我窗外就正好是发动机,上面刷了一行字:"The power of flight",于是我就想:The power of Tiny是啥呢?.

结构化方法和面向对象方法在软件开发中的对比

学习过C语言和JAVA的同学们一定清楚,这两种语言代表了两种不同的开发方式,即以C语言为代表的结构化开发方法和JAVA代表的面向对象的开发方法.由于二者在程序结构上有着很大的区别,因此,在软件开发领域中,根据自己的需求来选择合理的开发方式就显得尤为重要. 开发软件通常有三个层次: 1.满足用户需求 2.可维护性,即可修改性,让软件能随着用户需求的变更而容易改变 3.可重用性(在其它软件中,能尽量重用该软件的模块) 通过对软件的这三个主要层次的分析,我们就能在实际开发中确定我们的选择. 结构化方法

敏捷软件开发简述

前言:由于我读了邹欣老师的<构建之法:现代软件工程(第二版)>,因此对敏捷软件开发有了比较大的兴趣.于是我在网上找了一些论文,比如Requirements Engineering and Agile Software Development.A decade of agile methodologies: Towards explaining agile software development.在读了这些论文之后,对敏捷软件开发有了大致的了解.这篇博文主要是简单介绍敏捷软件开发,重点集中在主

敏捷软件开发VS传统软件工程

敏捷软件开发:又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新兴软件开发方法,是一种应对快速变化的需求的一种软件开发能力. 与传统软件工程相比,它们的具体名称.理念.过程.术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作.面对面的沟通(认为比书面的文档更有效).频繁交付新的软件版本.紧凑而自我组织型的团队.能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中"人"的作用. 本文将介绍敏捷软件开发的历史背景与发展,