TMake

在所有弱点中，最大的弱点就是害怕暴露弱点。 Provide Options,Don't make lame excuses. Don't live with broken windows. Be a catalyst for change. Remember the big picture. 欲求更好，常把好事变糟。 Make quality a requirements issue. 知识上的投资总能得到最好的回报。 Invest regularly in your knowledge portolio. Critically analyze what you read and hear. 我相信，被打量比被忽略要好。 What do you want them to learn? What is their interest in what you've got to say? How sophisticated are they? How much detail do they want? Whom do you want to own the information? How can you motivate them to listen to you? It's both what you say the way you say it 了解你的听众们，好好沟通，多倾听。

1.保持单元测试小巧、快速 理论上，任何代码提交前都应该完整跑一遍所有测试套件。保持测试代码执行符合预期，这样能够缩短迭代开发周期。 2.单元测试应该是全自动/非交互式的 测试套件通常是定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。 3.让单元测试很容易跑起来 对开发环境进行配置，最好是敲一条命令或是点击一个按钮就能把单个测试用例或测试套件跑起来。 4.对测试进行评估 对执行的测试进行覆盖率分析，得到精确的代码执行覆盖率，并调查哪些代码未被执行。 5.立即修正失败的测试 每个开发人员在提交前都应该保证新的测试用例执行成功，当有代码提交时，现有测试用例也都能跑通。 如果一个定期执行的测试用例执行失败，整个团队应该放下手上的工作先解决这个问题。 6.把测试维持在单元级别 单元测试即类（Class）的测试。一个“测试类”应该只对应于一个“被测类”，并且“被测类”的行为应该被隔离测试。必须谨慎避免使用单元测试框架来测试整个程序的工作流，这样的测试即低效又难维护。工作流测试（译注：指跨模块、类的数据流测试）有它自己的地盘，但它绝不是单元测试，必须单独建立和执行。 7.由简入繁 再简单的测试也远远胜过完全没有测试。一个简单的“测试类”会促使建立“被测类”基本的测试骨架，可以对构建环境、单元测试环境、执行环境以及覆盖率分析工具等有效性进行检查

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 转载请注明出处： 葡萄城官网 ，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。 原文出处：https://blog.bitsrc.io/do-your-buttons-lead-or-mislead-your-users-d5d83531238b 按钮是UI/UX最关键的组件之一，在不同设备及平台上得到了广泛的应用。它们具有影响用户行为和体验的能力。假如按钮设计不合理，会令用户产生误解及障碍。按钮设计的目的是引导用户完成我们在交互系统中预置的用户流程得以完成，但糟糕的按钮设计则可能会是你丢失你的用户。那么，现在是时候来研究该如何设计你的按钮了！所以今天我们不聊开发相关的知识，我们来看看这个在界面中小小并且重要的元素它的设计思路是怎样的吧。 1. 按钮要设计的让用户不假思索： 当用户同时看到好几个按钮，并且按钮的意义没有清晰地表述给用户，用户就会被你的“按钮阵”所误导，从而达不到预期的效果。所以具有清晰而合理的按钮层次结构，能促进用户能够直观、即时地分辨出你设计按钮的作用是什么。下面我们来看看影响按钮层次结构的3个方面： 按钮类型 我们先来介绍一下常用的4种类型按钮： l 立体按钮：一个具有立体效果的按钮，使它引人注目。 l 平面按钮：没有任何花哨效果的常规平面按钮。 l 幽灵按钮