软件开发总结

需求
 你能给出一些非功能性（或者质量）需求的例子吗？
 如果客户需要高性能、使用极其方便而又高度安全，你会给他什么建议？
 你能给出一些用来描述需求的不同技术吗？它们各自适用于什么场景？
 需求跟踪是什么意思？什么是向前追溯，什么是向后追溯？
 你喜欢用什么工具跟踪需求？
 你怎么看待需求变化？它是好是坏？给出你的理由。
 你怎样研究需求，发现需求？有哪些资源可以用到？
 你怎么给需求制定优先级？有哪些技术？
 在需求过程中，用户、客户、开发人员各自的职责是什么？
 你怎么对待不完整或是令人费解的需求？
功能设计
 在功能设计中有哪些隐喻？t出几个成功的例子。
 如果有些功能的执行时间很长，怎么能让用户感觉不到太长的等待？
 如果用户必须要在一个很小的区域内，从一个常常的列表中选择多个条目，你会用什么控件？
 有哪些方法可以保证数据项的完整？
 建立系统原型有哪些技术？
 应用程序怎样建立对用户行为的预期？给出一些例子。
 如何入手设计一组数量庞大而又复杂的特性，你能举出一些设计思路吗？
 有一个列表，其中有10个元素，每个元素都有20个字段可以编辑，你怎样设计这种情况？如果是1000个元素，每个元素有3个字段呢？
 用不同的颜色对一段文本中的文字标记高亮，这种做法有什么问题？
 Web环境和Windows环境各有些什么限制？
技术设计
 什么是低耦合和高聚合？封装原则又是什么意思？
 在Web应用中，你怎样避免几个人编辑同一段数据所造成的冲突？
 你知道设计模式吗？你用过哪些设计模式？在什么场合下用的？
 是否了解什么是无状态的业务层？长事务如何与之相适应？
 在搭建一个架构，或是技术设计时，你用过几种图？
 在N层架构中都有哪些层？它们各自的职责是什么？
 有哪些方法可以确保架构中数据的正确和健壮？
 面向对象设计和面向组件设计有哪些不同之处？
 怎样在数据库中对用户授权、用户配置、权限管理这几项功能建模？
 怎样按照等级制度给动物王国（包括各种物种和各自的行为）建模？
程序设计
 你怎样保证你的代码可以处理各种错误事件？
 解释一下什么是测试驱动开发，举出极限编程中的一些原则。
 看别人代码的时候，你最关心什么地方？
 什么时候使用抽象类，什么时候使用接口？
 除了IDE以外，你还喜欢哪些必不可少的工具？
 你怎么保证代码执行速度快，而又不出问题？
 什么时候用多态，什么时候用委派？
 什么时候使用带有静态成员的类，什么时候使用单例？
 你在代码里面怎么提前处理需求的变化？给一些例子。
 描述一下实现一段代码的过程，从需求到最终交付。
算法
 怎样知道一个数字是不是2的乘方？怎样判断一个数是不是奇数？
 怎样找出链表中间的元素？
 怎样改变10000个静态HTML页面中所有电话号码的格式？
 举出一个你所用过的递归的例子。
 在散列表和排序后的列表中找一个元素，哪个查找速度最快？
 不管是书、杂志还是网络，你从中所学到的最后一点算法知识是什么？
 怎样把字符串反转？你能不用临时的字符串么？
 你愿意用什么类型的语言来编写复杂的算法？
 有一个数组，里面是从1到1,000,000的整数，其中有一个数字出现了两次，你怎么找出那个重复的数字？
 你知道“旅行商问题（Traveling Salesman Problem）”么？
数据结构
 怎样在内存中实现伦敦地铁的结构？
 怎样以最有效的方式在数据库中存储颜色值？
 队列和堆栈区别是什么？
 用堆或者栈存储数据的区别是什么？
 怎样在数据库中存储N维向量？
 你倾向于用哪种类型的语言编写复杂的数据结构？
 21的二进制值是什么？十六制值呢？
 不管是书、杂志还是网络，你从中所学到的最后一点数据结构的知识是什么？
 怎样在XML文档中存储足球比赛结果（包括队伍和比分）？
 有哪些文本格式可以保存Unicode字符？
