学习了项目群管理后,我深受启发,在此发表下自己的一些个人感想. 项目群是指经过协调统一管理以便获取单独管理时无法取得的效益和控制的一组相互联系的项目. 项目群中的项目需要共享组织的资源, 需要进行项目之间的资源调配. 项目群管理是指为了实现组织的战略目标和利益, 而对一组项目(项目群) 进行的统一协调管理. 项目群管理需要运用知识和资源, 来界定.计划.执行和汇总客户复杂项目的各个方面. 我认为项目组管理的模式应如图1所示. 项目群管理是建立在统一目标的基础上的管理模式,其要解决的核心问题是是如

注意,这是我的架构实践心得的第二季的系列文章,第一季有10篇你也可以回顾. 见https://www.cnblogs.com/lovecindywang/category/1296779.html 最近我一直在思考几个问题: 业务代码究竟难不难写? 一直开发业务代码是不是完全学不到东西? 5年+开发经验的老程序员的价值在哪里? 如何通过面试来区分业务代码开发的水平? 其实,这几个问题或多或少是相互关联的.有的时候大家也会自嘲说,"程序员接手的代码永远是烂摊子,然后自己继续在这个烂摊子上产出代码,

朱晔的互联网架构实践心得S1E8:三十种架构设计模式(下) [下载本文PDF进行阅读] 接上文,继续剩下的15个模式. 数据管理模式 16.分片模式:将数据存储区划分为一组水平分区或分片 一直有一个说法就是不到没路可走的时候不要考虑数据库分片.有的时候业务量大到单个业务表在经过缓存+队列削峰等措施之后的平均的TPS超过1万,单表实在是扛不住,还是只能考虑分片手段. 分片前: 需要根据数据分布.压力情况.业务逻辑确定分片的方式,按照条件还是范围还是哈希等等(三个图展示了三种策略). 需要进行业务代

朱晔的互联网架构实践心得S1E10:数据的权衡和折腾[系列完] [下载本文PDF进行阅读] 本文站在数据的维度谈一下在架构设计中的一些方案对数据的权衡以及数据流转过程中的折腾这两个事情.最后进行系列文章的总结和之后系列文章写作计划的一些展望. 数据的权衡 正所谓鱼和熊掌不能兼得,舍了才能得.架构或技术设计方案中针对数据这个事情,有太多体现了权衡思想的地方. 空间和时间 我们来想想有哪些广义上空间换时间(性能)的例子,也就是通过使用更多的存储或内存空间加快了任务的单次执行速度或总体吞吐量: 让数据

朱晔的互联网架构实践心得S1E9:架构评审一百问和设计文档五要素 [下载文本PDF进行阅读] 本文我会来说说我认为架构评审中应该看的一些点,以及我写设计文档的一些心得.助你在架构评审中过五关斩六将,助你写出能让人收藏点赞的设计文档. 技术架构评审 架构评审或技术方案评审的价值在于集众人的力量大家一起来分析看看方案里是否有坑,方案上线后是否会遇到不可逾越的重大技术问题,提前尽可能把一些事情先考虑到提出质疑其实对项目的健康发展有很大的好处.很多公司都有架构评审委员会都有架构评审的流程,做业务的兄弟要

朱晔的互联网架构实践心得S1E7:三十种架构设计模式(上) [下载本文PDF进行阅读] 设计模式是前人通过大量的实践总结出来的一些经验总结和最佳实践.在经过多年的软件开发实践之后,回过头来去看23种设计模式你会发现很多平时写代码的套路和OO的套路和设计模式里总结的类似,这也说明了你悟到的东西和别人悟到的一样,经过大量实践总能趋向性得出一些最佳实践的结论.架构设计也是一样,这里结合自己的理解分析一下微软给出的云架构的一些模式.话说微软干这方面的事情真的很厉害,之前翻译过的<微软应用架构指南>写的

