感 触 中 国 人 月

原创 2006年05月17日 20:14:00

       ——《人月神话》读后感

       在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践,影响着一代又一代的软件人员。即使是在20多年后的今天,我们的工作更自动化,计算机的“马力”更强劲,但书中依然有很多好的忠告。因此,我们每一个人都应该不是一遍的来读这本书。

内容综述

1.         焦油坑

       在“焦油坑”中,Brooks博士用史前史中巨兽们在焦油坑中垂死挣扎的场面来形容过去的几十年,告别了英雄时代的大型系统开发。虽然他们中的大多数开发出了可运行的系统,但只有极少数的项目符合了目标、进度和预算的要求。可是,就像那些强壮的巨兽们一样,在这些团队面前,表面上看起来没有任何一个单独的问题会导致困难,每一个问题都能解决,但是当它们相互纠缠和累积在一起的时候,团队的行动就会变得缓慢,最后一个接一个淹没在焦油坑中。

       在指出如何解决这些问题之前,Brooks博士首先分析了系统开发这个职业,以及充满在这个职业中的乐趣和苦恼。他认为,在系统开发中我们的目标不是程序,而是编程系统产品,一个是相同功能程序的成本的9倍的产物。而编程,是一个许多人痛苦挣扎的焦油坑,一种乐趣与苦恼共存的创造性活动。

2.         人月神话

       在众多的软件项目中,缺乏合理的进度安排是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大。导致这种灾难如此普遍的原因是:

l         我们对估算技术缺乏有效的研究,更严肃的说,它来自于编程人员的乐观主义:一切都将运作良好,每一项任务仅花费它所“应该”花费的时间。

l         我们采用的估算技术隐含的假设人和月可以互换,错误地将进度与工作量相互混淆。

l         由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地估算这项工作。

l         对进度缺少跟踪和监督。

l         当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。

3.         外科手术队伍

       对于很多年轻的软件项目经理而言,他们偏爱于组建小型精干的队伍。事实上,由于程序员之间生产率的差异,而且小型队伍减少了人员之间的协作沟通,使得这种队伍往往能够按照预期的进行运作,并将产生良好地效果。但是,对于真正意义上的大型系统,它太慢了。因此,对于大型系统,Harlan Mills建议大型项目的每一部分由一个团队解决,而该队伍以类似外科手术的方式组建。

       与传统的队伍不同,在外科手术团队中,外科医生和副手都了解所有的设计和全部的代码,确保了工作概念上的完整性。在出现观点上的差异时,由外科医生单方面统一,避免了队伍之间人员的讨论和妥协让步。另外,团队中人员职能的专业化分工是高效的关键,它使成员之间采用非常简单的交流模式称为可能。

4.         贵族专制、民主政治和系统设计

       Brooks博士主张在系统设计中,概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路,宁可省略一些不规则的特性和改进,也不提倡独立和无法整合的系统,哪怕它们其实包含着许多很好的设计。

       编程系统的目标是易用性,功能与理解上复杂程度的比值才是系统设计的最终测试标准。单是功能本身或者简洁都无法成为一个好的设计的评判标准。对于给定级别的功能,能用最简洁和直接的方式来指明事情的系统是最好的,而这种简洁和直白来自于概念的完整性,这要求设计必须由一个人,或者非常少数互有默契的人员来实现。

       对于非常大型的项目,将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。体系结构陈述的是发生了什么,而实现描述的是如何实现。体系结构同实现必须仔细地区分开来。

5.         画蛇添足

       为了将制定功能规格说明地责任从开发快速、成本低廉地产品地责任中分离出来,Brooks博士认为需要约束结构师地创造热情。

       实际情况中,与承包商的尽早交流和持续沟通能使结构师有较好的成本意识,以及使开发人员获得对设计的信心,并且不会混淆各自的责任分工。想要成功,结构师必须

l         牢记开发人员承担创造性和发明性的实现责任,所以他只能建议,而不能支配。

l         时刻准备着为所指定的说明建议一种实现的方法,同样准备接受其他任何可能达到目标的方法。

l         对上述的建议保持低调和不公开。

l         准备放弃坚持所作的建议改进。

6.         贯彻执行

