首页软件开发正文

软件开发公司架构（软件开发公司架构图）

软件开发 2023-02-27T08:40:11 1350

本篇文章给大家谈谈软件开发公司架构，以及软件开发公司架构图对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。本文目录一览： 1、APP开发团队基本结构需要哪些职位以及职位数?

本篇文章给大家谈谈软件开发公司架构，以及软件开发公司架构图对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

1、APP开发团队基本结构需要哪些职位以及职位数?
2、软件公司开发项目是怎么搭架项目框架的(是一个人搭建还是每个人都建),程序员是怎么用搭架框架分工开发的?
3、软件公司都有哪些部门?
4、如何做好软件系统的架构设计
5、软件行业里常说的“架构”，究竟是什么东西
6、软件架构有什么?我们目前的软件开发架构是基于什么的?

APP开发团队基本结构需要哪些职位以及职位数?

1．产品经理：具有通信、计算机等相关专业知识，有独立的软件开发经验，能熟练使用网络测试工具，熟悉软件开发架构与流程；有良好的团队协作能力、沟通表达能力，有一定的项目管理经验；富有激情，有较强的执行能力和带队能力。

2．程序开发人员：计算机、软件工程等相关专业，熟悉开发框架，能够独立完成android开发；精通Java、C/C++等编程语言，熟悉 Http协议；有良好的编程思维和代码规范习惯，踏实好学，善于协作。

3．测试专员：计算机、软件工程等相关专业，有丰富的APP使用经验；了解android应用软件的测试框架和流程，熟悉QA标准，精通测试软件的使用，具有一定的数据分析能力、沟通表达能力和文档编辑能力；严谨细心，心思缜密，善于协作。

4．UI设计师：视觉传达、美术设计等相关专业，精通APP交互设计；精通Photoshop、Flash、Illastrator等专业软件;有较强的艺术感和较高的审美水平，了解市场对交互设计的要求，能够准确把握用户的审美需求；耐心负责，有较强的沟通理解能力、团队协作能力。

5．运营团队：营销策划、市场运营等相关专业，有丰富的产品运营经历和营销手段，能准确把握市场动向和社会热点；有项目推广、管理经验，较强的市场调查和数据分析能力，熟悉APP上线、维护流程；有较强执行力，热情善于交往，思维敏捷，良好的团队合作精神。

比如技术开发负责APP的程序编写,编写的过程中还要同UI设计进行交流,开发完成的APP需要交给软件测试人员进行测试来保证APP在正式上线时确保无BUG,这个过程也需要开发人员进行配合进行DEBUG;后期上线后还需要专门的推广营销人员开做市场调研。

软件开发公司架构（软件开发公司架构图）

软件公司开发项目是怎么搭架项目框架的(是一个人搭建还是每个人都建),程序员是怎么用搭架框架分工开发的?

你所指的项目框架是什么?!

根据个人感受，如果是小公司，所以分工不是那么严格，每个人需承担多个角色。

首先搞清楚业务需求，项目经理和需求分析人员做的事情，定位业务功能框架；然后进行设计，这个如果小组中有核心技术负责人的话一人可做系统整体开发架构，没有的话就需要项目经理找一两个技术比较牛的来讨论整体设计方案；定下需求就是规定了功能范围，整体设计就是涉及到实现系统的平台、技术、开发框架等问题；然后就是开发测试了，这个就根据模块单位来给程序员分配任务即可。分配任务时也要考虑将重要模块分配给技术比较强的、开发质量比较高的程序员。

对于java的开发，尤其要考虑技术的选型、框架的剪裁，是否需要用到开源组件等，能否达到功能需求的实现等等。

不知我的解决满意不？！满意就加分咯 5分太少呵呵

软件公司都有哪些部门?

问题一：IT公司或着软件开发公司都有些什么部门？开发部、技术部、电脑部、市场部（销售部）、财务部、行政部、人事部……

问题二：一个软件企业有哪些部门给你个实例

南京月牙网络技术有限公司组成情况:

由总经理室负责公司总体规划及管理,下设部门如下:

