﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>语源科技BlogJava-沈豫龙 的blog</title><link>http://www.blogjava.net/leosyl/</link><description /><language>zh-cn</language><lastBuildDate>Tue, 28 Apr 2026 18:57:32 GMT</lastBuildDate><pubDate>Tue, 28 Apr 2026 18:57:32 GMT</pubDate><ttl>60</ttl><item><title>[转]你浮燥吗？</title><link>http://www.blogjava.net/leosyl/archive/2006/08/23/65252.html</link><dc:creator>沈豫龙</dc:creator><author>沈豫龙</author><pubDate>Wed, 23 Aug 2006 04:52:00 GMT</pubDate><guid>http://www.blogjava.net/leosyl/archive/2006/08/23/65252.html</guid><wfw:comment>http://www.blogjava.net/leosyl/comments/65252.html</wfw:comment><comments>http://www.blogjava.net/leosyl/archive/2006/08/23/65252.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/leosyl/comments/commentRss/65252.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/leosyl/services/trackbacks/65252.html</trackback:ping><description><![CDATA[
		<font size="2">
				<span style="FONT-SIZE: 12px">本文转自Zee的专栏<br /><br />有人说80一代是尴尬的一代<br />大学，上吧，怎么这么没劲，不上，那前途更是无光，结果到了大学，玩吧。反正前后都不好走。<br />课不上，打游戏，睡觉，一个朋友说他们学校几个人比睡觉，除了去卫生间、吃饭（别人卖回来），结果一个同学一直睡了三天三夜。游戏更是玩疯了，我隔壁宿舍的一个同学，每天都坐在床上玩（电脑就在床边），饭没人买了，才逼着快速下楼买一次饭，被单从来没见洗，结果把学校的白墙搞成了深蓝色。<br /><br />人的本性是很随势的，看着别人怎么样，自己也就怎么样走，结果全都成了一个样子，于是怪这个社会，怎么怎么的坏，怎么怎么的堕落。怎么走到大学也算是知识分子了，知识分子怎么能没有思想？随着别人走下去，自己没有定力，不要乱怪。自觉的去厕所唱着国歌反省一下。<br />社会不欠80一代的什么，开放了，各种的思想都自然的会碰撞几次，你接受不了，那是你的能力问题。不是有这种说话吗？国外的思想进入国内的宗旨是：用尽一切办法让年轻人失去他们的信仰（朋友和我说的，只深记得这一句）。人家让你失去就失去了？太容易动摇是思想的问题。搞几个色情片，就把年轻一代给害成这个样子？<br /><br />我也浮燥过的。在电脑前面坐着，不知道干什么，狂点刷新，点了一个小时。<br /><br />不管你做过什么，之前不知道，做错了事，也是可以理解的，毕竟年轻。可是之后总要想一想吧，这一段时间，你干过什么？杨振宁年轻的时候还问过自己：杨振宁，你现在在做什么？我们为什么不能问问？咱不求能干成什么大事业，总要活得明白吧。活不明白，就在阳光下白逛了一圈。<br /><br />工作，每个人工作都是有闲有忙的时候，看过一个帖子，说你们工作闲的时候都在干什么？这话问的，好像别人都是充实的，只有自己是空虚的。如果你这样想，那你会一直空虚下去，自己找不到目标，要到别人的目标里找找？你不知道做什么的话，就打游戏呀；你不敢打游戏，你就看技术文档；你不想看技术文档，你可以看看小说；你再不想看小说，你就给点时间反省自己也是好事。你要是觉得这样多浪费生活，你就用脑子自己左脑和右脑下棋，练出来以后好用。如果像我一样没有这种能力，就好好的趴一会，休息总是为了更好的活着，不是浪费生命。<br />再说找资料或者软件，有人闲着没事（不包括对电脑一无所知的人），到群里就问人要东西，google,百度一搜索一堆的东西，也是出来就问要。狂叫了半个小时，结果没人理他，他就大声呼吁：社会冷漠呀。自己回家躲到被子里好好想想。别一张嘴就是社会的错。不过是自己懒，出来浪费别人的时间。<br /><br />学习，看了一个小时的书就很受伤很受伤的样子，手册没看完，问题比手册还长。你不安下心来好好的看看，实践几次，再出来问点稍有水平的东西。要是你真的没心思看下去（谁都有谁的事情），那就在不会的时候先去找找资料，网络上找不出来的资料，也应该算是难的了。<br /><br /><br />不管是学习和工作，都是要有定力的，不要看着别人做什么自己做什么，没有主见。<br />切忌：浮燥。<br /><br /><br />希望所有还没有清醒认识自己位置的人，冷静一点。</span>
		</font>
		<font size="2">
				<span style="FONT-FAMILY: 宋体; LETTER-SPACING: 1pt">
						<br />
						<br />
				</span>
		</font>
