软件开发模式

最新推荐文章于 2023-08-19 16:58:00 发布

htsitr

最新推荐文章于 2023-08-19 16:58:00 发布

阅读量677

点赞数

分类专栏：软件工程分类文章标签：软件开发软件工程

本文链接：https://blog.csdn.net/htsitr2/article/details/8752136

版权

软件工程分类专栏收录该内容

4 篇文章 0 订阅

订阅专栏

关于研发工作

研发工作是包括研究和开发，这是两个不同的领域。

先讲开发领域，其实这里所谓的开发已经有点面向软件实施的过程了。这种情况下可以遵循一般的软件管理的逻辑。招聘相关的人员，组成合理的布局。

而研究领域，则无所谓一个完整的团队建设，主要针对个人或小团队的范围。

  名词解释
  我所在的公司是一个中小型的公司。中小型的公司软件的开发方法很多都是基于快速原型及敏捷开发。
快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
非官方的解释是：用户和你都不太明确他想做什么软件，先让你做个简单的样板看看，符合胃口的话再继续做。就好像你想到市场上买把武器，但不知道选剑好，还是选刀好。这时候你就让伙计把他所有的兵器拿出来，你觉得哪种适合你，就为你打造那种。

        优缺点
      很多公司应该利用这种开发方法发展的很好，因为这样做的成本低，风险相对小。假如是基于其他引擎做二次开发或者上层开发，那么这种开发方法获得的效果更加大大的好。这点好像解释了为什么短短两三年，手机软件每天都会以上万计的被开发出来（暂时不讨论其中的质量问题）。

自然的，这种方法也存在不足。为了快速响应用户的需求，你就得加班了。所以本来是一项创造性的工作会变成一种劳力工作。真正能够读懂用户的需求，或者能创造性的做出让用户耳目一新并放弃他原本心中弱小的但又包含固执想法是很困难的，更不幸的是，有些项目参与者会坚持把自己的想法套在上面，因为那样会体现一个人在项目中的作用。
加班其实还只是表面现象，其实质却可能包含了更多的猫腻。看似风光的开发过程，其实做更多的开发也可能只是量的改变。我们都知道，人以上年纪，就看重经验，就会用以前的经验去判断事情将怎么去做。同样的，一种能够快速成功的方法，会让人认为这种方法可行。假如你用原型开发方法获得了成功，那么你就或多或少的被这种方法所吸引，从而减少对所作工作的知识的积累。所以到头来，你虽然拥有很多的成果，但他们之间的关系却没有形成网络联系。

        飘渺的办法
  既如此，那为何不采用更高级的开发模型呢？不过好像更高级只说应该不存在吧。每个公司，每个项目会有各自的特色，强行套用别人的方法恐怕会死的更早。我们知道当前世界有家公司比较特别，他就是苹果，他可以对用户的期望置之不理，直到发布了，你才知道他的产品的庐山真面目。我想这样的人才还是不多的，很多公司走出来就是为了赚钱，这也是他们的生存之道，如此的剑走偏锋他们吃不消的。
大型的公司会有专门的人负责底层的设计，然后另外的人在上面做功能开发。这样做，就好像自助餐的盘子，盘子够大，上面管你放汤，放水果还是放生鱼片。这样好像不错哦。
不过中小公司却用不了，因为完全负责底层设计的人而能够适应上层开发的人在这些公司很难找，存在一两个也可能不够数。很多人会说为何公司舍不得放长线钓大鱼。我想这样的想法有点理想。现实社会不是你敢闯就会赢，你得有资本，要么是头脑好使，要么赔的起运气好。两者都没有，犹如蚂蚁撼大象。当然上面的说法忽略那些可以这么做，但不敢做的人。

        或许的办法
上面看起来是一个死循环。既需要类似快速原型的方法来实现目标，又会被这种方法折腾的够呛。要突破这个死循环，或许再增加一项工作可以避免。这项工作大点的说是叫业务重组吧，小点的说是代码重构。
      业务重组不是我创的名词，本来就有的。简单的说就是对企业的功能进行重新划分。这个部门做什么，那个部门做什么。业务重组重新梳理公司的业务情况，归并功能相似的业务，分撤具有多个流程的业务。对于原先使用快速原型的公司做了很多产品的公司，能够找到相同类型的项目，然后提取出公共的部分，新的类似项目就在此公共的部分进行开发。
      代码重构，它适合于在一个项目内部来提取底层接口。简单的说就是你做一点东西，发现以后将会有类似的功能，或者以前就存在类似的功能的时候，就提取一个接口类。其实本来也应该这么做的，但人嘛，一则不能完全判断哪些是相似的，二则嫌麻烦，提取接口内核后会产出新的问题，三则对这样做是否值得，是否符合时机都存在疑问。