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

Posted claireyuancy

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了《开源框架那点事儿11》:软件开发杂谈相关的知识,希望对你有一定的参考价值。


杂谈之中的一个:技术仅仅是成功的一点点基础条件。真正还是得靠做人

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

 

【传说】杭州-悠然 18:31:13
lianzi本色最终出来了。

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

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

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

做“产品”,不外乎“要想自己爽。先让别人爽”。

永远站在用户的角度考虑问题。

细节、细节、还是细节。 依据实际情况排定优先级比确定功能更重要。


 

深以为然。在做Tiny框架中。框架组做Eclipse插件的同学其中做一个功能是运行器。他的方案是:开个首选项,然后由开发者在里面配置啥种类型的文件由哪个类去运行。于是我问。假设有好多个运行器,开发者不就配死了?于是他做了个功能扩展。添加一个批量导入功能,能够批量导致了。于是我问假设有100个项目,100个开发者,有100种 运行器,不同的项目须要的运行器又不一样。是不是就得配100次配置文件。然后花大量的成本去分发这个配置文件。还得让程序猿花大量的时间去导入这个配置文件??关键是随着项目的不断变化,用的运行器是可变的,那么上面的这个过程就得不断进行。还涉及到一个版本号维护的问题,比方有的人导入了新的,而有的人还是旧的。这样综合起来得投多少人力物力和管理成本?
我给的方案是:在开发运行器时配置一个运行器xml定义文件,然后project去扫描当前项目中的运行器xml定义文件,于是工具开发者仅仅开发一次,每一个运行器开发者仅仅配置一次,真正的使用者,啥也不用管。随时都是最新可用。0工作量。
两个方案对照,工具开发者工作量小了。运行器开者工作量大了能够忽略的一点点,最终使用者,节省了大量的工作量,关键是不会让他们认为使用麻烦,且不会出错。

杂谈之三:让程序抛错还是让程序“正确”运行?

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

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

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

悠然:由于出现了SQL解析异常,说明这个时候SQL是不标准的,有可能是适用于读写分离,有可能适用于分库分表,你无论採用哪一种方式进行处理。总有一种情况是用“错误”的方式去运行的,这样就会导致出现非用户期望的结果--并且这个时候,用户得到了看起来正常的结果--由于没有异常和发生错误。可是实际上结果是不对的。这样的处理结果比抛异常直接告诉他不支持这个功能严重得多得多,会直接害死你、害死你的老板、害死你的客户。

所以,请直接抛异常。而不是改成前面的处置方式。假设这个SQL对你很重要,那唯一正确的办法是扩展SQL解析器,使之支持。你认为怎么样?

龙振东:然。

他很快就完毕并提交给我,以下是沟通实录:
【传说】杭州-悠然 20:10:03
以后就直接在我们project上改吧。
这样就能够一起共享了。
今天我给你电话里讲的原则,在工作中一定注意了。

否则你给捅大搂子的要:) 【话唠】龙振东(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 你看看所有获奖感言其中,没有哪一个说:由于我NB所以,我才... 而感谢这个。感谢那个。感谢边边角角的人物。 【活跃】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
这个我认为和经验关系更大 <span></span>【吐槽】上海 浩子(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的话来说,你的起点决定了你的终点。

你期望说后面再去补充,这个成本是很高的。 就好象你想盖个大楼,前面没太想好,就直接上手盖。期望中间进行不断修正就能够盖出大楼来。 可是到最后的时候。发现根本没有办法进行调整好让它转向正确的方向。


细细品味!
 

 

欢迎訪问开源技术社区:http://bbs.tinygroup.org。本例涉及的代码和框架资料,将会在社区分享。

《自己动手写框架》成员QQ群:228977971。让我们一起动手,了解开源框架的奥秘! 

技术分享

以上是关于《开源框架那点事儿11》:软件开发杂谈的主要内容,如果未能解决你的问题,请参考以下文章

《开源框架那点事儿23》:採用TinyDB组件方式开发

《开源框架那点事儿19》:特斯拉建“桩”与开源的生命力

《开源框架那点事儿25》:对框架模板引擎实现方式的改造实录

《开源框架那点事儿25》:对框架模板引擎实现方式的改造实录

《开源框架那点事儿33》极限挑战:用一条循环语句正确输出99表!前两名奖图书一本

前端那点事儿——Tocify自动生成文档目录