朱晔的互联网架构实践心得S1E6:给飞机换引擎和安全意识十原则 [下载本文PDF进行阅读] 本文有两个部分,先介绍一下给飞机换引擎这个事情我的一些经验,因为篇幅较短然后介绍一下安全意识方面的一些心得. 给飞行中的飞机换引擎 所谓给飞行中的飞机(或飞驰的汽车)换引擎说的是我们需要对一个正在飞速发展的系统进行大幅度的架构改造,比如把All-in-one的架构改造成微服务架构,尽可能减少或消除停服的时间.一般而言,我们可以这么来考虑方案,从重构的彻底性来说,分为这么几种: 彻底重新做,直接从前到后抛弃

朱晔的互联网架构实践心得S1E5:不断耕耘的基础中间件 [下载本文PDF进行阅读] 一般而言中间件和框架的区别是,中间件是独立运行的用于处理某项专门业务的CS程序,会有配套的客户端和服务端,框架虽然也是处理某个专门业务的但是它不是独立程序,是寄宿在宿主程序进程内的一套类库. 图上绿色部分代表了框架,红色部分代表了管理系统,紫色部分代表了中间件.本文会着重介绍管理系统和中间件部分. 配置管理 比较知名的分布式配置服务和管理系统有携程的https://github.com/ctripcorp/apo

朱晔的互联网架构实践心得S1E4:简单好用的监控六兄弟 [下载本文PDF进行阅读] 这里所说的六兄弟只指ELK套件(ElasticSearch+Logstash+Kibana)以及TIG套件(Telegraf+InfluxDb+Grafana). 上图显示了两套独立的体系,ELK和TIG(TIG是我自己编出来的,网上没有类似于ELK这种约定俗成的说法): 这两套体系都由收集器+存储+展示网站构成,青绿色的收集器,蓝绿色的存储,红色的展示网站. 这两套体系都有免费的组件可以使用,安装配置也相对简单

朱晔的互联网架构实践心得S1E3:相辅相成的存储五件套 [下载本文PDF进行阅读] 这里所说的五件套是指关系型数据库.索引型数据库.时序型数据库.文档型数据库和缓存型数据库. 上图显示了一套读写服务搭配这五种类型数据库的例子: 1.    这里只是说明了我们可以这么来搭配这些类型的数据库,不是说我们所有的应用都需要用到这些类型的数据库. 2.    同步写服务负责第一时间把重要的数据落地和落缓存. 3.    异步写服务通过监听MQ来感知数据的变化,然后重新读取最新的数据来把数据写入其它次要数据

