原文链接: https://dsx2016.com/?p=661
 
 
单兵作战只能胜任分发到自己的模块,团队协作才能让产品快速而高质量上线.
 
有正必有反
 
 
想要提升团队协作的效率,先分析哪些事物阻碍了开发进度.
 
一般情况下,项目预估的时间相对的紧凑,如果发挥正常,则上线时间不会相差太远,中途有什么变化,也会根据反馈实时调整进度.
 
但有时候,代码能够稳定的发挥其固定的作用,人就不一定了,不同的行为会导致差别极大的影响.
 
负面作用
 
全局干扰
 
 
最近的一个项目中,进入到提测阶段的时候,一些新版的功能都已经通过第一轮测试.
 
但是在代码没有改动的情况下,测试忽然提出了一堆的bug,一些以前的功能部分都不能正常使用了.
 
请注意,一旦遇到类似的情况,几乎没有改动主要功能代码的前提下,忽然发生大面积的bug,于前端而言,不是后台挂了,就是某个兼容性问题,特定手机机型或者系统版本等.
 
还有一种不应该发生的错误,就是团队的其他分支代码影响到整个项目的全局,从而导致你的功能异常,如css样式覆盖,js变量覆盖等操作.
 
现在回顾一下,当时我的操作是先排查功能异常的原因,发现是vuex和vue-router传参parmas失效,但是为什么莫名失效,google了好久,定位到怀疑人生.
 
由于之前已经有过协作导致错误类似的经验,加上对自己代码机制还残留一点点信心(技术的熟练度决定排查问题的思维和方式),转而开始查看gitlab的日志记录
 
在查看同事的日志中,发现一段才提交不久的代码,这段代码的定义就是在全局路由做了一些操作.
 
在这里,我也犯了一个错误,看到对方的注释写的是仅在第一次登录xxx,然后就没有往下看代码的作用了,然后又开始怀疑人生.
 
当时间耗时超过半小时后,就应该想办法解决当下无法解决的问题,和同事交流或者稍稍放松,换个思维方式等,当排查超过一个小时,于是去问了同事.
 
同事说前不久是在ios上进行了全局操作,因为需要开发一个新功能,所以在ios上每次页面切换时,把vuex和vue-router传参parmas给重置了.
 
在这里,先不提排查和定位问题的能力,只能提醒在座的各位,如果明知道自己的代码会对全局有着影响甚至是颠覆的作用,请一定要在群里声明,或者至少和同事口头声明.
 
当然,尽可能不要产生对全局不可控的代码,没有谁能保证自己的代码不会对以前的功能或者同事的模块造成影响,解耦是一种能力,声明是一种态度,也是协作的方式.
 
tips:
 
有一些团队会进行codeReview,一个是提交时review,一个是提交后review.
 
不论哪一种,都是对代码的质量负责,像上述这种错误,如果进行了review,在发布测试前就会被发现和拦截,这种错误不应当出现.
 
团队没有review的流程,也没关系,大多数时候不要养成别人定了规则才会去执行的习惯,一定要有自己的独立思维,要有自己的优秀习惯,团队没有,但是不妨碍自己定期的review.
 
前几期讲了提升效率的方法和技巧还可以加上一条,加班时或者定期review,及时看看自己的代码和同事的代码,查漏补缺.
 
协作时间
 
 
前一段时间,测试在没有任何告知的情况下,周六加班冒烟测试,前后端的都不加班,也不知道要测试.
 
于是产生了几个严重的影响,同样也是人为的不该犯的问题.
 
一是由于没有邮件或者群里正式声明周六提测,导致前端没有发布最新的测试版本,周六测试的是上上个不知道什么时候打包的版本.
 
这种情况几乎可以说测试是白测了,所幸测试的版本恰好功能上都符合,只有一些样式没有跟上进度,所以没有造成极大的时间浪费,影响不大.
 
二是正常工作期间,前后端每次发版的时候,很少有人会主动在群里提起或者正式邮件声明(虽然有时候不需要太正式)
 
导致测试测着侧着就提示网络错误,或者用旧的标准在测试新的代码(如忽然改一个新需求和ui,但是测试不知道),导致提出bug或者被中断测试流程(如下单)
 
其实在发版前群里告知一下是基本的沟通义务,也是最起码的工作态度,就效率而言,能避免很多不应该出现的问题,仅仅是一句话的事情.
 
