CSDN日报20170721——《为什么我们创业失败了和选择创业公司的思考》

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/blogdevteam/article/details/75669610


程序人生 | 为什么我们创业失败了和选择创业公司的思考

作者:文西

这篇文章会从一个技术合伙人角度分享创业失败的感受,和从一个技术合伙人的角度分享一些创业公司选择的观点。

点击阅读全文


Android | 轻松学,听说你还没有搞懂 Dagger2

作者:frank

Dagger2 确实比较难学,我想每个开发者学习的时候总是经历了一番痛苦的挣扎过程,于是就有了所谓的从入门到放弃之类的玩笑,当然不排除基础好的同学能够一眼看穿。

点击阅读全文


Python | 决策树基础篇之让我们从相亲说起

作者:Jack-Cui

本篇讨论决策树的原理和决策树的构建的准备工作,完整实例内容会在下一篇文章进行讲解。

点击阅读全文


音视频 | 让 IjkPlayer 支持插入自定义的 GPU 滤镜

作者:湖广午王

不得不说,B 站开源的这个 IjkPlayer 播放器的确非常强大,代码设计的非常清晰,仔细看看,能学到不少东西。

点击阅读全文


Unity | Tiled 结合 Unity 实现瓦片地图

作者:Aimar_Johnny

Tiled2Unity 可以方便的把 Tiled 编辑器做的地图文件导出到 Unity 中,这这个地图文件我们在 Unity 中怎么用?

点击阅读全文


大数据 | HAWQ + MADlib 玩转数据挖掘之——奇异值分解实现推荐算法

作者:wzy0623

奇异值分解简称 SVD ,可以理解为:将一个比较复杂的矩阵用更小更简单的三个子矩阵的相乘来表示,这三个小矩阵描述了大矩阵重要的特性。

点击阅读全文



关注专栏【CSDN 日报】,获取最新及往期内容。

展开阅读全文

构架思考--我们为什么需要构架

08-23

在一个典型的系统的开发过程中,首先是客户提出需求,设计人员根据需求进行分析和设计,程序员根据设计进行编程,最后是系统的测试和系统的分发。在整个软件过程中,参与到系统的角色各不相同,各种角色之间的关系是既合作又敌对的。系统的客户总希望花更少的前,获取更多的功能。开发公司则相反。开发人员讨厌无停止的改动,客户则认为开发出来的东西总是不满足自己的要求。在开发的过程总需要一个能够折中体现参与到系统的不同角色的不同要求。一套详细的设计说明?如果时间和金钱上允许的话,也许可以这么做,而且客户也许会没有耐心和你讨论关于函数接口的问题。或者是什么都不做,加快时间把系统做出来再讨论。实践证明了此路不通。我们需要的模糊和过分的详细之间找到一个平衡点。我们把它称之为构架。构架体现了不同风险承担者的要求的综合,借助于构架,设计师就可以分析众多风险承担者所提出的各种要求的优先级别,并且将这些要求转化为系统的各个特性,针对这些的特性,系统要在结构上做一些的妥协。rn 在上面我们提到系统特性,在《软件系统和软件构架》中也提到两个概念,原则(principle)和质量属性(Quality attributes)。这三个是相互关联的概念,rn我个人认为系统特性是质量属性的具体的体现。软件的质量属性是指软件的性能,安全性,可用性,功能性和使用性等。系统的具体的某个需求大多数可以归纳为某个种rn类的质量属性。在SEI的Architecture Tradeoff Analysis (ATA)中就讨论了如何将系统的需求归纳整理为不同的质量属性。原则在某种程度上等同于质量属性,比如说某套系统的开发过程中的技术原则是要能实现互操作性,在质量属性中也有类似的概念。基本上来说原则更为工程化一些,也就是在不同的系统中,你可以制定不同的原则。而质量属性相对更为抽象一些。在SEI方面的软件构架文章中,我们常看到的是质量属性,而在IEEE 1470-2000以及TOGAF8中,都是用原则(principle)来表示。无论是质量属性还是原则,都是作为评审软件构架的标准。在以后的文章中,我们就统一采用质量属性这个称呼。rn 由于构架综合体现了不同的风险承当者的要求,不同的风险承当的所关心的问题肯定是不一样的,所以在进行构架描述的时候,我们需要从多角度的来进行描述。就象建筑设计中一样,把所有的东西,比如外观设计,受力设计,水电设计等都放到一起肯定是不可行的,但这些分开的设计也不是都毫不相干的,它们之间既相对的独立,又相互联系,形成对一座建筑的完整的描述,不同的参与人员只关心他们要关系的时间,如结构工程师关注受力设计,水电工程师关注水电设计,建筑设计师负责整体统筹规划。在软件构架设计中也是一样,通过多个相对的独立又相互联系的视图来对构家架进行一个完整的描述,关于构架描述的权威性论述是IEEE 1470-2000,在SEI的《软件构架实践》中用软件结构来表示类似于构架视图的概念。"Architectureal blueprints- the 4+1 view model of rnsoftware architecture"提出了一个被广为使用的构架描述的模型,RUP过程的构架描述模板和HP公司的软件描述模板都和这个有莫大的渊源。也正是因为通过多个不同的角度来描述说明构架。不同的风险承担者可以通过构架进行交流,并且找到解决方案。基本上来说,构架的重要性可以被归纳为以下三点:(1)构架是风险承担者进行交流的手段。(2)构架是早期决策的体现。(3)构架是可传递,可重用的模型。具体的说明参见《软件构架实践》中的‘什么是软件构架’一章。由于构架如此的重要,在RUP过程中更是明确的说明整个的设计过程是以用例为驱动,以构架为核心的。 论坛

没有更多推荐了,返回首页