我的2007, 兼谈些对技术的看法

看了代振军的<<我的2007>>, 恭喜下他的幸福生活~

然后说些对当前时髦技术的一些看法:

说实话, 我对rich ui controls,wcf,wpf再加上WWF中除了WCF, 其它暂时几年内都不看好. 最近做了些C++开发, 感觉到对于真正运行在客户端的软件最需要的东西真的不是WPF, 第一肯定是有用, 其次的也只能轮到运行的成本, 然后才是其它. 而安装额外的框架是一种软性的成本, 如果SL 2.0需要.NET Framework(编辑: 经jjx和装配脑袋提醒, SL2.0不需要.NET Framework, 所以不存在软性的成本,以下划掉的都是因为这个原因, 感谢以上两位, 我又重拾对SL 2.0的信心了), 那么它就相当于一个客户端软件的一个变种, 仅有的一条路就是Vista普及. 而微软在桌面操作系统领域的推进真的是非常乏力. 这不是因为Linux, 而是对于用户来说, 老的操作系统完全够用了.(编辑: 这是一个UE投入无效的例子).

共享软件不能用.NET, Word之类的软件也暂时没有能力转移到.NET; SL 2.0这样的东西, 或者更广泛的说, WPF, 加上大量控件和XAML, 从咱们程序员的角度看可能不错. 问题是用户的使用角度, 和美工设计者的学习和工作的角度, 恐怕是不愿意接受的. 前两天看一篇文章说, 正是.NET给了Java和其它解决方案重新走进桌面领域的机会, 确实有些道理. 问题是现在的发展方向, 其实就是变相的肥客户端, 要么不被接受, 要么就是为所有的饿狼开辟了一个新空间, 然后混战.

相反SL 1.0的轻薄(编辑: SL 2.0也同样具备), 加上与JS的结合, 是最好的出路. 这个也是Adobe没抓住, 从而使得Flash沦落成一个纯展示广告工具的一个关键点. 嗯, 除了Linq这样的提高生产力的东西一定会用到, WCF作为微软平台的这么一个方案也避免不了, 其它的微软技术(或其它技术)如果没有确切的, 较贴合需求的状况出现, 我的判断是一概不用学, 纯属浪费自己和拿其它组织的钱验证微软实验品是否经得住考验. 对于一个合格的技术组装者来说, 加上互联网和社区的帮助, 任何一种这样的工具, 边找参考资料边干, 也不会比预先演练慢很多.

UE, 这个词也是说得多实际意义少, 这是个增值的概念. 有时候UE很重要, 有时候则说明了其它问题: 基本需求还有大片空白, 主要精力财力不得不投入到研究UE, 有可能说明该应用已经缺乏突破口, 甚至是在面对未来出现更新形式的可能性, 该组织缺乏创新这一核心竞争力的表现. 这说明除了在自己当前产品上一点一点的改进非核心的部分, 已经没有空间了. 这方面从旧有的工业发展的经验里就能看到: 手机, 电视. 当然也有做UE成功的例子, 比如Apple, 不过Apple还是真正通过推动产业进步而挣钱的公司吗? 等着和Jobs一起垂垂老矣罢了.

编辑: AJAX方面随便加两句. 我比较不赞同使用JQuery之类的框架外再加上基于这些框架的控件库的做法. 基本这些框架我都粗略的看过, 确实很好, 各种界面库也很棒, 但是界面库的出现, 往往是在束缚而不是开发美术和交互设计的创造力. 而Web比起软件的一大优势, 在我看来就是界面的多样性. 其实JS的代码量已经非常小了, 我觉得每个人都应该自己去掌握一下, 自己开发适合自己的东西, 而不是用现成的; 无论是Ajax Control Toolkit还是其它框架下的库, 更多的是应该当一个例子, 而不是拿来即用. 当然企业开发用这些害处要小的多, 我对这些界面库了解也不够, 所以只是一个看法, 讨论一下.


下面是我的2007:

07年对于我来说, 是学习的一年, 其实早知如此, 还不如顺便报个学校, 拿个更高的学历, 两不耽误 :).

从我下决心做个Web界面层小框架到今天,再加上中间经历的杂七杂八的学习和不同项目的实践, 真正受益的事情是, 对技术的了解大大的长进了. 现在比较有代表性的重量级编程技术, 只有C++的模板元编程还没有真正接触过. 其它的具体到.NET下的反射, 抽象到函数式编程的思维方式和面向对象的建模种种, 现实到JS上进行兼顾效率的对象或组件式的编程实践, 阳春白雪到建立自己的思想方法并在各种语言和项目上应用, 现在都有一些心得了.

这些成果对我来说最重要的是, 可以让我进行比较全面的判断和相互参考. 同时我也建立起了一套行之有效的认识事物的方法, 在技术的海洋之中虽然不会说绝对不会迷路, 但是保险系数徒增. 未来无论走向技术深入, 还是走向偏向于技术方面的管理, 我都有信心可以平稳的增长下去.