其次,与人方便也是为自己方便,发版时也可以注明当前版本,发布内容(更新了哪些功能等),以及一些其他说明,让事物有据可查,有别人更容易理解.
 
但是在好几家公司发现,不论是刚入职的小白,还是混久的老油条,都不会去过多的关注一些团队和沟通的细节,或者说懒得操作,宁愿事后甩锅也不愿事前留心.
 
tips:
 
国内没有倾向于使用邮件的习惯,即使是重度有工作属性的职场.
 
如果不强制要求,别说邮件了,连聊天软件都懒得回复,如非需要,甚至口头内容都不会有.
 
建议大家多使用邮件,最少也应该使用有聊天记录的群或者沟通工具.
 
其实说到底,首先是一个工作态度的问题,愿不愿意协作和配合,其次才是工具的使用.
 
其次,要注意的事,最好的工作时间是全员都在的时候,有问题一定要及时处理.
 
不可能等到别人下班再去解决,这样也解决不了,事情要分轻重疾缓.(很重要,思维方式)
 
建议上班的时候解决要和人协作的问题,个人不太紧急和重要的问题可以留到临近下班或者加班或者解决合作问题之后.
 
权限问题
 
 
测试的过程常常需要反复去操作一个流程.
 
但是一个流程往往操作后就固定了数据状态,再次操作不可能再创建一个账户或者每次叫后台清空数据(仅前端).
 
虽然假数据也可以,但是有些逻辑仍然需要真实的反馈,如登录,短信验证,身份识别,提交订单等等等.
 
一般开发,有本地环境,测试环境,正式环境,至少在本地环境和测试环境,数据是可以临时操作的.
 
如果有管理后台建议获取操作测试环境后台面板,针对自己开发的模块做一些流程设定操作,如更改用户状态等.
 
如果没有管理后台,使用sql等直接操作数据库也行(前提是要会一点点数据库和对表结构了解~具体可以问后端)
 
前提是避免一个功能测试需要很多遍,但每次都要找别人来重置数据,别人也可能一直在忙,没有时间帮忙或者留意到你的需要.
 
其次是,直接操作数据库是一个很大权限的事物,哪怕只是本地环境,一定要尽可能避免产生脏数据,影响其他流程.
 
有的时候需要去复现一个bug,必须走完一些流程,操作繁琐且很难定位,通过后台和修改数据库会快很多.
 
总的来说,就是测试有的权限,你尽量也要有,如管理后台,数据库等,没有,就只能让相关模块的人尽量配合.
 
避免有时间但是流程卡住无法操作的情况,这种现象是真正的极大浪费时间,而且一废就是大半天.
 
tips:
 
当然还会有一些其他权限,如代码合并的权限,发布测试和线上的权限.
 
这就涉及到技术和态度意外的因素,要留心那些你有时间有技术但是你无法操作的事物.
 
正面作用
 
 
正面的方法可以简单概括为
 
 
分工合理,责任明确,模块化
 
 
高效的沟通机制(聊天软件,任务面板,邮件等)
 
 
定期检查,及时调整(codeReview,日报,周报,大小会议)
 
比起正面作用,更倾向于排除负面作用,哪怕正面作用不大,但至少不会影响效率和进度.
 
要知道吖,大大小小的公司,其实最混乱的,最致命的,也最为核心的.
 
从来不是技术和能力,而是团队管理和协作,是人与人之间的沟通和行为.
 
tips:
 
正面作用下一期文章再细说.

剑桥大学最近所做的研究发现，全球每年花费在解决软件问题上的成本已增加到3120亿美元。这个数字表明软件行业存在严峻的质量问题，各公司都花了很多钱来解决这个问题，但是基本都是治标不治本。而软件存在bug的一个主要原因就是：测试的效率低且测试不够全面。本白皮书将重点介绍提高测试效率的方法。

 

 大多数软件开发测试小组都有成百上千项测试要做，所以我们有理由要求开发测试小组在建立其它测试前，必须得确保已经充分利用了现有的测试。最明显的一点就是要保证开发人员可以在代码进行集成之前对每次软件修改进行全面测试。

 

 这个想法看上去好像很简单，但实际上很少有开发组织能够做到这一点，因为：

 1.    将所有的测试都执行一遍需要花很长时间

 2.    很多测试太复杂了，不好执行

 3.    测试结果很难理解

 

 上述三个问题中，最难解决的就是执行所有的测试所需花费的时间问题。这个问题是缩短软件发布周期和提高软件质量所面临的主要障碍。

 

 