A.商务部

负责技术资料收集和客户资料整理,备档,负责相关产品的采购询价等

B.办公室

负责各部门的协调工作和公司人事等方面工作

C.销售部

负责销售业务开拓及代理管理

D.工程部

下设软件维护部,编目部,系统集成部

E.软件开发部

负责教育软件开发,网站设计,项目设计等，企业软件开发等

工程部部门如下:

部门名称

工作内容

a.软件维护部

负责学校软件安装,培训,维护等售后服务工作

b.编目部

负责图书馆条码管理系统纸质图书的电子建库录入工作

c.系统集成部

负责软件实施过程中硬件网络布线,设计,组网等工作

类似网络公司的部门组成差不多

问题三：在软件公司里面一般有哪些部门人事后勤（办公室）、财务筹资（财务部）、物料采购供应（物资管理部）、生产制造（生产部）、技术研发（技术部）、质量监督（质量管理部）、经营销售（营销部）等

问题四：软件公司有多少个部门、多少个职位?拜托各位大神多少个部门？要依据公司的大小而论，大公司可以有很多，而小公司人数有可能就几个人还如何分部门呢，只能大概的跟你说可能会有如下几个部门：开发部(接项目做开发)，技术服务部或者叫外包部（用来为别的服务的，外派到别的公司），研发部（搞研发的，稍大一点儿的公司才会有)，测试部（搞软件测试的），说白了这些部门也不是固定的，相互之间可以调整人员使用，但所在的部门是不会变的，还有就是财务部，人事部等，公司大的话可能还有更细的划分，至少我们公司就是这一些部门，不同的公司定义稍有差异。

麻烦采纳，谢谢!

问题五：软件公司里一般有哪些部门不懂计算机能在里面做些什么一般都是市场部和开发部，再完善点的有个人力资源部。顾名思义，市场部就是卖产品的，把公司开发激产品或者软件卖出去；开发部负责开发，属于搞技术的部门；人力资源负责应配、后勤管理这方面的。

问题六：软件公司的测试部门有哪些常见的组织？测试总监-对应-开发总监

-测试经理-对应-开发经理

-测试组长-对应开发组长

-各级别测试人员（普通测试工程师）

每个级别的人的工作内容有所不同

有的企业里面还有测试架构师，测试设计师这样的职位。其中测试架构师和测试总监或者测试经理是平级的，测试设计师一般和测试组长是评级的，但是他们对于人员管理没有权限弧管理的是项目本身。不过这类的职位一般在国内不多见。

还有，有些企业会把QA和QC分离，就是普通的测试部门（QC）和质量管理部（QA），质量管理部是在软件项目开始的时候和进行中进行规则管理和规划的人员。都需要知道类似于CMMi之类的东西。督促测试或者开发在流程上的一些强化定义，并且确保整个过程中的流程上的质量。

QA和QC糅合的企业也很多。两者的工作都有。只是看更加注重什么。

测试根据测试的角度可以氛围很多种。有些企业可以细化（规模大的）比如ST，UAT分成不同的部门。黑盒测试，白盒测试，灰盒测试是不同的team负责，自动化测试和手工测试等等。看公司定位，客户需求以及项目特点。

问题七：软件开发公司有哪些部门开发部、技术部、电脑部、市场部（销售部）、财务部、行政部、人事部……

问题八：一个软件公司开发管理系统具体有哪些职位？一个完整团体具有：

项目总监，项目经理，系统架构师，系统分析师，程序员/软件工程师，美工/网页设计师，测试工程师，实施人员，数据库管理工程师/技术员，配置工程师。

我以前公司软件开发部门就有以上职位。

一般情况下都有：项目经理，程序员，测试，美工基本职员。

望采纳。

问题九：软件公司都有哪些部门人力资源部

户务部

开发部

质保部（测试部）

网络工程部

软件开发软件测试硬件维护产品发布需求确认用户跟踪服务器维护数据管理

系统集成部

行政部

等，希望有帮助。

