效率

始终以来，迁延症都被视作是高效的敌人。 但明天分享的这篇文章的作者认为——迁延和效率并不是对抗的，迁延并不代表低效率。 传统上，人们会把迁延症归因为懈怠，或者是不长于做工夫治理。但钻研表明，迁延症次要是无奈妥善治理本人的情绪，容易被挫败、放心之类的心理反馈摆布。 在迁延的时候，抉择用正确的形式去做一些正确的事件，从长期来看也是能够产生高生产力效益的。明天这篇文章，提出了三种能够让你的低效率迁延转变为高效率迁延的办法：摈弃消极的念头、禁止继续的迁延、造就与工作相协调的兴趣爱好等。 与其始终想着克服迁延症，倒不如偏向于让迁延症帮忙咱们防止那些最终可能导致长期迁延症的负面情绪，试着让它成为你进步工作效率的一个无效工具。以下，Enjoy： 一、迁延和效率并不是对抗的“在我意识的人中，令我印象最深的人个别都是可怕的拖延者。” ——保罗·格雷厄姆《迁延症的好坏》（Paul Graham ，Good and Bad Procrastination） 和大多数人一样，我也常常有“迁延”的行为偏向。但不同的是，我不会镇压它。相同，我个别会利用迁延来督促本人提高效率。 在我解释本人高效迁延的办法之前，让咱们先看看大多数人的迁延是什么样的： 开始思考工作。 刚筹备开始工作，就立马产生了想要迁延的激动。 之后，开始用一堆消极的喃喃自语来打击想要迁延的本人(例如，我就是这样一个拖延者；为什么你就不能集中注意力呢?) 在本已强烈的迁延激动之上，开始产生一些负面情绪，例如惭愧和悲观等。 最初，面临对于迁延的一些事件时，你在情感上开始变得麻痹。 大多数人不是为了回避工作而迁延；他们迁延是为了防止因误会本人所产生的迁延激动而导致的负面情绪。 最后产生的迁延激动并不是问题所在，其根本原因次要是咱们会把迁延看作是一件好事，进而产生很多负面情绪并将其强加在本人的身上。 上面，回到我的问题上。 以下是我早上的写作习惯，这次我补充了迁延症的具体情况： 坐在办公桌前，关上电脑。 而后迁延10分钟，浏览和评论敌人写的一些故事。 为正式写作做筹备，而后写30分钟文章。 而后再迁延30分钟，在草图巨匠（Sketch）上尝试设计一个新的网站设计模型。 从新回到我的文章，持续撰写1个小时。 持续迁延45分钟，浏览一本新书。 思考是否应该多写一点，但思考之后感觉不值得，因为间隔正式下班，我只剩下15分钟能够写文章了。 最初再迁延14分钟，在网上浏览黑客新闻网站（Hacker News）或者其余的一些货色。 只管迁延行为并没有间接帮忙我写文章，但从久远上看，它们帮忙我变得更有效率了。 在我浏览和评论敌人的文章时，我也正在建设和造就这些人际关系，并减少了其他人更宽泛地分享我的文章的机会；当我尝试一个新的网站设计时，我会做出一些对于偏好抉择的小决定。所以当我正式从新做网站时，它会变得非常疾速和简略，因为我曾经通过无数个30分钟的高效迁延在草图巨匠中实现了十分多的工作；当我在读一本新书时，其实我是在为写新文章收集信息和排汇新思维。甚至，浏览黑客新闻或其余博客文章也可能是很有用的，因为我在那里找到了很多我已经在时事通信周刊中分享的文章。 但更重要的是，通过让迁延的激动“顺其自然”地产生并发挥作用，而不是抉择去克制它，我防止了因为把迁延视为好事和集体性情缺点而产生的所有内疚和惭愧，也防止了可能真正会事与愿违的迁延的产生(比方，花半天工夫在Netflix上刷剧)。 二、在迁延的时候用正确的形式做正确的事件素来都不是真正的迁延如果你想尝试一下无效的迁延，这里有三个实用的策略能够让你借鉴。 2.1 摈弃消极的念头在我的内心里，我始终把迁延作为一个口头的指南。 ——纳西姆·塔勒布（Nassim Taleb） 人们迁延症问题的开始和完结，个别都是本人作弄本人的后果。具体来说，每当他们发现自己有迁延的激动时，他们就会进行很多消极的自我对话，比方: 为什么我不能集中注意力？ 我又开始分心了。 我如许心愿本人不是一个迁延症患者。 如果我再持续迁延的话，我就完不成工作了…… 所有这些消极的自我对话的问题在于，它让咱们自我感觉十分不好，通常会让咱们产生一些内疚或惭愧等负面情绪。 设想一下，如果你身边还有另一个邪恶的你本人，始终在你耳边嘀咕：“你是一个很蹩脚的人，并且将永远也不会扭转你本人，永远蹩脚。”如果每天都有人对咱们说这种话，你会感觉很好受吧?即便咱们从理智上晓得这不是真的，但如果咱们继续一直地受到它的轰炸，它也会开始影响咱们。 然而，咱们很多人个别都没有意识到，咱们常常这样看待本人。并且，相对来说，那些始终想克服迁延症的人往往更常常这样和本人进行消极对话。 如果你就是这样的人，那么你须要做的第一步就是当你想要迁延的时候，你要意识到你是如何喃喃自语的，要留神你心田的声音在说什么，而后将它写下来。 通过把这些声音写在纸上，你将会从你的内心世界走进去，从新进入事实世界，开始看清它的实质：它并不是你外在的性情缺点，而是一种心理习惯。 兴许这个心理习惯是你在通过多年甚至几十年的一直强化而造成的，但它也是能够通过一些意识和实际来打消的。 一旦你写下了你头脑中所产生的声音，你就能够为每一个声音或想法，想出一些其余不同的想法。 例如，假如我留神到每当我有迁延的激动时，脑海中浮现的第一个想法是:该死，我真心愿我不是这样的拖延者。 但你也能够产生一些其余的想法，比方： 我的确偏向于在写作上迁延，但我在很多其余事件上很自律，比方去健身房和筹备饭菜。 我想我并不是从开始就在和迁延作奋斗，而是产生在我开始一项新的工作之后。 我有迁延的激动，但这并不意味着我就是这样的人，也不意味着我效率不够高。 要点： 大多数真正起副作用的迁延症，比方狂看视频和刷剧、打游戏等，都是因为咱们总是试图回避或尽量避免因消极的喃喃自语而产生的羞耻感。 如果咱们能辨认并开始纠正这种消极的自我对话，咱们就会感到更少的惭愧和其余的消极情绪，就不太可能陷入这种有意识的、没有功效的迁延中。 2.2 禁止继续迁延“你永远都不应该和迁延的偏向进行反抗。” ——马克·安德森（Marc Andreessen）《Pmaraca的集体生产力指南》（The Pmarca Guide to Personal Productivity） ...