基于变更的测试可减少测试时间

 基于变更的测试（CBT）有助于企业更加快速、智能地进行测试，因为这种方法可以对照现有的测试用例对每次所做的代码修改进行分析，并筛选出该修改所影响到的测试子集。如果只执行这个测试子集，就会大大缩短测试的执行时间，而且开发人员也可以迅速了解到他们所做的修改产生的影响。这样，开发人员就可以在bug刚引进的时候，便立即将其修复，而不是在几周之后执行“全面”测试时才来修复。

 


 
图1：基于变更的测试（CBT）能够发现每次代码变更产生的直接和间接影响

 

 
基于变更的测试有助于提高QA的效率

 以前，通常都是在对源代码做了上百次修改之后才开始定期执行“全面测试”，这样就会浪费很多QA的时间来追踪造成重复测试的根本原因。执行基于变更的测试可以保证主要的源代码基准没有问题，因为每次对代码做了修改之后，都必须保证这些代码通过了所有现有的测试，才会进行集成。因而集成和QA团队可以集中精力构建测试去验证新功能，而不是对现有功能进行重复诊断。企业如果使用基于变更的测试，更容易赶在截止日期之前发布产品并生产出更高质量的产品。

 

 
基于变更的测试有助于提高测试资源的利用率

 使用基于变更的测试不仅能加快测试速度，还能提高测试资源的利用率，包括目标硬件的利用率。因为每次软件修改之后要做的测试减少了，所以每天能够执行更多次循环测试，还能够发现是哪次修改使软件质量倒退了。在测试设备和目标硬件紧缺的情况下，这种测试方法会显得尤为有效。

 


 
图2：使用基于变更的测试，每天就可以执行更多测试

 

 
基于变更的测试有助于加快产品的市场投放速度

 如今的软件开发组织都面临着巨大的压力，他们要完成复杂的开发项目，还要达到短时间内上市的要求。

 

 
基于变更的测试有助于提高软件质量

 上面分别说了CBT的几点作用，但是如果把这几点结合在一起，就是一个很有说服力的例子，证明基于变更的测试可以提高软件质量。

 

 
提高质量方面的商业案例

 在过去的30多年里，技术革命席卷了整个制造业，我们有很多这方面的记载。奇怪的是，一些相同且行之有效的理念却并没有用于软件开发中。实际上，交付的软件产品存在问题是一个非常普遍的情况，以至于客户都已经知道只要简单地重启一下就可以解决软件出现的“异常”行为。

 

 软件不仅仅是产品中的一个隐藏组件，在很多情况下，它还是让产品在竞争激烈的市场上脱颖而出的关键。而且，现在的客户比以往任何时候都更具影响力，他们可以通过网页和社交媒体工具及时反馈产品的使用情况。这就意味着，如果交付的产品存在很多软件问题，那将严重影响品牌效益，损害公司精心打造的名声。

 

 
VectorCAST与基于变更的测试

 VectorCAST可以提供一个协同测试平台，帮助提高整个企业的测试效率。VectorCAST的主要功能有：

 
让团队成员和各小组之间可以更好地共享测试资源
提供行之有效的发布就绪报告和测试趋势分析
团队所有的成员都可以进行完整的基于变更的测试
 
 

 


 
图3：基于变更的测试可以在保证测试完整性的同时大大减少测试时间

 

 
结论

 公司要解决软件质量问题就需要在测试资源上进行投资，以保证开发测试团队能够高效利用可重复使用的流程，生产出高质量的产品。利用VectorCAST基于变更的测试这一功能可以有效实现该目标。该功能可以提高测试效率，从而帮助提高软件质量，加快产品投放市场的速度，并提高客户的满意度。

 

前文提到过一个神器叫Resharper，功能强大，编码效率和代码质量那是蹭蹭的涨，但是神器的最大问题是太耗费资源了，每次系统提示内存不足的时候，那叫一个纠结啊。因此每次新的VS发布的时候都情不自禁的查看是否增强编辑功能，情不自禁的讨论一番，这次VS2015也不例外。
去年微软放出Roslyn的时候，微软就曾经放出过一个“尝鲜”版的VS编辑增强功能，恰恰就是重构（reflector），话说这个对控件开发太有用了，但是之前只有纠结的Resharper才有的，虽然它也不是很完整，当时还鼓动“群众”去微软功能收集网站上疯狂点支持呢。一年过去，微软正式命名Roslyn为.NET编译平台（.NET Compiler Platform），得益于这个平台，微软在VS2015完善了让开发人员欣喜的编辑器增强。
点亮的小黄灯泡可以展开一个快速动作的入口（看着看着总觉得像是从Resharper搬过来的，哈哈），当代码有为题的时候，提供各种修复建议。另外所有的重构功能也一到这里了，还增加了快捷键（Ctrl+<Dot>)。 
支持临时变量和本地变量重构，可以轻松把一个代码块替换成本地临时变量或者反过来把临时变量的执行块放回去。 
改名（renaming）有所增强，比如直接在编辑器里改名并应用到所有实例，还有一些典型场景下改名冲突问题都有所体现 

除了上面的重构功能，微软还做了其他的编辑器增强，主要是对于触摸设备支持，高分辨率设备支持等等，在没遇到问题之前，这些都不算什么，是以按下不表；但是对于Javascript编辑增强还是很有竞争力的，比如更好的导航，利用JSDoc改善智能提示，代码折叠等等，想想当年那个好几千行的wijmo widget实现，尽然觉得现在的“猿”们很幸福。
作为伟大的“程序猿”一员，仅仅有编辑器增强无疑是不够看的，还渴求一个好的调试和诊断工具，一直以来VS在这一领域做的都不错，但是还有有那么些痛处让广大“猿”们心里不安，当然，好消息是VS2015再次增强了调试和诊断工具，让我们可以更从容准确的找到问题的症结。下面我们一起来看看这些让其他开发环境羡慕，曾经很纠结的功能点吧：
附加调试时编辑执行（Edit and continue on Attach），想想无数次修某些小问题的时候，也就改了那么几句话，想看效果，得等待IDE停掉当前的调试，然后编译在启动新的调试，每次花费的时间看起来不多，累计效果确实很惊人的，因此编辑执行功能对复杂的开发场景还是非常爽的。如今，VS添加了对附加调试的编辑执行的支持，这对于很多web开发来说非常有用，举个例子，你在页面里用了C1 Studio for .NET的web控件，放到IIS上了，发现问题可能是少设置了某个属性，现在你只需要附加调试IIS，然后在合适时机通过编辑执行把这段代码注入进去就可以了。
在调试窗口执行Lambda。比如从EF返回了一个Entity，然后本地挂了一堆LINQ，调试到一半，看看中间结果是否预期，很高兴的在监视（Watch）、立即执行（Immediate）等窗口粘帖了一段代码，回车，期待了好一会，IDE提示有Lambda，不能继续，想想就很不爽。
XAML UI调试工具，经过这么多年的发展，WPF也算是在界面层站住了脚，但是IDE对于界面的调试这一块一直没有起色，很多工具都是磕磕巴巴，不是性能问题就是交互性不好，具体来说，比如C1 XAML里的FlexGrid，老板突然跳出来让你解释一下自定义编辑器那啥的，还真不好说清楚。VS2015为此提供两个小组件：Live Visual Tree和Live Property Explorer，打开界面，就可以实时调试界面上的很多细节，诸如元素位置，绑定细节等等。 
另一个WPF的功能点是Timeline Tool，替代了前代的XAML UI Responsiveness tool，有点像Webkit里提供的开发人员工具里相似的时间线，能把应用程序的性能按时间线的方式展开。对于WPF的性能调优来说，很及时，比更早期Performance Tool好了不止一点点。 

当然，实际VS2015还提供的更多其他效率和质量方面的增强，限于篇幅，这里就不赘述了，感兴趣的童鞋可以一起讨论。
下一篇我们会聊聊Asp.net~请持续关注吧~

把握质量和效率，追求创新并拥有No.1心态
 
１、如果把商场比作战场，质量和效率就是”飞机和大炮”，创新则是”核武器”,有更大的杀伤力。
 
这些是一个产品的核心竞争力和生命力。
 
质量：要对产品保持一种严谨和敬畏的心态，它面向的是用户，不是小孩过家家。
 
效率：提高效率就是降低成本，降低成本也是创造利润。提高效率能够以最小的成本快速的对市场反应，迭代试错，抢占先机。
 
创新：竞争中的核武器，一旦爆破，要么不响，要么一鸣惊人。这是打破常规，突破的必经之路。
 
2、在激烈的市场竞争中，拼的是：“人无我有，人有我优，人优我新。人新我更简单和高效，做到低成本和高效率" 。拼的是创意和企业产品价值。
 
3、树立自信，拥有No.1心态。
 
No.1心态不是说要自傲，认不清自己和对手，而是一种虚怀若谷，来自心底的自信，吸取别人之长处取长补短并敢于发出自己的不同声音。
 
不一味的追赶盲从和追赶潮流，有时敢于引领潮流，敢于大胆的创新和改变，敢于树立标杆，就是要争当这一领域的No.1。
 
BATZ很了不起？我们只能跟风和夹缝生存？
 
不宜妄自菲薄，他们也不一定都对，如果他们是神仙就不会在这里，就不会有后来的拼多多和张一鸣的字节跳动。
 
时代在召唤，时代在召唤英雄，英雄没点儿自信和气魄就不会是英雄。
 
提高效率的思考
 
 
模块化，组件化 搭积木的思想
 
玩积木的小娃何以能迅速的建立起各种模型，发挥创造力和想象力？
 
他肯定不懂某个模块儿是如何制造的，但能拿来即用。 模块化、组件化，最大限度的可复用。打造稳定可靠的可复用组件。让开发应用变得敏捷高效。
 
复用，不是一句口号，要有这方面的意识，不断的积累和沉淀。
 
复用，简单可分为技术组件的可复用和业务的可复用，或者是借力，站在巨人的肩膀之上。
 
技术组件作为构建应用的基石。
 
业务模块则需要不断的进化迭代和抽离。
 
借力，则不用重复造轮子，发挥自己的专职优势。
 
在《Android开发进阶，从小工到专家》一书的第26页中有这么一段话，说Android之父Andy Rubin在被采访时说过，在设计Android之初他就希望Android能像FaceBook那样可以使用不同的应用中的功能模块儿，通过现有的模块儿像搭积木一样方便地构建一个应用。正式基于这一理念，Android被设计为高度组件化、可复用的系统。
 
好书推荐《程序员修炼之道》
 
该书虽然没代码，但是它影响的是人的思想，思考方式，这远比敲代码更重要，推荐一下。
 
我们看到太多重复造轮子的故事。
 
正如书中提到“鞋匠的孩子没鞋穿”，作为一个pragmatic程序员，合理地使用工具/库/以及自己积累的开发的轮子，会让自己的productivity不断提升。
 
这让我想起公司里一个让人崇拜的“牛”，产品一直想把进程内cache做成多进程共享，正在大家还在讨论该怎么做的时候，“牛”已经用短短几天时间完成了，众人再次崇拜一把，原来“牛”是备有很多现成代码的，完成这个功能只是把之前积累的封装良好的模块重用就可以了。
 
书中讲到的一些观点
 
重复的危害 DRY原则（Don't reapeat youorself）：系统中的每一项知识都必须具有单一，无歧义，权威的表示
 
四种重复：
 
加强的重复（impsed duplication）：环境似乎要求重复（信息多种表示，注释，文档与代码，语言问题）
 
无意的重复（inadvertent duplication）：没有意识到信息的重复
 
无耐性的重复（impatient duplication）：开发者偷懒，似乎那样更容易
 
开发者之间的重复（interdeveloper duplication）：大家重复同样的东西
 
复用是解决重复一个最好的方法 Make it easy to Rease.让复用变得容易
 
1.你的知识资产 你应该一直投资知识资产，这是你成长的根本包括但不限与，定期读书，定期学习新的语言，尝试新的工具 。
 
2.破窗原则 任何时候你都应该使用你当时最高水品的技术去完成一个项目，如果你发现又不好的设计或实现应该修正它。
 
精益求精的工匠精神
 
什么是工匠精神?
 
工匠精神，是指工匠对自己的产品精雕细琢，精益求精、更完美的精神理念。工匠们喜欢不断雕琢自己的产品，不断改善自己的工艺，享受着产品在双手中升华的过程。工匠精神的目标是打造本行业最优质的产品，其他同行无法匹敌的卓越产品。
 
概括起来，工匠精神就是追求卓越的创造精神、精益求精的品质精神、用户至上的服务精神。
 
当今社会心浮气躁，追求 "短、平、快"(投资少、周期短、见效快)带来的即时利益，从而忽略了产品的品质灵魂。因此更需要工匠精神，才能在长期的竞争中获得成功。当其他热衷于"圈钱、做死某款产品、再出新品、再圈钱"的循环时，坚持"工匠精神"的企业，依靠信念、信仰，看着产品不断改进、不断完善，最终，通过高标准要求历练之后，成为众多用户的骄傲。
 
木桶效应
 
 
重视细节，细节决定成败
 
产品一定要打磨，精益求精。做到让用户好用、易用、爱用。惊讶，惊异、惊叹，不能仅满足于功能实现。
 
优点尚且难被发现，一些细节一旦被用户吐槽抱怨，再好的产品也瞬间拉低了档次。
 
一个产品的好坏，就像这木桶效应，取决于它的短板。细节决定成败，多注重细节。在功能实现的基础上多想一步，多进一步。
 
换位思考，多站在用户的角度想问题
 
１、拥有全局的意识，考虑到整个产品的生命周期，多站在客户使用者的角度想问题，运维人员实施维护的角度想问题。
 
２、不能只满足于功能实现，应把产品做好做优，把功能做稳定好用。让用户好用，让运维简单，提交效率。
 
３、提交效率也是降低成本，并且提高效率可以让精力从繁琐的低效劳动中解放出来，做些更有意义，更有价值的事。
 
４、不可只站在自己的角度上，方便完成任务结束项目或担心多做任务，而不从全局上考量。
 
不积跬步无以至千里，不积小流无以成江海
 
十年磨一剑，修的是内功。
 
滴水能穿石，这是什么力量？
 
三种力量 
 
习惯的力量
 
坚持的力量
 
积累的力量
 
锲而舍之，朽木不折；锲而不舍，金石可镂。
 
１、要善于沉淀、积累和总结。
 
２、习惯思考。
 
３、敢于坚持，只要坚持深，铁棒磨成针。
 
４、养成好习惯，常记笔记，做总结，写博客。
 
沉淀积累总结
 
１、主动思考，从琐碎的开发任务不妨抽出些时间，反思总结一下。
 
２、最大限度的复用,有意识的复用。
 
３、对以往的项目代码做一些梳理，提炼下组件和业务。
 
４、有些东西需要沉淀，如成熟的技术组件和项目文档。
 
５、打造成熟稳定的可复用的组件模块。
 
６、有意识的逻辑分层和搭积木的思想和意识。
 
哪些是可以复用的组件。
 
哪些是可以复用的业务。
 
哪些是做了很多重复的劳动。
 
７、有意识的把项目进行功能模块和组件划分。
 
８、养成记笔记或写博客的习惯，这是思考的过程。
 
９、动笔画一画，如果一份项目代码不能清晰的画出来结构和流程，说明对业务或架构理解还不够透彻。
 
做事的方法论
 
１、同现实世界做类比。 比如建造大厦，建造桥梁，如何协同分工。
 
２、讲究做事的先后顺序和方法。
 
３、先讨论，理出来或画出来结构模块儿和架构，在动笔编码。
 
同样是做一件事，方法有很多。
 
比如先整体后局部，从内到外，由细到粗，由粗到细，由点到面，由面到点等。
 
不同的方法，产生的影响也是不同的，即便最终都是完成了这件事。
 
因为这里面有时间和机会成本在里面，考虑到时间和机会成本，当然是时间更短的胜出。但是也不是绝对，因为有句话叫做慢工出细活，意思是说不能太过于急躁，急于求成，应沉下心来把东西好好打磨，但这更多是是针对熟悉的事物和同等生产力的情况下，做的越细当然越好。
 
针对不同的情况，应选择不同的方法，比如针对一个新事物，如果一下子考虑的面面俱到，很深很细，往往很难落地。因为复杂性和业务的多变性，充满太多的未知的不确定因素，往往容易让人知难而退，止步不前。俗话说万事开头难，难在迈出那一步。所以这时应当选取由粗到细的方法，先争取快速的实现业务，不要考虑的过深过细，毕竟有很多未知的变动的因素。得允许有试错和迭代的机会。否则，就是在失去先机。或许等面面俱到的实现了，也已经不再有大的价值和意义了。
 
把任务细分
 