问题十：IT公司或着软件开发公司都有些什么部门？开发部、技术部、电脑部、市场部（销售部）、财务部、行政部、人事部……

如何做好软件系统的架构设计

软件架构设计的目的对于外包业务类型的项目，软件架构设计的目的与产品类型的项目有所不同，在这里主要讨论外包类型项目的软件架构设计目的。 1、为大规模开发提供基础和规范，并提供可重用的资产，软件系统的大规模开发，必须要有一定的基础和遵循一定的规范，这既是软件工程本身的要求，也是客户的要求。架构设计的过程中可以将一些公共部分抽象提取出来，形成公共类和工具类，以达到重用的目的。 2、一定程度上缩短项目的周期，利用软件架构提供的框架或重用组件，缩短项目开发的周期。 3、降低开发和维护的成本，大量的重用和抽象，可以提取出一些开发人员不用关心的公共部分，这样便可以使开发人员仅仅关注于业务逻辑的实现，从而减少了很多工作量，提高了开发效率。 4、提高产品的质量，好的软件架构设计是产品质量的保证，特别是对于客户常常提出的非功能性需求的满足。软件架构设计的原则软件架构设计必须遵循以下原则： 1、满足功能性需求和非功能需求。这是一个软件系统最基本的要求，也是架构设计时应该遵循的最基本的原则。 2、实用性原则，就像每一个软件系统交付给用户使用时必须实用，能解决用户的问题一样，架构设计也必须实用，否则就会“高来高去”或“过度设计”。 3、满足复用的要求，最大程度的提高开发人员的工作效率。软件架构设计的几种视图我们常常在讨论架构设计该做些什么的时候，或是在架构设计评审的会议上，会提出各种各样的问题，例如开发人员该如何记录Log，事务如何控制？怎样才能提高我们的开发人员的工作效率，即在单位时间内更有品质的完成更多的功能？怎样满足客户的非功能性需求？怎样让生产环境的平台管理人员更好的维护系统？上面这些问题，实际上是软件系统的不同的干系人站在不同的角度上提出的问题，要回答上面这些问题，我们就得从不同的视角来看待软件架构设计这项工作。 1、逻辑架构视角，从系统用户的角度考虑问题，设计出来的软件架构能够满足业务逻辑的需求，能够处理现在越来越复杂的业务逻辑需求。 2、开发架构视角，从系统开发人员的角度来考虑问题，设计的架构要易于理解，易于开发，易于单元测试，最好做到让开发人员可以用最少的代码行数完成功能的开发。 3、运行架构视角，从系统运行时的质量需求考虑问题，特别关注于系统的非功能需求，客户常常都会要求我们系统的功能画面的最长响应时间不超过4秒，能满足2000个用户同时在线使用，基于角色的系统资源的安全控制等。 4、物理架构视角，关注系统安装和部署在什么样的环境上，例如现在最流行的企业应用服务解决方案IBM Http Server ＋ WebSphere Application Server ＋ DB2，WebLogic + Oracle等。 5、数据架构视角，如今我们开发的各类系统，如MIS，ERP，SAP，基本上都是对各类数据的操作，把一堆不太好懂的数据展现成用户容易看懂的数据，自动处理各类数据的运算等，所以数据的持久化是十分重要的一件事情。1、分析需求和理解业务模型（或领域建模），并选定关键Use case。软件的需求，可以分为从用户视角和开发人员视角来看，从用户的角度看，又可以分为功能性和非功能性需求，我们必须从不同的视角和级别去全面的认识需求并分析需求，理解业务模型。实践表明，常常被我们忽视的非功能性需求常常会导致整个项目失败。理解业务需求最好的方式莫过于进行领域建模，领域建模与需求分析往往是交替穿叉进行的，领域建模主要有以下三个方面的作用： ◆探索复杂问题，弄清领域知识。Martin Fowler曾经说过，他采用面向对象方法最大的好处就是它有助于解决更为复杂的问题。领域建模本身作为辅助思维的工具，帮助我们将注意力始终保持在最为重要的业务概念及其关系上，使我们能够不断深入地，系统的对需求进行分析和认识。领域建模往往是一个从模糊到清晰，从零散到系统的过程。 ◆决定功能范围，影响可扩展性。任何模型都是对现实世界某种程序的抽象，这种抽象就会忽略某一些东西，例如忽略对象的属性和对象间的关系，而这些忽略往往都是带有一定的目的性的，这种忽略就决定了功能的范围。模型揭示了各种功能背后的结构，如果说定义功能相当于“拍照片”的话，那么领域建模就相当于“做透视”，更加关注问题领域的内在结构，相当于对问题领域进行了一定的抽象，良好的领域模型不仅能很好的支持现有的功能，而且还可以在一定程度上支持未来可能出现的新需求，体现良好的可扩展性。 ◆提供交流基础，促进有效沟通。领域建模通常会使用UML图作为呈现的方式，这样为我们的沟通提供了方便。当然，有时候文字在描述某些特定领域的问题时可能更适合，可以灵活运用。在我们公司的实际软件开发流程中，往往领域建模缺少这一环节，这可能是在以后的工作中需要进一步提高之处。虽然我们总是期望架构设计师能全面掌握需求，但由于时间和精力的限制，摆在我们面前的现实就是架构设计师没有时间对所有需求进行深入分析，所以我们的策略就是“把好钢用在刀刃上”，即把大部分时间和精力花在对决定架构最重要的关键需求上。在选择关键需求时要注意：高优先级的需求往往是从用户的角度来看的，可能并不是真正的关键需求。在《RUP实践者指南》一书中向我们讲述了如何确定关键功能需求？A.作为应用程序的核心或实现了系统的主要接口的功能，B.必须被实现的功能，即如果这些功能不被实现，则开发出来的软件就失去了价值，C.覆盖了系统架构的一些方面，但没有被其他重要的Use case覆盖到的功能。 2、分别从各个视角来考虑软件架构的方方面面。软件的架构设计必须考虑到各方面，根据前期工作确立的领域模型，关键需求，系统约束等进行设计，必须从系统用户，开发人员，系统管理员，部署管理员，数据管理员等人员的角度去分析并解决问题。比如说，如果我们的运行架构采用Cluster方式时，就必须小心Cache和Session等的使用；如果我们的业务逻辑要求我们要操作多个数据库时，就要考虑采用支持二阶段事务提交的方式。只有将这些方方面面的问题都考虑到了，这样的架构设计才是完整的。至于每一个视图中，我们应该设计到什么细节这一问题，实际上与整个项目的过程定义有关。例如，如果我们有专门安排数据库概要设计的活动，那我们在架构设计的过程中就可以只需要关注更高层次的数据库特性及数据库之间的关系，而每一张表的数据字典可以在后续的相关活动中进行设计，但如果没有这样的活动，那我们就要细化到每一张表的每一个栏位，以及表之间的关系。 3、解决技术面的重点问题和难题在软件架构设计的过程中，我们往往会需要攻克一些技术面的重点问题和难题，这完全是一项极其需要扎实的理论知识和丰富的实践经验支撑的工作。例如，我们如何提高整个系统的性能？如何能很好的导出极其复杂的“中国式报表”（一般比西方国家产出的报表要复杂很多，而且很多开源的BI类的框架并不能完全解决问题）？当遇到确实是很困难的问题，可以去百度一下或Google一下，也可以去请教公司的资深技术人员或专家，或者召开小范围的技术专题讨论会议，采用脑力激荡的方法试着找找答案，这样才能提高工作的效率。 4、召开架构设计评审会议进行同行评审。架构设计评审是极其重要的一环，我曾将其形容为“七种武器”中的离别钩，就是因为在会议上，同行们可能会提很多问题或意见，而且很多意见很尖锐，所以一定要虚心接受，并做好记录，正所谓“良药苦口利于病，忠言逆耳利于行”。在评审会议之前，我们要完成很多准备工作，最好是能准备一份简明扼要的电子简报，把最重要的问题列出来，这样在进行评审会议时，就不会漫无目的，在会议前就将这些资料发给与会人员，请他们抽空先了解一下，在会议进行时，要学会控制会议的进度，提高会议的效率。 5、针对关键Use case在设计的架构上实现功能来验证架构。对于架构设计的验证也是一项十分重要的工作，其验证技术有很多种，在我们公司通常会采用Sample的形式，即XP中所说的迭代0，RUP中所说的切片。这样做的好处是既可以从实际的产品角度出发来有效的验证架构是否满足要求，又可以比抛弃型原型验证技术节省成本。这个Sample绝不是我们在解决架构设计中的问题时拿来做实验的一些代码的拼凑，而是完整的实现某一关键Use case的符合架构设计和一系列规范的可交付的代码及相关文档。同时，这个Sample可以作为你在给大家讲解或培训架构时的教材，也可以作为开发人员使用此架构进行开发的蓝本，甚至是只需要复制粘贴，加上简单的修改即可。 6、交付给客户Review。这一环节，在很多公司可能并不存在，因为他们的软件架构并不一定需要客户Review，但像我们这种做服务的公司，最重要的就是客尊，落实到软件架构设计这一活动，就是让客户理解并接受你的架构设计方案，同时，客户也会起到帮你验证架构的作用。通常，我们的架构得到客户的认可后，便可进入大规模的开发。在交付给客户Review时，通常可能会以会议的形式进行Review，所以我们可以参照评审会议时好的做法来召开会议，在这里就不再冗述。软件架构设计的常见误区及解决办法 1、架构设计的常常会“高来高去”。所谓高来高去，实际上就是我们的架构设计仅停留在模型阶段，但也绝不是产生第一支样例程式。 2、架构设计时常常会在某些方面过度设计（Over engineering）。为了一些根本不会发生的变化而进行一系列复杂的设计，这样的设计就叫过度设计，往往会带来资源的浪费并且会增加开发的工作量或难度。虽然我们必须考虑到系统的扩展性，可维护性等，但切忌过度设计。有时候或许你并不能判断出哪些设计是过度设计，此时你可以请教你的PM，让他站在整个项目的高度来帮你决策一下。 3、架构（Architecture）不是框架(Framework)，也不是简单的将几种框架或技术的组合，框架本身也是有架构的。框架一般是针对于某一方面或领域的重用性和可扩展性非常好的半成品，我们可以用一句较为经典的话来总结：框架是软件，架构不是软件，框架是一种特殊的软件。我们在工作中通过将许多方面的可重用的工具类，公共类，基础类等抽象出来，即可形成一些可重用的框架。 4、架构设计绝不是新技术展示平台，合适的技术才是对于项目有利的技术，必须考虑到开发人员的能力和维护人员的能力。作为一名架构设计师应该更多的考虑如何平衡业务需求，织织运作（主要指团队中的协作）和技术三者的关系，而不仅仅是去关注那些技术细节。 5、架构设计的成功与否决定着系统品质的好坏，因为架构设计不好而导致交付的系统Bug过多，无法满足客户非功能性需求等问题，从而导致项目取消的案例时有发生。架构设计不是架构设计师一个人的事情，也不是几天就能完成的一项工作，必须是架构设计师付出大量辛勤劳动后的成果，其成败往往与组织、主管、项目经理的支持有着密切的关系。关于架构设计的一点通用技巧 1、分层（Layer）规则。这里的层是指逻辑上的层次（Layer），并非指物理上的层次（Tier）。目前的绝大多数的企业级应用系统中都分为三层，即表现层，领域层和数据层。在对各层次进行划分时，主要可以从以下几个方面来考虑：A、每一层是一个相对独立的部分，可以作为一个整体，无需对其它层了解；B、将层次间的依赖性降到最低，即降低耦合；C、可以从某种程度上替换掉某一层，而对其它层不会产生过多的影响；D，层次并不能封闭所有的东西，假如用户界面上增加了一个栏位，那么领域层就要增加一个数据域，数据层就要增加一个相应的字段。同时，过多的分层可能会对性能造成一定的影响。 2、包（package）之间不要产生循环依赖。通常包的划分会先按不同的逻辑层来划分，在层的包下面再按功能来划分。避免包间的循环依赖是一个比较通用的规则，这样的规则一定有其存在的价值和道理，之所以这样主要是出于以下原因：A、循环依赖会使分层失去意义；B、循环依赖会带来许多潜在的风险，如可能会产生嵌套事务（nested transaction，JavaEE标准中并不支持这种事务）的现象，我就曾遇到过这样的问题，在一个项目中，事务放在业务逻辑层统一控制，但由于开发人员忽视了架构中这样的原则，在持久层调用了展现层的公用类，形成了回圈的现象，导致了嵌套事务的发生。 3、设计模式的应用。在很多人的观念里，提供设计模式就等同于GOF的设计模式，其实设计模式是个广泛的概念，比如需求模式、领域模式、反模式等都属于设计模式。模式其实是一门工具，是人们对于过去解决某一类问题的经验总结，所以我们可以在设计活动中应用各种设计模式，但是在应用这些模式之前一定要先分析清楚问题，否则就可能出现“牛头不对马嘴”的现象。成功的项目总有相似之处，失败的项目却各有各的失败之处。好的软件架构设计必定是成功项目的相似之处，我们有什么理由不把软件架构设计做好了？