普通人用类比思维，马斯克用“第一性原理”埃隆马斯克，这个如外星人一样的咱们的同类，却有着超乎常人的不一样的思维。 他做的事件看上去总是让人感觉很疯狂，他制作出人类最酷的电动汽车特斯拉，又钻研人类移民火星的打算，钻研脑机接口，钻研5000公里每小时的高铁，任何一件事件听下来都很疯狂，但他总在不遗余力地推动。马斯克说他是用第一性原理来思考并解决问题的。 所谓第一性原理，对牛顿而言，宇宙第一推动力，F=MA是最终的原理。爱因斯坦暮年致力于“大统一场实践”钻研，也是心愿找到统概所有物理定律的“第一原理”。 追溯到古希腊，泰勒斯的“万物皆水”，赫拉克利特的“万物皆火”，毕达哥拉斯的所有皆“数”，柏拉图的“相论”，亚里士多德的“形而上学”，都在试图解决“第一原理”。 对于马斯克而言，他的底层思维就是物理学思维。能够说，物理学思维，就是马斯克的第一性原理。 第一性原理是一个口头办法马斯克的第一性原理尽管没有这么终极，但的确是一个能够无效口头的办法。他说： 不论它是哪个畛域，肯定要确定最根源的假相，肯定要有十分高的确定性。在你作出论断之前，必须在这些最根源的真实性上得出结论。所以，物理的思维形式是一个十分好的框架。包含咱们能源的耗费、产品等等，外面都波及第一定律的利用……类比思考就是随大流。所谓类比，就是看看他人做得怎么，而后通过本人的致力达到绝对的劣势，在竞争中胜出。这是人类的一种广泛思维形式。 迈克尔 · 波特已经说过日本企业的劣势经常是“经营有效性”，基于模拟和改进的精益算不上是策略。阿尔法狗（AlphaGo）击败人类棋手用的也是这种形式，而阿尔法元（Alpha Zero）轻松击败阿尔法狗，用的就是所谓“第一性原理”。 马斯克所谓“类比的思考是随大流”，是指人们罕用的思维形式是相互比拟，本身的存在须要由伙伴来定义，这样就只能改进或陷入模拟，很难产生反动的发明。最好的状态近乎天然成长，这样的改良就是十分无限的。 使用第一性原理实现10倍好马斯克的打算和思维总会制订得更加疯狂、更加大胆、更加不堪设想和更激进的指标。如果个别人的指标是在当初的根底上改良10%，马斯克的指标就是在现有根底上做到10倍。 《连线》杂志的Jack Stewart 发现：在马斯克的世界里，如果一件事要用1年实现，到了他人的世界就要7到8年。 马斯克置信所有事件的倒退都比大多人意料的快，因而在他的世界里，所有指标布局都超乎常人。 他遵循了硅谷十分风行的一个观点：把一件事件做到10倍好,比做到10%更容易得多。主管谷歌实验室Google X的阿斯特罗·泰勒也是这个10倍思维的信徒。 泰勒说：“尝试做一样新货色，不外乎那么两种格调，一种是小幅变动，比方扭转生产模式，这时往往失去的就是10%的改良，但如果要取得真正的微小变革，一般来说你就得从新开始，尝试另一种形式或很多种形式，你必须突破一些根本的假如。” 循序渐进式的提高依附的是苦干，是更多的资源、更多的致力，而10倍的提高，则建设在勇气和创造力之上，是巧干。也就是说，10倍的指标逼着你走效率更高的翻新的智慧捷径。十倍速成长，你可能感觉不堪设想，但有人正在做所有致力的尝试。其实，真的这样去推敲并不是相对不可能实现的事件。 听着仿佛很形象，让咱们来看看马斯克是怎么做的？ 精彩案例分享1:拆解电池的老本。马斯克要弄一特斯拉电动汽车，他发现光电池就得5万美金，太贵了。 起初埃隆·马斯克怎么办呢，他跑去买来一块性能好的电池，而后把电池拆了，电池拆完看里边到㡳有啥。 有铅、有铜、有锡、有什么连线等等，不就这些货色吗？ 到市场上一打听，这些货色值不了多少钱，约为电池总成本的13.7%。 换言之，电池老本昂扬的间接起因，并不在于原材料，而在于原材料的组合形式。于是，马斯克立马决定寻找新的程序，将电池重新组合。为此，他与松下公司达成单干，采纳松下18650钴酸锂电池的电池管理程序，重组特斯拉电动汽车的电池，并获得了重大胜利，一举把电池的价格大幅降落，成为全世界最便宜效力又好的电池。 这里马斯克的逻辑是，“我不论当初的电池有多贵，我就回到实质问一个问题，电池的硬老本是什么形成的？无论如何也减不上来的老本是什么？无非就是铁、镍、铝这些金属，除了买这些金属的老本是相对降不上来的，剩下来的老本都是人类合作过程中产生的，那就有优化的空间。” 精彩案例分享2: 马斯克拆解超级隧道2016年12月，洛杉矶产生了一次大堵车，马斯克也深受其苦，他发 Twitter 埋怨说“本人几乎要被洛杉矶的交通逼疯了”，他还说，“我得做件事了，我要开一家叫‘无聊’的公司（英语 boring 也有钻孔的意思）。 为了降低成本，马斯克从四个层面进行了地底隧道的老本因素拆解。 第一，将隧道直径缩小一半以上，这意味着理论开掘面积是地铁隧道的1/4；第二，让机器在开掘隧道的同时，也能加固周边的墙壁，这样一来，整个过程的效率将会进步一倍；第三，将挖掘机功率晋升两倍，也就是将老本再次对半缩减；第四，将开掘进去的废土制成砖块贩卖，用发明的效益冲低成本。四管齐下，仅仅用了两年，这个平凡的构想就成为了事实！2018年12月18日，这条隧道就建成了，总长1.83公里，依照原始地铁形式开掘预估老本是11亿美金，而理论的施工老本仅为1000万美金，一下实现了“10倍好”的指标！ 精彩案例分享3:马斯克拆解火星移民马斯克的终极幻想是让人类有朝一日可能移居火星，而他本人能够在“火星上退休”。为此，他守业了美国太空摸索技术公司(SpaceX), 并立下了一个看似疯狂的指标：预计100年后，将100万人类移民火星。 别人眼中的夸大之举，在马斯克看来只需两件事即可实现。 第一件是领有过人的意志，而据马斯克的传记作者阿什利.万斯(Ashlee Vance)在《硅谷钢铁侠:埃隆.马斯克的冒险人生》一书中所述:“马斯克的意志无人能比。”第二件则是用适当的办法降低成本。不过要想移民火星，“10倍好” 或“100倍好”的规范必定远远不够，马斯克提出了新的指标——2.5万倍好。依照小布什时代的航空打算，如果技术支持，一个人去一趟火星(往返)至多须要破费100亿美元，而在SpaceX的火星打算中，单人单程的火星之旅，所需费用仅为20万美元左右。通过周密的剖析，他认为把人们送到火星移民，最大的瓶颈不是技术，而是老本。对于火星移民的第一性就是老本。从100亿到20万，老本升高了2.5万倍，那马斯克是怎么做的？ 马斯克认为这个问题实质上是一个数学问题，所以他把200000这个数字进行了拆解： 200000=20*1000*10 马斯克的拆解是什么意思呢？他其实是从诸多层面进行了思考: 第一，依照当初的太空旅行打算，一次只能送4-5名太空旅客登陆火星，而马斯克的打算是研发一架可同时包容100人的火星移民运输机，这便能让老本大幅升高，一下就晋升了20倍；第二，SpaceX公司创建之前，世界上所有的运载火箭都是单程的，发射升空后便自行崩溃，无奈循环利用，而SpaceX公司研发的“猎鹰”系列火箭可能重复使用1000次左右；第三，马斯克打算在太空轨道左近建设飞船加油站，晋升火星移民运输机的续航能力；第四，在火星基地中制作飞船的返程燃料，将火箭发射时的燃料负载降至1/2；第五，应用高效便携的新燃料....通过对以上第三、四、五的拆解，马斯克感觉能够再把老本升高10倍。随着他科研团队的刻苦攻坚，他们解决了一个又一个技术上的难题。2017年8月14日，SpaceX的“猎鹰9号”火箭搭载“龙”飞船从肯尼迪航天中心顺利升空，并且胜利回收！ 这一刻，值得被记入人类文明的史册！这意味着马斯克的火星移民幻想越来越近啦！ 使用马斯克的拆解基本要素办法实现研发效力10倍速晋升第一步 拆解剖析一下企业的研发价值流一般而言，都能够拆解成这些步骤： 第二步 对每一步骤再拆解要害因素进行度量 譬如上图所示，咱们能够列出三个要害指标： 解决工夫（PT）：工作的理论增值工夫前置工夫（LT）： 从前一步骤后工作可用到下一步骤实现的工夫，包含等待时间和解决工夫实现&精确的百分比（%C&A）：下一步骤能够解决的工作百分比针对每一个步骤都计算出来这三个要害指标的数据，如下图： 第三步 将三大要害指标进行汇总累加汇总失去 全副的解决工夫PT 是 31小时 全副的LT工夫 是 75 小时，全副的等待时间是 44小时。 滚动的C&A% 只有 33.7% ...