朱晔的互联网架构实践心得S1E2:屡试不爽的架构三马车 [下载本文PDF进行阅读] 这里所说的三架马车是指微服务.消息队列和定时任务.如下图所示,这里是一个三驾马车共同驱动的一个立体的互联网项目的架构.不管项目是大是小,这个架构模板的形态一旦定型了之后就不太会变,区别只是我们有更多的服务有更复杂的调用,更复杂的消息流转,更多的Job,整个架构整体是可扩展的,而且不会变形,这个架构可以在很长的一段时间内无需有大的调整. 图上画了虚线框的都代表这个模块或项目是不包含太多业务逻辑的,纯粹是一层皮(会调

朱晔的互联网架构实践心得S1E1:Pilot 最近几年写博客确实写得少了,初出茅庐的时候什么都愿意去写,现在写一点东西之前会反复斟酌是否有价值.工作十几年了,做了N多个互联网系统,业务涉及教育.游戏.电商.O2O.P2P,算是各种类型的互联网系统都摸过,多少有一些心得,架构方面的文章网上很多很多,有些是说一些方法论,有些是说一些具体的案例,感觉自己想分享的东西和别人已分享的是有点不同的,还是应该留下点什么.在这里我更多想分享一下搭建一套完整的互联网系统架构方面一些具体的实践心得,大概会从这几个方

前言 程序开发毕竟还不是搬砖这种无脑体力劳动,需要事先有标准,有架构,有设计,绝对不是新公司今天创立,明天就可以开始编码的.其实很多公司在起步的时候没有财力和资源建设独立的基础架构或平台架构部门,甚至运维团队都没有,但是这不妨碍我们心中有一个蓝图知道努力的方向,本文我们就简单聊聊平台架构相关的工作内容(或者说作为一个技术管理,应该去梳理.统一.明确的部分)的蓝图.由于本文覆盖的内容比较多,只能抛砖引玉大概提一些,无法一一展开太详细的东西.图中的数字是我认为的优先级,仅供参考. 规范 规范它虽然不

朱晔的互联网架构实践心得S2E6:浅谈高并发架构设计的16招 概览 标题中的高并发架构设计是指设计一套比较合适的架构来应对请求.并发量很大的系统,使系统的稳定性.响应时间符合预期并且能在极端的情况下自动调整为相对合理的服务水平.一般而言我们很难用通用的架构设计的手段来解决所有问题,在处理高并发架构的时候也需要根据系统的业务形态有针对性设计架构方案,本文只是列出了大概可以想到一些点,在设计各种方案的时候无非是拿着这些点组合考虑和应用. 有很多高并发架构相关的文章都是在介绍具体的技术点,本文尝试从根

刚开始接触LR的时候,做了一次内外网附件上传的并发测试,比较简单,但当时理解有些欠缺.以下为当时的实践心得: 1.分内外网测试的意义: 内网测试主要看负载压力情况等,外网测试主要考虑网络带宽.网络延时等.通过对比内外网结果,得知网络对附件上传速率的影响. 2.内外网测试对应的ip 内网对应内网网络.IP地址:外网对应外网网络.IP地址

嵌入式搬砖道路上的大三狗一枚,撑死算个初学者吧.才学有限,下面仅仅是本人对STM32学习的一点心得与建议,希望对题主有帮助吧. 心得:本人当初学习STM32的时候有一些跟风的因素,自以为学的芯片越多就越厉害 =_=. 其实,学习嵌入式重要的是整体的工程思想和项目经验积累,说到底这些芯片,我感觉学习起来都差不多吧,无非就是对内资源(寄存器.中断.定时器.串口等等),和对各种外设的操作而已,挂载的外设越多,系统会越复杂,这时可能会用上操作系统,同时,如果工程中涉及到各种算法.自动控制.采样.滤波等实

友情提示 本人喜欢直言不讳,不喜欢拐弯抹角.喜欢从客观和主观.自身和他人等多种角度去探讨问题.如有不当之处,欢迎吐槽. 若干心得体会1.企业客户的钱更好赚,个人客户的钱很难.  为什么这么说呢? a.企业有钱赚,为了更好地服务自己的客户,赚到更多的钱,花点钱,心甘情愿.只要你的商品和服务,不至于太坑. b.企业的功利心比较强,因此,非常有目标性,有动力,一定要解决自己遇到的问题. c.个人的付费意识很差,因为他们总认为自己赚的钱少,同时下意识地认为,别人花时间精力提供的服务或者劳动成果,不值钱.

首先要说的是,我这篇体会是针对一定的背景的,不能算是一种通用的管理方式,只能是我自己的经验总结,能给大家平常的管理提供一点思路,我就很满足了.先说说背景,我所在公司做的是大型桌面应用软件,简单点说就是软件规模达到3ds max或者office程度的软件.公司不做外包项目,单一产品,每年发一个新版本.每年的项目任务都是新功能.旧功能的升级.底层模块的整理,算法的实现等等.我个人入职将近6年,在公司实习期间表现还不错,因此毕业一进公司就赶鸭子上架开始带人做项目.由于软件规模很大,又是行业类软件,一个

近段时间使用html5开发一个公司内部应用,而触摸事件必然是移动应用中所必须的,刚开始以为移动设备上或许也会支持鼠标事件,原来是不支持的,好在webkit内核的移动浏览器支持touch事件,并且打包成app也毫无压力.原本以为touch事件应该跟鼠标事件是一样的道理,实践过程中虽然不难,但还是碰到了不少坑,才发现还是略有区别的. $(document).bind(touchEvents.touchstart, function (event) { event.preventDefault();

一.摘要: 今天在写一个页面,对css中的BFC(块级格式化范围)有了一点体会,今天把遇到的问题和解决方案总结下来,额外还总结一下强大的负外边距的使用心得. 二.总结: