我们在做软件开发时学到的很多思维、方法、工具、模型、算法……其实可以迁移到生活中使用,让我们生活得更美好哦。我这里暂举 7 个,以后有时间,慢慢补坑,争取补到 60 个。大家有兴趣的,可以留言补充你最有感觉的。
在网络编程中,客户端和服务器要通信,必须寻找特定端口,建立链接,遵守一定的协议,才能传输数据。比如 http、ftp、telnet、echo、rtp等协议,都是如此。这个过程,内含的道理就是:双方要沟通,先得相互调试,找到一个共同的频道和彼此都能接受的规则,才能有效完成数据交换。
这点应用在人际沟通上,是一个道理,为了让沟通有效果,达成目的,那你就要寻找对方的端口、协议格式等等,以对方能够接受的方式和ta聊,这样才能聊到一块去。
程序员都会用svn、git等版本管理工具管理自己的工作产出,提交代码时,还要写点日志,描述自己新增了什么features、修改了什么bugs,以便能够记住自己过去干了什么,必要时回滚。代码版本管理这点应用到生活中,就是我们要记录自己生活中的关键事件,比如取得的成功、很痛的失败,以便我们经常翻看,能够更好的生活。这就是,没有记录,就没有发生。
很多团队采用SCRUM运作项目,在SCRUM里,有个每日站会,每日站会,会问三个问题:
昨天完成了什么任务?
遇到了什么障碍?
今天准备做什么?
这一点,可直接拿来反省我们每天的生活。
比如,你可以每天早上使用5分钟回顾总结:昨天取得了什么进步?遇到了什么问题?然后再用5分钟做计划:今天准备做什么事情?养成了这样的习惯,苟日新、日日新、又日新,人生开挂不在话下。
操作系统在管理内存时,经常用到 一个算法——LRU(Least Recently Used,最近最少使用),把最近没用到的页面置换到硬盘上去,需要时再加载进来。
这个 LRU ,就是家中物品断舍离的原则:那些很久未用的东西,多半将来也很少有机会用到,可以直接扔掉或二手处理。比如你要整理衣服,取 3 年为阈值,3 年没穿过的,就扔掉,那就可以淘汰掉一大半衣服。比如你整理书籍,取 3 年为阈值,3 年没看过的,就扔掉,那就可以淘汰掉一大半废书。
我们写完代码编译时,编译器经常咆哮:你小子他娘的搞出1001个错误!我们虽然很不情愿,但很快就会乖乖的接受,动手去修改代码,解决问题。
可是我们生活中,往往不是这样乖巧的。我们是反着来!
比如我去年查出颈动脉粥样硬化,我就不能接受:“凭什么是我?我还不到四十!老天对我太不公平啦!”
比如男生张三和女生小兰竞争经理职位,小兰成功,张三败北。张三很可能就无法接受这个结果:“老子这么优秀,为什么偏偏不选老子当经理?这里面肯定有猫腻,说不定小兰被潜了!”
比如你早上起床晚了,匆匆忙忙开车出门,一出小区就被堵上了,立即就会埋怨:“我擦,怎么这么倒霉,堵成这样!”
……
生活中有太多类似的事情,我们总觉得自己是特别的,倒霉的事情不该发生在我们身上,可是,生活就是个编译器啊,我们就是程序员,用时间为生活撰写代码,编译器给我们抛出个错误,我们就得臣服啊。臣服,然后想想接下来怎么办。这样才是解决问题的上策。
kNN(k-Nearest Neighbor)算法很简单,它说的是,每个样本都可以用它最接近的k个邻居来代表。
kNN用在生活中,就是:你是你最亲密的5个朋友的均值。比如你的收入,就是你最好的5个朋友的均值。
想通这点,要想有更好的成就,就要不断更新朋友圈,不断和更有成就的人交朋友。
适配器模式是常用的模式之一,其主要意图就是做接口兼容:使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。有点类似这个:唐伯虎要点秋香,可你只有石榴姐,就找了张人皮面具画上秋香的样子,给石榴姐带上,让石榴姐看起来像秋香。
适配器模式就是为了沟通存在的,可用于各种人际沟通场景。
比如我们因为生活的年代和家里老人们的主流生活时代不同,我们就常常觉得他们不理解我们,以为说什么他们也理解不了。那这个时候,就可以使用适配器模式,把我们想说的话,用老人们可以理解的经验重新包装一下,再说给他们听,这样他们就能理解了。
来自:https://blog.csdn.net/IMbRl71u7pt5X29rlEu7/article/details/84587410
作者:《程序员的成长课》
作为开发人员,我们都希望在完成功能的基础上让代码运行的更快、更省空间,那如何衡量编写的代码是否更有效率,这就需要我们学会如何分析代码时间复杂度和空间复杂度.
JavaScript 是一门复杂的语言,不管处于什么样的水平,都有必要了解 JavaScript 的基本概念。本文介绍了 12 个非常重要的 JavaScript 概念,但绝对不是说掌握好 JavaScript 只需要知道这些就可以了。
服务器时间是东八区时间,页面会在全世界各地,页面 JS 功能需要对比服务器时间和用户本地时间,为兼容世界各地时间,需要将用户本地时间转换为东八区时间
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
先说结论:据我观察,至少有60%的团队误用了敏捷软件过程,或者说至少60%的团队在进行伪敏捷开发。与大家通常的认知是相反的,敏捷过程并不是一个非常容易实践或者实施的过程规范。
敏捷是一个很流行的一个词语,但是在敏捷里面,包括很多团队也是刚开始用Scrum,怎么让质量成为敏捷的一个助力而不是拖累,这个是我主要想谈的。
位我很尊敬的高级开发人员给我打来电话。他想找个朋友聊聊:因为担心自己只能得到可怜的 12% 加薪——而他所管理的其他初级开发人员,则有望获得 40% 的加薪。他还抱怨道
现如今,“ 敏捷 ”可以是指任何东西。渐渐地,它就变得毫无意义了。很多企业已经对”敏捷“感到厌倦了,甚至有了抗拒性。更糟糕的是,就像孔子说的那样:跨学科研究、原则和实践是敏捷的未来。
业务,似乎与开发人员不是太相关,开发人员天生处于技术端。但是,一个只会开发的开发人员,很容易被代替,只有真正了解业务,才能真正了解需求,做出好的产品。那么如何去解决这些问题呢?
前端和后端开发之间的界线正在发生变化。有一些常见的错误会导致前端开发人员增加工作量、浪费时间,本文将介绍一些常见的错误以及如何避免这些错误。公司向他们的开发人员和程序员提出更多的要求
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!