手册或者书面规格说明书,是一个非常必要的工具,它是产品的外部规格说明,描述和规定了用户所见的每一个细节;同样的,它也是结构师主要的工作产物。规格说明书的风格必须清晰、完整和准确,为此手册的作者必须注意到自己的思路和语言,达到所需要的精确程度。形式化定义和记叙性定义都可以作为表达的标准。形式化定义是精确的,倾向完整性。记叙性文字可以表达结构性的原则,描述阶段上或层次上的结构,并提供实例。我们必须以一种作为标准,另一种作为辅助描述,并照此明确的进行划分。

设计实现,包括模拟仿真,可以充当一种体系结构的定义,但这种方法有一些严重的缺点。直接整合,则是一种强制推行软件的结构性标准的方法。

会议是一种非常有效的方式,任何人可以提出问题和修改意见。少数解决问题的方案会被传递给一个或多个结构师,详细的记录到书面变更建议说明书中。接着,会对详细的变更建议作出决策。会议的收获在于不仅可以解决决策上的问题,还可以使得决策更容易被接受,每个人对复杂约束和决策之间的相互关系有了更透彻的理解。

允许体系结构师对实现人员的询问做出电话应答解释是非常重要的,并且必须进行日志记录和整理发布。产品测试小组是项目经理最好的朋友,它是使设计得以贯彻执行的必要手段,同样也是需要尽早着手,与设计同时实施的重要环节。

7.         为什么巴别塔会失败

交流和交流的结果——组织,是成功的关键。交流和组织的技能需要管理者仔细考虑,相关经验的积累和能力的提高同软件技术本身一样重要。团队之间可以通过所有可能的途径进行交流,包括非正式途径、会议和工作手册。

项目工作手册不是独立的一篇文档,它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档必须都是该结构的一部分,我们需要尽早和仔细设计工作手册结构。工作手册的实时更新是至关重要的,同时每一个团队成员应该了解所有的材料。

团队组织的目标是为了减少必要的交流和协作量。为了减少交流,组织结构包括了人力划分和限定职责范围。

8.         胸有成竹

仅仅通过对编码部分时间的估计,然后乘以任务其他部分的相对系数,是无法得到对整项工作的精确估计的。构建独立小程序的数据不适用于编程系统项目。AronHarrOS/360的数据都证实,生产率会根据任务本身复杂度和困难程度表现出显著的差异。

9.         削足适履

除了运行时间以外,程序所占的内存空间也是主要开销。即便如此,花费在驻留程序所占内存上的金钱仍是物有所值的。规模本身并不是坏事,但不必要的规模是不可取的。

软件开发人员必须设定规模目标,控制规模,发明一些减少规模的方法。对项目经理而言,规模控制既是技术工作的一部分,也是管理工作的一部分。他必须研究用户和用户需求,以设置待开发系统的规模。接着,把这些系统划分为若干部分,并设定每个部分的规模目标。但是,项目经理应该注意的是,仅对核心程序设定规模目标是不够的,必须把所有方面的规模都编入预算。规模预算必须与分配的功能相关联,在指明模块大小的同时,确切定义模块的功能。在整个实现过程中,系统结构师必须保持持续的警觉,确保连贯的系统完整性。培养开发人员从系统整体出发,面向用户的态度是软件编程管理人员的最重要的职能。

为了取得良好的空间-时间折中,项目经理可以做两件事来帮助他的团队:一是确保他们在编程技能上得到培训,特别是在使用新语言或者新机器时。另外一种方法是认识到编程需要技术积累,需要开发很多公共单元构件。

精湛的技艺出自创造,精练、充分和快速的程序也是如此。技艺改进的结果往往是战略上的突破,而不仅仅是技巧上的提高。这种战略上的突破有时是一种新的算法,但更普遍的是来自数据或表的重新表达——这是程序的核心所在。

10.     提纲挈领

在堆积如山的文件资料中,少数文档是关键枢纽,每一件项目管理的工作都围绕着它们运转。这些文档是项目经理最重要的个人工具。书面记录决策是必要的,只有记录下来,分歧才会明朗,矛盾才会突出。文档能够作为同其他人的沟通渠道,还可以作为数据基础和检查列表。