一个任务很艰巨的原因之一是这个任务很宏大。比如说你想要做一个菜谱构造程序，没有人能一下子完成它，这是一个目标而不是一项任务。一项任务是使你能够朝向目标更进一步的具体概念。一个好的任务是你能够立即拿来实施的，比如“画一个展示菜谱的草图”。 当你完成了上一个任务后，下一步就会变得更加清晰。你将会考虑一个菜谱有什么构成，你需要什么样的搜索机制，如何构建菜谱的数据库，等等。这样你就构建了一个引擎，每一个任务都会通向下一个任务。 对于每一个比较大的项目，我们应考虑我需要完成一连串什么样的任务，并且将这些任务加入到我的待办事项列表中去。同样，当我们做完一些任务之后把接下来需要完成的任务再加入任务列表中去。
 
简化任务
 
另一个让任务变得艰巨的原因就是它太复杂了。“写一本书”这个任务会放你感到无从下手，那么就先从写一篇文章开始吧。如果一篇文章也觉得太多了，那么就先写一个段落的概要吧。最重要的是真正做了一些工作，真正的有进展。 一旦你明确了你的任务之后，你就可以更清楚的判断它，更容易的理解它。提高完善一些已有的东西比从头创建东西更容易。如果你的一个段落写好了，那么一点一点积累，它会变成一篇文章，最终变成一本书。
 
多尝试新事物，新技术的引入是源头活水
 
问渠那得清如许，为有源头活水来。要想保持创新力，就需要打破常规，敢于尝试新事物，引进新思想和新技术，跳出舒适区。
 
避免陷入内卷化
 
什么是内卷化？
 
内卷化并不是一个新词，它来源于上世纪 60 年代末，是由一个名叫利福德·盖尔茨的美国人类文化学家提出来的。当时，盖尔茨
 
在风景秀丽的爪哇岛进行考察，他潜心研究当地的农耕生活，发现那里土地资源有限，而且还缺乏资本，再加上行政性障碍，使
 
得劳动力只能不断地投入到有限的水稻生产中。用犁耙松土，用镰刀收割，日复一日，年复一年。 虽然当地人的原生态农业维持
 
住了田园景色，但却没有什么实际性的发展，只是长期停留在一种简单重复、没有进步的轮回状态。于是，他就把这种现象称之
 
为“内卷化”。
 
内卷化，没有成长，没有进步。是无意义的重复和吃老本。
 
内卷化这个概念也可以延伸到一个行业、一个企业，一个组织，甚至是一个人的身上。 同样是忙忙碌碌，为什么有的人成长得特
 
别快，能力迅速提升？有的人却始终在原地徘徊，甚至能力在倒退？很可能，你的忙碌只是内卷化忙碌。看似很充实，但实际只
 
是停留在了没有成长的重复状态中，低水平循环，停滞不前。 每隔一段时间，应问下自己，是不是陷在了重复的舒适圈里，不愿
 
意跳出来，不愿意做出改变。日常自省，就很难陷入内卷化的怪圈。 每个人，每天起床后都会做同一件事。他们告诉自己，总有
 
一天要改变自己的生活，可没人付诸行动。 你会改变自己吗？ 孔子曰：“吾日三省吾身”。 我们也要经常的反省自己进步了吗？提
 
高了吗? 重复了吗?
 
坚持学习，不间断学习
 
学习也可以是一种兴趣爱好。
 
君子曰：学不可以已。
 
君子博学而日参省乎己，则知明而行无过矣。
 
１、活到老学到老，干一行爱一行。
 
２、兴趣是最好的老师，兴趣是最好的动力和坚持。
 
３、学习是一种每天都应坚持的，一辈子的事情。
 
学习是每天应坚持的事情，一种习惯。
 
应把自己至于广播接收器模式，处处留心皆学问，不只是某一面，天文地理，历史人文等。不一定是某一领域的技术，思想的改变更了不起。它需要外界不同事物的触发，触动。每天接收新知识。
 
从小我们被教育到要“好好学习,天天向上”，现在这话更多的成为了一句口号。
 
其实应该叫”天天学习，好好向上”，才更有意义和激励作用。因为向上是一种方向，而学习才是应该可以量化的和每天坚持的。
 
不进步就是在退步，永远有人比你走的更前面。
 
我的博客即将同步至腾讯云+社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=29p3puezzmskk