人生如旅

5. 软件工程UML敏捷开发敏捷测试6. 领域软件

出处：http://www.jobbole.com/entry.php/1117导读：人人似乎都同意IT行业是一个艰难领域，但怎样才能克服逆境，成为一名成功的IT专业人士呢？下文这些特质应该是关键。　　此文作者还是Jack Wallen，他在前段时间写过不少文章讨论IT职场，比如

墨菲定律说：“事情如果有变坏的可能，不管这种可能性有多小，它总会发生。”所以，如果提交SVN时可能没有填注释，那么既然有这种可能性它总会发生的，甚至每天都会发生，所以今天我决定，在提交SVN时禁止不填注释，否则拒绝提交。SVN其实在每次操作的时候都会执行一个脚本，定义了几个事

听运营办王主任关于文档重要性的讲座听了两遍，虽然主要内容相似，但是每一次听都有很大收获，虽然上周五是第二次听，却仍然收获颇丰。文档最重要的功能是“备忘”，而不是“沟通”。关于这两个功能，以前都深有感触的，但并没有系统性地划分主次。的确，文档的沟通功能是有限的，这个不仅取决于文

假设项目有n个模块，第个模块之间都有关联关系（或引用、或有接口等），且每个模块的工作量相同，且完成每两个或多个模块之间的关联关系的工作量都是1，则完成整个系统需要的工作量（单位为1）T(n) = (n + 2^n-1 + T_exp*4)/6其中，T_exp为根据经验估计的时间。其实2^n - 1是根据公式R(n) = C(n,1)+C(n,2)+C(n,3) + ...+C(n,

很久了一直思考程序员应该先学哪门编程语言，必须掌握哪些编程语言，如何一个学习顺序。正好看到金老师也在研究第一门编程语言选谁(http://blog.youkuaiyun.com/bitfan/article/details/7939691)，在此也表达一下个人看法。   金老师说到的第一门编程语言必须“有趣、简单、有用”的观点，我是基本同意的。    首先，如果一开始没趣，不能激发学习者的兴趣很难让学

对于前几天的一篇博文《好的程序员应该熟悉的几门编程语言》，有网友质疑我对程序员的定义，很可能是感觉我对程序员的定义超出了其想象，但事实上程序员的定义应该远远超乎其想象。这里说明一下我对程序员的理解，也没有绝对的对错，不同意见的朋友可以讨论，疏漏部分期待补充，欢迎交流沟通。    在软件工程上“软件=程序+文档”，有些把数据也列为软件的一个要素，但我喜欢把数据当成程序的一部分，因为数据是用于记录

多线程向来是一个让程序员头痛的一个问题，不只是初学者容易犯错误，很多老鸟也难免站着中枪。一旦出现问题很难定位和解决，除了可能因为编程者知识上的缺陷导致的疏漏外，另一个难题就是问题重现难度大，避免多线程导致BUG最好的方法就是预防。　　首先，在开始进行多线程编程之前要考虑好，我们是否真的需要多线程，什么时候才需要多线程。正所谓”大道至简“，越简单的设计越是好的设计，如果单个线程就可以完成任务解决

最近整理了一下SaaS软件公司或互联网公司的常用技术，按层次简单画了个“地图”，供学习者参考，同行交流，后续逐步完善。尤其未来要成为架构师、技术总监的同学们可以参考，欢迎批评、指正、补充，有空再改一版。...

我依然记得当我完成学业时，我是多么的天真。那时我深信自己已经准备好进入任何一家软件公司，并开始成为一个顶级的开发人员。显然，开始工作后没多久我就意识到，还有很多事是我所不了解的。　　在不断吸取经验的同时，我一直在努力学习那些我从来没有学过的，但却是成为优秀的开发人员所应了解的基本

转自：http://www.jobbole.com/entry.php/334. 一个程序员用在写程序上的时间大概占他的工作时间的10-20%，大部分的程序员每天大约能写出10-12行的能进入最终的产品的代码 — —不管他的技术水平有多高。 好的程序员花去90%的时间在思考、研究和实验，来找出最优方案。差的程序员花去90%的时间在调试问题程序、盲目的修改程序，期望某种写法能可行。“一个卓越

学习任何一门学问，只要掌握了其重点，了解了期命脉，顺藤摸瓜很快就会上手，而且进步很快，下面我谈一下学习ASP.NET的心得，应该先掌握的几个点，如果这几个点没有掌握可能学习起来比较慢。 1. ASP.NET的工作原理本质。 实际上ASP.NET跟ASP、JSP、PHP等都一样

C语言原本是面象过程编程的一个很好的例子，但却是应用非常广泛的一门编程语言，特别是在嵌入式领域，更是占据着不可替代的位置；另一方面，面向对象分析、设计、编程等概念已经被广泛接受，面向对象最大的优点就是使日后的维护变得容易，主要体现在软件架构设计和代码的解耦上，如果你按照“高内聚

如何成为一位杰出的工程师-How to be a Star Engineer Robert E. Kelley, Carnegie Mellon University (Robert E. Kelley, "How to be a star engineer," IEEE Spectrum, pp. 51-58, Oct. 1999.) 翻译：马仕毅 在1985 年，我被问了一些问题,从那时起,我就开始找寻真正的答案。提出问题的是贝尔实验室(那是仍然是AT&T的一部分，现在属于 Lu

有些问题对于小型的C++项目来说可能无关紧要，但对于大中型C++项目来讲，这些问题却成了大问题。什么样的项目算是小型项目呢，什么样的算是大中型项目呢，我认为10万LOC以下为小型项目，10-50万LOC为中型项目，50万LOC以上为大型项目。当然，不能单纯地以代码行数作为衡量标准，前几天产品重构，我用四二三十行代码换掉了原来的三四千行代码，那这个项目的规模是用这二三十行来计算呢，还是用那三四千行算呢？软件很难有一个准确的度量标准，暂以行数作为一种参考性标准吧。     当项目较大量一些在小型项目中不需要考

设计模式被认为是面向对象技术的第二代技术，公认的主要有设计模式(design patterns)、反模式(anti-patterns)、实现模式(implementation patterns)。这三方面都有标志性的书籍 Gof 的 “Design Patterns” William J. Brown, et al. “AntiPatterns” Kent Beck. “Implementation Patterns” 这三种模式涉及到软件设计的方方面面，而且侧重点也不一样，设计模式侧重于

摘自：http://www.cnbeta.com/articles/115415.htm 1. 你的 UI 是否高度一致？ 2.用户能自由掌控自己的操作吗？网站是否容易导航。 3.你知道谁是你的用户群吗？ 4.你是否有足够的预防错误的措施？ 5.你的设计是否简约？ 6.你是否使用了视觉提示？ 7.你的 UI 是否有操作提示？ 8. 你的内容是否清晰？ 9. 你如何使用色彩？ 10. 你的 UI 是否大象无形？你的 UI 应该让用户去体验，而不是放一些花哨

    软件的风险其实就是软件失败的可能性，控制好的风险就是降低了软件失败的可能，定期总结如何控制软件开发中的风险，并在后续的开发过程中避免已知风险，不断总结积累，避免得越多，成功的可能就越大。 1. 需求阶阶段 1）充分沟通通，保证信息的完整性。         需求人员一般与研发、工程人员是分开的，所以需求人员在调研需求时一般只倾向于对功能性的调研，而对性能、健壮性、系统约束等问题考虑可能欠缺。不可能要求需求人员对研发及工程人员关心的信息收集完整，所以在需求阶段需求调研人员必须与开发人员、工

不论在中国还是在外国，程序员应该是加班最厉害的工种之一吧，而且程序员都很反感加班（没几个喜欢加班的）。关于加班问题，一直在想，我们为什么加班，怎样才可以不加班或者少加班。     首先，可能是不加班干不完。 这要看加班的原因是什么：    a) 额外紧急任务。这种情况也应该是任何人都必须无条件接受的，因为各个行业各种工作都会有这种情况，你不可能找到一种没有紧急任务的工作；可能是软件行业有太多任务是紧急的，但是否真正紧急呢？有一种情况是很紧急的，那就是重大BUG，影响生产系统运营的。但为什么会有这

今天一朋友跟我说他们有一个问题，就是他们网络课程中有一个页面是乱码，要在浏览器中手动选择编码才能够正常显示，她们单位那个技术牛人想了好久都没有解决，而且向美国那边求救，人家给列出了8种可能的解决方案，结果都没有解决。看到这里，对WEB开发比较熟悉的就会想到，应该是页面的编码设置有