项目经理的任务是制定计划,并实现计划。但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人员、项目内容、资金。这些少量的关键文档封装了项目经理大量的工作。通过遵循文档开展工作,项目经理能更清晰和快速的设定自己的方向。

11.     未雨绸缪

对于大多数项目,第一个开发的系统并不合用。它可能太慢、太大,而且难以使用,或者三者兼而有之。要解决所有的问题,除了重新开始以外,没有其他任何的办法——即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成,也可以一块块的完成。所有大型系统的经验都显示,这是必须完成的步骤。因此,为舍弃而计划,无论如何,你一定要这样做。

一旦认识到试验性的系统必须被构建和丢弃,具有变化思想的重新设计不可避免,那么,面对整个变化现象就是非常有用的。开发人员交付的是用户满意度,而不仅仅是有形的产品。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。于是,软件产品易于掌握的特性和不可见性,导致它的构建人员面临永恒的需求变更。因此,我们应当注意的是,并不是顾客所有的目标和需求变更必须、能够或者应该整合到设计中。目标上的一些变化无可避免,事先为它们做准备总比假设它们不会出现要好得多。

为变更计划软件产品的技术,包括细致的模块化、可扩展的函数、精确完整的模块间接口设计和完备得文档。另外,还可能会采用包括调用队列和表驱动得一些技术。最重要的措施是使用高级语言和自文档技术,以减少变更引起的错误。变更的阶段化是一种必要的技术。每个产品都应该有数字版本号,每个版本都应该有自己的日程表和冻结日期,在此之后得变更属于下一个版本的范畴。

现在软件编制小组失败的主要原因是管理控制的太少,而不是太多。设计人员不愿意为设计书写文档得原因,不仅仅是由于惰性或者时间压力。相反,他们通常不愿意提交尝试性得设计决策,再为它们进行辩解。为变更组建团队比为变更进行设计更加困难。当系统发生变化时,管理结构也需要进行调整。这意味着,只要管理人员和技术人才得天赋允许,老板必须对他们的能力培养给予极大的关注,使管理人员和技术人才具有互换性。组建外科手术队伍式的软件开发队伍,这整个观念是对上述问题得彻底冲击。

程序维护的一个基本问题是——缺陷修复总会以固定(20%-50%)的几率引进新的bug。所以整个过程是前进两步,后退一步。理论上,在每次修复之后,必须重新运行先前所有的测试用例,从而确保系统不会以更隐蔽的方式被破坏。实际情况中,回归测试必须接近上述理想情况,所以它的成本非常高。显然,使用能消除或者至少是能指明副作用得程序设计方法,会在维护成本上有很大的回报。同样,设计实现人员越少,接口越少,产生的错误也就越少。

LehmanBelady发现模块总数随着版本号的增加呈线性增长,但是受到影响的模块以版本号指数的级别增长。所有修改都倾向于破坏系统得架构,增加了系统得混乱程度。系统软件开发是减少混乱度的过程,所以它本身是处于亚稳态的。软件维护是提高混乱度的过程,即使是最熟练的软件维护工作,也只是放缓了系统退化到非稳态的进程。

12.     干将莫邪

项目经理应该制定一套策略,并为通用工具的开发分配资源。与此同时,他还必须意识到对专业工具的需求。项目经理必须考虑、计划、组织的工具首先是计算机设施。它需要硬件和使用安排策略;它需要操作系统,提供服务的方式必须明了;它需要语言,语言的使用方针必须明确;然后是实用程序、调试辅助程序、测试用例生成工具和处理文档的字处理系统。

13.     整体部分

防范bug的定义。细致的功能定义、仔细的规格说明、规范化的功能描述说明以及这些方法的实施,大大减少了系统中必须查找的bug的数量。在编写任何代码之前,规格说明必须提交给外部测试小组,以详细的检查说明的完整性和明确性。采用好的自上而下的设计可以从四个方面避免bug。结构化编程中,程序的控制结构仅由支配代码块的给定集合所组成,这种方法很好的避免了bug,是一种正确的思考方式。

系统调试花费的时间会比预料的更长,它的困难证明了需要一种完备系统化和可计划的方法。这些方法包括使用经过调试的构件单元、打建充分的测试平台、控制变更、一次添加一个构件、阶段化和定期变更。

14.     祸起萧墙