软件行业里常说的“架构”，究竟是什么东西

一直以来，在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。甚至于很多架构师一说架构，就开始谈论什么应用架构、硬件架构、数据架构等等。我曾经也到处寻找过架构的定义，请教过很多人，结果发现，没有大家都认可的定义。套用一句关于 big data 流行的笑话，放在架构上也适用：

Architecture is like teenage sex，everybody talks about it，nobody really knows what is it。

事实上，架构在软件发明时的 N 多年以前，就已经存在了，这个词最早是跟随着建筑出现的。所以，我觉得有必要从源头开始，把架构这个概念先讨论清楚，只有这样，软件行业架构的讨论才有意义。

什么是架构?

架构的英文是 Architecture，在 Wikipedia 上，架构是这样定义的：

Architecture (Latin architectura, from the Greek ἀρχιτέκτων arkhitekton” architect”, from ἀρχι- “chief” and τέκτων “builder”) is both the process and the product of planning, designing, and constructing buildings and other physical structures。

从这个定义上看，架构好像是一个过程，也不是很清晰。为了讲清楚这个问题，我们先来看看为什么会产生架构。

为什么会产生架构?

想象一下，在最早期，每个人都完全独立生活，衣、食、住、行等等全部都自己搞定，整个人类都是独立的个体，不相往来。为了解决人类的延续的问题，自然而然就有男女群居出现，这个时候就出现了分工了，男性和女性所做的事情就会有一定的分工，可是人每天生活的基本需求没有发生变化，还是衣食住行等生活必须品。