虽然在哪一个领域我也算不上拔尖的高手, 但我心里的大石头却落地了, 知道在未来的生涯中不会有什么意外彻底摧毁我的工作和生活的中心. 象微软的新技术, Java的新框架, Ruby这样的新冒头的语言, 我一概可以不学也知道自己不会被时代抛弃, 它们一定有它们自有的方式和窍门, 可关键的是我掌握了学习和实践的经验和技巧.

说实话现在看着网络上那么多介绍文章, 一点兴趣都提不起来; 而过去, 我对类似于P3P这样的角落里的细节都害怕错过, 把很多类似的用户手册或游戏秘籍当作什么非要了解的东西, 就怕有别人会而我连知道都不知道的. 现在别说这些七零八碎的具体知识, 什么设计模式和面向对象思想在我这里也已经风淡云清, 虽然不是说我已经多么的驾轻就熟, 不过剩下的都是不断的设计和实践才能得到的东西.

尤其是最近的一个C++的小软件项目让我重新找回了一些信心, 虽然我不能像最先进的那些C++高手那样写出奇技淫巧的程序, 但是我终于证实了几年的Web和.NET干下来, 我并没有成为一个为各种各样的变相的系统集成行为写脚本的"程序员", 虽然C#看似不是一门脚本语言. 这话估计博客园上很多人不爱听, 但在过去, 我真的心里很害怕, 怕写.NET写下去, 写成一个离计算机很远的所谓"程序员". (编辑: 不过要说明的是, 离计算机很远的程序员或从业人员, 也有一些是与技术领域的核心问题息息相关的技术的, 比如对各种编程方式的深入探讨和摸索).

而大家都知道, 弄个数据库或文档管理模块, 根据需求或设想, 结合业务规则, 写点Web或企业应用, 在未来很可能转移到领域专家的手里去...., 其实现在很多Web程序员或创业者严格的说根本不能叫做程序员, 叫做Web领域的专家更得当. 当然, 领域专家的价值只能大于程序员, 而不太可能小于程序员, 这是我还在迷惑如何选择的问题之一: 我的长处和意愿, 到底是变成一个领域专家, 还是一个真正的技术人员, 或者站在中间, 成为一个粘合剂?

嗯, 不过我也有放弃的科目, 就是汇编, 因为汇编偏重于技巧和具体环境大过于偏重建立和表达我们的想法. 还有没放弃但做的不够好的, 我现在最对自己不满意的, 就是我算法上还不够扎实, 而且马马虎虎知道的那些算法知识也太大众化了, 尤其是脑子里没有自己独特的东西. 现在对我来说有个判断是必须做的, 如果未来深入技术实现的具体工作, 就应该把这块拿下; 如果将来更多的是走向管理, 那么这一块就属于交给真正的专家的工作了.

等真正覆盖了还缺乏了解的那几个重要领域(现在预期的重点是分析模板元编程的工作效率/运行效率/项目可靠性的影响, 另外一个是重新核实一遍对各种算法的了解程度), 明年, 我积累的各种了解(我只敢管它们叫了解)逐渐的就可以走向实用了, 生产上的顺利是可以预期的 :).

希望明年是开花结果的一年. 也希望我能克服一些人性上的, 比技能更根本的弱点.

编辑: 刚才订到Modern C++ Design了, China-pub上缺货了好长时间, 这真是个用户习惯问题, 在他那买惯东西了, 没有都不愿意换. 可惜模板元编程一书无论译本和原本都没有, 我就日. 顺手定了本著名的<<敏捷软件开发>>的C#版, 查了一下该书的目录, 果然是本对现在的我已经毫无帮助的那种书, 干嘛要买, 还买本C#呢? 因为里面把那些关于设计的词全都拽全乎了(比Java那本全乎), 只当是买了一本过去一段时间流行词汇大全吧....

编辑: 本来是个很个人的东西, 不想发到首页了, 但是作为一个半程序员对自我的要求和规划, 抛砖引玉吧...

编辑: 明年我的工作, 有感兴趣的可以相互通通气, 看看能不能一起大干一场:

1. 完成我这个ASP.NET Web表现层小框架, 并围绕该框架做几个产品, 支持几个合作伙伴的业务. 有可能的附加任务: 该小框架向PHP, Ruby的移植.

2. 如果1能够进入一个平稳阶段, 同时确认传统Web领域已经缺乏制造属于自己的核心竞争力的机会, 那么现在是时候投入P2P了, 一个是对现有的流行的P2P开源产品的改进, 作为初步的实践和研究, 更重要的是看看能不能革新一下认识, 在P2P领域中找出些不同的东西来.
原文地址:https://www.cnblogs.com/guaiguai/p/990139.html