工作中一些原则体会

Posted xiaoqiang-code

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了工作中一些原则体会相关的知识,希望对你有一定的参考价值。

尽可能让一切变得简单,用最简单的方式完成工作

能用最少的概念,最精简易懂的概念模型来抽象系统,多一个概念就多一份别人了解系统以及维护系统的复杂度,别人也会质疑多一个概念的意义所在,自己如果没想清楚就容易被diss。

特别是在类的设计中,会发现其实很多时候用一个类就可以表达要干的单一职责了,每个类职责清晰,类于类之间关系易于理解及维护。

设计系统时某些功能只在需要它时构建

对于这点深有体会, 特别是在对设计此类系统没有业务经验的时候,不要尝试第一次就构建一个所谓“完美”系统,系统是要面向迭代的,永远都是随时准备修改或增加功能,所以设计系统的目标不在于追求一次性构建完美全面的功能,而在于追求系统对功能支持的扩展性,是否能具有快速cover新业务需求,从而分秒迭代自身的能力。

并且业务是多变的,设计时满足好当前的功能需求,并预留扩展点,即使目前功能不完备,也能在未来快速构建它。

没必要过度设计,特别是在自身经验不丰富的情况下,意淫的美好都是太自我,虽然多思考敢于尝试是好事情,但还是要找高手明确好要做的事情,否则对开发人力的浪费。开发暂时不需要的功能会导致最“重要且紧急”的需求delay或bug风险

敏捷迭代思维

先学会爬,然后再学会走,最后学会跑。换句话说,先保证能够正常运行,然后优化它使其更好,最后逐渐让它变得完美。为每个功能制定一个开发周期(最多2周),然后不断迭代。

注重投资回报率

工作中会发现任务都是排着队的,至于任务队列的 compare方法怎么写,对于事情的四象限法则,事情的投资回报率是评估是否重要的重要考量。

功能的设计和测试尽可能独立。如果在设计时考虑到这一点,长远来看,它将省去很多麻烦,否则只有一切构建完成时你才可以开始测试整个系统。很多时候直到要测试某个功能的时候,才发现代码相互依赖,而无法独立测试某模块。

推行MVP(最小可行产品)

该理念的核心在于:先制定一些用例,完成用例所涉及的相关功能,立即发布产品,然后根据反馈和经验对产品进行优化。

在需求评审阶段尽可能明确要做的事情,知悉pm需求的业务意义,才能更好更明确的带着目标做事情,技术评审阶段,尽量想清楚需求边界及所需的技术和业务资源来评估好开发时间,并乘以一个系数作为交付时间(主要是为后期突然插入的事情留buffer),从项目生命周期开始,直到上线期间,和相关人员经常进行 关键步骤同步和确认,大家不会天天盯着你在做的事情,要主动同步进度,寻求反馈,可以避免方向走偏,同时方便对于领导也能掌控全局信息。

在多人协作过程中,流程规范化的意义,比如结论文档化,分支管理按照契约。大家都有了common sense,办公效率也是极大提高。

试想微服务系统节点较少,俩人协作的时候,信息的沟通等价于最简单的的Pub/Sub模型,信息的传递较为简单,大家都会把对方同步给自己的事情处理好,甚至还闲着没事儿催促你好几遍,因为每个人只订阅对方的消息,来源单一,处理起来不会遗忘。后来的后来系统复杂了(同事多了),你作为生产者有了好多个消费者同事,比如你要改一个接口,涉及到好几个其他模块开发者,你推动这次升级需要每阶段都push各方同事这时候有个问题:

除了其它端,发现 支付端 也需要升级你的接口,然后屁颠屁颠跑人家那又巴拉巴拉描述如何升级——每个消费者接入,都需要生产者开发适配新消费者的消息发送代码。

学会解耦

别忘了工作中你本身作为生产者同时也在订阅别人,总之你作为一个节点,你的所有peer消息你都要处理,消息量大还处理不过来,容易遗漏。要么是push消息,要么是处理别人的消息,对于push别人的消息,你还要做好“降级”,因为你告诉别人这样做了,你确保不了别人一定按你说的做,消息一多这个时候人脑子会很容易乱的,别人如果做错了,如果不承认你给他push过消息怎么办?你要背锅嘛。。。

怎么办呢? 引入业务消息中间件~

所以人多了就得学会解耦,每个模块都有人专门负责,模块间的沟通工作,需要一种协议来确保沟通准确性和解耦,上面说的是典型的同步rpc协议,意味着你要了解所有的消费者,还要处理新来的消费者,没有消息落盘,不可追溯。如果这个时候有一些文档或消息群来承载结论性的消息变更,大家都只需要跟踪这个文档或这个群就可以了,生产者就往里push消息,剩下的分布式消息处理一致性让别人来保证就可以了,哪一端没处理好,怪不了你了可。

首先不用处理对别方的降级,都按文档约定的来的,也同步给你了,对于新的消费者接入,看文档就好了。 每个人就只需要push消息到文档落盘,订阅别人的文档watch变更,大量消息落盘,个人可以异步消费,而不会丢消息,落盘的消息可重复消费,可记录历史,避免沟通的扯皮,确保研发环节的有条不紊。当系统更大的时候,每个人工作消息模式复杂度保持不变,这也是 消息中间件 消息消峰 解耦的意义。

还没关注我的公众号?

  • 扫文末二维码关注公众号【小强的进阶之路】可领取如下:
  • 学习资料: 1T视频教程:涵盖Javaweb前后端教学视频、机器学习/人工智能教学视频、Linux系统教程视频、雅思考试视频教程;
  • 100多本书:包含C/C++、Java、Python三门编程语言的经典必看图书、LeetCode题解大全;
  • 软件工具:几乎包括你在编程道路上的可能会用到的大部分软件;
  • 项目源码:20个JavaWeb项目源码。
    技术图片

以上是关于工作中一些原则体会的主要内容,如果未能解决你的问题,请参考以下文章

关于管理上的一些新的体会

团队工作心得体会Ⅱ

关于软件研发的一些体会总结

jvm性能调优的一点体会

实验2的一些心得体会

面向对象六大原则