为什么说程序员懂设计很重要

1、拥有同理心，才能实现更好的团队合作

设计师拥有像素眼，重视外观和易用性，思维比较感性；而程序员写代码的时候更重视功能的实现和性能的提升，思维比较理性。如果程序员懂一些设计的基本原则，比如如何对齐、字体排印、配色和装饰元素，就能理解设计师提高产品观感的设计心理，和朝夕相处的设计师获得同理心。

如果一个团队的开发人员和设计人员视彼此为竞争对手，结果可想而知。如果程序员只盯着自己的一亩三分地看，遇到实现困难的时候就很容易对队友产生敌对心理。他认为设计师不懂自己，只会提出奇奇怪怪的需求。如果有设计的知识，便不会轻易产生这种想法，而会理解其实大家都是在为了共同的目标努力，设计师不是敌人。

小漫画：程序员和设计师-圆角引发的惨案

没有同理心，团队是无法高效合作的。如果开发人员懂得设计师的语言，理解设计师的想法和思路，才可以降低沟通成本，在一起无缝衔接工作。只有工程师和设计师可以理解彼此的出发点和难处，才能有更密切的团队合作。

2、为了做出更棒的产品，影响到更多人

每一年，都有各种形状、尺寸和功能的设备推出，程序员不得不去适应它们。要讨论各种新的交付，包括设计系统、风格指南和模式库的挑战。还要改组工作流程，以响应式网页设计。这是一个自然的和积极的进程。

在这个快速发展的世界里，程序员越来越需要一双懂设计的眼睛：有审美，懂设计的基本组成，还会重新诠释它们。这一组设计作品的外观和行为大概是怎样？如何将为桌面设计的标签集用于移动端？设计人员和开发人员可以共同合作来解决这些问题，才能得出一个优雅、有效、合理的解决方案。

同时，如果你了解了一个设计系统是如何建立和运行的，你就可以写出更简洁、连贯和DRY的代码。你还可以识别设计模式，写出更加模块化、面向对象的CSS。这两点对开发网站至关重要，你才可以开发出更棒的网站/产品，从而改变世界。

Facebook拥有数百名设计师，Google有千余名设计师，而Apple的设计师只有100名左右。因为苹果公司的每一个员工，从工程师到市场，都在某种程度上保持设计师的思维模式。HR也用这样的要求来招人，能够把设计考虑进工作中的人会被优先考虑。苹果的工程师能够以设计为中心出发，所以设计团队可以依靠工程师直接开始造新的App接口，而不用自己先开始画模型。

所以，苹果的出色设计不是由于苹果拥有最伟大的设计师，而是因为那里的工程师文化和组织架构都非常欣赏和支持设计师。那里的每个人都在考虑UX和设计。这才是苹果的产品拥有完美设计的深层次原因。

3、理解设计等于理解用户

小漫画：程序员和用户眼中的彼此无知的恐龙

总是埋头码代码很容易忘了，我们在做的工作是为真实的用户服务的。程序员的工作是为了解决实际问题，而不是把过多的精力放在技术挑战上面。学习和理解设计有助于提醒自己，理解这样设计要解决什么问题，从而更贴近用户。

事实上，程序员才是一个产品最后的「设计师」，因为当他们开始参与一个项目的时候，将不得不用代码做出影响和修改设计的决定。在产品的前期规划阶段，单靠产品经理和设计师几乎没有时间可以考虑一个网站的所有细节，这些未被考虑到的细节就丢给了工程师。如果工程师懂一些设计知识，可以参与设计师团队最初的讨论，就会考虑地更加全面，及时指出和调整需要折衷设计方案，最大程度地实现用户需求。

在硅谷，在Facebook 和 Quora 这样的公司，程序员不是对代码之外的事情视而不见，设计师更不会提出荒谬的方案而对开发一窍不通。只有整个团队在产品设计和开发过程中的每一个步骤对用户负责，了解其他人在干什么，才能真正的保证产品的质量。

4、增加工作的乐趣

也许，学习设计的最好的理由其实很简单：提升工作的乐趣。换一换脑子，了解设计，能为开发工作带来一些不同的乐趣。如果一位程序员对一个项目的贡献超出了技术方面，是不是更能获得成就感和满足感呢？

所以，程序员们，无聊时逛逛Dribbble学学产品细节吧！和办公桌旁的设计师聊聊天，混一混设计圈子，理解他们的语言和思路，给平凡的生活增加一点新鲜感和好奇心吧！

最后，给有心学习一点设计知识的程序员推荐一些资源，其中有书，也有在线的教程，感谢@豆瓣zhouqun的分享：

1、《写给大家看的设计书》这本书简单易懂，介绍的也都是可以遵循的规则，很适合业余爱好者阅读，非常推荐。

2、 Type is Beautiful 很好的字体博客，里面的基础文章非常值得一看。

3、Thinking with type 关于字体设计的好书，可以在线阅读。

4、《色彩设计的原理》最近出的书，浅显易懂。

5、《版面设计的原理》和 《色彩设计的原理》 是同一个系列，能学到很多关于布局的知识。

6、Designing for the web 包含了字体排印、配色和版式设计等多方面内容，值得一看，可以在线阅读。

7、Twitter & Twitter Bootstrap 如果你可以把 Twitter 整个网站自己写一遍，一定会受益匪浅。

作者：oec2003

公众号：不止dotNET

本文继续来介绍接口隔离原则（ISP）和依赖倒置原则（DIP），这两个原则都和接口和继承有关。文章最后会简单介绍几个除了 SOLID 原则之外的原则。

提起接口，开发人员的第一反应可能是面向对象编程语言中的 interface ，但接口更广义的理解会包含：

不管是上面的哪一种，要想设计好，就需要用到接口隔离原则了。

接口隔离原则的定义是：

接口被设计出来后，就会有地方对接口进行调用，调用的地方希望接口中提供的方法都是他需要的，所以在接口设计的时候，需要考虑应该将哪些方法放入其中，让调用者使用，这就是对定义的解释。

相反，如果不精心设计，接口就会变得越来越庞大，会带来两个问题：

1、在一个更高层的接口中添加一个方法只是为了某一个子类使用，所有的子类都必须对其实现，或提供一个默认实现；

2、接口中包罗万象，调用者可能会误用其中的方法。

举个例子：我们现在正在开发 SaaS 产品，里面会涉及到对租户的 *** 作，比如租户需要注册、登录等，抽象成接口代码如下：

上面的 *** 作是针对租户这个角色的，现在有新的需求来了，对于 SaaS 厂商的管理员来说，希望能禁用租户，一种偷懒的做法就是直接在 ITenant 接口中添加禁用的方法，如下：

上面的代码就违反了接口隔离原则，因为在普通租户的使用场景下，并不希望能调用到 Diabled 方法，正确的做法是将这个方法抽象到一个新的接口中，如下：

可以看出来，改造之后，每个接口的职责更加单一了，好像跟单一职责有点类似，仔细想想，还是有些区别，单一职责原则针对的是方法、类和接口的设计。而接口隔离原则更侧重于接口的设计，另一方面就是思考的角度不同，在上面例子中，按照普通租户和管理员两种不同角色的维度来思考并进行拆分。

这个原则的名字中有两个关键词「依赖」和「倒置」，先来看看这两个词是什么意思？

依赖：在面向对象的语言中，所说的依赖通常指类与类之间的关系，比如有个用户类 User 和日志类 Log ， 在 User 类中需要记录日志，就需要引入日志类 Log，这样 User 类就对 Log 类产生了依赖，代码如下：

倒置：有依赖的倒置，那肯定就有正常的依赖，我们正常的编程思维都是从上而下来编写业务逻辑的，遇到分支就写 if ，遇到循环就写 for ，需要创建对象就 new 一个，就像上面的代码，上面的代码就是一种正常的依赖。User 类依赖了 Log 类，如果倒置了，那就是 User 类不再依赖 Log 类了，下面会进一步来解释。

正常的依赖会带来的问题是：User 类和 Log 类高度耦合，当有一天我们想使用 NLog 或者 Serilog 替换 Log 类时，就需要改动 User 类，说明日志类的实现是不稳定的，而依赖一个不稳定的东西，从架构设计的角度来看，不是一个好的做法。解决此问题就需要用到依赖倒置原则。

先来看看依赖倒置原则的定义：

什么是高层模块？什么是低层模块？按照上面的代码示例，User 类是高层模块，Log 类是低层模块，二者都要依赖于抽象，就需要提取接口了：

调整后的代码 User 类中依赖变成了 ILog 接口，日志的实现类 Log 也依赖 ILog 接口，即从 ILog 接口继承而来，现在都是依赖 ILog 接口，这就是依赖倒置。

当想要将日志组件替换为 NLog 时，只需要创建一个新的类 NLogAdapter 类继承 ILog 接口，在 NLogAdapter 类中引入 NLog 组件。

这样，当日志组件替换的时候，User 类就不用修改了，因为 User 类的构造函数中使用的是 ILog 接口来接收的日志组件的对象，那到底是谁决定传递 Log 对象还是 NLogAdapter 对象呢？这就要引入一个新的概念叫「依赖注入」。

关于依赖注入可以看我之前写的两篇文章：

依赖倒置是一种架构设计思想，指导架构层面的设计，依赖注入则是一种具体的编码技巧，用来实现这种设计思想。

除了 SOLID 五大原则之外，还有一些原则也在指引我们设计好的代码架构方面发挥着作用：

KISS 的全称是：Simple and Stupid ，该原则就是告诉我们，在设计时要尽量保持简单，大道至简嘛。这里的简单不完全是指代码的简洁。现在已经不是单打独斗的时代，大部分情况下开发人员都是在一个团队中协同工作，所以我认为对简单的理解可以分为：

将复杂的东西能够深入浅出，做到简单、简洁，这是能力的体现。

YAGNI 的全称是：You Ain’t Gonna Need It。直译就是：你不会需要它。核心思想就是指导我们不要做过度设计。

1、当我们能识别到代码的变化点的时候，可以预留扩展点，但不要提前做复杂的实现；

2、持续重构来优化代码，而不是一开始就提取各种通用方法，例如一个私有函数只有一个调用的时候，就放在类里面，离调用者最近的地方，当有不止一处都会使用时，再考虑重构来进行通用方法的抽取。

过度设计会浪费资源，让代码复杂度变大，难以阅读和维护。

DRY 的全称是：Don’t Repeat Yourself ，就是不要重复自己，提升代码的复用性，告别 CV 大法。

很多初级程序员都喜欢面向 Ctrl+C、Ctrl+V 编程，当需求变化的时候，很容易就遗漏一些场景，但即便是复制粘贴也不完全都是违反 DRY 。

代码的重复有两种情况：

1、代码的逻辑重复，语义也重复：这种违反了 DRY ，需要进行重构；

2、代码的逻辑重复，语义不重复：在某个阶段，两段代码逻辑是相同的，但其实是两种不同的应用场景，语义不一样，就没有违反 DRY。如果对这种代码进行重构提取成公共方法，随着业务发展，两种不同的场景独立演化了，稍不注意，代码中就会出现各种 if 判断，影响可读性和可维护性。

LOD 全称是：The Least Knowledge Principle ，也被称之为迪米特法则。该法则有两条指导原则：

1、不该有直接依赖关系的类之间，不要有依赖；

2、有依赖关系的类之间，尽量只依赖必要的接口。

其实就是一直流传的代码要高内聚、低耦合，单一职责和接口隔离想要表达的也是这个意思，区别只是侧重点有所不同：

各种原则之间相辅相成，有很多只是有些细微的差别，慢慢理解原理，才能以不变应万变。

Smartdrv命令是一个外部命令，用于在内存中创建一个磁盘缓冲区，用来暂时存放磁盘中的信息，从而加快磁盘的读写速度。

主要作用

Smartdrvexe这个文件主要作用是为磁盘文件读写增加高速缓存。内存的读写速度比磁盘高得多，如果将内存作为磁盘读写的高速缓存可以有效提高系统运行效率。Smartdrvexe这个文件在Windows各个版本的安装光盘中或是硬盘上的Windows/command /里都有，只有几十KB，把这个文件复制到软盘下，启动系统后直接运行这个程序(可以不加参数，该程序会自动根据内存大小分配适当的内存空间作为高速缓存)，再安装Windows XP即可。另外提醒大家，这个程序在安装完Windows后，不要运行，否则Windows可用内存将减少。

以上就是关于为什么说程序员懂设计很重要全部的内容，包括:为什么说程序员懂设计很重要、设计模式：面向对象的设计原则下（ISP、DIP、KISS、DRY、LOD）、什么是smartdry程序等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！