日常上网，总会遇到需要收藏的网站，一般我们会用浏览器自带的书签工具来收藏，但是当书签量过多的时候就不容易管理，并且各个浏览器之间也不能互通，而Pinbox很好的解决了这些问题。 Pinbox 主打功能是收藏和收藏管理，但是围绕着收藏又做了很多特别方便的辅助功能，比如可以给某个收藏添加快捷键，可以编辑收藏的标题和描述，还有会抓取网页的缩略图。 Pinbox 不仅仅可以收藏网页，还可以收藏图片和文字。 一个网站怎么能吸引用户，第一个关键就是要界面好看，Pinbox 的界面可以说是非常有品质的，干净简约但又不失单调，整个网页给人一种轻盈素雅的感觉。 收藏使用三种方式展示 卡片模式 列表模式 和 极简模式 收藏可以通过拖拽卡片的方式轻松的移动到左侧任何收藏集里或者回收站里 也可以通过多选批量操作，支持按住 Shift 键快速选中卡片 文本收藏支持 Markdown格式，代码可以高亮显示，很适合收藏代码片段 点击右上角的加号可以添加网页或文字或者图片地址，也可以导入本地书签 最近 Pinbox 上线了主题色和暗黑模式，可以自由的选择自己喜欢的颜色作为主题色 提供了6 种主题颜色可以任意选择，支持暗黑模式和跟随系统功能 跟随系统在这里说一下，如果用的是Chrome系浏览器，选择了跟随系统，Pinbox 就会随着系统的模式而改变，也就是说当系统设置为夜晚模式，Pinbox 会自动跟随为暗黑模式，系统设置为白天，Pinbox 会自动设置为亮色，很好的提高了用户体验。 暗黑模式下的 Pinbox 现在 Pinbox 还很小众，用的人也不多，但是它出色的设计和完美的功能可以说是一款品质很高的产品了，能看出它背后团队的认真和用心，是真的想要做好产品，希望 Pinbox 能越做越好，保持初心，加油！

首先这和你熬夜加班没有半毛线关系,千万别自己感动自己. 但凡是互联网项目,出现延期是常有的事情. 项目延期之后,一般流程是领导开会,大家讨论,新一任背锅侠,然后下一次还是老样子. 项目评审 项目初期,评审是最重要的一个环节. 这个需求能不能做,那个需求要怎么改,最后给到手的任务预估一个开发时间. 初入开发的小白,最好有同事帮衬点,做不到的需求千万别接,不然整个项目都要卡壳. 需求改不改关系不大,有的实现方式很简单,查一查资料就能快速上手,有的实现很复杂,没有谁会给你几天时间开发一个无关紧要的功能,不如直接砍掉,或者换一种简单的,免得费心费力还不讨好. 最难的就是估算开发时间,哪怕是一个有多年经验的老鸟,也不敢说估算的很准,不准确就意味着可能延期,没有奖金还扣绩效. 所以尽可能的多估算一点时间,因为老总和领导并不太在意你的开发难易程度,他们只要结果顺利,其他的自行想办法. 有时候,感觉评审就像是讨价还价的菜市场,刚刚手撕产品,又得单挑Boss,实在是弄得心力交瘁. 这个时候你别来提时间管理,老板是看市场行情,不是看工作卖力. 指定要在某个节日上线,假如留给你的时间只有一个月,实际项目开发要二个月以上. 评审的时候,你按最低最低的时间甚至预计自己加班后的最低时间估算,要二个月,中间不生病,不请假等等. 老板总会觉得这个模块不值得你估算的这个时间,这边砍几天,那边砍几天,非要砍砍才满意. 若是砍不到节前一个月的时间,口头上会临时加派人手,实际上每个项目都会有临时需求,别的都差人,哪来的给你用. 改需求 刚刚评审完敲定了项目流程开发时间,出了会议室还没有回到座位,新的需求就来了. 本来时间就一半当成两半花,结果左一个新需求,右一个新需求,三天一个大需求,一天几个小需求,搞得好像需求不需要时间似的. 没办法,产品,Boss一家亲,小小员工没有拒绝的权利. 如果说Boss定的时间,你加班,熬夜,周末也不休息,努力赶一赶工期,只要和预期差别不是很大,一般没什么问题,最多就是没有加班费,身体快挂了一样的累. 那产品需求就是枪林弹雨,不定时的炸弹,任你再多的时间都直接被打成筛子,一个炸弹就让整个项目可能挂掉重来,这种事情并不是没有过. 要知道,改代码往往比新功能开发至少多花费几倍以上的时间,越改越多bug,看似一个芝麻小的需求,很可能就需要推倒整个模块. 人人都是产品经理,可试问,有几个产品懂技术? 那种app识别手机壳颜色的操作不在文章讨论范围...... 开发联调 时间可以预估,需求可以砍掉,但是人才是最不稳定的因素. 产品/UI和前端,前端和后端,前后端和测试,就拿前端来说,几乎和每个环节都要打交道. 一个项目由不同的人开发不同的模块,开发过程中需要不断的沟通和协调,才能顺利进行下去. 谁先谁后,或者同步进行,都有规律可循,一旦中间环节掉链子,空有大把的时间也只能卡壳. 正式开发的时候大家时间都很紧张,能够愿意腾出时间沟通,算是性格比较好,技术品过得去的. 最常见的问题是 API改了字段或者增删了接口,既没有及时通知别人,也不修改文档,让别人莫名其妙的排查,最终定位到他的时候,才懒洋洋的说知道了.测试包一直等待打包,确实是人忙不过来,还要一个一个手动打包,或者有时候忘了,等过一段时间问起,才想起来,又或者其他的,优先级问题记得有一次,测试在禅道上提出一个bug,没有截图,说明也很极简,并不能很好的表达出问题所在.(注:自己刚入公司) 这边尝试复现,定位问题和排查,因为流程复杂,操作一遍需要一定长的时间,最后去问测试的时候,对方直接扔来一句"你不会自己去看啊". 流程里就规定要注明机型,场景,尽量有截图,视频,总有人不按规定,这个bug定位只有他手上的测试机机型才有这个现象,而他知道却没说明. 要明白,主动过去不是意味着求帮助,而是花费自己的时间尝试去和对方友好沟通,去之前就完整的排查了一遍,要是文案详细,也没必要找测试. 类似于这种人,工作不负责,沟通不友好,说不定还是个老油条,对上面客气,上面不动他,对新人和同事不友好,你不喜欢他也对他没什么影响,活还是要继续干. 所以这种人,建议直接拉入黑名单,公事公办,之后的bug,但凡不明确的一律踢回去. 虽然公司会议上和项目群里一直说后台API要自测,测试反馈要详细,其他怎样怎样,可长期还是老样子,这其实和一个公司的团队氛围,管理能力,息息相关. 人在职场,除了本职能力以外,最重要的就是沟通能力,自己的沟通能力要强,可别人愿不愿意配合就是另外一回事了. 技术问题 一个bug卡半天的也不是没有. 个人的技术能力也决定了开发效率,只能说技术可以自我提升,但是上面的种种非人力可以干扰. 其次加班的效率并不高,常常三个小时不抵白天的半个小时,而且一般都是解决一些临时需求和伪需求. 技术本身说难也不难,说简单也不简单,区别在于花多少时间学,用什么方法学,有没有兴趣之类. 技术是一个软实力,无法可视化,无法短时间提升,也是一个综合能力,不一定和本职技术有关. 开发效率往往可以从一些软件,插件,硬件,工具,方法和技巧上来做提升,短时间几倍十几倍的提升. 如何提升工作效率,是一个开发人员长时间要去思考的问题,尤其是经常加班的前提下.