测试
 什么是回归测试？怎样知道新引入的变化没有给现有的功能造成破坏？
 如果业务层和数据层之间有依赖关系，你该怎么写单元测试？
 你用哪些工具测试代码质量？
 在产品部署之后，你最常碰到的是什么类型的问题？
 什么是代码覆盖率？有多少种代码覆盖率？
 功能测试和探索性测试的区别是什么？你怎么对网站进行测试？
 测试套件、测试用例、测试计划，这三者之间的区别是什么？你怎么组织测试？
 要对电子商务网站做冒烟测试，你会做哪些类型的测试？
 客户在验收测试中会发现不满意的东西，怎样减少这种情况的发生？
 你去年在测试和质量保证方面学到了哪些东西？
 
维护
 你用哪些工具在维护阶段对产品进行监控？
 要想对一个正在产品环境中被使用的产品进行升级，该注意哪些重要事项？
 如果在一个庞大的文件中有错误，而代码又无法逐步跟踪，你怎么找出错误？
 你怎样保证代码中的变化不会影响产品的其他部分？
 你怎样为产品编写技术文档？
 你用过哪些方式保证软件产品容易维护？
 怎样在产品运行的环境中进行系统调试？
 什么是负载均衡？负载均衡的方式有哪些种？
 为什么在应用程序的生命周期中，软件维护费用所占的份额最高？
 再造工程（re-engineering）和逆向工程（reverse engineering）的区别是什么？
 
配置管理
 你知道配置管理中基线的含义么？怎样把项目中某个重要的时刻冻结？
 你一般会把哪些东西纳入版本控制？
 怎样可以保证团队中每个人都知道谁改变了哪些东西？
 Tag和Branch的区别是什么？在什么情况下该使用tag，什么时候用branch？
 怎样管理技术文档——如产品架构文档——的变化？
 你用什么统计管理项目中所有数字信息的状态？你最喜欢哪种工具？
 如果客户想要对一款已经发布的产品做出变动，你怎么处理？
 版本管理和发布管理有什么差异？
 对文本文件的变化和二进制文件的变化进行管理，这二者有什么不同？
 同时处理多个变更请求，或是同时进行增量开发和维护，这种事情你怎么看待？
项目管理
 范围、时间、成本，这三项中哪些是可以由客户控制的？
 谁该对项目中所要付出的一切做出估算？谁有权设置最后期限？
 减少交付的次数，或是减少每个交付中的工作量，你喜欢哪种做法？
 你喜欢用哪种图来跟踪项目进度？
 迭代和增量的区别在哪里？
 试着解释一下风险管理中用到的实践。风险该如何管理？
 你喜欢任务分解还是滚动式计划？
 你需要哪些东西帮助你判断项目是否符合时间要求，在预算范围内运作？
 DSDM、Prince2、Scrum，这三者之间有哪些区别？
 如果客户想要的东西太多，你在范围和时间上怎样跟他达成一致呢？
作者简介：
Jurgen Apello：荷兰ISM eCompany首席信息官，该公司不久前被评为荷兰成长最快的技术公司。
Jurgen的兴趣在于软件工程、质量改进和复杂性理论，曾在DDJ等多本技术杂志上发表文章。
译者简介：
李剑是InfoQ中文站(www.infoq.com/cn)敏捷社区的首席编辑，Ethos(宇思信德)资深工程师。
他的译作包括《深入浅出Struts2》和《硝烟中的Scrum和XP》，二者均为InfoQ中文站迷你书。
（本文来自《程序员》杂志0903期）


在这个世界上，有数百万的人热衷于软件开发，他们有很多名字，如：软件工程师（Software Engineer），
程序员（Programmer），编码人（Coder），开发人员（Developer）。
经过一段时间后，这些人能够成为一个优秀的编码人员，他们非常熟悉如何用计算机语言来完成自己的工作。
但是，如果你要成为一个优秀的程序员，你还可以需要有几件事你需要注意，
如果你能让下面十个条目成为你的习惯，那么你才能真正算得上是优秀程序员。

