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

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

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

 

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

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

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


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

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

龙振东同学,一直在使用TinyDbRouter,也发现了里面的一些BUG,也提了许多的改进建议。由于他是把代码拉到本地在本地改的,我建议他直接fork我们的代码,并在修改之后pull request给我们,这样,对两方都有好处。
其中涉及到一个问题,他在QQ上问我如何处置:有些非标准SQL,SQL解析器不支持,他建议(实际上他前期就是这么做的)在出现不支持的SQL异常的时候,改由读写分离方式去执行。
由于当时在开车,是在电话里和他沟通的,因此就没有聊天实录了,我直接敲字敲上来吧。
  1. 悠然:由于出现了SQL解析异常,说明这个时候SQL是不标准的,有可能是适用于读写分离,有可能适用于分库分表,你不管采用哪一种方式进行处理,总有一种情况是用“错误”的方式去执行的,这样就会导致出现非用户期望的结果--而且这个时候,用户得到了看起来正常的结果--因为没有异常和错误发生,但是实际上结果是不正确的。这种处理结果比抛异常直接告诉他不支持这个功能严重得多得多,会直接害死你、害死你的老板、害死你的客户。 
  2.  
  3. 所以,请直接抛异常,而不是改成前面的处置方式。如果这个SQL对你非常重要,那唯一正确的办法是扩展SQL解析器,使之支持。你觉得怎么样? 
  4.  
  5. 龙振东:然。 

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

杂谈之四:再论缓冲相关代码的演变
本人写过一篇关于缓冲方面的文章,可以通过点击上面的链接去查阅。有许多人回复,有些人觉得不错,有的人觉得不好,各说各有理。
其实计算机领域当中,解决一个问题,可以有N种方案,有时他们的差别非常小,这个时候就需要仔细斟酌了。
这不,周末大家又问了:
  1. 【活跃】lianzi(756215798) 10:03:18 
  2. 早,现在不知道看什么技术文章啦,昨晚睡觉前看了篇悠然和hasor的博客 
  3. 就是那篇缓存重构调优的 
  4. 逻辑是很清楚的,至于最优解,鬼知道 
  5. 【传说】杭州-悠然 10:05:45 
  6. 下面不是被喷了么:) 
  7. 【活跃】lianzi(756215798) 10:07:19 
  8. 好吧,那最后的优化方案是什么呢?实际效果如何呢? 
  9. 【传说】杭州-悠然 10:07:40 
  10. 实际,我们用得感觉还不错。 
  11. maven插件? 
  12. 【传说】杭州-悠然 10:07:58 
  13. 关键是避免程序员参与缓冲方面的事情。 
  14. 由于通过Maven插件动态嵌入代码,因此性能方面也非常有保障。 
  15. 【活跃】lianzi(756215798) 10:08:52 
  16. 这个说法,我觉得,要看场景 
  17. 如果小弟不怎么给力是好事,但是程序员在调试代码的时候怎么办?至少内置个http server 有个缓存的dashboard 
  18. 你觉得呢? 
  19. 【传说】杭州-悠然 10:09:46 
  20. 其实你可以理解成一种AOP处理。 
  21. 程序调试代码,就是全部从真实数据库取数据呀。 
  22. 又没有任何影响,用Maven命令处理过,只是通过缓冲加速了而已。 
  23. 【活跃】lianzi(756215798) 10:10:57 
  24. 我的意思是这样子的,缓存应不应该对程序员透明 
  25. 【传说】杭州-悠然 10:11:28 
  26. 我们的选择是透明。 
  27. 【活跃】lianzi(756215798) 10:11:39 
  28. 认同 
  29. 【传说】杭州-悠然 10:11:48 
  30. 文章中说了诸多好处,尤其是一种缓冲方案换成另外一种缓冲方案的时候。 
  31. 关键是避免程序员参与缓冲方面的事情。 
  32. 【活跃】lianzi(756215798) 10:12:02 
  33. 是,逻辑清晰 
  34. 【传说】杭州-悠然 10:12:07 
  35. 选择透明的方式,只要架构师或高程完成就好了,原有代码不用做修改。 
  36. 【活跃】lianzi(756215798) 10:12:19 
  37. 我们老大也经常骂我,说要把故事讲完整 
  38. 【传说】杭州-悠然 10:12:25 
  39. 上次我们从MC->Redis,那代码改得,都吐血了。 
  40. 【活跃】lianzi(756215798) 10:12:53 
  41. 没做抽象层? 
  42. 【传说】杭州-悠然 10:13:01 
  43. 如果再从Redis->另外的方案,不是又要吐血了? 
  44. 【潜水】上海-云卷江南(25269626) 10:13:08 
  45. 改个实现类不就行了 
  46. 【传说】杭州-悠然 10:13:31 
  47. 如果你做了抽象层,使用的就一定是KV的。 
  48. 如果要深层次使用,就麻烦了,有的支持有的不支持。 
  49. 但是技术肯定是双刃剑,有好处也有坏处。 
  50. 【活跃】lianzi(756215798) 10:14:53 
  51. 这个我理解 
  52. 【传说】杭州-悠然 10:15:06 
  53. 如何发挥好处,避免坏处了。 
  54. 即使是搞了抽象层,我在文中也写了,到处是处理缓冲逻辑的代码,也是不好的。 
  55. 【潜水】上海-云卷江南(25269626) 10:15:43 
  56. 简单用 
  57. 【传说】杭州-悠然 10:15:53 
  58. 所以,比较好的办法就是采用面向切面的方式进行处理。 
  59. 【活跃】lianzi(756215798) 10:17:25 
  60. 这个我认可,一开始设计的就有问题 

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

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

细细品味!

欢迎访问开源技术社区:http://bbs.tinygroup.org。本例涉及的代码和框架资料,将会在社区分享。《自己动手写框架》成员QQ群:228977971,让我们一起动手,了解开源框架的奥秘!

posted on 2015-06-23 22:12 柏然 阅读(50) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。


网站导航:
 
<2015年6月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

常用链接

留言簿

随笔档案

搜索

  •  

最新评论

阅读排行榜

评论排行榜