但是一旦多人分工配合作为生存的整体，力量就显得强大多了，所以也自然的形成了族群：有些人种田厉害，有些人制作工具厉害，有些地方适合产出粮食，有些地方适合产出棉花等，就自然形成了人的分群，地域的分群。当分工发生后，实际上每个人的生产力都得到了提高，因为做的都是每个人擅长的事情。

整个人群的生产力和抵抗环境的能力都得到了增强。为什么呢?因为每个人的能力和时间都是有限的，并且因为人的结构的限制，人同时只能专心做好一件事情，这样不得已就导致了分工的产生。既然分工发生了，原来由一个人干生存所必需的所有的事情，就变成了很多不同分工的角色合作完成这些事情，这些人必须要通过某些机制合在一起，让每个人完成生存所必需的事情，这实际上也导致了交易的发生(交易这部分就不在这里展开了，有机会再讨论)。

在每个人都必须自己完成所有生活必须品的生产的时候，是没有架构的(当然在个人来讲，同一时刻只能做有限的事情，在时间上还是可能会产生架构的)。一旦产生的分工，就把所有的事情，切分成由不同角色的人来完成，最后再通过交易，使得每个个体都拥有生活必须品，而不需要每个个体做所有的事情，只需要每个个体做好自己擅长的事情，并具备一定的交易能力即可。