1. 学无止境。就算是你有了10年以上的程序员经历，你也得要使劲地学习，因为你在计算机这个充满一创造力的领域，
每天都会有很多很多的新事物出现。你需要跟上时代的步伐。你需要去了解新的程序语言，以及了解正在发展中的程序语言，
以及一些编程框架。还需要去阅读一些业内的新闻，并到一些热门的社区去参与在线的讨论，这样你才能明白和了解整个软件开发的趋势。
在国内，一些著名的社区例如：CSDN，ITPUB，CHINAUINX等等，在国外，建议你经常上一上digg.com去看看各种BLOG的聚合。

 

2. 掌握多种语言。程序语言总是有其最适合的领域。
当你面对需要解决的问题时，你需要找到一个最适合的语言来解决这些问题。
比如，如果你需要性能，可能C/C++是首选，如果你需要跨平台，可能Java是首选，如果你要写一个Web上的开发程序，
那么PHP，ASP，Ajax，JSP可能会是你的选择，如果你要处理一些文本并和别的应用交互，可能Perl, Python会是最好的。
所以，花一些时间去探索一下其它你并熟悉的程序语言，能让你的眼界变宽，因为你被武装得更好，你思考问题也就更为全面，
这对于自己和项目都会有好的帮助。

3. 理性面对不同的操作系统或技术。程序员们总是有自己心目中无可比拟的技术和操作系统，有的人喜欢Ubuntu，
有的人喜欢Debian，还有的人喜欢Windows，以及FreeBSD，MacOSX或Solaris等等。
看看我的BLOG(http://blog.csdn.net/haoel)中的那篇《其实Unix很简单》后的回复你就知道程序员们在维护起自己的忠爱时的那份执着了。
只有一部分优秀的程序员明白不同操作系统的优势和长处和短处，这样，在系统选型的时候，才能做到真正的客观和公正，
而不会让情绪影响到自己。同样，语言也是一样，有太多的程序员总是喜欢纠缠于语言的对比，如：Java和Perl。
哪个刚刚出道的程序员没有争论去类似的话题呢？比如VC++和Delphi等等。争论这些东西只能表明自己的肤浅和浮燥。
优秀的程序并不会执着于这些，而是能够理性的分析和理心地面对，从而才能客观地做出正确的选择。

4. 别把自己框在单一的开发环境中。 再一次，正如上面所述，每个程序员都有自己忠爱的工具和技术，
有的喜欢老的（比如我就喜欢Vi编辑程序），而有的喜欢新的比如gedit或是Emacs等。有的喜欢使用像VC++一样的调试器，
而我更喜欢GDB命令行方面的调式器。等等等等。程序员在使用什么样的工具上的争论还少吗？到处都是啊。
使用什么样的工具本来无所谓，只要你能更好更快地达到你的目的。但是有一点是优秀程序员都应该了解的——那就是应该去尝试一下别的工作环境。
没有比较，你永远不知道谁好谁不好，你也永远不知道你所不知道的。

5. 使用版本管理工具管理你的代码。千万不要告诉我你不知道源码的版本管理，
如果你的团队开发的源代码并没有版本管理系统，那么我要告诉你，你的软件开发还处于石器时代。
赶快使用一个版式本管理工具吧。CVS 是一个看上去平淡无奇的版本工具，但它是被使用最广的版本管理系统，
Subversion 是CVS的一个升级版，其正在开始接管CVS的领地。Git 又是一个不同的版本管理工具。还有Visual SourceSafe等。
使用什么样的版本管理工具依赖于你的团队的大小和地理分布，你也许正在使用最有效率或最没有效率的工具来管理你的源代码。
但一个优秀的程序员总是会使用一款源码版本管理工具来管理自己的代码。如果你要我推荐一个，我推荐你使用开源的Subversion。

6. 是一个优秀的团队成员。 除非你喜欢独奏，除非你是孤胆英雄。但我想告诉你，今天，可能没有一个成熟的软件是你一个人能做的到的，
你可能是你团队中最牛的大拿，但这并不意味着你就是好的团队成员。你的能力只有放到一个团队中才能施展开来。
你在和你的团队成员交流中有礼貌吗？你是否经常和他们沟通，并且大家都喜欢和你在一起讨论问题？
想一想一个足球队吧，你是这个队中好的成员吗？当别人看到你在场上的跑动，当别人看到你的传球和接球和抢断，能受到鼓舞吗？

7. 把你的工作变成文档。 这一条目当然包括了在代码中写注释，但那还仅仅不够，你还需要做得更多。
有良好的注释风格的代码是一个文档的基础，他能够让你和你的团队容易的明白你的意图和想法。
写下文档，并不仅仅是怕我们忘了当时的想法，而且还是一种团队的离线交流的方法，更是一种知识传递的方法。
记录下你所知道的一切会是一个好的习惯。因为，我相信你不希望别人总是在你最忙的时候来打断你问问题，
或是你在休假的时候接到公司的电话来询问你问题。而你自己如果老是守着自己的东西，
其结果只可能是让你自己长时间地深陷在这块东西内，而你就更本不可以去做更多的事情。
包括向上的晋升。你可能以为“教会徒弟能饿死师父”，但我告诉你，你的保守会让你失去更多更好的东西，
请你相信我，我绝不是在这里耸人听闻。

8. 注意备份和安全。 可能你觉得这是一个“废话”，你已明白了备份的重要性。但是，我还是要在这里提出，
丢失东西是我们人生中的一部份，你总是会丢东西，这点你永远无法避免。比如：你的笔记本电脑被人偷了，你的硬盘损坏了，
你的电脑中病毒了，你的系统被人入侵了，甚至整个大楼被烧了，等等，等等。
所以，做好备份工作是非常非常重要的事情，硬盘是不可信的，所以定期的刻录光盘或是磁带可能会是一个好的方法，
网络也是不可信的，所以小心病毒和黑客，不但使用软件方面的安全策略，你更需要一个健全的管理制度。
此外，尽量的让你的数据放在不同的地方，并做好定期（每日，每周，每月）的备份策略。

9. 设计要足够灵活。 可能你的需求只会要求你实现一个死的东西，但是，你作为一个优秀的程序，
你应该随时在思考这个死的东西是否可以有灵活的一面，比如把一些参数变成可以配置的，
把一些公用的东西形成你的函数库以便以后重用，是否提供插件方面的功能？
你的模块是否要以像积木一样随意组合？如果要有修改的话，你的设计是否能够马上应付？
当然，灵活的设计可能并不是要你去重新发明轮子，你应该尽可能是使用标准化的东西。
所谓灵话的设计就是要让让考虑更多需求之外的东西，把需求中这一类的问题都考虑到，
而不是只处理需求中所说的那一特定的东西。比如说，需要需要的屏幕分辨率是800×600，
那么你的设计能否灵活于其他的分辨率？程序设计总是需要我们去处理不同的环境，以及未来的趋势。
我们需要用动态的眼光去思考问题，而不是刻舟求剑。也许有一天，你今天写的程序就要移植到别的环境中去，
那个时候你就能真正明白什么是灵活的设计了。

10. 不要搬起石头砸自己的脚。程序员总是有一种不好的习惯，
那就是总是想赶快地完成自己手上的工作。但情况却往往事已愿违。越是想做得快，就越是容易出问题，越是想做得快，
就越是容易遗漏问题，最终，程序改过来改过去，按下葫芦起了瓢，最后花费的时间和精力反而更多。
欲速而不达。优秀程序员的习惯是前面多花一些时间多作一些调查，试验一下不网的解决方案，如果时间允许，一个好的习惯是，
每4个小时的编程，需要一个小时的休息，然后又是4个小时的编码。当然，这因人而异，但其目的就是让你时常回头看看，
让你想一想这样三个问题：1）是否这么做是对的？2）是否这么做考虑到了所有的情况？3）是否有更好的方法？
想好了再说，时常回头看看走过的路，时常总结一下过去事，会对你有很大的帮助。

以上是十条优秀程序员的习惯或行为规范，希望其可以对你有所帮助。