门户网站百度百科,网页设计 效果图,怎么优化自己网站,科技公司网站模板下载软件开发实际上跟英语比较类似#xff0c;都是一项工具#xff0c;服务于各行各业。从程序员的个人修养上来讲#xff0c;一是要研习好软件开发这门技艺#xff0c;二是要深入到所服务的行业。说到底#xff0c;软件的终极目标是模拟业务#xff0c;在此期间常常会有一个… 软件开发实际上跟英语比较类似都是一项工具服务于各行各业。从程序员的个人修养上来讲一是要研习好软件开发这门技艺二是要深入到所服务的行业。说到底软件的终极目标是模拟业务在此期间常常会有一个认知层面的小误会即软件开发人员在入行之初所学习的都是与计算机、编程语言相关的知识于是就形成“只需要把代码写完”事情就算完成的观念显然这远远不及对软件架构师所要求的业务主导意识。最近在看王概凯(Kevin)的《聊聊架构》其中特别强调软件架构师应深入到业务中并以业务的问题是否解决作为工作优良的判断标准比较受启发接下来我也根据过往工作经历说说自己的感知和体会。软件所模拟的业务行为其核心也在于数据它们共同表达的都是行为背后的状态和结果先看看下图在明确了业务主体后业务目标自然就可以得到聚焦有了清晰的业务目标就值得花精力来探知业务的生命周期接下来就可以像外科手术医生一样细致地实行架构拆分。由此可见软件架构师在实行架构拆分行为时基本上都把业务从头到尾捋了一遍否则势必陷入设计不足或过度设计的漩涡。软件架构师需要走出时间困境好的架构拆分是基于对业务的正确认识但业务这个东西往往总令人心生畏惧。在众多的传统企业中信息技术部肩负起了全集团、全公司的以业务为导向的信息化重担。依靠所有成员去解构业务是不现实的这时候软件架构师或者项目负责人就需要迎难而上积极参与到需求分析中。可以肯定的是只有直面业务的人才能真正体会到按时、按需解决业务问题所面临的时间压力这种压力的源头恰是职业人的天性因为人们总倾向于认为自己从事一个行业然后精通该行业就可以殊不知软件行业其本质就是服务业那么作为软件架构师则必须超越对时间、对业务的恐惧认识到需要解决问题的主体是业务人员而非自己即需要解决的问题是“非软件行业”的问题自己是在协助业务人员解决问题从这个层面来讲工作是否完成其实是由业务人员决定的而不是软件架构师自己。倘若选择避重就轻尽管在短时间内部署上线了但问题并未真正得到解决业务部门的催促又会加重后续任务的时间压力。况且仅仅以做好自己的编程工作为主要目标并试图用自己的软件知识去理解另一个行业又很容易陷入沟通困境。在 2016 年才加入申通快递不久就接到客服部关于开发备案系统的诉求这个系统是涉及到全国网点在备案请求提交后会由上级机构审核。我在接到这个任务的时候首先按常规把会议记要过了几遍然后对其中的审核功能做了重点铺开想像。我的脑补过程是这样的首先它涉及到多机构递交审核那么这期间有没有可能出现并行会审的情形当流程出现退回时又该如何处理要不干脆上一套流程框架吧但发现 .NET 平台下开源的框架并不多那就考虑 Java 平台的 Activiti 吧可转而发现更换平台的成本又太高而且照这样做下去在预定的时间内恐怕很难交付。况且这个审核功能还只是所有问题之一困惑之余觉得还是要主动跟业务代表客服部做二次沟通。通过主动出击了解到审核的节点只有三步左右只需采用最常见的串行单审即可并不需要太多的复杂步骤。得到这样的答复后可谓喜出望外回来的路上就想好了基于状态模式的实施方案这样减去了引入各种工作流框架的麻烦重要的是对时间压力和对交付 deadline 的焦虑减轻了许多。虽然这个例子可能相比较于很多大型系统来说有点偏小或者说是带有运气成份但至少可以说明积极地与需求方沟通能在很大程度上减小实现与需求的误差以及自身对业务和时间的恐惧。这里包含了一个隐形的要求即软件架构师需要把对编程上的职业成就感适当的转移到解决业务工作中把完成业务工作作为自己的最大利益。如此随着对业务的熟悉那么对时间的恐惧便会慢慢消失。软件架构师应树立生命周期的意识人的生命周期无非是出生、成长、衰老直至死亡而软件亦同根据核心生命周期和非核心生命周期之分通常可以把非核心的部分分工出去让新进人员来承接锻炼并促成其快速地融入大团队的协作。不妨思考一个问题软件开发生命周期和软件运行生命周期哪一个更偏向于核心生命周期呢通常企业开发一款软件的目的就是拿来使用的其效益的持续提升依靠的正是软件的稳定运行所以我觉得软件运行生命周期或者说运维才是核心。可以稍微再提一提关于对非核心生命周期的分工问题这是软件架构师需要日常考虑的问题。分工即拆分而架构的拆分从本质上来讲也是一种利益的重新分配毕竟每个人处理问题的承受力总是有限的这就需要把一些非核心的业务分拆出去无形中也是让自己走出时间困境的有效办法。然而在甄别一项业务是否为核心业务的时候就需要特别仔细倘若对相关人的利益分析不透彻便极易导致架构无法落地。理解到了业务的主体及其生命周期后就可以安心的做架构方面的拆分从而形成不同的软件生命周期从大的方面通常包括有开发和运行周期。软件开发生命周期开发的生命周期其实就是代码的累积过程它以项目启动为始然后和业务人员学习业务并形成需求文档进而编码、测试以达到正确模拟现实业务的效果最终得以部署上线这时开发生命周期就终止了。最值得注重的其实是在开发之前就需要为软件的运行来考虑一系列的资源比如机器、子域名申请以及监控等等所以软件架构师在统筹方面需要更多的前瞻。2017 年下半年我参与到了申通快递的自动分拣项目中这又是一个涉及全国各地的系统而且是专为各大型转运中心所使用为提升数据分发和故障排查等方面的效率我们寻思着先从消息队列和监控两方面来改进。全新启用的开源消息队列 RabbitMQ 很好的帮我们桥连起各个子系统它自身所带的监控页面也帮我们在日常运维上省了不少心。趁此机会又梳理了自动分拣项目所涉及的全部服务器以期望并入统一的监控体系中这时我想起了孙宇聪在高可用架构里提到的《SRE: Google运维解密》大致解决办法还是在每台机器上运行一个代理程序那我姑且就叫“埋点”吧通过这样简单又很有效的方式对各子系统的运行状况做了监控初步就以发短信的形式通知到组内人员这样第一时间便能知晓线上运行状况。其实软件开发的过程可谓是八仙过海各显神通。每一位软件架构师或者项目负责人能依据不同企业环境将软件构建出来就是最大的成功究竟是采用传统的瀑布式(Waterfall)或是新兴的敏捷(Agile)迭代甚至是两相结合都无可厚非我最想强调的是对外沟通即上面提到的对获取各项资源的前瞻性。毕竟“外行人”并不知道开发中的细节不清楚我们一天到晚坐在那儿究竟在干什么所以我们要对外保持 Open 状态并显现出沟通的意愿。软件运行生命周期软件运行生命周期才是一个软件真正的开始一个有价值的软件从它启动的那一刻开始就已经为企业带来了效益所以运行生命周期即运维才是真正的核心竞争力。运维的业务目标很简单即保证软件稳定地被用户访问那么风险控制工作便是重中之重。首先是隔离措施。软件的开发生命周期通常是日常办公环境而软件运行周期则是服务于用户的因此要区分出办公环境或测试环境和生产环境。以我目前熟悉的快递行业上规模的企业基本都有自建机房和运维团队其电源、网络、空调、排风都是一体化的独立管控。其次是控制变更。这里面还划分有被动变更和主动变更被动变更包括机器主板或硬盘的损坏以及用户访问量的突增等等这时候作为软件架构师就需要警醒一下必要时提醒运维人员针对上线的子系统做好负载均衡小型应用通常保持两台机器面向全国全网的应用就需要考虑四台以上机器了。主动变更多半情况下指的是频繁的发布更新为了最大程度的降低影响面要确保在指定地点、指点时间进行变更并让所有的运维人员知情。从安全和便利角度考量往往还会用到运维堡垒机如果要求更为严苛还可以从帐号、公钥等方面进一步来加强。在软件运行这样一个最为核心的生命周期中发布更新的质量直接影响到企业信息部门的运维表现结合孙宇聪的诸多建议我也列举一些值得注意的要点线下测试Offline Test。重点检查线下测试环境是否完善除此之外还需要产品人员和开发人员的督促。除了一般的代码逻辑测试尽量再兼顾到压力测试。灰度发布Gray Released。指的是根据业务特点、数据特点来选择一批有极强代表性的线上服务器实例进行发布其发布的比例可以考虑按 1%、10%最后 100% 这一指数型方式来增长。这样有利于把新上线功能可能的不良影响降到最低当然也可以作为小范围收集用户的反馈意见以待完善产品功能。灰度发布可以视作是上线前的最后一道安全防护机制。回滚机制Rollback。一般来说用上一个版本的相关程序集进行覆盖即可但有时还会出现数据格式的兼容性问题。比如数据库表字段的类型此前发生了变化那这时候还需要有配套的回滚 SQL 脚本。另一种情形是新的变更内容把数据删掉了回滚后数据也回不来了这种情况是没有补救措施的建议的做法是将程序代码分成两块逻辑先发布第一段逻辑并记录好日志等发现没有问题后再将删除的代码作为第二次发布。在实际工作中开发生命周期和运行生命周期往往是并行存在的。在软件部署上线后总会不断地进行修改比如出现了 Bug或者是要增加新的需求这时软件的开发、测试以及部署流程就需要再迭代一遍。无论新需求的开发多么重要都要摆正软件运行生命周期的核心位置。不管是软件架构师还是软件开发人员通常都很专注于技术以致于不太重视各种技术背后的业务使得技术与应用总是无法较好的相融。计算机相关的技术围绕的核心点始终是如何让用户能够更好的使用软件这背后千丝万缕的业务关系无不是源于现实生活所以认真工作之余还可以多读一些人文历史并走进生活以获取灵感。原文地址:https://www.cnblogs.com/ramantic/p/9022828.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
