获得徽章 9
这几天终于把要上线的项目，划分了模块，以及指定了对应的开发人员。准备开始撸技术方案和代码了。
不容易呀，之前折腾环境、工程和需求，到了今天，终于可以撸代码了，俺手都开始痒痒了，很想撸代码。
话说老板已经出了未来两年的it规划了，后续有的撸了。
【一个39岁中年it大叔的日常】
不容易呀，之前折腾环境、工程和需求，到了今天，终于可以撸代码了，俺手都开始痒痒了，很想撸代码。
话说老板已经出了未来两年的it规划了，后续有的撸了。
【一个39岁中年it大叔的日常】
展开
3
4
逛了一圈脉脉，发现之前认识的一些cto，离职后，在脉脉上备注的过往经历，都是写着担任技术负责人，似乎不敢写cto了，
。
这年头，cto是个蛮危险又压力大的岗位。
。这年头，cto是个蛮危险又压力大的岗位。
3
4
昨天终于把环境（开发环境、测试环境、线上环境）折腾起来了。技术选型大概如下:
1、nacos、mysql、rocketmq、java17、redis5、SchedulerX、docker、阿里docker镜像存储、ng、spring boot、spring cloud、dubbo；
2、dms（数据管理组件）、云效流水线、云效代码仓库和私服；
已经能使用云效流水线，从构建到打包到部署，一次搞定。后续后端开发人员能自行上线，无须专业运维。
架构分层这块，则借鉴了DDD，分布式微服务框架，则使用spring cloud alibaba，工程搭建和基础组件也都搞定了，下周可以开始项目的技术设计和撸代码了。
1、nacos、mysql、rocketmq、java17、redis5、SchedulerX、docker、阿里docker镜像存储、ng、spring boot、spring cloud、dubbo；
2、dms（数据管理组件）、云效流水线、云效代码仓库和私服；
已经能使用云效流水线，从构建到打包到部署，一次搞定。后续后端开发人员能自行上线，无须专业运维。
架构分层这块，则借鉴了DDD，分布式微服务框架，则使用spring cloud alibaba，工程搭建和基础组件也都搞定了，下周可以开始项目的技术设计和撸代码了。
展开
评论
4
我自己是如何判断微服务拆分的粒度的?
有几个判断维度：
1. 开发团队的人数:如果开发团队的人数非常少，而拆分的微服务非常多，那会影响上线、运维、维护和研发效能的。同样，如果开发人员已经非常多了，但是还是单体应用的话，那在并行协作开发上，就会有很大的障碍，会有各种冲突问题要解决，且也加大了维护系统稳定性的难度；
2. 核心业务系统的稳定性:核心业务系统是要单独剥离出来，避免受到其他边缘的影响。核心系统出问题，会影响业务的；
3. 系统水平伸缩能力:当用户体量上来后，系统需要能快速扩容，以应付更大的流量。另外在做营销活动的时候，也需要应付瞬时大流量；
4. 边界：确定业务边界和应用边界，有助于分析微服务拆分的粒度问题。
综合这个几个维度，在根据公司it团队当前的实际情况，进行取舍和平衡。
有几个判断维度：
1. 开发团队的人数:如果开发团队的人数非常少，而拆分的微服务非常多，那会影响上线、运维、维护和研发效能的。同样，如果开发人员已经非常多了，但是还是单体应用的话，那在并行协作开发上，就会有很大的障碍，会有各种冲突问题要解决，且也加大了维护系统稳定性的难度；
2. 核心业务系统的稳定性:核心业务系统是要单独剥离出来，避免受到其他边缘的影响。核心系统出问题，会影响业务的；
3. 系统水平伸缩能力:当用户体量上来后，系统需要能快速扩容，以应付更大的流量。另外在做营销活动的时候，也需要应付瞬时大流量；
4. 边界：确定业务边界和应用边界，有助于分析微服务拆分的粒度问题。
综合这个几个维度，在根据公司it团队当前的实际情况，进行取舍和平衡。
展开
评论
1
昨天终于在阿里云购买了当前所需要云资源，今天准备开始搭建环境了。
【开发环境】
为了节约成本，业务型的微服务就直接在开发人员的本地电脑上启动就行，毕竟刚开始微服务就几个。而像中间件、mysql、redis等则部署在开发环境里。就相当于是，这种环境，属于本地环境+开发环境的方式。虽然low，但其实目前是够用的；
【测试环境】
测试环境的话，就需要单独搭建了。开发人员在开发环境自测完后，可以到测试环境里进行功能测试和联调。
【生产环境】
这个当然是严格的跟其他环境隔离的，单独的。
搭建环境，当然不止这些事情，还有如下一堆的事情。
第一，maven私服，直接用阿里云免费版的私服；
第二，代码仓库，直接用阿里云免费版的云效codeup
第三，发布流水线，也是直接使用阿里云效的流水线。可以让开发直接用流水线部署应用；
第四，数据库管理，这块是付费买了阿里的DMS，之所以付费，是想用它的审核机制等功能，毕竟做线上变更，一定要谨慎。且dms还有很多很多强大的功能；
还有很多内容没讲，这个后面等有空，写一些文章，详细说一下。
【开发环境】
为了节约成本，业务型的微服务就直接在开发人员的本地电脑上启动就行，毕竟刚开始微服务就几个。而像中间件、mysql、redis等则部署在开发环境里。就相当于是，这种环境，属于本地环境+开发环境的方式。虽然low，但其实目前是够用的；
【测试环境】
测试环境的话，就需要单独搭建了。开发人员在开发环境自测完后，可以到测试环境里进行功能测试和联调。
【生产环境】
这个当然是严格的跟其他环境隔离的，单独的。
搭建环境，当然不止这些事情，还有如下一堆的事情。
第一，maven私服，直接用阿里云免费版的私服；
第二，代码仓库，直接用阿里云免费版的云效codeup
第三，发布流水线，也是直接使用阿里云效的流水线。可以让开发直接用流水线部署应用；
第四，数据库管理，这块是付费买了阿里的DMS，之所以付费，是想用它的审核机制等功能，毕竟做线上变更，一定要谨慎。且dms还有很多很多强大的功能；
还有很多内容没讲，这个后面等有空，写一些文章，详细说一下。
展开
评论
4
上周终于把上阿里云需要的预算整理出来了，需要的云资源不多。之所以选择阿里云，而没有选择华为云或者腾讯云，有如下几个原因:
第一，团队的人，都比较熟悉阿里云，上手会比较快；
第二，我之前认识的运维，基本用的都是阿里云，万一我这边搞不定，也可以请教一下他们。毕竟目前技术团队里，是没有专业运维的；
第三，阿里提供的整套组件，比较全，且可以大大的降低运维门槛；
第四，目前阿里云那边还是活动期间，价格也比较实惠，尤其是针对新用户。且还可以使用阿里云代理商，享受渠道折扣，相当于是折上折了。老板还是比较看中成本这块的；
第五，阿里云用的人也确实比较多，有问题的话，阿里云的文档或者百度谷歌一下，基本也能找到解决方案。
第一，团队的人，都比较熟悉阿里云，上手会比较快；
第二，我之前认识的运维，基本用的都是阿里云，万一我这边搞不定，也可以请教一下他们。毕竟目前技术团队里，是没有专业运维的；
第三，阿里提供的整套组件，比较全，且可以大大的降低运维门槛；
第四，目前阿里云那边还是活动期间，价格也比较实惠，尤其是针对新用户。且还可以使用阿里云代理商，享受渠道折扣，相当于是折上折了。老板还是比较看中成本这块的；
第五，阿里云用的人也确实比较多，有问题的话，阿里云的文档或者百度谷歌一下，基本也能找到解决方案。
展开
1
点赞
目前开发人员只有几个人，只能一边当开发，一边当运维了。云服务购买，环境搭建，工程搭建，基础组件搭建，代码开发，都得自己来。不过呢，在技术这块，也相对自由一些。
也算干的不亦乐乎哈。
也算干的不亦乐乎哈。
28
9
了解一个人的品性和能力是需要时间的，而这个相互认识的时间只能是入职之后。可能要3个月或者更长的时间才能真正了解一个人。
因此绝大多数公司在招聘的时候，会特别的看候选人的学历（学习能力，聪明程度，悟性）、履历（实战经历）。这一关通过后，才进入面试，在短短的几轮面试中，也只能初步的了解候选人。
面试也通过了后，有时候不放心，想知道候选人的真实综合能力到底怎样的时候，就会开始背调了。
因此学历、履历、背调，我觉得都是正常的操作，毕竟没有共事过，真不知道候选人到底是什么样的人。
只能通过一些手法，尽量的去了解。
到了这里，也就应该能知道，为啥内推是相对而言比较靠谱的招聘方式，毕竟知根知底的。像我最近入职的一家创业公司，我是优先找认识的人，因为知道他的真正能力是怎样的，这样可以降低招聘风险。
因此绝大多数公司在招聘的时候，会特别的看候选人的学历（学习能力，聪明程度，悟性）、履历（实战经历）。这一关通过后，才进入面试，在短短的几轮面试中，也只能初步的了解候选人。
面试也通过了后，有时候不放心，想知道候选人的真实综合能力到底怎样的时候，就会开始背调了。
因此学历、履历、背调，我觉得都是正常的操作，毕竟没有共事过，真不知道候选人到底是什么样的人。
只能通过一些手法，尽量的去了解。
到了这里，也就应该能知道，为啥内推是相对而言比较靠谱的招聘方式，毕竟知根知底的。像我最近入职的一家创业公司，我是优先找认识的人，因为知道他的真正能力是怎样的，这样可以降低招聘风险。
展开
1
2
在失业的三个月里，还是认真的把之前在极客时间里购买的课程，再次学了一次。还别说，真有些用。至少在面试的时候，一部分知识还是会被问到。
当然我没看的特别的细致，只是把一些知识回顾一下，同时也扩展一下知识面。对于我这个年纪而言，知识面是否广，是很重要的，尤其是去面试一些级别高一些的岗位，这点尤其重要。
当然我没看的特别的细致，只是把一些知识回顾一下，同时也扩展一下知识面。对于我这个年纪而言，知识面是否广，是很重要的，尤其是去面试一些级别高一些的岗位，这点尤其重要。
展开
评论
6
在今年it环境如此差的情况下，想找到还可以的工作，有几个关键点：
最重要的是运气，某某公司刚好放出了某某职位，而你的职业履历和技能刚好也还匹配，然后有了面试的机会；
行业匹配度，现在看来，这点很重要。当你艰难的获得了面试机会后，行业经验几乎可以决定你能否拿到offer。比如说你在茶饮或者餐饮行业做过，对方需要你的经验，然后才能开始正经的好好的谈。现在好多岗位jd里，会把是否做过某个行业作为硬性要求；
剩下才是你的技能，这块的话，如果你目前已失业一段时间了，那么切记，要多准备多梳理多学习，不能在家躺平，因为当有了机会后，如果这块太差，那机会你就接不住。
以上是我最近失业后，找到工作后的一些体验。最后想说的是，在职业生涯里，总会有你的高峰期，然后开始慢慢下降，这个不可避免。我们也只能努力找第二增长曲线，慢慢再创高峰。
最重要的是运气，某某公司刚好放出了某某职位，而你的职业履历和技能刚好也还匹配，然后有了面试的机会； 行业匹配度，现在看来，这点很重要。当你艰难的获得了面试机会后，行业经验几乎可以决定你能否拿到offer。比如说你在茶饮或者餐饮行业做过，对方需要你的经验，然后才能开始正经的好好的谈。现在好多岗位jd里，会把是否做过某个行业作为硬性要求；剩下才是你的技能，这块的话，如果你目前已失业一段时间了，那么切记，要多准备多梳理多学习，不能在家躺平，因为当有了机会后，如果这块太差，那机会你就接不住。以上是我最近失业后，找到工作后的一些体验。最后想说的是，在职业生涯里，总会有你的高峰期，然后开始慢慢下降，这个不可避免。我们也只能努力找第二增长曲线，慢慢再创高峰。
展开
10
9
今年大环境好差，你会发现，某家公司刚把新职位放出来，隔天HR就把招聘岗位关闭掉了，原因是，一下子N多人去应聘。太多人在找工作了，且都竞争同一岗位，醉了。
4
2
对于做技术管理的人来说，【如何让自己的位置做的稳】，是一个需要时时去考虑的问题。但是呢，只要是带团队的manager，【你的位置是否做的稳，并不是你能控制的】。
第一，它会依赖于你的上级以及上级的上级是否做的稳，他们都不稳了，你也经常会受到波及。在我自己的10几年的职业生涯里，真实的遇到过几次了。
第二，它会依赖你的公司的业务发展是否顺利，当不顺的时候，管理岗位的就会岌岌可危；
第三，它会依赖于公司的发展阶段，有时候大老板会突然觉得，当前公司不需要那么多管理者；
只要带团队的，由于岗位的职责就在那，注定就是压力大、风险高的。
第一，它会依赖于你的上级以及上级的上级是否做的稳，他们都不稳了，你也经常会受到波及。在我自己的10几年的职业生涯里，真实的遇到过几次了。
第二，它会依赖你的公司的业务发展是否顺利，当不顺的时候，管理岗位的就会岌岌可危；
第三，它会依赖于公司的发展阶段，有时候大老板会突然觉得，当前公司不需要那么多管理者；
只要带团队的，由于岗位的职责就在那，注定就是压力大、风险高的。
展开
评论
1
作为技术管理者，有时候【少写代码】是被逼的，就是说【不是你不想多写代码】，而是你压根就做不到。有如下几种情况，会导致你没时间写代码。
第一，你的上级和上级的上级，太喜欢搞制度和流程的东西了，但是团队的人意识和能力又一般，不喜欢被约束。于是就得有所谓的【一个管理者】花大精力去协调；
第二，业务系统的完整性太差了，没有管理后台，产品功能缺胳膊少腿的，导致到处都需要做很多【人工手工的支持】，你会时时刻刻被打断的，你的每个工作日里，几乎没有一个完整的时间段；
第三，你的上级和上级的上级，太喜欢开会了，啥事都需要开会，一天下来，得开几个小时的会议；
在这样的环境下做技术管理者，很容易导致【自废武功】的，因为【写代码的能力】是永远都不能丢的。
如果你在一家公司里做技术管理，管理时间占30%，开发时间占70%，那就挺好的了。
奉劝一句，写代码的比例太少的【技术管理者】，在最近几年【不太好找到合适的工作】。
第一，你的上级和上级的上级，太喜欢搞制度和流程的东西了，但是团队的人意识和能力又一般，不喜欢被约束。于是就得有所谓的【一个管理者】花大精力去协调；
第二，业务系统的完整性太差了，没有管理后台，产品功能缺胳膊少腿的，导致到处都需要做很多【人工手工的支持】，你会时时刻刻被打断的，你的每个工作日里，几乎没有一个完整的时间段；
第三，你的上级和上级的上级，太喜欢开会了，啥事都需要开会，一天下来，得开几个小时的会议；
在这样的环境下做技术管理者，很容易导致【自废武功】的，因为【写代码的能力】是永远都不能丢的。
如果你在一家公司里做技术管理，管理时间占30%，开发时间占70%，那就挺好的了。
奉劝一句，写代码的比例太少的【技术管理者】，在最近几年【不太好找到合适的工作】。
展开
9
3
做技术管理的，到底是聚焦于技术还是聚焦于管理呢? 也很多人来问我这个问题。我自己的想法是，如果你是做技术管理的，就不要跟谁谁比什么技术细节了，你只要在技术架构、技术方案、技术规划上，能给出解释和决策，那就行了。能做到这样，对于技术管理者而言，在【技术】这块，你已经是合格了，可以聚焦于管理了。
3
2
下面几个事情挺影响研发效能的：
第一，技术系统划分不清晰，导致每次做需求的时候，开发人员需要一下子改动N多个服务；
第二，产品线没有划分清楚，会让产品经理不知道重点聚焦做什么， 他需要承担的最重要的任务是啥，然后技术团队跟着遭殃；
第三，组织架构不合理，到底选择职能组织架构，还是产品架构，还是矩阵架构，大老板没啥想法，他不知道在当前公司，选用哪种组织架构是最合理的，导致一堆的沟通、效率问题；
第四，其中某条职能线的人太少了，比如说前端开发太少了，UI设计人员太少了，变成瓶颈了；
你可能你觉得你在以前的公司，项目交付还挺快的，那肯定是你之前的公司的某些领导做对了以上的几点或者一部分。
第一，技术系统划分不清晰，导致每次做需求的时候，开发人员需要一下子改动N多个服务；
第二，产品线没有划分清楚，会让产品经理不知道重点聚焦做什么， 他需要承担的最重要的任务是啥，然后技术团队跟着遭殃；
第三，组织架构不合理，到底选择职能组织架构，还是产品架构，还是矩阵架构，大老板没啥想法，他不知道在当前公司，选用哪种组织架构是最合理的，导致一堆的沟通、效率问题；
第四，其中某条职能线的人太少了，比如说前端开发太少了，UI设计人员太少了，变成瓶颈了；
你可能你觉得你在以前的公司，项目交付还挺快的，那肯定是你之前的公司的某些领导做对了以上的几点或者一部分。
展开
评论
1
对于大部分的中小公司而言，如果你是个基层管理者，那少去跟产品经理较劲什么需求价值的问题，你这个位置的，最重要的是，解决效率的问题。如何尽量提高需求的交付速度和质量，才是你应该重点考虑的事情。
中层管理者，比如技术总监的，我也是觉得，重点投入在效率这块。只有像管着产品经理的CTO，才需要重点的去考虑，需求的价值问题。因为他管着产品经理，同时汇报对象又是公司的最高管理层。因此CTO肯定是要想着，如何汇报的问题。
中层管理者，比如技术总监的，我也是觉得，重点投入在效率这块。只有像管着产品经理的CTO，才需要重点的去考虑，需求的价值问题。因为他管着产品经理，同时汇报对象又是公司的最高管理层。因此CTO肯定是要想着，如何汇报的问题。
展开
1
2