当人们听到某个项目的进度发生了灾难性偏离时,可能会认为项目一定是遭受了一系列重大灾难。然而,项目进度经常以一种难以察觉,但是残酷无情的方式慢慢落后。一天一天的进度落后是难以识别、不容易防范和难以弥补的。根据一个严格的进度表来控制大型项目的第一个步骤是制定进度表。进度表上的每一件事被称为“里程碑”,它们都有一个日期。里程碑的选择只有一个原则,那就是里程碑必须是具体的、特定的、可度量的事件,能够进行清晰定义。好的里程碑对团队来说实际上是一项服务,可以用来向项目经理提出合理要求的一项服务,而模糊的里程碑是难以处理的负担。当里程碑没有正确反映损失的时间,并对人们形成误导,以致事态无法挽回的时候,它会成为彻底碾碎小组士气的石磨。慢性进度偏离同样也是士气杀手。

对软件开发队伍来说,进取是非常重要的。进取提供了缓冲和储备,使开发队伍能够处理常规的灾祸,可以预计和防止小的灾祸。而对任务进行计算和对工作量进行度量,会对进取超前造成一些消极的影响。然而,并不是每一天的滞后都等于灾难,我们可以采用PERT或者关键路径技术来判断哪些偏离是关键的。

当项目经理发现自己的团队出现了计划偏离后,他必须采用两种方法把事实摆在老板面前。一种是减少角色冲突和鼓励状态共享,另一种是猛地拉开地毯。在第一种方法中,要求老板必须区别行动信息和状态信息。他必须规范自己,不对项目经理可以解决的问题做出反应,并且决不在检查状态报告的时候做安排。如果老板把会见、评审、会议明显标记为状态检查和问题-行动会议,并且控制自己的行为,这对整个过程会很有帮助。不论协作与否,拥有能了解状态真相的评审机制是必要的。PERT图以及频繁、明确的里程碑是这种评审的基础。对于大型项目,一个对里程碑报告进行维护的计划和控制小组是非常可贵的。

15.     另外一面

对于软件编程产品来说,程序向用户所呈现的面貌——文档,与提供给机器识别的内容同样重要。即使对于完全开发给自己使用的程序,描述性文字也是必需的,因为它们会被用户-作者遗忘。只是向软件工程师灌输文档的必要性以及优秀文档所应具有的特点很难取得好的效果,而把重点放在“如何做”上则效果很好。

16.     没有银弹

软件项目具有一些人狼的特性(至少在非技术经理看来),常常看似简单明了的东西,却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此,我们听到了近乎绝望的寻求银弹的呼唤,寻求一种可以使软件成本像计算机硬件成本一样降低的尚方宝剑。

在《没有银弹》这篇文章中,Brooks博士大胆的提出“在未来的十年里,无论是在技术上还是管理方法上,都看不出有任何突破性的进步,能够独自保证在十年内大幅度提高软件的生产率、可靠性和简洁性”。

所有软件活动包括根本任务——打造构成抽象软件实体的复杂概念结构,次要任务——使用编程语言表达这些抽象实体,在空间和时间限制内将它们映射成机器语言。虽然软件生产率在近年取得巨大的进步,但它们只是次要方面。除非次要任务在全部软件工作中占了9/10,否则即使全部次要任务的时间缩减到零,也不会带来生产率数量级上的提高。

软件开发中的困难也可分为根本的和次要的,其中根本问题中困难的是规格说明、设计和测试这些概念上的结构,而不是对概念进行表达和对实现逼真程度进行验证。高级语言、分时、统一编程环境是软件领域中取得的最富有成效的三次进步,但它们每一次解决的都是次要困难,不是本质属性,也不是主要困难。尽管如此,在现实的软件领域中,既有大量优秀的工作,也有不引人注意的平稳进步。所有针对软件开发过程中的次要困难的技术工作基本上都能表达成以下的生产率公式:任务时间=(频率)×(时间)。因此,我们必须考虑那些解决软件上必要困难的活动。购买和自行开发、需求精练和快速原型、增量开发、卓越的设计人员等都是针对概念上根本问题的颇具前途的方法,可以帮助我们准确的表达复杂概念结构。

17.     再论“没有银弹”

