1. 希知网首页
  2. 信息技术与社交网络

信息系统开发常用的方法有,信息系统开发用到的技术

• 信息技术与社交网络

1，IT架构和项目管理的基本理论

信息化的发展自19世纪40年代兴起传导到企业后，一直在高速的发展，不到70年的时间，理论发展十分迅速且其准入门槛已经是非常的低了。

软件工程，特别是多项目管理的理论作为一门学科的发展迅速的有点不可思议，这是因为它借鉴了一个成熟体系：建筑学。欧美成熟的建筑学理论和体系很快被计算机科学家复制适配到了软件领域；

建筑说白了就是建房子，根据不同的场景，不同的需求，有需要建一个简易小屋的，有需要建一栋两层house的，市区人口密集，则多是20到50层的小高层和高层建筑，金融中心则会有一片超高层的地标；

针对简易小屋，通常就是平整一下要建房子的空地，房基略高，周边略低方便排水，然后挖掘屋基用石头水泥做一个基座直接就建起来了；适用于临时使用或储物；

针对house，通常用户居家使用，要求稳固坚实，使用周期长，但规模较小成本不高，通常是在平整的地基上挖掘屋基，打上钢筋水泥的地基和框架，填上砖石覆上屋顶，隔音，通风，保暖，遮雨，按生活使用功能分区；

小高层就复杂很多，因为规模较大，楼层高度较高，成本高，规模大，周期长，涉及物料，人员也较多且对人员的要求要也更高，普通建筑的施工人员基本都不能胜任，所以需要先规划，设计蓝图，再核算好成本，按建设阶段规划好物料入场时间顺序以及对应的工程人员的介入；蓝图成本核算完成后，就是要先打地桩，普通的地梁式地基不能承受高层建筑，需要勘测地下土壤结构的受力，然后决定地桩深度，再在地桩上深挖地基打一个够结实的地梁，这块打好后，后续就直接用钢筋水泥浇筑整体的框架；最后再用空心砖分割住宅的使用功能区域；

高层及超高层建筑则更为复杂，除了需要考虑小高层的全部因素，还需要考虑各个楼层的上下通达，消防，水，气，电，周边交通等配套因素，蓝图规划也要将这些因素考虑进去，比如消防步行梯通常有2个通道，每10层左右一个消防层，高层供水需要加压，电梯使用高速电梯且保养频率要更高，地基下的地桩更是更深，更密集，整体框架更为厚重，很多功能区域也规划到整体框架中直接在浇筑框架时就已固定；

任何一家开发商为了攫取更多的利润，自然会想办法标准化其整体的作业过程，所以可以看到，万科，花半里，鸿荣源等开发商再设计和交付产品时，多个项目相识度非常的高，就是其将所有的规划架构已经标准化了，只需要再新项目中修改部分细节设计即可，这样既节省了时间，更是节省了成本，同时也避免全新规划和施工带来的风险；

信息化建设根据公司业务规模及形态，对信息化的要求就如同人们对建筑的需求一样，临时性的需求就是一个简易小屋，能遮阳，挡雨挡风即可；如果业务对信息化的依赖不大，则使用对应的常规系统即可，如产品化的管家婆。如果行业没有成熟的软件，则定制一个； 如果公司的业务规模较大，产品类型较为复杂，业务流程较长，则需要按一个高层建筑来规划，甚至是一个高层的建筑群来规划；譬如一个大规模的集团公司（高层建筑群），他们的架构一定是底层够厚重，各个复用的功能肯定是建成组件库了（地桩，内部钢筋架，门，窗，格局按类别统一一个标准），同时，由于规模过大，也肯定是多个出入口，甚至根据需要规划人车分流（系统内外部对接接口，系统集成），小区内部也肯定有多个区域划分及管理需求；这些理念被借鉴时，自然就导致IT的设计及项目管理理念高度相似了。

一套信息系统的底层建设，自然也是可以从过往经验中抽离出来，整理成一个标准度很高，集成度完善的框架，这样，应用到对应规模的软件研发中，自然就节省了时间和人力，无需将过往用到的模块再重新开发（如跟支付宝，微信，钉钉的对接，权限模块，消息模块的开发都已经标准化了），在一个完善的框架里，开发人员只需要像做填空题一样，把具体的业务逻辑编码出来，前端UI像装修人员一样，根据开发商或客户的需要作出UI对接业务逻辑，就能快速的开发出应用系统了。

2，关于软件框架那些事儿