<img src ="http://www.blogjava.net/leosyl/aggbug/65252.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/leosyl/" target="_blank">沈豫龙</a> 2006-08-23 12:52 <a href="http://www.blogjava.net/leosyl/archive/2006/08/23/65252.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>抽象程度思考</title><link>http://www.blogjava.net/leosyl/archive/2006/08/22/65146.html</link><dc:creator>沈豫龙</dc:creator><author>沈豫龙</author><pubDate>Tue, 22 Aug 2006 12:21:00 GMT</pubDate><guid>http://www.blogjava.net/leosyl/archive/2006/08/22/65146.html</guid><wfw:comment>http://www.blogjava.net/leosyl/comments/65146.html</wfw:comment><comments>http://www.blogjava.net/leosyl/archive/2006/08/22/65146.html#Feedback</comments><slash:comments>6</slash:comments><wfw:commentRss>http://www.blogjava.net/leosyl/comments/commentRss/65146.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/leosyl/services/trackbacks/65146.html</trackback:ping><description><![CDATA[
		<p>
				<font size="2">“软件设计的重点在于抽象”，不记得这句话是哪位说的了，我想改正一下：“保证软件灵活性设计的重点是抽象”，由此可知，抽象的作用是“保证软件的灵活性设计”。越来越多的语言、平台构建在OO思想之上，这充分说明了OO的正确性。OO，一种思想，一种谈到软件设计时必须涉及的思想，越来越多的人开始追捧它，当然，我也是其中之一。有了它，软件设计可以提升到一个“美”的境界；有了它，软件的可读性、可维护性、灵活性、可扩展性等等一大堆的“性”得到了很大的提高。为什么会这样？因为面向对象思想把软件跟现实更紧密地联系了起来，便得一些现实物理世界中的思想可以很容易的运用到软件中去。这几年，“设计模式”、“架构”等等一系列的名词越来越受到人们的关注。所有这些东西，其实就是为了实现一个抽象层次的编程，以保证软件的灵活性。</font>
		</p>
		<p>
				<font size="2">那什么是抽象？引用一位网友的话：“抽象就是有选择的忽略”，中国有句真理，叫“太极生两仪，两仪生四象，四象生八卦，八卦生万物”。从太极到万物，这种金字塔式的结构在复杂的软件工程中也是存在的，越接近金字塔的顶端，越要有选择的忽略掉更多的东西，从而具有更高的抽象程度。举个例子，两个功能A、B都是实现对数据的增删改，A是针对“客户”的，B是针对“产品”的，我们可以做一个增删改服务或者容器之类的东西来支持所有的增删改功能，A、B功能代码只用对使用这些服务然后再实现一些各自特殊的东西就可以了。这样做就把“增删改逻辑”给抽象了出来。再比如说O/R映射工具，它其实就是把数据操作抽象了出来。“抽象”的反义词应该是“具体”，我们可以把抽象理解为活的，具体理解为死的。各个具体的事物之间肯定会有重复，比如男人和女人都会走路，都会吃饭；比如你没有使用O/R映射工具的数据层的各个类都要实现一些相同的逻辑。软件设计中有一个原则：“Don't  Repeat”，就是不要重复。理想状态下，一个系统的任何代码、逻缉、概念在这个系统中都是唯一的，这样的系统肯定是非常灵活，因为“抽象”对应“活”。唯一性很容易保证，但是逻缉、概念的唯一性就很难保证，应该说是根本保证不了，概念这东西抽象到最上层什么都没有了。什么事情都有个度，只能说是软件的灵活性会随抽象程度的提高而提高。</font>
		</p>
		<p>
				<font size="2">这么说，是不是就意味着抽象程度越高越好？不是！刚才说了，任何事物抽象到最上层就是叫“事物”，还从哪来软件？一些书目中或明或暗地提到软件设计肯定有个最好的抽象程度，而且我们应该去努力达到这个抽象程度。不错，说得很对。但是，项目与项目之间是不同的，不存在适用于所有项目的最好抽象程度。</font>
				<font size="2">我的一个同事给我说过一句话：“软件项目的成功标志是什么？有三点：客户满意，公司满意，员工满意”。客户怎么满意？软件按照预算工期、成本完成，并为为他们创造价值；公司怎么满意？软件按照预算工期、成本完成，并为公司创造利益；员工怎么满意？软件按照预算工期、成本完成，开发过程顺利，自已的利益得到保证。得到的结论就是软件项目顺利的按照预算工期、成本完成，就算是成功了。运用抽象的最终目的肯定是促使项目成功，并不是让你搞“科研”。一个项目的所有因素决定了这个项目最好的抽象程度，项目经理、架构师需要反复思考，软件设计时究竟抽象到什么程度最好？这肯定要根据现有的资源（开发人员、工具等）来确定，如果过于抽象，你水平到位，可以理解，那么下面的开发人员呢？你必须要考虑培训成本、沟通成本，过于抽象，会延长工期，甚至让项目遥遥无期。<br /><br />说了这么多，并没有给出一套权衡的方法，在下实在水平有限，其实在自已带领的项目中也并没有把这些东西把握得很好，希望认真思考过这个问题的人能留下你的只言片语。</font>
		</p>
