企业网站备案好不好,图标使用wordpress,开发公司工程项目经理岗位职责及工作内容,四川省城乡建设网查询[转贴] 段先德 2006-5-20 似乎作为一个软件开发者#xff0c;就注定要背着沉重的行囊#xff0c;穿行在茂密的热带丛林里#xff0c;酷热#xff0c;没有风#xff0c;只有腐烂的植被、浓浓的瘴气、不时从肩膀上爬过的毒蜘蛛和从脚背上“嗖”地窜过的毒蛇。汗流浃背…[转贴] 段先德 2006-5-20 似乎作为一个软件开发者就注定要背着沉重的行囊穿行在茂密的热带丛林里酷热没有风只有腐烂的植被、浓浓的瘴气、不时从肩膀上爬过的毒蜘蛛和从脚背上“嗖”地窜过的毒蛇。汗流浃背疲惫不堪却不能休息片刻——因为这是一个软件开发的混乱的时代 充分的前期需求分析严格的开发流程控制严密的后期测试这些都做到了啊可是为什么软件还是有bug特别是用户频繁地提出新的要求软件要不断地修改每一次修改都胆战心惊几近崩溃这到底是为什么神啊到底要怎么做才能获得好的软件设计啊 人们一直都没有停止思考如何能够获得好的软件设计。软件工程风行了几十年“没有银弹”的咒语还没有解除。人们不禁要抛弃所有的“软件工程”带来的规制回到软件开发的源头寻找答案。如下就是笔者看到的火烧云的形状像猫像虎任凭端详。 1、要有技艺高超的开发者 软件是人的思维活动的产物软件开发首先需要的是人的创造性。就如同其他一切人类创作一样人是占据核心地位的。恐怕再过一百年也没有哪个自动化的工序可以代替金庸先生的妙笔写出《笑傲江湖》这样经典的小说。所以当前软件工程企图用其眼花缭乱的流程控制来达到“软件工厂”的目的是方向性的错误。人只有人技艺高超的开发者才是产生好的软件设计的核心因素。 技艺高超的开发者应当有丰富的软件开发经验。有了丰富的软件开发经验才会培养出对软件设计中的各种“坏味道”的敏锐的嗅觉才能熟练地绕过软件设计中的种种陷阱有了丰富的软件开发经验才会对各种软件体系结构模式烂熟于胸才能运用成熟的设计模式解决那些普遍的设计问题有了丰富的软件开发经验才会对各种语言、工具的特长和限制了如指掌才能选择针对当前问题的最合适的编程语言和设计工具有了丰富的软件开发经验才会对各种平台和环境的特性和差异有所了解才能在设计的过程中最大程度地利用平台和环境的特性并可充分考虑到程序的可移植性。 技艺高超的开发者应当有专业的领域知识。软件总是服务于某一领域的应用各个领域的专业特性不同使得软件开发也产生了许多分支。从事某一专业领域的软件开发必然要对该领域的专业知识有深入的了解才能在软件设计中正确地把握对概念的抽象。随着软件的复杂性的转移领域建模越来越受到重视。在此强烈推荐《领域驱动设计——软件核心复杂性应对之道》Eric Evans著陈大峰等译清华大学出版社出版一书。 技艺高超的开发者应当有求真务实的技术作风。在这个浮躁、虚华、官僚化的社会里“求真务实”显得太可贵这也是对开发者提出的很高的要求。求真务实的技术作风就要求开发者不要盲从技术风潮软件开发的技术发展飞快也产生了不同技术流派各个流派都想扩大自己的影响这时候就需要开发者自己去识破各种幌子吸收真正对软件开发有所助益的好方法求真务实的技术作风还要求开发者实事求是地看待各种非技术机制对软件开发的影响看看这些机制是否对软件设计质量的提高有帮助有则批判地采纳无则无情地抛弃不要抱有“这个流程是某某认证所必须的且其他很多公司都这样做了所以它一定有它的道理”的想法这些目前看不到好处的东西不要指望将来给你带来什么好处求真务实的技术作风更要求开发者抛弃官僚主义作风和自大的姿态在技术面前人人平等以开阔的胸襟对待不同技术观点和反对者友好地同其他人合作以把软件设计做好为要旨。 技艺高超的开发者的成长需要长期的磨练代价很大。且人的因素确实是一个很不确定流动性很大的因素软件工程减少不确定因素的初衷是好的但是人的地位毕竟不可替代。“软件蓝领”是又一个软件工程产生的畸形儿软件工程宣称只要几个月的短期训练就可以胜任软件开发的工作。真是可悲 2、要有合理的软件过程 软件开发早已不是单兵作战而是一项有组织的集体活动但是跟修水库和建筑施工等“工程活动”不同软件开发需要集中团队中每个人的智慧。软件开发的过程中最终要达到的目标在最初往往并不十分清楚所以需要不断地去探索。软件开发的核心复杂性在于对应用领域的抽象与建模很多时候软件开发也是一个建立模型、验证模型、改进模型的一个不断迭代的过程所以一个合理的软件过程至关重要。 一个合理的软件过程应该能获取准确的需求。软件需求据行业领域和客户的要求不同而差异很大没有一个通行的模板可以套用那么就需要对行业领域的充分研究以及与客户的充分沟通来获取到真实的需求。客户把自己的需求表达清楚本身就是一件困难的事开发者理解用户的表达又增添了困难语言会产生偏差我们注重点的不同也会产生偏差所以往往我们“按照”客户的需求做出来的东西并不是客户真正想要的东西。再者很多用户的需求随着时势的变化会发生改变这都是很正常的。因此我们不能“苛求”一开始就能全盘获得准确的需求要想获得准确的需求就要保持一直与客户的沟通允许在我们的开发的过程中客户提出变化随时表达和强调他们真正想要的“软件”只有这样我们的开发才不会偏离客户的初衷一切设计才有意义。 因此合理的软件过程应该将客户需求的表达穿插在软件过程的全部环节中而不是指望在开始设计之前跟客户订好需求的“契约”就以为万事大吉。 一个合理的软件过程应该快速的反馈软件构思。软件设计是开发者思维活动的产物这种思维是建立在领域建模和软件构建的基础上的。建模的过程中需要开发者极大地发挥自主性和创造性不同的人在不同的知识背景下思考的方式会不一样所以设计过程迫切需要验证当前的思路是否正确需要一些反馈信息来证明当前的模型是准确地满足了某一需求。并且构思是一个不确定、不严密的脑力活动对开发者的经验有很强的依赖性而经验的运用往往会产生不知不觉的错误或疏漏所以需要及时的反馈来验证构思的正确性从而避免“错之毫厘谬以千里”。 快速的反馈是保证设计构思不会“离题”的必要手段所以合理的软件过程需要提供一个快速反馈的机制而不是一味地想象直到如梦初醒。 一个合理的软件过程应该保障团队成员的沟通顺畅。团队成员合作开发共同完成一个软件系统成员各自的思路之间是有“缝隙”的要将每个人的设计联结成一个整体的设计就需要充分的沟通来填补这些“缝隙”只有充分的沟通才能保证各个成员各自完成的部分组合起来的协调性才能避免牛头对个马嘴。Brooks在其《人月神话》中曾描述过一种情况往一个效率低下的软件开发团队中增加人员不但不能提升其开发效率反而会降低其开发效率。这说明团队成员越少越好同时也说明团队成员之间沟通的时间耗费是巨大的。团队成员交流的主要是对系统的理解和自己对模块接口的划分因此需要的是直接的“对话”是随时展开的是“辩论”是立竿见影的对设计者思路的冲击这样才高效。而多余的文档、图表、流程或任何其他形式的沟通媒介不仅耗费了开发者宝贵的时间更可能引起传递“信号”的失真带来歧义。 一个合理的软件过程应该提倡“Work smart, not just hard.”笔者借用这种说法其本义可以参考http://www.jorydesjardins.com/pause/2006/05/what_does_that__1.html软件设计是一项智力劳动其核心成果来自开发者发挥自己的聪明才智和创造性。google就是一个很好的例子。开发者的创造性来自对行业领域的钻研和领域以外的借鉴所以开发者应当有丰富的领域外的知识的涉猎在行业领域之外也有多姿多彩的阅历和思考素材发展自己的个性。这样思路才不会呆板思维才更活跃。 合理的软件过程应该给开发者营造一个轻松的工作氛围允许开发者的个性化才能让开发者身心愉悦地投入到软件设计的虚空间中去激发设计创意。 回头审视一下传统的“软件工程”过程。在软件工程中十分强调“流程”和纪律追求软件过程越是“自动化”越好。希望需求是被稳固下来事先就做好可以作为“原料”输入到一连贯相互独立“工序”中通过控制开发人员在每个工序中的作为使得产品严格按照预先期望的模子生产出来希望开发者都安分守己地努力所有的沟通和交流最好都文档化以分清责任减少争论同时以文档为驱动规规矩矩按部就班地做上一个流程的文档给自己规定好的事情。呜呜正在焦油坑里挣扎的猛犸象还少么 3、要面向代码 再强调一遍源代码就是设计 即使在软件工程中这一点也是不可否认的虽然不被承认。很多人认为软件设计是指编码之前的“概要设计”和“详细设计”代码只是“实现”只是个体力活儿。但是代码却是软件设计最真实、准确、有价值的表现。在编码前再好的构思也只是“预设计”是没有被验证、没有被认可、没有被赋予现实意义的空想。“预设计”再好也并不是设计在所谓“概要设计”和“详细设计”阶段通常不乏玲珑的构思但是由于轻视了代码而去重视那些只是临时使用一下的设计文档往往能“化神奇为腐朽”况且没有在代码中被验证与整个系统的协调性的神奇构思又有什么值得称道的呢 所以我们的设计应该面向代码而不是轻视它。有什么好的设计构思最好赶紧在代码上表达出来并很快地验证这个构思是正确的是与整个系统相容的而不是把很多构思都堆积在“设计文档”中掩盖了矛盾和错误并在编码的时候把它们放大。 设计面向代码应该从测试用例出发。比较好的方法是采用“测试驱动开发”TDD源自《测试驱动开发》Kent Beck著的方法直接面对需求把需求用测试用例准确地表达出来所有的设计都从测试用例出发这样我们的设计就能够更贴近真实的需求直接将需求和代码联系起来减少了中间所有的不确定的环节。明确的需求都是可以测试的编写测试用例的过程其实是一个促使开发者对需求真正认识的过程这也是寻找好的软件设计的出发点实在不应该忽略或轻视。并且有了准确的测试用例做保障我们在改进过程中随时都可以验证所做的修改的正确性。 设计面向代码要求在变化中保持代码“健康”。代码是在开发的过程中不停地被改变的但是随时要保持代码的“健康”。这种改变不是往旧墙上刷新粉整个过程也不是“code and fix”特别是软件开发的后期最好不要有显眼的“补丁”而应该针对任何变化最好把所做的修改或加强融入到现有的设计中使之和谐不留痕迹。至于什么样的代码才是“健康”的我想这是一个值得展开讨论的话题。 设计面向代码切忌盲目复用。软件开发为了提高资源利用率和开发效率希望能够在新的应用中运用已有的设计成果最大限度地实现软件复用这种愿望可以理解但复用一定是有条件有限度的。复用别人现成的代码天然受到别人设计的制约要想复用首先要充分了解别人的设计特别考察它的“通用性”由于不是为我们的应用定制的所以我们的设计要迁就这种“通用性”这种迁就是相当有风险的很可能使我们的设计变得僵硬。不记得哪位高人曾经说过“复用只是神话”我觉得是很有道理的采用别人的代码的当时是省心省力但是后期的维护似乎还有漫长的痛苦等着你。再者应用是有差异的哪怕相同的应用削足适履而不是根据脚的尺寸去做鞋是不可取的。 4、要重构 不知道有没有特别厉害的软件设计高手可以将好的设计一步到位地呈现出来不过我想对于大多数人来说设计并不是一蹴而就而是循序渐进的。最初的设计可能与最终的设计相差巨大这是再正常不过的事情。重要的是软件设计要朝一个好的方向演进重构的过程就是演进的过程。重构是对现有代码的设计进行优化和改良《重构改善既有代码的设计》候捷等译中国电力出版社出版一书指出了存在于代码中的常见的22种“坏味道”并针对性地提供了一些很中肯实用的重构手法很值得借鉴。其实重构应该是软件开发者的一种自觉习惯重构手法也是经过长期实践经验已经潜移默化了的。 最初的设计总是丑陋的重构是使“丑小鸭”变“白天鹅”的必要手段。哪怕再巧妙的构思也会有制肘哪怕再谨慎的防备也会有疏漏所以设计的雏形总会有这样那样的不足或多或少地脱离现实问题。这些不足的地方都是可以改进的关键是有意识地去寻找出这些不足并纠正它们。因此我们可以为了更紧密地贴合需求放心地让我们最初的设计粗糙一些我们总可以用重构的方法改造它。 好的设计是不断地重构才显露出来的。设计应当是从需求出发做出一些“粗糙”的解决问题的方案然后根据经验对该方案不断进行改进、完善使其越来越灵活越来越趋于稳定得到的自然就是好的设计。而不是从经验出发先想象出一些“玲珑”的构思然后修修补补使其符合我们的需求。前一种方式是借鉴经验后一种方式是强求经验前一种方式是慢慢演化水到渠成后一种方式是急于求成生拉硬拽前一种方式灵活有更进一步优化的空间后一种方式呆板越修补越走样。优劣自现。 设计过程中要“两顶帽子”轮流戴。“两顶帽子”是Kent Beck为了形象地描述重构过程中的两项任务而引入一种比方。一顶帽子是改善现有设计另一定帽子是增加新功能。提醒我们任何时候应该只做一件事除非你喜欢把两顶帽子摞起来戴改善现有设计的时候就立足于现有设计用现有的测试用例可以很方便地验证改善的正确性在增加新功能的时候容纳一种新的需求就充分信任现有代码的正确性而立足于该功能关注在新增功能的测试用例上以保证测试用例的正确同时修改或增加代码使得所有测试用例包括新增的通过。如果觉得新增了功能设计被污染了别急测试用例通过后可以换戴另一顶帽子。 5、要新陈代谢 软件设计不是一劳永逸的技术更新很快软件设计要为应用服务就要适应新的技术条件新陈代谢。软件设计本身要有开放、灵活的架构而开发者也要有与时俱进、开拓创新的精神。 软件设计要吸纳需求的变化不断适应新的环境。软件是服务于应用的应用的背景发生了变化软件必然要跟着变化所以好的软件设计要有在变化中存活和发展的生命力这就要求软件本身的架构是开放、灵活的。软件架构是在软件在开发的过程中不断纳入新的需求软件设计自身不断地进行调整到最后稳定下来的部分。所以软件架构是在需求不断变化的打磨下进化而来的是软件设计的骨架。只有来自于实际应用的动态的软件架构才方便改变自己以适应应用环境的改变。 开发者要不断学习提升自己的眼界。软件应用的领域范围广泛软件技术的发展也朝不同的方向在不断地提升软件开发的本质规律还没有完全大白于世软件业界存在着众多的思想流派不同流派正对一些技术方法会有一些争议。而开发者往往只能集中精力于某一特定的方向而对其他方向的发展比较生疏或者开发者只信奉一个思想流派对其他不同的意见不屑一顾——这些都是眼界受局限的表现。开发者应当了解其他领域的一些基本情况其他流派的一些基本主张这有益于反思自己开发中的一些困惑启发自己的思路。 开发者还要保持开放的心态要革故鼎新。好的软件设计要经受住时代变迁的考验和用户的挑剔。所以设计者要有开放的心态虚心接受用户的批评和建议并积极改进软件的设计以满足用户的要求。特别是对于新的有用的技术元素如新的软件架构理念、新的网络技术、新的数据库技术、新兴的编程语言等要有一定的敏感度要从中吸取积极的启发来加强软件设计的技术跟进。对于一些不合时宜的设计要更新换代始终保持软件设计与时代同步。 开发者还要有一点完美主义情节。软件设计是软件开发者心血的结晶是开发者思想的表白所以开发者往往对自己成功的作品爱不释手。就像母亲总觉得自己的孩子最棒一样开发者会觉得自己的设计是最好的。应该对那些倾心尽力做出软件设计的开发者致以崇高的敬意但是也有必要提醒他们要理性客观地对待自己作品的不足还有不完美的地方。这些话特别需要善意地对那些对现在的“设计”自我感觉良好的人说。相当多的开发者长期在设计的荒原已经习惯了在萧瑟的秋风和飞砂走石中缉拿隐藏在荆棘中的bug还从来没有想象过软件设计其实可以做得更好没奢望过还有鸟语花香的春天。该醒醒了不要安于在黑暗的屋子里窒息的命运 转载于:https://www.cnblogs.com/8942/archive/2006/08/04/467680.html
