当程序员被别人说自己的代码写得“不够好”时,他们会作何反应?
还有很多类似这种“不够好”的说法,比如“不够简洁”、“不够好理解”、“对用户不够友好”,等等。我经常和程序员聊起这样的话题:为什么要让设计架构更简洁,为什么要让代码简洁易懂、为什么要格式化代码、为什么要在两个符号中间加一个空格……如果你是一个技术老鸟,或者经常看一些讲解如何写出好代码、设计出好架构的书,你可能也会有同感。这些都是最基本的概念,但并不是每个程序员都能意识到它们的重要性。
不仅是一些新手程序员不会拿这些高标准来要求自己,那些有多年经验的老手程序员也存在同样的问题。你可以建议他们去阅读《代码大全》、《代码整洁之道》、《Unix编程艺术》之类的书,或许他们当中有些人能够从书中获益,但有些仍然我行我素。
为什么并不是每个程序员都能写出高质量的代码或做出高质量的架构设计?有可能是因为他们经验不足,也有可能是因为他们不知道如何将从书中学到的或从经验中总结出来的东西应用到实际当中,又或者他们只是在完成任务,对于他们来说,程序员只不过是个糊口的工作。但从根本上讲,那是因为他们认为自己只是个程序员,而不是软件艺术家。
成为一个程序员需要具备哪些条件?
而成为一个软件艺术家需要具备哪些条件?
为了回答这个问题,我们先来看看一个艺术家的设计应该是什么样子的。
Eames夫妇在1950年设计了这张塑料座椅,到现在已经流行了几十年。我被它简洁的设计和舒适感所折服,于是我在想,我们怎样才能像设计这把椅子一样设计我们的软件呢?
这把椅子我用了三年,之所以很喜欢它,是因为:
那么,如果我们要开发出具有这种“风格”的软件应该是什么样子的?
如果一个程序员能做到这些,那么他肯定就不是只个程序员,他一定是一个软件艺术家。
或许有人会发出这样的疑问:怎样才能知道自己是否达到艺术家的标准了呢?比如“怎样才算尽可能简洁”?有些人可能会想,如果一个方法的代码行数超出了一个屏幕的范围,那它就是一个需要进行重构的“长方法”。又或者他们会建议一个对象的生命周期当中应该有多少种状态,在写代码时注意不要超出这个范围。
但其实,成为软件艺术家的意义不在于如何量化这些东西,而在于持续改进。在设计一个项目时,应该问自己:这个项目可以设计得更好吗?在代码通过测试之后,也可以问自己:代码的结构看起来够优雅吗?敢不敢拿它与你见过的最好看的艺术品做一番比较?
程序员在完成设计或写完代码之后一般不会想着怎么去改进,但艺术家会。这是程序员和软件艺术家之间最大的区别。程序员不一定都很糟糕,他们也能写出很好的代码、做出很好的设计,但一旦停下了追求的脚步,他们就无法成为艺术家。
来源: https://juejin.im/entry/5a1cfd0751882534af25b144