我在上一篇的文章大BU级别的"前后端分离"实践中提出了我们当前的前端团队中存在一些问题以及解决思路，并且在其中详细地写出了统一视图服务的实现思路和收益。这篇文章主要写关于前端迭代及上下游协作效率我们是如何解决的。 背景我们的目的是提升前端迭代及上下游的协作效率，我们从四个出发点开始讲起： 团队负责的业务越来越读，如何提高资源、组件及代码的复用率，提升整体研发效率；提升项目的上下游协作效率，涉及到从UE到UI到FE再到QA的整个流程，这需要很强的推动力和足够的说服力；提升人效比，一人顶三人，提升项目中前端开发人员的人效比，让前端做的更快、更多、更好；最后是将整体方法进行梳理，把提效的这部分能力应用在web、wap、小程序中，实施中台化。 解决思路 首先，建设前端物料体系，重新定义和统一前端的开发标准，建设前端物料资源体系，其中包括设计和单元测试等资源；第二，实行工具化管理，完善工程体系，统一前端的开发流程和技术栈，保证资源复用率；最后也是最重要的就是渐进式开发，因为它决定了物料完成之后能不能达到最佳的复用率。 整体架构 问：什么是物料？答：可按照规范进行标准化构建，并且可以在不同项目，不同团队，不同成员之间复用的任意资源。我们把这类资源统称为物料。参与物料资源生产和消费的对象共有四个：开发者、使用者、设计者、产品/运营。为此，物料中台提供了标准化的物料资源，其中包括项目的基础框架、组件库、区块和模板。基础框架是项目的样板框架也就是俗称的boilerplate，组件库是基于部门内设计同学提出的Union Design设计规范开发前端组件库，它同时支持web和小程序两个宿主环境。区块可以简单理解为组件的拼装集合，它比组件库提供了更上层的业务封装能力，但是这也让它变得没有组件库那么地纯粹；模板就是各种站点的样式模板，其中整合了前面所提到的基础框架+组件库+区块等各种资源。让开发者可以最大限度地减少工作量。 图中的中间部分是可被支持的宿主环境，包括Web端、移动端及小程序。Web端可以支持TypeScript+Vue/React框架模式进行开发，移动端支持VW/REM布局方式，同时也支持Hybrid模式进行开发，具体文章请参考端动态化方案详细设计。另外由于业务原因，小程序目前支持微信小程序和智能小程序两种。 最下面是物料中台提供的工程化体系，提供了CLI工具和GUI工具。CLI工具用于在前端项目开发中，让FE可以便捷地对物料进行生成和消费；此外物料中台还提供了GUI工具，让物料的消费方可以通过拖控件的方式，对项目进行快速地原型落地和模板设计，里面具体的细节请等待后续的文章更新。 我们和设计同学一起推出了物料相关的设计资源，其中就包括Union Design设计规范。为了降低物料在项目中的落地阻力，物料中台还提供了完善学习资源，包括文档、教程，也会定期组织培训和分享。 最后，在整体上实现了物料中台的功能。 组件库设计我们在进行组件库设计是主要考虑了两个方面： 组件分级 基础UI组件复合组件业务组件组件边界 越界操作副作用侵入性循环依赖首先对组件进行分级，根据对业务的侵入性和纯粹性（复用程度）为分界点，拆分为三级，如下图： 如图中表示，越往下业务侵入性越高，抽象程度越低。越往上复用程度和纯粹性越高，同时抽象程度也越高。 组件库设计的关键就是组件的边界限制，每个组件都是非常独立的且不可再拆分的最小单元。首先是禁止组件的越界操作，只让它处理份内的事情，对外部的事情不能染指半分；第二是副作用，禁止（尽可能的少）有副作用，如果了解过函数式编程，就会知道副作用的各种优缺点；第三是侵入性，禁止纯粹的木偶组件（组件库中的每个组件都是纯粹的木偶组件）对业务的侵入性，因为侵入性越高复用率越低，组件库对于其他人也就越难用；最后是禁止组件内部的循环依赖。 最终实现 最终实现中，整体分为四层，最下面是技术实现，往上是依赖的设计资源，再往上就是组件库提供的五种基础组件，包括基本操作、表单、视图、导航和数据处理等。最上层则是接入的业务方。自下而上地完成了整个前端业务方向的组件库方案。 上下游协作对上下游协作效率优化的流程中最核心的就是效率提升和物料复用。 效率提升 交互设计单元测试回归成本物料复用 物料共享生成和消费业务迁移渐进式开发整体流程如下图： 在整体协作流程中主要包含两条操作流程，物料管理和物料使用。 物料管理的功能是给物料开发者使用的，负责物料对不同平台的支持，创建，生成和列表管理，可以在管理列表中对自己上传物料进行消费。 对于物料的消费，提供物料实时预览、下载、使用、和源代码查看功能。使用物料时会自动生成CLI命令，在终端中执行命令就可以在项目中使用此物料。 另外，也可以将项目中的某些功能抽离为物料，供其他项目使用。以此实现可持续迭代和渐进式开发。这样就完成物料资源在不同团队，不同项目，不同成员之间的共享和复用，提升前端的整体协作效率。 整体收益 内部接入6个项目；在公司内部NPM中开源了2个组件库；在BU内部共推出了4款产品，分别是Union Design设计规范、@baidu/union-design、@baidu/union-design-wechat和marble-cli/GUI工具； 在代码复用率方面，项目基础框架为46.1%，业务逻辑为21.87%；全新开发一个项目迭代周期缩短23.8%，迭代的项目缩短21.4%； 最后有任何疑问请联系作者

研发效能的重要性：研发效能肩负着提升企业产品交付和创新能力的责任。我们为什么要提高研发效能，因为技术本身是为业务服务的，产品的价值体现在业务上，技术的所有价值最终都要通过业务结果来呈现，我们的根本目的是帮助业务成功，促进业务腾飞。那技术就不重要了吗！重要，因为所有的业务价值最终都要通过软件服务来变现，两者相辅相成，互相促进。然而，如果对研发效能是什么缺乏共同的认知，我们又如何去改进它呢？ 效率竖井是研发效能改进的最大问题：如今大部分公司以传统的角度，更关注各个职能和部门的独立改进。然而，产品交付需要前后职能（如：产品、开发、测试等）和平行部门（如：前端、后端、算法等）的协作，过度局部优化，相反会导致效率竖井，反而影响整体的效率。 上图描述了传统开发模式下，产品交付面临的困境。从交付周期线明显可以看出，从需求的提出到交付需求的过程中，由于大部分时间都在等待，导致交付周期增加，从而影响研发效能。而这些等待有可能是需求需要批量处理等待，或者是部门间需要协作相互等待。最后导致虽然各个局部闲的繁忙“高效”，但整个系统对外响应效率很低。这就是效率竖井，也是研发效能提高要解决的主要问题。 阿里巴巴所提供的的解决方案：基于这样的度量体系，应该设定怎样的目标呢？我们在多个团队的实施过程中，逐渐沉淀出了可供参考的目标体系，它可以总结为三个数字——“2-1-1”。 “2-1-1”最初来自天猫新零售，其后在闲鱼和研发中台、阿里云等团队完善和采用。什么是“2-1-1”呢？其中“2"指的2周的交付周期，85%以上的需求可以在2周内交付；第一个“1”指的是1周的开发周期，85%以上的需求可以在1周内开发完成；第二个“1”指的是1小时的发布前置时间 - -提交代码后可以在1小时内完成发布。 达成“2-1-1”的愿景并不容易。1小时的发布前置时间，需要持续交付流水线，产品架构体系和自动测试、自动部署等能力的提升。1周的开发周期，涉及更多的能力和实践，如：需求的拆分和管理，开发团队的分工协作模式，以及持续集成和持续测试实践；最困难的则是2周的交付周期，首先它要以另外两个指标为基础，同时还涉及整个组织各职能和部门的协调一致和紧密协作。 当然，“2-1-1”是源自特定的团队，并非所有团队都要使用同样的值，比如对于涉及硬件开发的团队，两周的交付周期通常过于挑战。组织应根据自己的上下文设定恰当的目标，重要的是，它要指明改进的方向。 课程介绍：本课程将从研发效能的定义和度量着手，逐渐深入解析来自不同业务部门提升持续交付能力的实践、方法和工具，同时还将分享如何基于持续交付能力，切实提升产品和业务创新的效率和效果。• 课时1：研发效能如何定义：详细讲解研发效能的定义。• 课时2：研发效能如何度量：讲解研发效能的度量体系和改进愿景。• 课时3：利用看板帮助效能可视化价值流动：以可视化价值流动为基础，及时暴露价值交付过程中的问题和瓶颈。• 课时4：需求持续、快速地流动和交付：控制在制品数目，可以更及时的暴露问题、阻碍和瓶颈，促进团队系统性的改进，从而让价值顺畅流动。• 课时5：内建过程质量：以需求为单位保障各环节的质量，把质量内建到每个需求的各个环节。• 课时6：搞笑的每日站会：站会以价值交付为线索，从右向左检视需求的状态，聚焦于发现和处理价值流动中的问题。 关于如何改进研发效能详细内容：阿里巴巴研发效能提升实践系列公开课 课程讲师：何勉，阿里巴巴集团研发效能事业部资深技术专家，畅销书《精益产品开发 原则、方法与实施》作者，知名产品交付和创新方法专家。