Brooks博士在《没有银弹》声称和断定,在近十年内,没有任何单独的软件工程进展可以使软件生产率有数量级的提高。没有神话般的解决方案这一论点,引发了众多议论,至今还在延续。他们大都同意《没有银弹》一文中的多数观点,但接着断定实际存在着杀死软件怪兽的银弹。而事实上,曾被强烈推崇的秘方并没有出现所声称的戏剧性的效果。

个人评论

       在《策划人语》中提到“几乎所有的人都认为,软件开发是年轻人的职业。程序员一边挥着汗水,辛苦地熬夜写代码,一边又对自己30岁以后的职业发展方向充满惶恐。……为什么中国的程序员总是在不断学习新的开发工具、钻研程序代码,而不能逐步提升自己的视野、思维和经验?”挥着汗水熬夜写代码、不断学习新的开发工具、钻研程序代码、对30岁后的职业发展方向充满惶恐,这些的确是中国当代软件人员的真实写照。但是,究竟是谁塑造了这一切?谁又该为此负责?

金山软件公司总裁雷军曾说过:“在印度,包括在美国,我见到的项目经理都是三、四十岁的人,他们‘越老越值钱’,有些人甚至拥有超过20年的行业经验。”其实,中国的项目经理又何尝不是三、四十岁,而且他们的工资也远远高于初级的程序员。可是,在大量年轻人充斥的中国软件行业,究竟又有多少人最后能够走到项目经理的位置呢?答案是,很少。

现在计算机的技术更新很快,即使是年轻人也会有力不从心的感觉,那些跟不上技术发展的“老”程序员逐渐被遗忘在角落里,渐渐被人们淡忘。而失去了昔日的光辉的程序员们,再也找不到自己的价值,只能默默选择离开,或者被公司辞退。与行业经验相比,中国的软件行业似乎更看重新鲜血液。

那为什么不提升自己的视野、思维和经验?正如我们上面所说的,在中国的软件行业里看重的是技术,而不是软件工程。无论是项目经理(特别是从开发人员走到项目经理的),还是对软件开发人员,他们对技术尤其痴迷,因为他们感觉那是权威的体现。每当你去应聘一家软件公司的时候,你被问的最多的是“.NET”、“J2EE”、“UML”。没有人会因为你读过《人月神话》而对你另眼青睐。因此,不是中国的软件人员偏爱于技术,而是环境塑造了这一切。

Brooks法则——“向进度落后的项目中增加人手,只会使进度更加落后。”——是我在阅读这本书时感触最深的。当项目进度落后时,一些项目经理们的第一反应就是增加人手,尤其是那些非技术型经理。这里,我们无意去贬低任何人,只是编程人员能经常从自己的工作经验中感受到这一点。即便如此,一些技术型项目经理在这种情况下也敢于冒险,其结果可想而知。在我看来,真正的了解人与月的关系,根据项目的实际情况,制定合理的进度,并对项目时间进行控制管理才是正确的。

纵观全书,《没有银弹》可以说是本书的精华所在。“在未来的十年里,无论是在技术上还是管理方法上,都看不出有任何突破性的进步,能够独自保证在十年内大幅度提高软件的生产率、可靠性和简洁性。”之所以出现这样的现象,是因为软件项目中的根本困难没有得以解决。虽然各种技术不断出现,甚至于我们经常惊叹于一些技术的设计与构思,但它们解决的都是次要问题。需求精练和快速原型、增量开发都是针对概念上根本问题的颇具前途的方法,可以帮助我们准确的表达复杂概念结构,但并没有带来突破性的进展。归根到底,我认为这是软件行业缺乏专业性的原因。软件行业里到处充满了只懂得软件技术的业余人员,谁都可以去开发生命攸关的软件。可是,“手中有个锤子未必是一个建筑师。”中国的软件行业要发展,首先需要将计算机应用与行业相结合。尽管我国现在的软件行业在这方面已经有了一些发展,如很多软件公司的开发是面向特定行业的,很多政府部门和企业也有自己的计算机部门,但是目前所做的还是远远不够。首先,虽然软件公司是面向行业的,但是由于软件人员的流动性很大,因而一个软件人员很难拥有特定行业的资深经历。其次,虽然很多政府部门和企业拥有自己的技术人才,但是他们没有充分发挥自己计算机知识与行业知识相结合的优势,他们应当在电子政务、电子商务和企业信息化的建设中起到举足轻重的作用。拥有行业知识与计算机知识相结合的复合人才,应该是政企今后发展的一个方向,它可以解决软件项目中需求获取困难的问题,从而减少软件项目中的风险。因此,我相信大量复合人才的出现将会成为真正的“银弹”。