<img src ="http://www.blogjava.net/leosyl/aggbug/65146.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/leosyl/" target="_blank">沈豫龙</a> 2006-08-22 20:21 <a href="http://www.blogjava.net/leosyl/archive/2006/08/22/65146.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>项目修复－把有麻烦的项目带向成功</title><link>http://www.blogjava.net/leosyl/archive/2006/08/22/65138.html</link><dc:creator>沈豫龙</dc:creator><author>沈豫龙</author><pubDate>Tue, 22 Aug 2006 11:36:00 GMT</pubDate><guid>http://www.blogjava.net/leosyl/archive/2006/08/22/65138.html</guid><wfw:comment>http://www.blogjava.net/leosyl/comments/65138.html</wfw:comment><comments>http://www.blogjava.net/leosyl/archive/2006/08/22/65138.html#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.blogjava.net/leosyl/comments/commentRss/65138.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/leosyl/services/trackbacks/65138.html</trackback:ping><description><![CDATA[
		<font size="2">
				<font face="Verdana">
						<strong>
								<font size="3">
										<font face="Garamond">定义有麻烦的项目</font>
										<br />
								</font>
						</strong>
				</font>
				<br />首先，我们来定义一下什么叫有麻烦的项目，它们一般具有以下特征：<br />1、项目表面上已经进入后期，但是没有人能说出项目结束时间。<br />2、产品漏洞百出。<br />3、管理层已经无法控制进度，制定的进度计划没有半点准确性。<br />4、开发人员日夜加班，效率低下。<br />5、项目小组的</font>
		<font size="2">
				<span style="FONT-FAMILY: 宋体; LETTER-SPACING: 1pt">士气极度低落，失去了工作的激情。<br /><br /><br />像这样有麻烦的项目在行业内普遍存在，如果不采取一些措施来修复的话，项目注定会失败，什么是失败？失败项目的成本、工期远远超过估算，甚至项目被取消。作为项目经理，项目的负责人，我们有什么方法可以把这些有麻烦的项目拉向正轨呢？本人前一段时间亲身经历过一个像这样的有麻烦的项目，读过《快速软件开发》一书后，其中的“项目修复”一节使我受益非浅，成功的把项目拉向了正轨，本文在参考《快速软件开发》一书的基础上介绍一些实用的项目修复方案。<br /><br /><br /><font style="BACKGROUND-COLOR: #ffffff" size="3"><strong>修复项目<br /></strong></font><br /><br />修复项目有三个最基本指导思想：<br />1、筛选需求，缩减项目规模。<br />2、注重短期的过程改善。<br />3、面对现实，放弃原计划，着手制定新的计划。<br /><br /></span>
				<span style="FONT-FAMILY: 宋体; LETTER-SPACING: 1pt">对于一个有麻烦</span>
		</font>
		<font size="2">
				<span style="FONT-FAMILY: 宋体; LETTER-SPACING: 1pt">项目，很多人都还把注意力放在如何赶上原计划上，这样的项目，最重要的是怎么完成，完成！不要再幻想出现什么转机，项目已经有了麻烦，和原计划已经有了出入，所以，我们应该面对现实，把当前的事情做好。<br />如果你想改变项目的现状的话，动作一定要大一点，小打小闹的改变不足以改变现状，小打小闹在公司高层眼里意味着什么？意味着你并没有什么办法来修复项目。<br /><br /><br />下面详细说明修复项目的措施：<br /><br /><br /><strong>第一步要做的<br /><br /></strong><br />1、<strong>分析自已的处境</strong><br /><br /><br />评估一下项目的最后期限到底有多重要，或许项目本身就不存在硬性的完成期限，这样的话，你就不必担心项目修复是否成功了。还有，有这个时候，公司上层或者是客户为了避免项目严重延期，会和你商讨一些功能上的取舍。<br /><br /><br />2、<strong>客观分析<br /></strong><br /><br />为了在现有的基础上成功，项目组需要做什么？公司上层需要做什么？客户需要做什么？过去的都已经过去了，关键要着眼于现在。<br /><br /><br />3、<strong>自已要做好项目修复的准备</strong><br />如果你的项目处于修复状态下，而且落后的不是一点半点。那么你要意识到你的项目已经支离破碎了，必须有一些大的举动来挽救，让所有人都知道要对项目采取一些措施来修复。<br /><br /><br />4、<strong>争取多方意见</strong><br />　<br />询问一下你的开发组、你的其它同事、你的领导等所有了解项目的人，有什么方法可以使项目走向正轨。<br /><br /><br />5、<strong>面对现实<br /><br /></strong><br />有麻烦的项目组需要一个客观的、现实的项目经理。项目修复刚开始，你不要再向任何人承诺项目的完成日期，不要再陷入：“迫于压力的承诺－&gt;更大的进度压力-&gt;更多的错误-&gt;更加偏离计划”这样的死循环。你应该用几天的时间去认真分析一下项目，再给出一个客观、准确的计划。<br /><br /><br /><br /><br /><br />影响项目成本、进度的四大因素：人员、过程、产品（功能集）、技术。在项目后期，在技术这一因素上已经没有多大的改进余地。我们在此讨论针对其它三个因素的改进措施。<br /><br /><br /><strong>人员<br /><br /><br /></strong>人员是影响项目进度最重要的因素，我们应该在这个因素上下最大的功夫。<br /><br /><br /><br />1、<strong>采取一切措施来恢复开发人员的士气<br /></strong></span>兵战者，求胜于势，恢复开发人员士气对于项目修复的成败起着决定性的作用。恢复开发人员士气的最佳方式是做一件很明显的事情让他们知道公司已经把他们放在了首位，比如说，完成任务可以提前回家，在不影响进度的前提下允许他们请假等等，当开发人员意识到自已受到了重视，项目组士气自然会得到提升，提升士气的方法很多，可以根据实际情况来选择恢复士气的方法，其实有时候领导的一句话就足以恢复整个项目组的士气。<br /><br />2、<strong>消除重大的人员问题<br /></strong>如果你觉得项目有一位有问题（不合作，难以沟通等）的员工，那么就请勇敢的面对这个现实。即使他现在起着关键性的作用，也要毫不犹豫的撤掉他，这些的员工对项目组士气的影响要大于他在技术上的贡献。<br /><br />3、<strong>增加新成员要谨慎<br /></strong>虽然有一句话叫作：“向一个已经延误工期的项目上增加新成员无异于火上浇油”。但是如果能把项目组的任务分解到新成员并不影响原有开发人员的话，就不存在“浇油”的问题。不过你要考虑到新成员很可能用8小时的时间去完成原有开发人员用1小时所能完成的任务，这样的情况出现后，你是否能维持与管理层的关系，因为管理层极可能不会容忍一个人用8小时的时间去完成1小时的工作。如果你无法妥善处理这样的后果的话，那么就不要增加新的人员。<br /><br />4、<strong>充分利用开发人员的时间<br /></strong>在项目修复模式下，你要尽可能的充分利用现在开发人员的时间，因为他们已经对这个项目非常熟悉。打算增加新开员的成本，还不如用在提高现有开发人员的效率上。<br /><br />5、<strong>观察开发人员的节奏<br /></strong>千万不要让开发人员陷入“进度压力—更多的缺陷－更多的工作量－更大的进度压力”这样的循环里面，给他们足够的时间，让他们能考虑一下质量问题，这样的话进度就自然而然的加快。<br /><br /><br /><br /><strong>过程<br /></strong><br />虽然是人员是影响项目进度的最为重要的因素，但是如果想成功修复项目的话，用心整理一下过程也是必需的。<br /><br />1、<strong>修复支离破碎的过程<br /></strong><br />项目一遇到麻烦，大家通常都知道是开发过程哪一个环节出现了问题，其实，出问题的环节一定是忽略了软件开发最基本的东西。<br /><br />如果缺陷管理困难，就搭建一个缺陷管理系统；如果开发人员得不到及时的任务分配，那么就放更多的精力于各开发人员的任务完成状态上，可能你做更多的工作以保证任务的及时分配；如果开发人员的代码质量总是难以保证，那么就加入代码审核过程。<br /><br />2、<strong>创建详细的小型里程碑<br /></strong><br />在项目修复模式下，一定要建立一个项目跟踪机制，以便于实时了解项目的状态。<br /><br />小型里程碑可以让你每天都能看到项目进度是否在按着计划进行。小型里程碑有三个特点：1)小型性2)二元性3)彻底性。小型性指每个里程碑必须在一两天之内可以完成；二元性是指里程碑要么就完成，要么就没有完成，不存在“差不多完成”、“完成了90%”之类的情况；彻底性是指当你完成了最后一个里程碑时，项目也就完成了，不存在你所建立的进度表之外任务，如果还有其它任务，那么就把它加进来。<br /><br />创建一些没有太大意义的小型里程碑有助于提高项目组的士气，人都是这样，快速完成一个任务心里总会感到愉快，即使这个任务不是那么重要。<br /><br />在项目初期是不适使创建小型里程碑的，因为那个时候你对所要做的工作了解的详细程序还不够。但是项目修复模式下，每个人都清楚的知道项目还剩下些什么。<br /><br />3、<strong>依据里程碑的完成来安排进度</strong><br /><br />为每一个里程碑设立完成日期。不要再打加班的主意，完成日期必须是在没有考虑加班的情况下设立的。每一天任务的完成保证了，才有每一个月的保证，最后也会保证项目的成功。<br /><br />4、<strong>细致的跟踪项目进展情况</strong><br /><br />创建了小型里程碑，但如果不跟踪实际进度的话，就没有一点儿实际意义。每天都要检查里程碑的完成情况，一定要确保标记为“已完成”的里程碑是百分百完成了，如果把“99%完成”的里程碑标记为已完成，就会打乱你的计划，你所能对项目控制的程度也会越来越弱。<br /><br />绝对不能让开发人员在小型里程碑进度上偏离正轨，如果误了里程碑，并不加以改正，项目很容易偏离正轨。晚了1天的任务有可能会晚2天，晚2天就会晚3天，接下来项目实际进度就和计划完成脱节了。如果一个开发人员在里程碑上落后了，就让他当天加一下班，以赶上进度。如果是计划制定的有问题，那就要及时的修正它。<br /><br />5、<strong>记录延误里程碑的原因<br /></strong><br />如果一个里程碑延误了，一定要延误原因记下来，这样可以帮你发现潜在的问题。<br /><br />6、<strong>短期后修正<br /></strong><br />每1、2周都要对计划的里程碑进行修正，如果完成开发人员用5天的时间完成了3天的任务，而且没有可以改进方法的话，那么就把剩下的工作量乘以5/3，千万不要幻想着你能在以后的时间里把以前落下的任务补回来。<br /><br />7、<strong>在得出有意义的进度前不要固守着某一个<br /></strong><br />在计划/进度表没有达到非常准确的情况下，不要急着把它交给领导过目，一个良好的进度/计划肯定是在从制定到跟踪，从跟踪到修正，再跟踪、再修正这样的循环中得出的。<br /><br />8、<strong>勤快的进行风险管理<br /></strong><br /><br /><br /><strong>产品（功能集）</strong><br /><br />产品的功能没有管理好，那么项目修复就是不可能的<br /><br />1、<strong>稳定需求<br /></strong><br />在项目修复模式下，首先稳定需求是最为重要的任务，如果在这个时候需求还是频繁化的话，那么你就不用考虑其它修复手段了，花时间去稳定它。很多项目都是在后期还不确定究竟要完成哪些功能，这样的项目注定是要失败的。<br /><br />2、<strong>修正功能集<br /></strong><br />毫不犹豫的把那些优先级较低的功能、特性剔除掉，一定要根据优先级来完成任务。<br /><br />3、<strong>去除没有用的垃圾<br /></strong><br />如果一个模块质量极其低下，改了又改，bug还是不断涌现，那么就从把这个模块的代码去除掉，重新设计它，不要让一堆无法控制的缺陷把项目拖死。<br /><br />4、<strong>持续降低缺陷数目<br /></strong><br />功能、特性可以权衡，质量是不可以权衡的，项目管理三角形：成本、进度、功能。三角形里并没有质量这一角，不要为了追赶进度而在质量上做手脚。<br /><br />参考书目：<br />《快速软件开发－有效控制与完成进度计划》   电子工业出版社<br /><br /><br /></font>
<img src ="http://www.blogjava.net/leosyl/aggbug/65138.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/leosyl/" target="_blank">沈豫龙</a> 2006-08-22 19:36 <a href="http://www.blogjava.net/leosyl/archive/2006/08/22/65138.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>