本文将会介绍 Markdown 中 Markdown 标记的典型使用场景使用空格、空行、缩进等元素优化排版的方法常用中文标点符号规范这些是 Markdown 写作的比较常见的排版格式指导，同时也是排版格式约定。遵守它们能使得排版更加美观，更加方便阅读，也能让你有固定的模式可依，降低写作时对于排版的心智负担。 一、Markdown 标记的典型使用标题文章的顶层标题使用二级标题每个小节的标题使用三级标题小节中进一步分层组织时使用四级标题尽量少用五级标题和六级标题，考虑用有序列表和无序列表代替完全不用一级标题粗体、斜体需要强调某处内容时使用粗体，如： 中文全角标点符号占一个汉字宽度，英文半角标点占半个汉字宽度（亦即一个字母宽度）。在中文排版中不使用斜体。在英文排版中可用斜体表达强调，或表示书名、题目。 引用以下情况使用引用标记： 引述内容时（也可直接用引号替代）作示例时给出提示、警告等额外说明时行内代码、代码块某一行文字中嵌入简短代码时使用行内代码，如： 打开 Linux 虚拟终端，输入 echo 'Hello World'。恭喜，你已经入门 Shell 了 ：）展示多行代码时使用代码块，也可用于 XML、JSON、配置项等。尽量在使用代码块时给出语言标识，有些 Markdown 工具会针对该语言高亮显示其中的语言元素。如： ```javapublic class Main {&nbsp&nbsp&nbsp&nbsppublic static void main(String[] args) {&nbsp&nbsp&nbsp&nbspSystem.out.println("Hello World");&nbsp&nbsp&nbsp&nbsp}}```将显示为： public class Main { public static void main(String[] args) { System.out.println("Hello World"); }}图片Markdown 中使用  的方式来插入图片，这里的「图片名称」可以任取，但是推荐使用对图片主题具有描述性的文字。因为在一些网站或软件中，图片无法加载时会显示这个「图片名称」，这时至少还能给读者传递出一点有用信息。 二、空白符号的运用空格Markdown 中半角空格的使用很重要，一些情况下能调节文字间距使得排版更加美观。 中英文混排时，英文前后各加一个空格，如： 请坚信 Markdown 会为你带来生产力的提升。中文和阿拉伯数字混排时，数字前后各加一个空格，如： 2008 年已经过去 11 年了！若英文或阿拉伯数字若紧邻中文全角标点，则其与标点之间不加空格，如： 有了 Markdown，可以不再用 Word。空行正文段落之间用一个空行来分隔，可以显得段落分明、结构不拥挤，如： Markdown 是一种标记语言。在写作时，你的所有文字都是没有样式的纯文本，在其中插入若干 Markdown 标记后，被标记的文字便有了样式。比如，在你所写的文字中，希望某一行的最终排版呈现一级标题的样式，那就给这行文字加个一级标题的标记；某个地方有两个字需要加粗，那就给这两个字加个粗体标记。 ...

一、写作排版是个难题写作是每个人日常生活和工作中必不可少的内容，无论是写博客、写邮件，还是写报告、写接口文档、写项目方案文档。 在使用 Word 或类似编辑工具写作时，想必你一定纠结过字体、字号、间距等等的排版问题吧 ：）。 Word 这类富文本编辑工具，以所见即所得的方式，为用户提供了大量的可选样式和排版支持。它的功能十分强大，样式选择也足够自由，但也正是因为这样，让没有经验的用户面对排版样式的汪洋，不知所措： 一级标题用什么字号什么字体？二级辩题用什么字号什么字体？正文用什么字号什么字体？正文与前后标题的边距怎么设定？行间距，字间距，段落间距？......由此看来，想要让文字排版成一篇看起来有模有样的文章确实不是一件容易的事，不仅需要掌握一些排版知识，也需要培养基本的排版审美。要是你向我一样有强迫症那就惨了，不停地去调整比对，却总是不尽人意 ：）。 那有没有这样一个模版，推荐一个好看的样式，让我不用关心各类字体、字号、间距等等的问题，而是可以直接往里头套用？ 试试 Markdown 吧。 二、Markdown 是什么Markdown 是一种标记语言。在写作时，你的所有文字都是没有样式的纯文本，在其中插入若干 Markdown 标记后，被标记的文字便有了样式。样式将会在渲染的时候呈现，并且样式的显示效果由 Markdown 工具决定。 比如，在你所写的文字中，你希望某一行的最终排版呈现一级标题的样式，那就给这行文字加个一级标题的标记；某个地方有两个字需要加粗，那就给这两个字加个粗体标记，最终的排版效果中这两字就会是粗体模样。 Markdown 支持对多种文章元素做标记，包括但不限于： 一至六级标题粗体斜体引用列表图片表格链接代码块当前这篇文章就是用 Markdown 写的。你正在看的这部分内容的 Markdown 形式是这个样子的： Markdown 是一种标记语言。在写作时，你的所有文字都是没有样式的纯文本，在其中插入若干 Markdown 标记后，被标记的文字便有了样式。样式将会在渲染的时候呈现，并且样式的显示效果由 Markdown 工具决定。比如，在你所写的文字中，你希望某一行的最终排版呈现一级标题的样式，那就给这行文字加个一级标题的标记；某个地方有两个字需要加粗，那就给这两个字加个粗体标记，最终的排版效果中这两字就会是粗体模样。Markdown 支持对多种文章元素做标记，包括但不限于：- 一至六级标题- 粗体- 斜体- 引用- 列表- 图片- 表格- 链接- 代码块这些内容经过渲染之后便是你所看的的效果。 三、Markdown 的使用方法前面说了，Markdown 其实就是给文章内容作标记，把某处内容标记成什么那它最终就呈现对应的样式，而这些标记是一些简单的符号。 那 Markdown 标记都有哪些，样式效果是怎么的呢？ 常用的标记(1) 二级标题 ## 这是二级标题这是二级标题(2) 三级标题 ### 这是三级标题这是三级标题(3) 四级标题 #### 这是四级标题这是四级标题(4) 粗体 这是**粗体**这是粗体 (5) 引用 > 这是引用这是引用(6) 有序列表 ...