这实际上就形成了社会的架构。那么怎么定义架构呢?以上面这个例子为例，把一个整体(完成人类生存的所有工作)切分成不同的部分(分工)，由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。由以上的例子，也可以归纳出架构产生的动力：

必须由人执行的工作(不需要人介入，就意味着不需要改造，也就不需要架构了)

每个人的能力有限(每个人都有自己的强项，个人的产出受限于最短板，并且由于人的结构限制，同时只能专注于做好一件事情，比如虽然有两只眼睛，但是只能同时专注于一件事物，有两只手，无法同时做不同的事情。ps. 虽然有少部分人可以左手画圆右手画框，但是不是普遍现象)

每个人的时间有限(为了减少时间的投入，必然会导致把工作分解出去，给擅长于这些工作的角色来完成，见 2，从而缩短时间)

人对目标系统有更高的要求(如果满足于现状，也就不需要进行架构了)

目标系统的复杂性使得单个人完成这个系统，满足条件 2，3(如果个人就可以完成系统的提高，也不需要别的人参与，也就不需要架构的涉及，只是工匠，并且一般这个工作对时间的要求也不迫切。当足够熟练之后，也会有一定的架构思考，但考虑更多的是如何提高质量，提高个人的时间效率)

有人可能会挑战说，如果一个人对目标系统进行分解，比如某人建一栋房子，自己采购材料，自己搭建，难道也不算架构嘛?如果对于时间不敏感的话，是会出现这个情况的，但是在这种情况下，并不必然导致架构的发生。如果有足够的自觉，以及足够的熟练的话，也会产生架构的思考，因为这样对于提高生产力是有帮助的，可以缩短建造的时间，并会提高房子的质量。事实上建筑的架构就是在长期进行这些活动后，积累下来的实践。