有一个好的框架，开发软件就会事半功倍，这些年，从架构到框架，软件人的追求从来没有停滞过，SOA，RESTful，微服务，低代码……，框架更是层出不穷，SSH，SSM，SpringBoot，SpringBoot alibaba等等等等，然后每个架构师再在这些公用性较强的架构基础上，再搞一个自己的框架出来才会有成就感；

(1) 软件框架

先从最近很火爆的低代码平台说起吧！

从10年前接触到低代码平台到如今，低代码平台的发展已经迭代了很多类型出来了。简单归类为如下集中

A) 通过拖拉拽和设置的方式生成数据字典和功能表单

B) 通过拖拉拽生成数据字典和表单，设计完基本功能后，一键生成整个基本功能的源代码；

C) 只能生成前端页面的代码；后端不予支持。

D) 微服务架构代码脚手架+前端拖拉拽生成前端页面代码；这种其实本质并不是一个低代码生成器，二是一个功能较为强大的技术框架+前端代码生成工具；

第一种入门的门槛较低，但是，限制也较多，离开这个开发平台寸步难行，比如多个子系统只能全部寄宿在这个低代码平台，逻辑太复杂的地方需要先开发平台来支持，不能支持的就只能通过在数据库中编写存储过程来实现；数据量大了效率低下，集成其它组件非常麻烦，特别是有行业特性的组件，系统集成也很麻烦，界面难看，生成的B/S界面不灵活；当然，最大的问题就是开放性不够，只能在现有平台提供的功能里设计和开发，且数据量并发很低，不适用与大型平台和并发量较大的系统；金蝶的BOS也属于这种，但是由于限制太多，只能作为金蝶ERP扩展功能使用；若想利用低代码平台开发复杂功能或整个模块，则较为困难；

第二种则相对较为灵活，其本质是一个代码生成器，但是呢，又可以把基本的功能提前生成出来并内置好部分公用组件，可扩展性较高；

第三种在互联网行业用得较多，因为他们已经有了成熟的数据中台，所有的业务逻辑大部分都是通过中台抽取出来再简单组合即可，这样，大部分的工作量就集中在前端；所以比较适用于业务比较成熟且系统成熟度较高的企业；

最后一种比较适用于中大型信息系统了。常用的组件都已经集成在软件开发架构里了，比如工作流引擎，权限管理模块，微服务接口的发布，鉴权及限流，消息模块的集成，公用组件类的集成（且可以后续扩展），前端界面要求不高的直接用内置的代码生成器工具直接生成。要求较高的则有专业前端来开发和调整。各个业务模块可以在架构设计最初做好切割，方便分布式发布，且各个模块分布式发布都可以自成一体，配置对应独立的业务数据库和LB；

(2) 优劣势结论

从如上分析可以看出，各种架构和模式适用的场景不同，针对小微系统，可以随意选择如上A和B，针对中型系统，可以选择C，针对大型系统，只能选择D了。

3，基于微服务的脚手架

(1) 架构图

这里架构图只给出了一组nginx，主要是示例gateway的LB，实际上，微服务端（即每个Gateway都可以切割成一组独立的业务模块）是可以按业务领域切割部署，每个领域单独部署一组nginx服务器；其对应的数据库也是可以按组部署单独的多节点以及读写分离；

(2) 框架功能说明

(3) 开发简介

① 所有的业务逻辑均到指定的业务逻辑层直接编写，测试后就可以作为微服务发布出来；

② 需要用到如上框架说明的功能的，无需从0开发，直接使用现有的集成好的接口即可，门槛低，上手快；如工作流，微信，支付宝收款，API微服务鉴权，文件系统等；

③ 前端页面早期可以安排专业前端设计好几个常用类别，后续其它类似界面后端开发人员只要能够简单看懂前端代码即可稍作修改，直接使用；简单的前端页面可以利用框架自带的拖拉拽设计器设计出来，然后复制代码后根据需要调整即可。

④ 所有的组件均集成好拆箱即用；

⑤ 支持服务器群组和负载均衡；

本文地址：https://www.cknow.cn/archives/11249

以上内容源自互联网，由百科助手整理汇总，其目的在于收集传播生活技巧，行业技能，本网站不对其真实性、可靠性承担任何法律责任。特此声明！

如发现本站文章存在版权问题，烦请提供版权疑问、侵权链接、联系方式等信息发邮件至candieraddenipc92@gmail.com，我们将及时沟通与处理。

赞 (0)
上一篇 2022年11月12日 23:52
下一篇 2022年11月13日 00:13

相关推荐