【分享】梅津泰臣 三部曲《次强音》(Mezzo forte),《风筝》(A Kite),《黄色星星(Yellow Star)

梅津泰臣 三部曲发表于 2013 年 3 月 31 日 由 百世妖 “梅津泰臣三部曲”,是“梅津泰臣的三部曲分别是《次强音》(Mezzo forte),《风筝》(A Kite),《黄色星星(Yell...
  • wangzi867258173
  • wangzi867258173
  • 2015年08月14日 01:04
  • 48719

PAT 乙级 采花生 (模拟)

---------------------------------处女blog------------------------逃… 题目描述 鲁宾逊先生有一只宠物猴,名叫多多。这天,他们两个正沿着乡间...
  • qq_34761996
  • qq_34761996
  • 2017年04月10日 19:45
  • 176

NOI 1775:采药(C++) 动态规划

典型的01背包,动态规划问题 虽然AC了,但是还有有点不明白,为什么要加不选择物体的for循环(初步的想法是,有可能条件不满足调价物体,但是不应该是0,最少应该是【i-1】【j】的值) 参考:http...
  • v_xchen_v
  • v_xchen_v
  • 2017年04月06日 16:31
  • 413

web安全认证机制知多少

如今web服务随处可见,成千上万的web程序被部署到公网上供用户访问,有些系统只针对指定用户开放,属于安全级别较高的web应用,他们需要有一种认证机制以保护系统资源的安全,本文将探讨五种常用的认证机制...
  • wangyangzhizhou
  • wangyangzhizhou
  • 2016年05月07日 08:37
  • 14141

C#与Java基础语法初比较

1. C#命令输入和输出语法是:Console.ReadLine()和Console.WriteLine()(当然不换行的话就去掉Line,这些想必大家都知道,所以文章中只提供比较常用的)。 J...
  • kingmax54212008
  • kingmax54212008
  • 2015年11月03日 22:07
  • 567

《深度学习的艺术 - 采桐》读书笔记

/******************************* …… 虽然本书强调,用「提问、解码、操练、融合」的方法去做深度学习的尝试,但并不是提倡,对所有可学的材料,都以深度的方式去学。只因为...
  • dawn2034
  • dawn2034
  • 2015年08月23日 23:38
  • 439

乡下回忆:王子臣

乡下回忆:王子臣   终于想起周家村的一个人,是名老师,也是村里的医生,挺业余的那种医生。大家都称呼他王老师。乡下那两年半,我跟他的接触还是很多的,却总是记不起那人的名字。今天在蒙蒙细雨中却灵光一闪,...
  • tang803
  • tang803
  • 2017年01月07日 00:43
  • 219

黑龙江省五常农民有钱大买房子

黑龙江省五常农民有钱大买房子了 。    黑龙江省五常市以盛产大米而闻名,大米是当地的支柱产业,也让这里的农民富了起来。眼下的五常已经冰天雪地,忙活了一年,卖完了大米,这个时节的农民,腰包...
  • zzwu
  • zzwu
  • 2016年12月08日 15:46
  • 1060

Fast Mask-RCNN 配置及运行训练过程中踩坑(二)

Fast Mask-RCNN 配置及训练过程中踩坑及处理
  • Aimer_Chen
  • Aimer_Chen
  • 2017年11月21日 17:31
  • 384

做网站采集文章,采还是不采?

做网站采集文章,采还是不采?   做网站有一段时间了,自己做的也是小网站,小网站刚起步内容比较少,流量少,所以暂时只能靠采集生存,但是怎么样采集呢,采集有哪些好处,又有哪些坏处呢?世界是矛盾的,我们...
  • u012854850
  • u012854850
  • 2014年03月07日 08:46
  • 331
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:感 触 中 国 人 月
举报原因:
原因补充:

(最多只允许输入30个字)