这篇文章是有感而发，也算是自己软件开发生涯的一些所思所想的总结吧。IT科技在这几十年来发展迅速，各个领域都萌生出所谓的“最佳实践”。今天主要想来谈谈这些所谓的最佳实践可能并不是那么的“最佳”，甚至有的时候它们还会是“最糟”的存在。
表明立场
首先需要表明一个立场，我并没有排斥最佳实践的意思，我跟许多人一样是RubyOnRails，Django这些Web开发最佳实践的全栈式框架的受益者。这些框架的开发者根据自己或者社区的经验把一些能够方便开发者的，比如，数据库操作，目录结构，路由定制等特性进行有效组织并集成到框架当中，虽说不同的社区侧重点有所不同，但是总体而言并没有脱离MVC这个基础模型。或许我可以认为即便它们“长相”各异，写法各异，分属于不同的社区，但他们的核心灵魂以及概念是想通的。
然而如果要脱离基础概念，区别对待，硬要从Rails，Django这些框架中选择出一个所谓的“最佳实践”就有点耍流氓了。前面也说过每个社区的侧重点不同，我以前写Django的时候还不知道有静态资源编译这回事，那时候的Rails早就有了AssetsPipline。另外，Django可能是为了让i18n的性能更加出众，相关的翻译资源都需要经过预编译的，而Rails则是运行时直接从yml文件中读取。那到底谁的做法更佳？似乎是个见仁见智的问题了。
为此请允许我简单把最佳实践归纳为
特定领域最佳思想之实践。
跟今天许多人所寻求的“最佳框架”，“最佳语法”的实践似乎不是同一个频道。你会以运行速度不够快来抨击Ruby，他会以啰嗦来抨击Java，还有人会以语法过于复杂来抨击C++。在这种层面上谁才是“最佳”真的能够争出个结果来？合适的才是最佳的。
下面我从几个方面来谈最佳实践，以及一些最佳实践为团队带来的负面影响。
最短即“最佳”？语法糖的滥用
今日之开发，抽象程度越来越高了。人们之间似乎流行出一种“最短”即“最佳”的想法。
想想刚入前端圈那一年工作组为了“掩盖”语言本身的“丑陋”，发布了ES6，确实带来了许多好处，比如总算有块级作用域了，class关键字也能用了，生成器，装饰器都有了。有了这些利器我们可以让代码变得更简短，优雅，这本身并没有什么问题，但是这似乎也为过度封装大开方便之门。
拿装饰器来说事，它实质上就是一层语法糖衣，它的作用大概如下
decoratorclassA{}//等同于classA{}A=decorator(A)A;这是一个不错的改善，能够精简语法。但是一旦被过用，代码将会变得有点奇怪了，我曾经见过这种代码
abcclassA{}好好的糖衣变成了糖精-或者说语法糖浆（英语：syntacticsyrup），指的是未能让编程更加方便的附加语法。这似乎应了那句话金钱使浅薄的人更浅薄，使深刻的人更深刻。
最早接触装饰器是写Python的时候，我记得当时有个人说过：“即便装饰器很好，但是如果多了它会使代码变得晦涩难懂，所以请尽量限制层数”。作为程序员应该要在代码易读的基础上让代码变得更简洁，脱离易读性而单单追求简短的代码纯粹是炫技，如果真的只是为了炫技而写代码，何不直接写二进制？那就真的没几个人能看懂了，而且还会显得自己很高端。
统一写法等同于最佳实践?
最近许多人都追求写法统一
WriteOnceRunEverywhere
美其名曰提高开发效率，能够使得程序员更高产。ReactNative这些技术的出现，让JavaScript编写移动端应用成为可能，这似乎是好事，我可以只学会React技术就去编写移动端软件了。更有甚者MPVUE以及Taro等框架的兴起，似乎意味着只需要学React或者Vue就能够编写各种小程序或者APP了。假设你有一个React的团队，或许采用Taro这些框架将会比写原生的小程序原生语法更爽，许多人把这看成是最佳实践。不过据我观察，世界比你想象的要残酷。
毕竟我没能够开发出这种类型的框架，没资格对这些框架评头论足，但我只想就事论事。关于统一写法我有以下的考虑
1.统一写法重要吗？
我记得有一些这类框架的拥戴者的说法是“