﻿<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/2.9.2" -->
<rss version="0.92">
<channel>
	<title>彼岸晴天</title>
	<link>http://www.baqt.net</link>
	<description>The other side of sunny days.</description>
	<lastBuildDate>Wed, 14 Jul 2010 01:19:22 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>麦当劳免费wifi密码</title>
		<description><![CDATA[M记WIFI账号密码，隐藏WIFI，要自己手动添加，全国通用。
账号：McDonald-OC
密码：Ac28Idfjla92ifjsl3jsHdowIo
账号密码需要区分大小写
密码采用的是WPA-PSK验证，数据加密是TKIP的（电脑设置），手机请用隐藏网络，WPA/WPA2制式
]]></description>
		<link>http://www.baqt.net/?p=469</link>
			</item>
	<item>
		<title>Happy birthday</title>
		<description><![CDATA[
手机拍的不太好，清晰的随后送上。。。
]]></description>
		<link>http://www.baqt.net/?p=458</link>
			</item>
	<item>
		<title>SQL2008混合身份验证</title>
		<description><![CDATA[由于需要，要把SQL2008单一的Windows身份验证改为混合模式身份验证。在此做一备忘。
步骤：
1、用Windows身份验证方式进入SQL2008，在“对象资源管理器”右击根目录，弹出服务器属性。在“选择页”-&#62;“安全性”-&#62;勾选Sql Server和Windows身份验证模式-&#62;确定。
到这里就可以断开连接退出并使用“SQL Server身份验证”模式登录了。
由于默认不启用sa，所以如果启用sa账户登录，则还需要如下设置:
2、回到“对象资源管理器”，展开“安全性”，展开“登录名”就会看到登录名sa，右键它&#8211;&#62;属性，“选择页”上选“状态”，右边的登陆选“启用”。确定。
这样就可以用sa登录，密码默认为空
3、若要修sa密码，可做如下操作：
新建查询，执行语句：
EXEC sp_password NULL, &#8216;你的密码&#8217;, &#8217;sa&#8217;;
（在此注意的是密码的策略，如果要用简单密码，则要在sa属性页里取消掉“强制实施密码策略”）
 sp_password 的说明：sp_password oldpassword,newpassword,loginame
但是在后续版本的SQL中，MS建议使用ALTER LOGIN而不是sp_password：
ALTER LOGIN sa WITH PASSWORD = &#8216;aa&#8217;  &#8211;把登录密码改为aa
ALTER LOGIN用来更改 SQL Server 登录帐户的属性：
ALTER LOGIN abina WITH NAME = abina2020;&#8212;-将登录名abina改为abina2020
ALTER LOGIN abina ENABLE;  &#8212;&#8211;启用已经禁用的登录
此时就可以用sa账户和自定义密码在SQL身份验证模式下登录了！
4、万一还登录不了，可做如下尝试：
打开“SQL Server配置管理器”&#8211;&#62;展开“SQL Server网络配置”&#8211;&#62;“MSSQLSERVER 的协议”，在右边启用“TCP/IP协议”。
然后在SQL Server服务 里重启MSSQLSERVER服务即可。
与本主题相关的一些后记：
vs2008自带的数据库是SQL2005的Express版本，其默认根目录是 系统盘:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL，这个路径可能会和我们安装的SQL2008路径不同(实际上绝大多数情况下的确是这样)，于是在不了解的情况下，当登录服务器名称选择为XXX\SQLEXPRESS登录后，会惊讶的发现自己以前创建的数据库“丢失”了！在作了相关了解后便知道其缘由了。
]]></description>
		<link>http://www.baqt.net/?p=456</link>
			</item>
	<item>
		<title>软件开发的真正问题：管理太复杂（转）</title>
		<description><![CDATA[项目越来越大，软件开发越来越复杂，管理者有时会感觉自己需要通过更加复杂的管理方法来解决这一问题。然而这被证明是不成功的。Lott先生是一位拥有30余年软件开发经验的程序员、DBA、项目管理以及软件架构师，近日撰写了一篇博文描述了自己解决复杂问题的一些经验。特将内容翻译如下：
有人总喜欢拿“软件危机”说事。我们无法足够快、足够低成本或足够好的开发软件。我同意埃德斯加·狄克斯特拉(Edsger Wybe Dijkstra)的观点，软件开发确实非常非常复杂。那么我的结论是否指软件成本缘于其复杂性？不，我认为软件成本高的原因来自于使用了错误的行为来管理软件的高成本。
控制的误解
人们关于控制的最大误解当属项目计划。我认为，软件开发项目管理工具，尤其是微软的Project，是我们犯下的最大错误。至于证据，大家可以了解一下敏捷开发方法。敏捷开发的一个关键元素是削减(或消除)软件开发相关的项目管理愚蠢行为。
我认为，软件开发工程一般都非常复杂，一个大的MPP文件并不能削减其复杂性，也不会有助于任何人理解其复杂性。我认为，我们不应该尝试征服这种复杂性，那是一种非常愚蠢的行为。如果你发现自己需要一个非常复杂的文档来征服许多非常复杂的复杂性，你正在犯错。
简洁性说明
我认为，用户开发经历非常有用，因为它们将软件开发的复杂性简化为我们可以清楚表达和记忆的东西。这让我们更有机会去裂解它。
如果用例要求一个大的复杂文档，我们可能正在错过本质的东西。它应该有一个简洁、易记和非常容易写到便笺条上的总结。它可以有一个详细的技术性附录。但它必须有一个简洁、易于表达清楚的总结。
如果你无法轻松的解释清楚用例，就说明它有些过于复杂了。
架构
一个架构图可能非常有帮助。作为地基的架构必须是经过反复分析后确保是正确的。你必须绝对自信它的可行性。就如同任何数学方面的分析，你需要图标和公式，而且你需要展示你的工作。
架构不需要故弄玄虚，而需要务实。一些简洁的公式(便于记忆)再加上合理的解析，效果会好的多。
工作分解结构(WBS)问题
我发现，具有复杂工作分解架构的项目又多加了一层复杂性和无用的管理。软件的成本非常高，那么让我们尝试通过增加管理来削减我们的成本。但是，这种为削减人力而增加人力的做法并没有实际意义。
与其浪费时间增加工作量，还不如确定一个人选，由其实现更有效的决策和保持开发进度保持正常。
更多的推出局部解决方案，这比每周状态报告更具价值。在理解详细设计过程方面，更多的与产品拥有者交流，比一个精心编写的计划更有价值。
反驳项目管理的辩解
我们或许会这样为项目管理辩护：通过消除“障碍”或“低效”，它可以让软件开发过程更高效。我也曾经相信这些，但现在我的观点变了。
让我们一起看一些项目管理可能会消除的那些所谓障碍：
◆用户参与。更确切的说，无需用户参与。我认为项目管理这种做法除了伤害用户外没有其它效果。如果用户不通过积极回答问题或检查近期结果来帮助软件开发，那么开发出来的软件不会创造任何价值。现在就停止工作，发现哪些事情是用户真正需要的。
◆技术资源。协调技术资源(数据库管理员的、系统管理员的、独立测试者的等)并不需要一个复杂的计划、状态会议或报告。它只需相关人士之间的几个电话。简单直接而有效。
◆决策。项目经理不是产品所有者，也不是用户，也不是技术专业人员，不会理解软件开发过程中的危险所在。实际上，他们只是在一场他们无法完全理解的会话中担当一个服务者的角色。如果他们能够做到不去承担不属于自己的任务而坚持服务理念，这也不错。
我不明白我们为何仅仅把重点放在IT项目管理上。敏捷开发人士的观点是正确的。通过真正削减成本和复杂性的做法来削减成本和复杂性，而不是通过增加管理。
]]></description>
		<link>http://www.baqt.net/?p=434</link>
			</item>
	<item>
		<title>项目管理－问题分析及改进建议（5）</title>
		<description><![CDATA[5 配置管理方面
5.1 配置信息等发布相对不畅，且发布形式不利于查询。
项目的配置管理信息发布渠道目前多数是通过mail来发布，此方式信息零散，不利于查询。
改进建议：提议尽快建立和健全配置管理信息发布系统，结束信息的分散发布形式，并提供强大的查询方式。
 
5.2 项目环境管理方法不够自动化
对于项目环境的发布等，自动化程度不高，特别是对中途的编译失败等原因导致发布失败时，往往没有采取特别有效的应对方法。
改进建议：目前项目环境的建立一般是采用ant来编译，最终发布到tomcat, weblogic等应用服务器上，因此，可以总结归纳常见的发布方式，制作自动化发布工具，如自动取源代码，自动编译，自动发布编译结果，自动部署应用程序，自动发布部署结果，自动跟踪结果等，以提高项目环境的自动管理方法，高效且出错率低。
 
5.3 项目环境监控不够，问题出现频繁。
项目中对于项目各种环境的监控一般都无法到位，出现问题才开始找原因，没有采取提前预防措施，从而使得问题出现频繁。
改进建议：对于应用服务器，数据库服务器，应该采用监控机制，推荐制作一套简单的工具，去监控硬盘空间，数据库文件大小，网络状态等等信息，发现问题，能够自动通知。
]]></description>
		<link>http://www.baqt.net/?p=432</link>
			</item>
	<item>
		<title>项目管理－问题分析及改进建议（4）</title>
		<description><![CDATA[4 程序测试方面
4.1 测试case质量普遍不高，测试质量低。
目前大多数项目的测试case书，大多数都是根据详细设计书，采用复制，粘贴来完成，细化工作不够，遗漏case比较多。此外，在测试过程中，由于大多采用纯人工测试，测试结果的质量，也完全取决于测试人员本身的素质，而测试团队目前多数是临时组建，受测试专业训练较少，项目中的最终测试结果往往令人堪忧。
改进建议：测试质量很大程度上直接和测试case的质量挂钩，对于目前项目中的测试case来说，遗漏的case多数是详细设计不充分引起的，所以也可以先从加强详细设计这方面来进行。此外，对于共通case最好能够分成两部分来区别对待，第一部分是技术共通或者业务共通case，第二部分是非共通实现的相同测试case，其中第一部分由于是共通实现的，因此测试时可以有针对性，不需要在每个用到的地方都做详细测试。而第二部分由于是非共通实现，因此必须想对待非共通case一样，进行细致的测试。关于测试人员的测试质量问题，也应该是管理者们应该重视的，评价一个测试人员的好坏，就应该把他的测试质量作为一个很重要的点考虑进去，不能只考虑测试效率，并且需要采取一定的措施，来检查测试结果的质量。
 
4.2 高效的制作测试数据的手段缺乏。
目前测试过程中，测试数据的制作一般都是人工制作，测试数据较少，命中率较低，且测试数据制作过程耗时，且测试数据的人工导入也相对麻烦，容易引起冲突。
改进建议：可以通过制作或引进测试数据的制作工具，当然一般情况下，测试数据发生器，都需要一定的规则制定，这些规则，我认为融入在测试case中是比较合适的，这样可以直接用测试case作为输入，生成的测试数据作为测试case的一部分，此外，该测试数据也会给单体测试带来好处。
 
4.3  快速测试手段缺乏，测试效率普遍不高。
目前项目中缺乏快速测试（包括自动化测试）的手段，测试手段一般都停滞于纯人工方式，测试效率普遍不高，且测试的结果经常有失误。
改进建议：从目前的项目周期来看，测试已经占了很大比重，但往往，大家都关注于开发效率，对测试效率不够重视，目前测试效率绝对是一个瓶颈，提高测试效率大致有以下几个途径，一是使用一些快速测试工具，来提高效率；二是总结现有测试方法，推广效率较高的测试手段；三是研究新的快速测试方法。这些途径可以一起实施来提高测试的整体效率。
 
4.4 回归测试手段缺乏，回归测试不充分。
项目中缺乏高效的回归测试手段，回归测试往往采用纯人工方式，且一般经常以强化测试来代替，最终产生的回归测试经常是不充分的，总会产生问题的遗漏。
改进建议：回归测试基本上是对程序的修改部分的一个再测试过程，而从目前项目的变更频率高的情况来看，回归测试更是尤为重要，但目前基本也就停留在人工测试的手段，如采用一定范围的强化测试来代替完整的回归测试。对于这些重复的人工测试手段，问题遗漏比较多，且一般要耗用大量工时。因此只有采用自动回归测试的工具或手段，来解决这个问题，关于自动回归测试，技术上可能还存在一系列问题，在实际项目中推荐采用自动测试为主，人工测试为辅的方式。
 
4.5 压力测试手段缺乏，且实施过于靠后。
目前对于应用程序的负荷，并发，性能等压力测试手段缺乏，且压力测试的实施也过于靠后，经常导致一旦发现性能等问题已经为时太晚，很难再解决，或者说解决的代价是巨大的，可能一直要影响到设计，往往成为客户非常不满的一个方面。
改进建议：首先当然是要重视压力测试，因为压力测试产生的问题，一般都是比较致命的，应该把部分压力测试的实施提前。对于压力测试的手段，技术上可能也存在一系列问题，但还是应该尽可能的去挖掘或研究出测试的手段，把这部分的风险降低。
]]></description>
		<link>http://www.baqt.net/?p=430</link>
			</item>
	<item>
		<title>项目管理－问题分析及改进建议（3）</title>
		<description><![CDATA[3 程序开发方面
3.1 项目技术积累太少，每次新项目的开发基本都是从头开始。
项目开发中，对技术的积累投入太少，导致目前项目结束后很少有真正整理好且严格审核的项目技术积累，每个新项目，往往都是从头开始，或者是直接从别的项目代码中copy部分代码，而这些代码往往没有经过严格的审核和挑选，往往这些代码没有充分共通化，其中鱼龙混杂，不利于再利用。此外，对于新开发的共通，学习成本大，且新的共通代码设计等方面往往不成熟，本身潜在问题可能比较多。
改进建议：针对以上问题，我认为不仅仅是要做好技术总结，以及平时的技术积累，技术收集工作，更关键是要建立一些最典型的开发场景，有点类似于appfuse的思想，然后针对于这些开发场景，收集整理好构建场景所需的各种共通并充分对其共通化，以便扩展，然后经过严格的评审，最后在实际项目开始时，采用合适的开发场景，在该场景之上去构架项目，即实现了跨项目之间的重用，也更便于学习的重用。此外，这些开发场景也应进行统一的维护，升级。
 
3.2 开发团队磨合期少，整体水平差，代码质量低。
由于当前人力资源的调配并不固定，分配给项目的开发者的水平也参差不齐，且开发水平普遍不高，新手较多，要在很多的时间内组合的团队，整体开发战斗力不强，且代码质量偏低，BUG率高，程序的潜在问题多。
改进建议：我觉得一个技术开发团队，成员的整体战斗力，决定了最终开发出来的项目的成败和质量，因此就必须采取手段已提高成员的战斗力水平，然而成员战斗力在短期之内是不可能有大的提升的。我认为，提高战斗力关键靠平时，且无时无刻的注意成员的培养，比如说可以在代码review的时候教导新手，拿我自己做个例子，我给很多人的代码进行过review，但我并不会只指出他们哪些地方是有问题的就完了，我更愿意告诉他们怎么做才更好，为什么好，遇到类似的问题处理原则是怎样的，然后要求把这些review的结果整理出来，在适当的时候对整个开发团队进行教育。这个只是个例子，我们更应该把这些可以提高整体战斗力的有效手段整理出来，在平时不断的实施，在适当的时候做总结。
 
3.3  缺乏分类的共通化管理，代码重复出现率高。
项目中往往缺乏一种分类化的，易查询，易追加的共通化管理，从而使应该重用的代码没有被重用，各自编写类似的逻辑代码，使得整体的可维护性，重用性方面降低。
改进建议：我认为应该建立一种管理机制，如果是一套管理系统更好，可以把项目中的共通有序的管理起来，包括共通的申请，审查，开发，维护，发布，查询等。这样可以大大提高共通业务，共通代码的管理，提高开发效率，减小开发成本。
 
3.4 应对式样等变更意识不强，程序结构扩展性较差。
对于应对式样等变更的意识不够强，程序开发中经常忽略此环节，扩展性考虑不够，当式样等变更频繁发生时，程序结构无法适应，往往造成大的程序变动或者出现丑陋的补丁。
改进建议：我认为式样变更是不可避免的，但也不是一味地去适应式样变更，把程序的扩展性做的非常强，这样往往是得不偿失的（当然特殊场合除外），正确的做法，应该是去估计式样变更，一般情况下，通过业务式样，能够估计出，哪些式样可能会有变动，哪些不大可能变动，对估计出来的式样变更，做扩展性考虑，这样才是比较有针对性的，往往效率也比较高。
 
3.5 开发的程序普遍文档不足，质量低。
对java doc的质量重视不够，文档注释等普遍不足，且质量偏低，不利于后期维护。
改进建议：我认为代码的注释，不仅体现了程序的质量，更有助于维护，而且注释是给人看得，并不是应付检查和规约的。因此，实际项目中贯彻这一点，把代码的质量真正做好。
 
3.6 程序单体测试普遍不足，导致后续bug率高。
由于开发时间的压缩，以及开发人员开发效率，开发水平低等问题，程序的单体测试普遍不足，导致后续bug率偏高。
改进建议：目前的大多数项目单体测试普遍不足，这个是事实，很多开发人员抱怨开发时间短，这个的确是一个方面，但我认为绝不是根本原因，对于目前很多项目的开发现状，很多开发人员的开发效率普遍不高这个才是根本原因，其原因多数可归结为本身能力不过关，解决问题的方法不妥当，自我计划性差，某各开发环节耗时。对于后三个原因，我认为完全可以对症下药，来提高开发效率，而如果问题出于第一个的话，那就无法马上解决了，要么把他安排他适合他的其他工作，要么对其进行技能教育，提高其能力。
 
3.7 程序log过少，出现问题时，很难直接通过log来锁定问题原因。
在I/F，DB取值等关键地方log太少，导致出现问题时，对于那些程序间联调的错，和那些依赖于DB数据的错误，很难通过log来发现问题。导致只有通过debug等手段来分析问题，跟踪处理问题效率非常低。
改进建议：我认为log主要用于通过文字的形式来记录运行场景，记录运行的一系列过程和状态，记录出错信息等等，而和程序员最相关的就是debug log，这种级别的log，功能相对专一，主要是为了在开发阶段定位出错所用，调试所用，一般我建议需要在和本程序的接口处和外部数据取得的地方出debug log，以便于出错定位，一般是程序间的接口处和对非画面显示的DB取值域(如：判断用flag)。此外，debug log也不是越多越好，因为大量的log信息，会占大量磁盘空间，同时也不利于查看。而对于非debug log的处理，其实是很有讲究的，特别是对出错log的处理，因为正常运行的场合，一般都不会去看log，只有当出错了才会看，而最终的用户环境里，debug log往往会被关闭，这个时候，出怎样的error log等信息以及怎么出，才能定位出错原因，这个是个课题，需要进行一番研讨，至少目前我参与过的项目里还没有对这个问题处理的好的。
 
3.8 编码过于依赖详细设计书，问题发现率低，且缺乏有效的统计，跟踪和处理。
程序员过于依赖详细设计书，没有抱着怀疑的态度去发现问题，及时提出问题，问题发现率低，导致很多问题往往到后阶段才被发现，从而使问题的解决成本变大，并且，对于编码阶段的问题，也缺乏有效的统计，跟踪和处理。
改进建议：详细设计书是人写的，难免有错也难免有遗漏和考虑不周的地方，特别是业务人员更注重具体业务的时候，而忽略一些细节的时候，小问题一般会比较多。而这些问题，对于该设计的review者和程序员，都有职责去尽早地发现问题，和提出问题，不应该怕麻烦，或推卸责任。至于如何去发现问题，我觉得一般可以从以下几个常见角度去看：分支判断处理是否完全？各种异常情况是否都已考虑和做出合适处理？是否有性能问题？对于表示细节的常见问题是否有相应对策和处理？此外，对于发现的问题，应该及时记录，提交管理者，以便于管理者进行统计，跟踪和处理。
]]></description>
		<link>http://www.baqt.net/?p=428</link>
			</item>
	<item>
		<title>项目管理－问题分析及改进建议（2）</title>
		<description><![CDATA[2 式样设计方面
2.1 整体方式设计和业务设计有脱节现象，交流磋商要加强。
目前项目的应用程序的整体表现标准，处理方针等，都是由方式设计组完成，但经常出现业务设计组并不清楚方式的现象而使设计五花八门，或经常出现违背方式的设计而并未告知方式组，导致这些设计在实际的实现中遇到种种困难。
改进建议：每个项目都会有一个相同的要求，那就是要求风格统一。而对于风格统一这项要求的完成，不仅仅取决于方式组，也同时取决于业务设计组，首先在业务设计开始时，就必须先尽量把一些方式定下来，大家基于这个统一的方式来设计，如果遇到方式不明确，设计可能出现不统一的地方，应立刻向方式组提出，以求一个统一的方式，这个就是逐步统一的过程，因为没有一个项目能在设计之初，就把所有的方式给统一下来。此外，对于一些特别要求，有悖于统一方式或者统一方式不能满足需求的情况，也应该向方式组提出，方式组对特殊情况也应记录在案，以便于后续的实现考虑。可以看出这个过程中，方式组和业务设计组等的交流是非常的重要的事情。
 
2.2 式样设计中为下阶段考虑的内容太少，为统计，抽出有用数据考虑做的工作太少。
项目中式样设计为下阶段（如：编码，测试等）考虑的内容太少，以及为一些今后有用的统计（如：画面依赖，共通调用，DB操作统计等）所做的考虑也过少。
改进建议：式样设计在整个开发过程中是一个最不能被自动工具替代的过程，因此我们往往希望利用式样设计的成果物，为其他工程阶段，自动生成初期成果物来降低开发成本，提高效率。而对于要为下阶段要产生怎样的成果物，其实并不能立刻把握住，而且一旦设计书编写完成，如果再发现缺少可抽取信息为下阶段所需的话，一般也不会再去回头修改设计了。因此，必须在设计的前期，就需要把设计书充分规范化，不仅仅是要便于人们阅读，而且也要便于机器“阅读”。而且需要把最期望得到的统计信息的原始数据信息，完整的记录于设计书之上。
 
2.3 详细设计的细化工作并不明显，很多是基本设计的翻版。
详细设计经常没有把基本设计书里面含糊的地方给设计清楚，没有把该进一步细化，进一步搞明白的地方给做到位，很多详细设计基本成了基本设计书的翻版，从而也成为客户不满的一个方面。此外，详细设计也应该包含整个基本设计的内容，最好不应写直接参照基本设计，否则会给版本控制等带来麻烦。
改进建议：我认为优秀详细设计的内容，就应该在充分理解基本设计的基础上，把基本设计中没有提到的细节，模棱两可的地方和未处理的异常等都在详细设计里进行明确下来，这个过程肯定是需要不断和基本设计人员进行交流的，使得程序员能够直接根据详细设计，而不用参照基本设计，来进行程序设计。目前，越来越多没有经验的设计人员来参与详细设计，很容易忽略这个关键点，往往以为能看懂基本设计了，能够按照详细设计的格式来写详设了，就算达标了，没有做到这个关键点，我认为就不合格，详细设计review的时候，就应该特别检查这一点。此外，对于技术内容偏重的详细设计，最好能够进行技术专家级别的review，因为糟糕的设计，基本上会毁了整个实现。
 
2.4 设计书中往往缺少本设计内容的整体式样概括和流程说明，导致阅读困难。
目前的设计书往往缺乏对本设计内容的整体式样概括和流程的说明，不利于快速阅读和整体设计review的实施。
改进建议：目前大多数的详细设计里，对于阅读者，很难通过纯文字描述来一下子看明白设计的目的，方法，手段，以及实现过程等情况，也就很难发现其中的问题。所以我建议应该对本设计内容的进行整体式样概括以及流程上的说明（最好以图的方式来表达）。
 
2.5 式样变更没有有效的进行控制，式样变更频繁。
目前项目中式样变更往往没有进行有序的控制，式样变更过于频繁，变更次数也没有得到有序的控制，导致对应成本过大。
改进建议：经历的一些项目，式样变更相当频繁，对于这些变更，实际上我们应该变被动为主动，去有意地控制这些变更，让变更变得更有计划更有阶段性，比如，可以把多次变更合成一次变更，把次要的变更延后或者合并。此外，还可以把局部发现的问题而引起的变更，引申为全局，把迟早要发生的变更提前，而做统一的变更。这样对变更成本的控制，才是积极的。
 
2.6 式样中对于异常case的考虑普遍过少。
式样设计中，一般只考虑了正常case，对于各个业务式样的异常case考虑普遍偏少。
改进建议：大家都应该知道，在程序中，对一个考虑异常程序和一个不考虑异常的相比，在实现代码行数上来看，就有相当大的差距。我认为是否对每个异常情况都是否处理，这个是比较两个程序水平的一个很重要的点。对于式样设计也一样，而且更加重要，原因就是，程序的实现，都应该是有依据的，这个依据就是设计，要提高程序对异常的处理，最有效的方法，就是在设计的时候就全面的考虑进去，把每种异常该如何处理，都记录下来。这个可以通过采用异常处理的教育和review设计来强化这点。
 
2.7 DB式样变更过于平凡，随意，严重影响效率，返工耗时严重。
项目的DB式样变更经常是过于平凡，随意，且并没有很好的受到控制，严重影响各工程阶段效率，返工耗时严重。
改进建议：在现代软件架构中，DB设计可以说是整个设计的基石，可想而知，基石不牢，如何能建成牢固地高楼大厦呢！目前就发现很多DB式样变更平凡，随意，且没有受到很好的控制，引起很多的混乱，返工耗时严重。对于现在的DB设计，我认为，首先，就一定要要求，DB的设计者必须是DB设计方面的专家，或者有专家指导，这样才能做出范式要求的设计。其次，DB设计的变更，应该是谨慎的，同时必须是经过严格评审的（包括影响度分析）。再次，对于多子系统的DB设计，应该把各子系统间的DB设计分离，且子系统间的DB表尽量解偶。最后，对于DB设计变更的对应也应该具有前瞻性，我提议可以提前做到可以从详细设计等中抽出DB使用详细一览，当设计变更来临时，能够很清楚的确认变更范围和变更对应方法，以及回归测试方案。
 
2.8 设计中共通化工作做得不够充分，遗漏较多。
设计中，共通化工作一般都做得不够充分，遗漏较多，给后续工程带来了不少麻烦。
改进建议：共通化这个过程很多情况下是在详细阶段才能被发现，首先，共通化这个过程，需要了解整个子系统的业务人员来判断，而且应该是主动的过程。其次，还可以和其他子系统的业务人员进行沟通，以求得更高规模的共通化。此外，进行必要的共通化管理也是必须的，可以参见：3.3。
 
2.9 设计时对程序效率问题考虑过少，和技术团队对于该问题上缺乏交流。
设计时，对程序的效率问题考虑的太少，一般都不去考虑各数据表的数据量等问题，最终设计出来的画面，有些效率异常低，对于效率上的问题，也很少跟技术团队等进行交流。
改进建议：首先对于一些简单的就能分析出来的性能问题，就应该在设计中考虑进去，常见的设计上的性能问题，很多都是与DB操作有关系，如循环中带检索，对数据量巨大的表进行非索引检索等等。因此，我认为，可以开展教育，让大家学会如何去考虑性能问题，如何去用其他变通的方法去解决性能问题。此外，设计时也可以多和技术团队进行交流，以求解决方法。最忌把性能问题留到最后。
]]></description>
		<link>http://www.baqt.net/?p=425</link>
			</item>
	<item>
		<title>项目管理－问题分析及改进建议（1）</title>
		<description><![CDATA[根据自身多年的项目经验，从项目开发的各个方面，总结了公司在整个项目开发过程中常出现的不足和问题，并分别对这些不足和问题提了一些改进建议，目的还是为了改进我们项目的整个开发过程，如有不妥之处，还望指出。此外，项目问题的分析其实还可以从人的方面来切入，这个就留在以后再来分析了。
 
1 项目管理方面
项目人力管理和计划管理：
1.1 日常人力资源管理成本大，人力资源浪费现象普遍。
需要不停从计划中或者人工的收集人力资源空闲状态来进行人力资源的管理，费时费力，且容易出错。目前项目管理中并未实时跟踪人力资源空闲状态，从而导致人力资源浪费。
改进建议：目前，公司的项目规模越来越上规模，对于百人以上同时作业的项目，如果还是停留在人工的从各个信息中抽取分析的话，那对于管理者来说，简直就是个恶梦。目前，公司里已经使用了一些管理工具，比如ms project等，但一般情况下，普遍用excel版本的各种一览管理文档为主，对于这些很多信息，可以说是分散的，对于各个管理工具来说，也是互相独立的。信息的分散，管理方法的分散和重复，给目前的管理带来了巨大的成本。因此，迫切需要一个整合的管理环境，能够把各种分散的信息，统一的进行汇集，进行分析和控制。要实现这个整合的管理环境，需要走比较长的路，但该走的路迟早是要走的，现在起就可以把需要整合的数据，以及需要整合的功能给整理出来，目标可以是通过技能，任务，人员三大视图，来进行有效的管理，使得整个管理操作是轻松的，实时的。把需要的数据通过便捷的方式进行导入，进行编辑，并且记录自动记录各种履历信息，使一切管理都是可回溯的，慢慢的有计划的把需要的功能整合进去，逐步淘汰现有的分散工具。
 
项目问题分析：
1.2 对项目的问题分析时常是经验主义，差错多，且分析成本大。
目前项目管理中，对问题的分析，都是凭借项目管理者自身的经验来做，分析方法，分析结果和实际问题的差异，完全取决于各自的经验。
改进建议：参见1.1
 
项目内容管理：
1.3 管理中责任者指定有漏洞。
一般项目都会按照系统分类，按照画面等来划定各个阶段的责任者，但随着人员的调动等原因，责任者的指定得不到实时的更新，经常出现责任漏洞。
改进建议：参见1.1
 
1.4 CMMI不该是无形的指导，更应是有形的体现。
CMMI不只用来参照和检查的，更应该是用来指导项目开发，以求完善软件开发的每个过程，从而来提高软件开发的成熟度。当前项目中，CMMI的指导作用并不能有形的体现在开发的每个环节，各开发者也并不能完全的感受到。
改进建议：加强CMMI的教育，以最简单的方式来教育CMMI，并在整个开发过程中，标识出CMMI，在各环节起到的作用，把无形化有形，让各开发者充分感受到CMMI。
 
1.5 对式样变更引起的一系列对应，缺少有效的变更管理和高效的跟踪手段。
各种式样变更，渠道众多，缺少有效的变更管理，以及后续的跟踪手段。
改进建议：参见1.6
 
1.6 TODO事项的跟踪管理力度不强，和代码，式样等TODO事项没有很好的挂钩。
代码中出现的TODO事项，往往缺乏自动化跟踪的手段，且并没有很好地和式样等TODO事项做到挂钩，且没有采用高效率的方法对TODO事项的紧急度，和后续处理做跟踪。
改进建议：针对式样变更管理，TODO事项管理等，建议建立一套集成管理工具，把管理者从各种管理文档中解放出来。这个功能可以整合进整合的管理环境，参见1.1。
 
项目目录和文件管理：
1.7 项目文件目录分类缺乏有效管理，文件放置随意。
项目的目录一般只是在项目初期，统一建立一次，之后就缺乏有效的管理，而时常出现想保存的文档找不到合适的目录，而胡乱放置的情况。
改进建议：参见1.11
 
1.8 文件移动，目录变化等操作缺乏有效的通知手段，重复文件的情况较多。
经常出现改变目录名称，文件名称，移动文件等情况，但没有发布有效的通知。且非常容易出现重复文件。
改进建议：参见1.11
 
1.9 缺乏文件的并发访问控制
特别是对于非共有的文档，多人同时希望更新的场合，缺乏有效的管理，经常出现需要等待他人关闭文件后才能再更新，导致并发效率低下。
改进建议：参见1.11
 
项目文档查找，版本，履历管理：
1.10 文档查找困难，查找效率低。
目前使用文件服务器来存放文档，没有任何辅助的存放信息，只能支持在目录中进行文本文档的全文检索，效率低，搜索到的有效信息命中率太小。此时如果再出现文档放置目录混乱的现象，则查找就更加困难。且目前无法支持按版本检索。
改进建议：参见1.11
 
1.11 文档版本管理，文档履历管理问题多。
经常需要对式样书等文档进行版本管理，现行做法往往是通过在式样书中记录更新版本信息，然后通过一个一览文件来抽取这些版本信息，来跟踪版本号。
此外，目前对于文档的履历的管理，存在一些问题，不能真正做到履历的有效管理。
有些直接通过Excel或者Word来记录履历信息，此方法容易出现履历信息记录不全，丢失等现象，以及有履历查看麻烦，文件大小膨胀等问题。
有些通过备份修改前版本来保存履历信息，此方法容易出现丢失有效的履历信息，如更新者，更新时间等信息。
改进建议：目前公司使用文件服务器方式来管理项目中的所有文档，文件，以及权限等，该方法存在一系列不足和问题（参见1.7-1.11），而这些问题，有些很难通过文件服务器或者人为的管理来解决。因此，我建议，建立一套项目文件管理系统来取代直接操作文件服务器。使用该系统对项目的目录按需求进行分类管理，对文件的追加，修改等进行版本控制，权限控制，并发控制，建立一套完善的查询机制，有针对性的支持最高效的查询操作。同时支持文档的基线管理，文件备份，恢复，文件打包等等，通过设计该系统来实现自定义的功能，来满足实际项目的需要。
]]></description>
		<link>http://www.baqt.net/?p=422</link>
			</item>
	<item>
		<title>未来五年程序员应当具备的十项技能(转)</title>
		<description><![CDATA[作为一名程序员，如果你想在这个领域内继续向前进步或者在当前的经济形势下保持不被炒鱿鱼，那么你就决不应当自满自足，你需要继续学习。近日，著名IT评论员Justin James在他的博客中列出了未来五年程序员应当具备的十项技能，如果照此实践，你未来的工作前景一定一片光明。
当前的经济形势下，很多程序员将目光聚焦在短期内的工作形式上，但是你仍然要抽出时间和精力学习新的技能。以下是作为程序员应当即刻学习的十项技能，以确保在未来五年内你的简历上有真材实料。当然这个名单很难做到详尽而没有遗漏，有些领域没有涉及到（比如大型机开发者）。然而，对于一般的主流开发而言，你至少要学会以下十条中的七条，而且掌握的程度不是那种你在工作面试上能够夸夸其谈，而是真正能够用于实际开发。
1，三大主流开发体系之一(.NET, Java, PHP)
除非软件开发领域发生巨大的变革（这机率好比行星撞击地球），不然程序员至少需要知道三大开发系统中（.NET (VB.NET or C#), Java, PHP）的一种。而且仅仅了解核心语言是不够的，因为现在的项目拥有越来越多的不同功能，这也迫使程序员对相关的框架和库了解得更深。
2，富客户端应用（Rich Internet Applications）
无论你对Flash是爱还是恨，我们都不得不承认在过去的几年里Flash的发展壮大已远不仅是应用于动画制作。Flash以及Flex和AIR都具备越来越多的功能。而Flash的竞争者，如JavaFX和Silverlight等也在不断提升自身的性能和表现。让富互联网应用更加活跃的是，HTML 5正整合进所有种类的RIA功能，包括数据库连接、将W3C置于AJAX上等。在不远的将来，作为一名RIA领域的专家无疑将给你的简历添上浓重的一笔。
3，Web页面开发
Web开发恐怕在未来的很长时间内都是主流技术之一。许多程序员往往满足于构建后台、或者只是专注于框架基础而忽略了Web。但是越来越多的企业需要如何在交互代码（hand code）级别处理Web技术的人员，所以掌握JavaScript、CSS和HTML必将在未来五年内的职场上无往不胜。
4，Web服务端开发
REST 还是SOAP? JSON 还是XML?当然选择答案得依据项目来定，但如果一名程序员不会创建Web服务（尽管这个程序员也许不用写Web应用），那么他在工作岗位上一定倍感艰难。因为即便是过去那些被ODBC, COM或者 RPC主宰的领域现在也转到了一些形式的Web服务上了。
5，软性技能
一段时间以来就有这样一种趋势即：无论在企业内部还是企业外部提高IT的能见度。程序员被越来越多地带去参加非开发性会议来提供技术支持。例如，没有IT升级系统，首席财务官不可能改变收支细则；没有IT升级CRM工作流，运营总监不可能改变一个中心呼叫进程。同样，客户经常直接与开发团队沟通以确保他们的需求被完成。是否每个程序员都应该回去学习礼仪课来与别人更好的交往呢？那倒不必，但是程序员的确要提高待人接物的软性能力，以在职场上获得更大的价值。
6，一种动态或者函数式程序设计语言(Functional Programming Language)
类如Ruby, Python, F#和Groovy等的语言虽然不完全主流，但是语言内部包含的思想却是开发界的主流。比如，微软.NET中的LINQ系统就是函数式程序设计语言的一个直接派生。得益于Rails框架和Silverlight的发展，Ruby和Python语言在一些领域变得很热门。学习这样一门语言不仅丰富了你的简历，而且会开阔你的开发视野。我所遇到的顶级开发者几乎都曾在演讲中提到学习一门动态语言或者函数式程序设计语言的重要性，就我的个人经历而言，这确实很有用。
7，敏捷开发
当敏捷开发第一次冲击主流的开发意识时，我跟许多开发者一样持怀疑的观点。因为它抛弃了控制、标准等，看起来是一种完全与传统方法相悖的开发方法。但随着时间的发展，敏捷背后的思想被定义的越来越好，应用得也越来越棒。许多开发或者采用敏捷，或者在敏捷开发的实验阶段。尽管敏捷不是失败项目的万灵药，但它确实在软件开发中有一席之地。那些对敏捷有很好的理解并且有应用经历的开发者必将在未来五年内成为抢手货。
8，业务领域知识
开发团队越来越被看做是项目的合作者，这意味着了解该领域的开发者将对该项目的贡献更大。有了敏捷，开发者可以说我们可以在这儿很简单地增加这个功能，而这将让我们的产品更具价值。或者这个要求不符合我们日志显示的常用类型。由于越来越多的程序员反对必须了解该领域内的所有问题（实际上也不可能做到），所以不可否认的是越来越多的企业希望开发者起码了解该领域内的基础知识，越多越好。
9，质量控制
几年前的时候，很多企业和产品没有bug跟踪系统、没有版本控制和其他类似的工具，所写出的代码和产品都只是跟程序员和他所用的IDE有关。幸而开发领域有了新的、集成的工具如Microsoft Visual Studio Team System，而且产品、代码高质量及可用性的透明度提高，开源环境等，现在没有这种工具的企业已经越来越少稀少。开发者除了知道如何源代码控制、如何使用VM系统构建测试环境之外，还要做更多的质量控制工作，并具备很好的清洁意识来确保他与他的团队协调一致。那些将代码处存在个人硬盘中，没有记录代码变更、任务目录等的开发者，不但在传统的开发环境中不受欢迎，在敏捷的开发环境中也不受欢迎。
10，移动开发
在上世纪90年代末，Web开发一跃成为主流并且将原来传统的桌面应用开发边缘化。在2008，移动开发大肆进入人们的视野，而且至少在五年内移动开发都将是开发领域的重中之重。当然移动开发的方式有很多种，但无论你选择哪一种都将令你成为未来的抢手货。（译/王玉磊）
文章出处： http://news.csdn.net/a/20090408/210278.html
]]></description>
		<link>http://www.baqt.net/?p=412</link>
			</item>
</channel>
</rss>