当这 5 个条件同时成立，一定会产生架构。从这个层面上来说，架构是人类发展过程中，由懵懵懂懂的，被动的去认识这个世界，变成主动的去认识，并以更高的效率去改造这个世界的方法。以下我们再拿建筑来举例加强一下理解。

最开始人类是住在山洞里，住在树上的，主要是为了躲避其他猛兽的攻击，以及减少自然环境的变化，对人类生存的挑战。为了完成这些目标，人类开始学会在平地上用树木和树叶来建立隔离空间的设施，这就是建筑的开始。但是完全隔离也有很多坏处，慢慢就产生了门窗等设施。

建筑的本质就是从自然环境中，划出一块独占的空间，但是仍然能够通过门窗等和自然环境保持沟通。这个时候架构就已经开始了。对地球上的空间进行切分，并通过门窗，地基等，保持和地球以及空间的有机的沟通。当人类开始学会用火之后，茅棚里面自然而然慢慢就会被切分为两部分，一部分用来烧饭，一部分用来生活。当人的排泄慢慢移入到室内后，洗手间也就慢慢的出现了。这就是建筑内部的空间切分。

这个时候人们对建筑的需求也就慢慢的越来越多，空间的切分也会变成很多种，组合的方式也会有很多种，比如每个人住的房子，群居所产生的宗教性质的房子，集体活动的房子等等。这个时候人们就开始有意识的去设计房子，架构师就慢慢的出现了。一切都是为了满足人的越来越高的需求，提升质量，减少时间，更有效率的切分空间，并且让空间之间更加有机的进行沟通。这就是建筑的架构以及建筑的架构的演变

总结一下，什么是架构，就是：

根据要解决的问题，对目标系统的边界进行界定。

并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。

并对这些切分出来的部分，设立沟通机制。

根据 3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

同样这个思考可以展开到其他的行业，比如企业的架构，国家的架构，组织架构，音乐架构，色彩架构，软件架构等等。套用三国演义的一句话，合久必分，分久必合。架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。架构的产出物，自然就是对问题的分析，以及解决问题的方案：包括拆分的原则以及理由，沟通合并的原则以及理由，以及拆分，拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。

望采纳！