1.不要使用+和fmt.Sprintf操作字符串+操作字符串很方便，但是真的很慢，在Go语言里使用+会导致你的程序跑得可能比脚本语言还满，不相信的可以自己做个测试，用+操作，迭代十万次，Python、Javascript都比Go快很多（是很多噢，不是一点点） func TestStr(t *testing.T) { str := "" for i := 0; i < 100000; i++ { str += "test" }}测试结果 PASS: TestStr (3.32s)str=""for i in range(100000): str+="test"测试结果: ~/» time python test.py 0.03s user 0.03s system 81% cpu 0.078 total作为静态语言的Go，居然在这么一个段简单的代码上执行效率比Python慢了100倍，不可思议吧？不是Go的问题，而是在Go中使用+处理字符串是很消耗性能的，而Python应该是对+操作字符串进行了重载优化。（Javascript +操作字符串也很快） 最有效的方式是采用bufferstrBuf := bytes.NewBufferString("")for i := 0; i < 100000; i++ { strBuf.WriteString("test")}结果可以自己测试，会让你很惊讶 有一些需要简单组合两个字符串，用Buffer麻烦了点，比较容易让人想到的就是用fmt.Sprintf()来组合，很多包里的源码也是这么写的。其实fmt的Sprintf也非常慢，如果没有复杂的类型转换输出的情况下，使用strings.Join性能会高很多 func TestStr(t *testing.T) { a, b := "Hello", "world" for i := 0; i < 1000000; i++ { fmt.Sprintf("%s%s", a, b) //strings.Join([]string{a, b}, "") }}PASS: TestStr (0.29s)func TestStr(t *testing.T) { a, b := "Hello", "world" for i := 0; i < 1000000; i++ { //fmt.Sprintf("%s%s", a, b) strings.Join([]string{a, b}, "") }}PASS: TestStr (0.09s)从结果来看strings.Join 比用Sprint快4倍左右吧。 ...

著作权归作者所有。商业转载请联系 Scott 获得授权，非商业转载请注明出处[务必保留全文，勿做删减]。Scott 近两年无论是面试还是线下线上的技术分享，遇到许许多多前端同学，由于团队原因，个人原因，职业成长，技术方向，甚至家庭等等原因，在理想国与现实之间，在放弃与坚守之间，摇摆不停，心酸硬扛，大家可以找我聊聊南聊聊北，对工程师的宿命有更多的了解，有更多的看见与听见，Scott 微信： codingdream。本系列共 18+ 篇（最开始 15+ 篇，未来会扩充到 30 篇），此为第六篇预热[对旧文章进行了更多观点的更新和补充]，大家感兴趣后面文章可以点下关注，再转发下朋友圈我就心满意足了。 正文开始中国铁路大提速是指由 1997 年至 2007 年期间，中国铁路一共进行了六次大面积的提速，提速前的 1993 年，全国列车平均旅行速度仅有 48.1 公里/小时，到今天，中国着眼于建设高速客运专线，使其最高速度达到 350 公里，如今庞大的高铁协调系统复杂程度远超过往，而调度运输效率同样翻天地覆。技术革命会促使组织结构发生巨大的变化，也会给组织间的协调方式带来新机遇和新挑战，这一点在互联网公司同样成立。我们提到互联网公司，总能联想到敏捷、快、轻、颠覆这些字眼，而事实上除了头部巨头公司的部分部门和部分小而美的中小创业团队，真正能做到敏捷的公司并不如想象中的多，这些公司不仅缺乏敏捷和效率才能持续优化组织升级的思维和意识，更多是缺少自我革命推倒重来的勇气，所以 996 横行，只能靠人力和时间来弥补效率和能力的不足，来实现所谓产品上的快速迭代。 实际上产品上能实现连续正确的快速迭代，影响它的因素是有很多的，比如：业务团队的决策和执行、产品经理的行业功底、项目经理的管理能力、工程师的项目经验、前后端之间的协同等等。从顶层的战略设计，到管理层的理解与推动，到一线的过程设计和执行，任意一个环节掉链子，都会导致产品的迭代出现方向上或者速度上的问题，而工程师的视角容易自前向后自左向右自内向外，往往缺少自上向下的透视，我们重点看前后端协同这块的优化路径。 研发流程的核心人物是 PM这是小菜技术部我们所遵守大项目研发流程，它往往是线性的： 其中在开发阶段，也是跟前后端工程师密切相关的就是在数据对接这一层有较大的合作成本，我们把这个线性的过程再绘制如下： 来看红色的几个，系统设计，里面涉及到 Java 服务端工程怎么搭建、骨架怎么搭建、服务怎么拆分，最后具象的时候，是服务端同学设计这个数据库和表结构，这几张表上面的字段有哪些。然后接口设计，服务端同学会给出接口的文档，比如说会给你提供五个接口，每个接口 15 个字段，才会进入到前后端对接完之后，再帮你去做一份 Mock  数据，然后前端在页面上把页面样式重构之后，再去调假的 Mock  数据，然后页面交互流程调通之后再切到正式接口，大概是这个套路。这里面有很多工具栈，很多第三方开源的工具可以用，那我们发现这里面前后端堵塞在这个点，而且堵塞很多年也解决不掉，因为接口设计控制权在服务端手里，前端不知道会给到多少接口，然后在接口评审时候，15 分钟或者一个小时，前端基本上很难理解哪个字段背后的业务含义，过后还要和服务同学反复再沟通确认，就因为在这个点的堵塞导致上面三个问题不是很好解决。 往往产品迭代出了问题，就有可能就是上图中某个环节出了问题，所以我们会需要强势的靠谱的 PM 做更严谨的项目管理，同时从技术团队也要给产品经理和运营施加压力，来挤压出最真实的需求，这里对项目经理业务能力和项目能力是重度依赖的，越靠谱的项目经理，这里就有越高效合理的项目迭代，反之可能就坑坑无数。 通过这里引入更靠谱的项目经理，我们可以大大降低前后端以及研发前置和后置流程中的风险点，迭代也会更有节奏感，再往下到数据接口层面的对接和 UI 上的透出效率，项目经理就爱莫能助了。 展示层协同与效率的成本结合多端展示多样化报表的场景，最初研发成本居高不下，从前端的视角看过去是这样的： 第一个是多端之间的类报表同步，大家现在开发前端，可能开发小程序，APP，PC，会有多端，对我们公司场景来说我们这个端比较杂，可能要在 ERP 要透出报表，在 App 上透出报表，在小程序上透出报表，但是面对不同权限的人报表透出的维度不一样，但本质上下面的数据源是同一份，那我们就可能开发很多个接口去对应不同的 APP，那这个纯靠前端做数据切片组装不太现实。 第二个是多端之间多模块共享，这个模块还不是组件，比如有一个用户模块，一个订单模块、一个物流模块，每个模块里面可能会有一两个组件来组成，但向下所需要的基本数据可能还是同一份或者同两份，只是在不同端上的 UI 呈现不一样。那我们想要让这些模块之间去共享数据很难，我们在不同端上开发一个组件就绑定一个接口，这个组件拿到另外一个里面去，套到那个模块去用的时候发现行不通了，这也是一个很大的成本。 第三个是业务变化快，产品总要升级迭代，UI 重构或者交互改版的时候，加一个字段，减一个字段，或者叠加几个字段合并后的状态值，那么接口又要升级，或者加一个新接口，这个同样导致合作成本很高。 把三个问题再抽象一下，其实就是这三个： 第一个是  API  的设计，服务端同学有的时候会被迫也好，被 “强奸” 也好，我必须要面向你多变的 UI 去做 API 的设计，面向这些页面服务，页面变化的时候，API 可能也要升级。 ...

想到更多再持续更新。我总是面临一个心态的平衡问题，就是要么很着急很着急要把一个东西很快弄懂做出来，那结果往往就是看了点皮毛就开始implement，结果一团糟；要么很放松很放松期望会学很久，于是搞得也特别慢，往往不能很快应用于现实。我今天意识到这个问题，想要来解决一下，看看有没有好的平衡点。我觉得最好的方式应该是1）提升效率 2）先快速上手，然后如果需要的话，边深入学习边在应用中（implementation中）提高。以下主要讨论1，并且主要是深入学习当中提升效率。有哪些办法可以逼迫自己提升学习技术的效率：1） test driven的方式，这里的测试并不一定指unit test这种，而是说去尝试例子的精神，从例子当中学习。e.g.要学python就要经常打开python shell去试各种函数，要学spark就要开spark，别懒，光看有个毛用！！！2） 看别人的code，但不是光急急地copy&paste，而是要弄懂。往往弄不懂的地方，再深入钻研下去，就会发现很多亮点。3） practice driven，这个不多说了，我已经每次提醒自己了，但就是行动还要跟上。4） exam driven，也不多说了，逼迫自己复习和检验！

Ankur Biswas 原作，授权 LeanCloud 翻译。分享我最喜欢的一些 MacBook 屏保，让电脑看起来美美哒～Padbury ClockWord ClockSimple ClockGrid ClockFliqloFractal ClockWord Clock如果喜欢这些屏保，可以和小伙伴分享！留言告诉我，哪个屏保是你的最爱？LeanCloud，领先的 BaaS 提供商，为移动开发提供强有力的后端支持。更多内容点击 www.leancloud.cn

转载请注明文章出处：https://tlanyan.me/recommand-…Awareness是Futureproof公司的产品，官网地址：http://iamfutureproof.com/too…。Awareness的功能非常简单：告诉你在电脑上工作了多久并在整点提醒你 。其设计理念是让用户知道自己已经用了多久的电脑，于是可以在必要时停下手头的工作，站起来泡咖啡、上厕所走动一下，或者伸懒腰、做深呼吸放松身体，劳逸结合以便长时间高效地工作。Awareness启动后会播放敲钵的声音，并在右下角托盘生成图标。此时软件已经开始计时，你可以放心地关掉桌面上Awareness的窗口，准备接下来忙碌的工作。连续用电脑达到一小时，软件将再次播放敲钵的声音，提醒你已经连续工作一小时。如果你花五分钟时间离开电脑放松放松，比如伸个懒腰顺便喝下午茶，Awareness的计时将重置为0，直到你再次用电脑才开始重新计时。用电脑期间，你可以随时将鼠标放到托盘的图标上方，看看已经连续工作了多久。<img src=“https://tlanyan.me/wp-content...; alt=”" width=“422” height=“277” class=“aligncenter size-full wp-image-3147” />可以看到，Awareness是一款功能简单、设计简约的软件。它非常贴心，静默工作，没有广告也没有弹窗，是小而美软件的典范。对经常长时间用电脑工作的人士，这款软件十分推荐。例如程序员，写代码调试程序经常一坐就是两三个小时。有了这款软件，每隔一小时会铁行，此时可以起来喝水上厕所，或者走动透透气。既能清醒头脑保持后续工作效率，也能让全身肌肉放松，一定程度上预防和缓解颈椎脊椎劳损，保持身体健康。从实用性上说，Awareness可谓是电脑办公人士的贴心小棉袄。Awareness也提供Mac版本，苹果电脑也能使用。当然苹果电脑上有另外一款更知名但名称类似的软件：Aware，其官网是：https://awaremac.com/。Awareness官网推荐了另外一款我电脑上必备的软件：flux。flux是一款色温调节软件，会根据日出日落时间自动调整显示器的色温，防止屏幕过亮或过暗刺激眼睛，从而预防眼疲劳。什么都不用做，flux便会自动呵护你的眼睛，并几乎从不打扰你。其同样是一款小而美、非常贴心的办公辅助软件，也是我电脑的必备神器。

原文作者： Darren Burns 翻译：weakish@LeanCloud原文链接：Power Up Your Command Line本文是「命令行威力提升」系列的第二篇，这一系列展示一些出色的非标准工具，这些工具能让命令行用起来更容易、更享受。peco 交互式过滤将任何命令的输出通过管道传给 peco，便能交互式地过滤输出，查找所需信息。你可以把它想成交互式 grep，随着输入实时更新结果，让搜索过程更直观。你可以使用上下键选择搜索结果，然后用回车键确认。按下回车后，peco 会输出结果。安装 pecomacOS （Homebrew）： brew install pecohexyl 十六进制查看器检查二进制文件时通常查看文件的十六进制表示。hexyl 是个命令行下的十六进制查看器。界面分为三栏：偏移量 当前所在的字节数十六进制 文件的十六进制表示（自身又分为两栏，不过在上面的 gif 例子中不可见）表示 尝试将文件显示为文本（同样分为两栏，gif 例子中未显示）hexyl 显示的每个字节的颜色取决于其类型（NULL、ASCII、non-ASCII等），这很有助于可读性。小窍门 ：查看二进制文件或大的文本文件时，输出经常会超出屏幕，所以你可以把 hexyl 的输出传给 bat 或 less，以支持分页。如果用 less，需要加上 –raw-control-chars/-r 参数以正确显示颜色。hexyl 由 David Peter 使用 Rust 编写，他也是 bat、fd、hyperfine 的作者，我在本系列的第一篇文章中介绍过这些工具。安装 hexylmacOS （Homebrew）： brew install hexylpomo 番茄钟计时器番茄工作法是提升生产效率的好方法。如果你还没听说过，那么它大概是这样的：你心无旁骛地工作 25 分钟放松 5 分钟，做任何你想做的事情（只要不是工作 ????）重复以上步骤 4 次（根据需要调整这个数字)，接着休息 15 分钟根据番茄工作法这一理论，遵循这一计划能让你在相对较短的时间内完成相对较多的事情。这也许不适用于每个人，但我个人验证了它的有效性！pomo 是一个简单的命令行工具，助你依照番茄工作法管理时间。安装 pomo在 macOS 上安装：从 GitHub 下载二进制文件：curl -L -o pomo https://github.com/kevinschoon/pomo/releases/download/0.6.0/pomo-0.6.0-darwin-amd64设置权限：chmod +x pomo加入 PATH：mv pomo /usr/local/bin初始化数据库：pomo initncdu 分析、清理磁盘空间如果你的计算机上有很多项目，最近也没有清理过磁盘。那么你几乎一定能找到一个占用大量磁盘的文件夹（我发现旧项目的 node_modules 文件夹特别容易占用大量空间）。ncdu是我最爱的修复工具。事实上，在创建下面的 ncdu 演示例子时，我清理了 10 GiB 的磁盘空间！只需运行 ncdu 即可使用。它会扫描当前目录下的所有子目录，所以如果在家目录运行 ncdu，也许需要较长时间扫描。ncdu 的 ncurses 界面可以使用方向键，也可以使用 vim 风格的快捷键。安装 ncdumacOS （Homebrew）： brew install ncduHTTPie curl 的现代替代品HTTPie 是一个更简单（不像 curl，每次使用都要 Google 下用法）、功能更多、更美观的 curl 替代品，可以在命令行调用 HTTP 的 API。到目前为止，我介绍的工具中，它是最流行的，而且有很精良的文档。http 命令的输出足够与 cURL 区分开来。输出的 JSON 响应带语法高亮，十分美观，可读性要好很多。如果你偏爱图形 UI，那么你也许会喜欢 Insomnia、Postman 或 Paw （Paw 需要购买许可，并且只适用于 macOS）。安装 HTTPiemacOS （Homebrew）： brew install httpie结语感谢阅读！在这一系列的下一篇文章中，还有一些工具值得一提。如果你有任何建议，欢迎联系我！如果你对更多类似内容感兴趣，可以在 Twitter 上关注我。 ...

原文转载自 Antirez翻译：江宏在编程界的传说中，一个 10x 程序员可以完成普通程序员十倍的工作量。所谓普通程序员，可以想象是一个擅长他/她的工作，但没有 10x 程序员那样神奇能力的人。更好地描述「普通程序员」的说法是它代表了专业程序员里平均的编程输出水平。编程社区对于这种动物是否存在有两极分化的看法：有的人认为根本不存在，有的人却认为不仅存在 10x 程序员，如果你知道怎么寻找的话，甚至能找到 100x 程序员。如果你认为编程是一个「线性」学科，很明显 10x 程序员存在的可能性看起来确实不符合逻辑。跑步者如何做到比另一个跑者快 10 倍？或者说一个建筑工人在相同的时间内如何做到其他人十倍的工作量？然而，编程是一种很特殊的设计学科，即使当程序员不参与架构上的实际设计时，在实现一个产品时，仍旧需要对实现策略进行设计。所以如果程序的设计和实现不是线性能力，那么在我看来，工作经验、编程能力，知识储备，辨别无用组件的能力等都是非线性的优势，它们以乘积的方式在产品开发中发挥作用。当然，当程序员能同时负责软件的设计和实现时，这种事半功倍的现象就更多了。一个任务越是「目标导向」，潜在的 10x 程序员就越有空间利用她/他的能力以比别人少很多的努力达到目标。当手头的任务更僵化，对开发工具及实现方式有很多限制时，10x 程序员在更短的时间内完成更多工作的能力就被削弱了：它仍然可能利用对「局部」设计的把控来做的更好，但却无法根本上改变到达目标的路径，包括把设计规范的某些部分彻底去掉，以大大减少工作量却达成几乎同样的目标。在作为程序员工作的二十年里，我观察过很多和我一起工作的程序员，由我指导以达到既定目标，如为 Redis 和其他项目提供补丁。正是在这些协作过程中，很多人认为我是很高效的程序员。考虑到我远非工作狂，我就以自己为参考来谈谈如何快速开发。以下是我认为对编程效率影响最大的几点特质。纯编程能力：完成子任务程序员最明显的优劣势体现在实现程序的一个部分的子任务中，包括函数，算法或其他任何东西的实现。令人惊讶的是，根据我的经验，非常有效地使用基本指令式编程工具以实现某些东西的能力并不像大多数人认为的那么普遍。在一个团队中，有时我观察到非常不称职的、甚至简单的排序算法也不知道的程序员能完成的工作却比理论上应该很强在实践中却很弱的大学毕业生要多。经验：模式匹配我所说的经验指的是已经探索过的一系列重复性任务的解决方案。经验丰富的程序员经过积累最终知道如何处理各种子任务。这不仅能提高效率，也是防止设计上的错误的强大武器，这些错误往往是简化设计的最大敌人。重点：实际时间 VS 假设时间不看质量光看编程花费的时长是毫无意义的。内部和外部因素都可能影响你的专注程度。内部因素是拖延症、对项目缺乏兴趣（不喜欢的事情你一定无法全身心投入）、缺乏锻炼、睡眠不好或很少等。外部因素是频繁的会议、工作环境不佳、经常被同事打断等等。很自然，提高专注度，减少中断对于提高开发效率有不可忽视的作用。有时为了集中注意力，需要采取一些极端措施。比如我，通常只在固定时间收发电子邮件且只回复重要部分。学会取舍：通过干掉 5％ 来获得 90％当人们不愿承认一个非根本的目标造成了很大一部分设计的复杂度，或者因为一个根本功能和一个非根本功能之间存在取舍压力而造成更重要的目标难以达到时，复杂度就产生了。对设计者而言，认识到设计中难以都实现的那些部分非常重要，也就是说，付出的努力与收益不一定是成正比的。在项目中为了获得最大收益，就需要专注于能在有限的时间内完成的最重要的部分。例如，在设计消息代理 Disque 时，我意识到通过只尽力（而不是绝对）保证消息的顺序，项目的其他方面都可以得到实质性的改进：比如可用性、查询语言以及客户端交互、简洁性和性能等。简洁性这是一个显而易见的观点，这一点至关重要。为了理解简洁性，有必要检查复杂度都是如何产生的。我认为复杂度的两个主要驱动因素是不愿意进行设计上的牺牲，以及设计活动中错误的积累。仔细考虑设计的过程，每一次错误选择都使我们离最优解决方案更远。一个最初的错误当遇到错误的人时，不会导致这个系统的重新设计，而会导致设计另一个更复杂的方案来应对这个错误，因此，这个项目就随着每个错误的出现而变得更加复杂和低效。简洁性可以通过在脑子里进行“概念验证”的推理来实现，这样可以让程序员设想大量的简洁的设计，然后动手实现看起来最可行和最直接的方案，随后再靠经验和个人设计能力改进设计，并为子级设计找到合理的方案。然而每当需要一个复杂的解决方案时，都有必要花很多时间思考如何避免复杂度，只有在考虑过各种替代方案后都没发现更好的选择之后再继续朝那个方向走。完美主义，或者说如何牺牲生产力并引入设计偏见完美主义有两种类型：一种是让程序的可量化性能达到最优的工程师文化，另一种是人格特质。我认为这两种情况下完美主义都是程序员实现快速交付的最大障碍。完美主义和对他人评价的恐惧会导致设计偏差，导致选择不当，仅根据心理或无关紧要的可量化参数来改进设计，却从未考虑诸如程序的健壮性，简洁性，及时交付能力之类的事情。知识：一些理论会有帮助在处理复杂的任务时，关于数据结构，计算的根本局限性，适合特定任务的重要算法等的知识将会对找到合适设计的能力产生影响。并没有必要在各方面都成为一个超级专家，但知道一个问题的多种潜在解决方案是必须的。例如，接受设计上的牺牲（接受一定错误率）并了解高概率地估计集合大小的方法，可以避免设计出复杂，缓慢和占用大量内存的从流数据中计算唯一元素数量的方案。底层：了解机器即使是在使用高级语言时，有很多程序里的问题都是由对计算机完成特定任务的方式产生误解造成的。因为所使用的工具或算法存在根本问题，这甚至可能导致项目需要从头开始重新设计和实现。掌握好 C 语言，理解好 CPU 如何工作以及搞清楚内核如何运行、系统调用是怎样实现的，可以避免在后期出现严重的意外。调试技巧花费大量时间找 Bug 是很常见的事。如果你善于逐步获取 Bug 状态以用理性的步骤修复，并且编写代码的时候注意尽量简化以减少 Bug，就可以大大提升效率。在我看来，以上这些特质对输出产生 10 倍的影响并不奇怪。它们使得好的实现可以从一个可行的模型和比替代方案简单数倍的设计开始。有一种强调简洁性的方式，我喜欢称之为「机会主义编程」：在开发的每一步中，选择实现对用户有最大影响并需要最少努力的功能。

开开心心地上班,这时你得打开我的电脑,点进D盘,打开某个项目;然后还得打开XX文档,还有….最后的最后,你的桌面便成了这个样子每天你都得天打开多个文件夹，切换时找文件找的晕头转向而烦恼。每天层层深入的找某个文件而浪费时间。今天为大家推荐一款资源管理神器“Colver”,Colver可快速找到文件，打开多个文件夹,桌面还是一样的整洁方便的Tab页功能,像浏览器一样打开文件夹要掌握功能强大，操作简单的标签页，只需记住Ctrl+T新开页面，Ctrl+W关闭页面，Ctrl+Tab切换页面，工作效率提高何止一倍！操作系统无缝集成Clover 通过插件的形式集成到 Windows Explorer，保留您通常的使用习惯，无需学习新的文件管理操作，马上就可以使用啦。快如闪电的书签栏按Ctrl+D添加当前路径，或者直接将文件夹拖入书签栏。再也不用到处寻找要访问的文件夹了，瞬间到达，何等痛快！管理书签设置快捷键如果你的文件存放位置杂乱无章的话，再推荐一款神器——Everything，让你瞬间找到你想要的文件,比系统自带的搜索功能不知道强大N倍。当然平时养成一个整理文件的好习惯很重要，再结合Clover，开发效率会提升不少，快去试试吧。获取方式</article>长按二维码,回复:资源管理坚持日更:39天您的点赞、转发是对我最大的支持！ THANDKSEnd -一个立志成大腿而每天努力奋斗的年轻人伴学习伴成长，成长之路你并不孤单!

本文转载自我的博客Git 可以说是目前最受欢迎的版本管理工具了，很多团队也都在用它来管理自己的项目代码。在一个多人协作的项目中，往往采用的是一个分支一个特性进行开发，随着每天的代码提交、合并，仓库中会有越来越多的冗余分支。这么多死分支不仅会掩盖真正在使用的分支，而且也为管理带来不便。如果你像我一样，也经常被淹没在 git branch 或 git branch -r 返回的分支大海中，那么，就是时候考虑给你的 git 仓库做一次大扫除了！本地分支与远程分支大扫除之前，首先给自己做个深呼吸，回忆一下远程仓库和远程分支的概念。我们本地的仓库既保留有本地的分支，也保留有跟踪远程仓库的 remote 分支（类似 remotes/origin/** 这种的）。后者相当于是远程仓库分支在本地仓库的代理，每次 git fetch 或 git pull 时，都会将远程仓库的分支同步到本地对应的 remote 分支上。比如远程仓库新增了一个 feature/add_a 分支，那么我们在本地 git fetch 后，会得到一个 remotes/origin/feature/add_a 分支，这个名字表示 origin 这个远程仓库下的 feature/add_a，origin 是本地给远程仓库默认起的名字，你当然也可以改成别的名字。理清楚了本地分支和远程分支，本地仓库和远程仓库，接下来我们就动起手来做清理吧！本地分支清理查看我们本地的分支只需要执行一下git branch我们还可以找出所有已经合入到 master 的本地分支git checkout mastergit branch –merged针对这些已经合入的分支，如果确定已经不会使用的话，就可以将其删除了git branch -d feature/XXX如果十分确定所有合入的分支都不再需要了，那么可以考虑一次性解决（(^*) 是匹配当前分支，其余 (master|dev) 部分可以根据自己项目的实际情况进行修改）git branch –merged | grep -v “(^*|master|dev)” | xargs git branch -d这么一来，就可以安全地删除所有已经不再需要的分支了。除此之外，也可以浏览一下没有合入 master 的本地分支，检查看看哪些分支已经废弃，不需要继续开发了git branch –no-merged针对这些分支，只用 git branch -d 命令会收到系统的善意提醒。如果十分确定可以删除，那么可以使用强制删除命令（一定要确认好啊）git branch -D feature/XXX经过这么一番清理，相信你的本地分支现在已经十分轻佻了，git branch 返回的结果看起来也十分清爽。接下来就来清理一下本地的远程分支。远程分支清理远程分支的查看只需要在 git branch 命令加一个 -r(–remotes) 参数即可git branch -r远程分支的清理，一方面是清理远程分支中，已经合入 master 的分支，另一方面是清理远程仓库已经删除了的分支，而本地还在跟踪的。第二种情况的清理非常简单，只需要执行git remote prune origin事实上，我们可以在每次 git fetch 时，添加一个参数 -p (–prune)，这样每次 fetch 远程仓库时都可以顺手删掉本地多余的分支（建议将 git fetch -p 直接 alias 到 git fetch 命令~）。再来看第一种情况，虽然同样可以通过 git branch -r –merged 来查看已经合入 master 的分支，但由于远程分支不只是自己开发的，所以还需要别人的确认才能进行删除。好在我们可以在命令行的帮助下快速筛选出每个人的分支，然后就可以把这份统计摘要发给 TA 来确认。for branch in git branch -r --merged | grep -v HEAD; do echo -e git show --format="%ci %cr %an" $branch | head -n 1; done | sort -r | grep AUTHOR_NAME这行命令首先是过滤出所有已合入 master 的远程分支(git branch -r –merged | grep -v HEAD)，然后遍历每个分支，展示(git show)其最后一次提交的绝对时间(%ci)、相对时间(%cr)和作者(%an)信息，按时间倒序排列(sort -r)，最后过滤出作者是 AUTHOR_NAME 的分支。如果想查看更多的信息，可以在 git show 的 format 加上 %s（提交信息）和 %h（commit SHA1 前缀）这样一份报告，给到相关开发同学，确认之后，就可以执行批量清理了。注意，远程分支的删除应该到远程仓库去删除（否则下次 fetch 还会再拉下来），因此需要我们把这个删除动作 push 到远程仓库。最后，如果你 push 了删除动作到远程仓库，不要忘了提醒下其他同学 git fetch -p 来同步删除自己本地的远程分支哈！git push origin –delete feature/YYY找找我是谁如果自己经常换机器开发、push 代码，而且不同机器的 git config 不完全一样的话（比如我不同机器上 user.name 有的是英文名有的是中文名），提交的作者签名也不一样，这时还需要根据不同的 user.name 进行查找……不过好在我们有命令行，用以下命令就能得到仓库里所有提交过的作者了~git shortlog -s ...