2016正值而立之年，在这个所谓的IT圈子混迹了7年有余。虽然早已不是那个初入江湖的毛头小孩，但也不能算什么老江湖。不上不下，仅此而已。
一直身在江湖，江湖却鲜有传说。IT这个江湖何等之大，时时刻刻人才辈出。相比那些恨不得挂着BAT等大公司工牌满街跑的人，大多数人更显得小众和默默无闻。但是我仍然坚信：这是最坏的时代，这是最好的时代。
我是个喜欢回忆和思考的孩子。
相比科班出身，半路出家的貌似更多，往往也能做得更好，好像每个行业都有不乏这样的现象。大学计算机网络专业出身的我，现在本应该是在轰隆的机房里守着路由器度日。初进社会那会儿，如同丈二和尚一般，对于开发语言仅仅略有耳闻，无奈迫于生存才硬着头皮转而学习编程。从一开始的HTML、CSS、javascript到flex、C#、php再到java、GO、android移动开发，往往是公司哪里需要就往哪里，当然要感谢IT自身产出物提供的便利，才能让我有机会一边学习，一边应付工作。Copy代码多了，自然就掌握了，这个你懂的。唯一明确的是，我是个程序员，但却又注定很难在一种编程语言的路上走到黑。
接触了这么多开发语言，我还是喜欢干些前端相关的事情。制作标准优化的代码，并增加交互动态功能，同时结合后台开发技术模拟整体效果，进行丰富互联网的Web开发，致力于通过技术改善用户体验。这是百度百科中对于前端工程师的一段定义。看似简单的几句话，却包括了大而全的技术知识要求。据统计当前前端相关技术有上百种，而且还在以相比某些单一编程语言更快的速度进行着出新和迭代。如果一个工作一两年的人，以合格的前端工程师自居，那么请看下图：
怎么样？能圈出多少能熟练掌握的技能？诚然，这并不是对前端技术的完整概括，或许也只是冰山一角。诚惶诚恐，我也不清楚自己哪只脚在门里，哪只脚还在门外。我一直不是一个合格的前端工程师，单纯就技术而言，仅仅比门外汉好过一点而已。
至于为什么要写这些前端相关的东西，也并非搬起石头砸自己的脚。个人一直认为，丰富的编程知识固然重要，然而好的编程习惯和架构意识**更加有助于工作的高质量完成。如果目标只是完成工作，那么编程就显得过于枯燥乏味了。一门技术，有时候更应该像门艺术。工作久了，难免想写一些心得，和大家一起分享和讨论。希望真诚沟通，更感谢不吝赐教。
不讨论技术，只聊聊一些**。
从来没有人能够在江湖单打独斗后一统江湖，也从来没有一个人的战斗。
相对其它端的技术，前端技术似乎丰富得有些过头。的确，就目前的前端技术实现，完全能够拼出一套完整的解决方案，但并不是每一套完整的解决方案就是最佳的解决方案。我们真正生产中所需要的解决方案是经过前人创造、后人不断检验实践完善中得出的经验组合。这是一种最佳，或者称为最优的解决方案。没有任何一种编程语言能够做好所有的事情。
前端技术，以及其他所谓的某端，都不是特指单一的编程语言，这是一种统称，来自于多种编程语言搭配组合而成用户体验的呈现。必须承认，当前主流的前端技术中大多属于新生儿，尽管经历着较为快速的迭代成长，但仍还有待经受更多的考验和完善。例如稳定性、兼容性、扩展性等。
不可否认，每个程序员的成长都是得益于所在公司的实际业务，没有人会每天看着枯燥的书籍面对着电脑冥思苦想就能够快速提高。每个公司的业务发展也从来不是依附于某个人的能力，如果是，则将公司置于危险之中，处于悬崖的边缘。一个人置身于团队当中，保持着谦卑心态，将其所代表的编程语言特性用在最合适的架构位置，才能将最优的解决方案推动业务的向前发展。
技术实力是必备条件的一方面，但态度很重要。
除此之外，了解一种编程语言的初衷是很关键的一件事，我们不能对自己所掌握的编程语言除了使用之外一无所知。有必要花一些时间去搞清楚它为何而生，要向哪里去，关注它所处的发展环境，哪些足够成熟，哪些还有待完善，更有必要的是付出贡献去推动它的向前发展。
说起前端技术所涉及的编程语言，可能很多人首先想到的是HTML和CSS。不过，我并不认为两者属于编程语言，严格意义讲两者都属于标记语言，却带有某些编程功能而已。相比某些前端工程师可以后天学习的编程语言，这两者更像是一个硬性前提，不掌握HTML和CSS，就不能以前端工作者自居。
以前有这样一则新闻，说澳大利亚急缺搬砖工，日薪高达4000RMB。紧接着社会上下一阵惊呼，自叹不如。殊不知，无论何时何地，自身价值并不是随随便便就可以上天。
轻松的笑容背后往往隐藏着许多通过长期积累才能得到的东西。
前端技术在很多时候是以看得到的直观体验的方式产出着，网页即是最常见的一种产品，HTML、CSS就是网页最基础的构成。如果说开发网页的过程像搭建房子，那么HTML和CSS就是这个房子必需的砖头和油漆，每一块砖的堆砌，每一抹油漆的粉刷，都是独一无二的构思。
下面这个图在普通用户眼里是这样的：
在前端工程师眼里也许是这样的：
简单地说普通用户和前端工程师的不同，无可厚非。然而真正在后两个情况的对比中，才真正地体现了不同的设计**。在最终的视觉效果上看，两者并没有什么不同，但我还是认为有必要讨论一下其中的细节。
Div 和Table 都是HTML中频繁使用的标签。用以实现当前这个页面效果，几乎都没有任何难度，不存在太过复杂的代码逻辑。一个好的产品，都是应该实际生产中表现最优的实践，脱离了实际应用就算不得真正的产品。问题不在于div用了两个，table用了一个。众所周知，浏览器采用从上到下边加载边解析HTML标签，严格地讲，div会先于table展现出来一部分，table需要等待其内容完全加载。也许你会有疑问，没有必要这么较真，时间在视觉感官上也没差。那想一想如果用户访问量是上万或者上亿，并成几何级增长，情况又是如何呢？
不过，这也并不代表着table从此被弃用，如果需要呈现的是更为复杂的网页，div套用层级过多带来的问题也许会更加的头疼。
在CSS角度上，先不去计较二者所用class属性的多少，单纯在图片上来说，使用Sprites的形式处理，也许将大大提高网页性能。然而这样却提高了图片切片精细度的要求，同时将class处理提升到了像素级，网页需要的图片过多，却又加大增加了合理规划的时间代价。
先是自我肯定，却又自我否定，这不是一种矛盾，只是恰好证明了世事无绝对。我们需要良好的规划意识，根据不同的场景，采用最优的编程方式，即使后期循序渐进地优化迭代都是可以接受的。在埋头苦干的时候，让我们多花一些时间来进行规划，越是合理，才能越对最终产品有利。
搬砖工有很多，就效率而言，还是不尽相同。
没人喜欢呆板的照片，所以我们选择在拍照的时候喊声茄子。同样，呆板的产品一点也不显得多么友好。
产品，作为程序员跟用户进行互动的一种方式，不应该只是跟用户干巴巴地四目相对。所有技术的发展都是为了更好地为用户提供服务。于是很多产品都开始变得活泼起来，通过各式各样的元素展现自己独特的一面。
如果说HTML、CSS并不算什么高深技术，javascript等脚本语言的出现，使得前端多了一些新鲜的玩法，但是脚本语言还是把程序员向编程语言拉近了。Javascript、ActiveX、flash等极大丰富了前端的展现形式。尤其是javascript，已成了前端人员另一种不可不知的技术。尽管javascript长时间内并没有太大的起色，近几年却风风火火，重新聚拢了人们重视的眼光。Javascript像众多编程语言一样，需要大段的逻辑代码和方法函数进行支撑，不一样的是其离不开对网页DOM的操作。
任何断言某项技术马上完全取代另一项技术的言论，都是不正确的。这取决于其自身的不断完善实践，也受益于另一项技术的不求进取。正如Flash的没落，不仅仅归咎于移动厂商齐刷刷地倒戈，还与其自身多重原因有关，再加上HTML5、CSS3、javascript新标准的及时制定出现，更是雪上加霜。同时Jquery、nodejs及其二者的枝繁叶茂便成了javascript最得意的成绩。当然flash也不会一夜之间消失，需要的是一个过程，一个前者转移技术路线的过程，一个后者丰富自身创造替代品的过程。
魔术师是一个神奇的职业，包袱里面总有一些新鲜的玩意儿掏出来，虽然不能预知下一秒什么东西会出现，但是我们仍然满怀希望，甚至惊奇地眼前一亮。如今我们的前端产品已经足够活泼和丰富，堪比魔术师的包袱，呈现给用户丰富多彩的服务。前端产品往往通过与用户的交互，在满足用户需求之外，给予用户额外的归属感。尤其是在移动互联网高速发展的今天，更需要在核心服务之外提供更多的附加感触给用户。这不是在鼓励去大包大揽，而是对创新表现形式的激励。
如此的“换汤不换药”，却是另外一种新鲜滋味。
如果观众对魔术师说要一个苹果，魔术师就会给他一个苹果，当然如果包袱里有的话。苹果可以是一个青涩的苹果，也可以是一个红彤彤的苹果。大多数的情况下，观众可能更喜欢红彤彤的苹果。魔术师就超越了观众的期望。但如果观众说想要一个烂苹果，可能包袱里即使有，魔术师也得跟观众说声抱歉，坦诚自己的能力有限，然后告诉他烂苹果会伤害健康，并且将好的苹果给观众。魔术师就引导了观众的期望。
你就是你，我就是我，javascript就是javascript，flash就是flash，只是我们之间都存在一些交集。
魔术师的包袱永远不是万能的口袋，可以超出期望，但不能满足奢望。
越看起来简单，越要做得更多。
既然前端技术总是标记语言、脚本语言打交道，那么编程语言还有没有必要去学习呢？当然。不过首先说明，这里和全篇文字所说的编程语言都是指的高级语言，即需要解释器编译的开发语言。
当按钮不再需要高光阴影的时候，“扁平化”这种极简主义成了前端时尚的推崇。用户也越来越希望看到一个干净的画面，但却越来越希望能够通过计算机完成更多的事情。惰性依赖与便捷性初衷开始走向两极，甚至于让我们独立思考的时间愈加减少。
计算机已经改变了生活中的很大一部分的工作方式，前端技术则表现了这些全新的工作方式，置于与用户交互的最前沿。交互产生数据，将数据图形化和增强数据流动性，是前端技术所肩负的职责之一。然而一味地从后端那里拿来数据，前端展现出去就可以了吗？
当然答案是否定的。尽管表面上看前端的工作已经完成了。但是我们的目标显然不仅如此，我们需要做得更有效率。尽管随着标识语言、脚本语言以及其它非编程语言功能的迭代成长，以至于它们接近甚至已经能够完成一些本来由编程语言负责的工作，不过这大多源自于对某些编程语言特性的一些借鉴和对实际问题的深入思考。
从一个项目的技术架构角度来讲，HTML、CSS、javascript三者组合可以构建完整的系统，三者加上诸如PHP、JSP等编程语言也可以构建完整的系统，再加上Java、python等编程语言同样也可以构建完整的系统。技术架构往往是一个如何解决问题的过程，同时也直接地考验了一个人或团队的经验积累。不仅仅是如何充分发挥身边可用的人的技术能力的问题，还是如何根据业务特性进行技术实现的问题。取舍是一回事，组合又是一回事。尽管前端技术和其他端的技术所能完成的工作越来越接近或者说彼此取代，但是当问题成为综合性问题的时候，情况并不能简单地考虑，大胆尝试的人嘲笑谨慎保守的人，并不总是对的。
谁站前面，谁站身后，量力而行，齐心协作才能走得更远。
有些时候，不能仅仅局限于对一种或者一类知识进行学习，即需要横向的扩展，又需要纵向的深入。在基础知识和经验积累的同时，由单点掌握向网状了解进行演化。学习一种语言，需要在掌握使用的基础之上，还有必要了解它为何而生和未来如何发展，熟识它的技术特性，才能更好地为我们的需求提供技术服务。
每天早晨醒来，看着镜子中的自己，会不会说一句：又特么帅了。
“一千个人眼中有一千个哈姆雷特”，一千个人就有一千种思考问题的方式。一个问题的解决基于我们自身的认知和知识经验的积累，因此我们坐在电脑前敲出的代码往往就代表了我们自己。本来作为技术品，有时候更像是艺术品。
Bug恐怕不止对于前端人员，或是每个程序员来讲，都是一个感到极为不舒服的词。然而很多时候测试中少量或者没有Bug，同样使人心怀不安。这既来自对调试和测试水平的疑虑，也来自对自身编码能力信心的不足。
我们暂且把开发过程中的自我排错调整称为调试，把交付使用前的专业测试人员的工作称为测试。调试和测试的针对性可能不太一样，但都是关注细节，需要细心和细致的事情，两者都是为了产品的成功而必不可少的工作。
最先进的并不一定是最合适的。
同样，为了最大限度的节省人工劳动，提高生产效率，调试和测试的工具也是种类繁多。与此同时，我们普遍关注的是软件性能和业务需求两个方面。在软件性能方面，不仅需要考虑数据的产生、接受、输出的正确性等等，还要考虑软件的稳定性、可扩展性、安全性等等；在业务需求方面，首先是要熟练掌握所要提供的业务服务的细节，其次是要平衡业务展现和业务交互的合理性。
前端作为产品重要的一部分，离不开调试和测试，甚至于调试和测试的手段和工具更是多种多样。Firebug、Chrome、Weinre、Fiddler、LoadRunner等对于前端技术人员来说并不陌生，然而每款工具都有其独特的侧重方向和适用场景，假设条件允许，经过越多的工具考验，越有益于产品的最后产出。调试和测试是复杂繁琐的事情，除了借助于针对性的工具，还更需要丰富的经验积累和业务认知。这些也很难用几句话去说清楚。
产品的情感是一个特别的话题。产品是人造事物，就带有人的思维方式和事物认知，与用户交互时也就像两个人之间的互动。所以在进行设计和开发时需要考虑用户的感受，除了don’t make me think 还要make me comfortable。例如在页面加载的时候，从无到有像是惊喜，从有到无却难免会感到有些失落。于是有人设计出来漂亮有意思的等待动画，也有人预置了填充数据，还有人对页面进行了阶段规划使用了懒加载，这些都是为了照顾用户的感受。
我们需要认真地对待每一个产品，就像把自己介绍给其他人一样，时而简单直白，时而委婉优雅。当我们带着十足的自信站在镜子前，就可以底气十足地说一句，实在是太帅了！
计划和市场是资源配置的两种基本手段，所以就产生了计划经济和市场经济。产品和服务的生产及销售在市场经济体系下完全由自由市场的自由价格机制所引导，而计划经济一般由国家所引导。
每个人都崇尚和渴望自由，在前端技术的世界里亦是如此。特别是在最近几年的时间里，前端技术在开源的世界里枝繁叶茂，各种**哲学自由生长。Javascript从认为先天不足的脚本语言，到提升效率的jquery、zepto、templatejs、requirejs，再到如今功能强大的nodejs、reactjs、angularjs。从AMD到CMD，从MVC到MVVM。从HTML4到HTML5，从CSS2到CSS3，从flash到svg、Canvas，等等。一切就好像沙漠一夜间变成绿洲。前端技术开始变得强大，甚至无所不能。
如今很多人都在嘲讽计划经济，极力推崇市场经济，认为市场经济能够解决现有的一切问题。从理论上讲，市场经济是自由的经济、公平的经济、产权明晰的文明经济。但这仅仅是理论上的说法。我们都希望自己所代表的编程语言或技术能够发展壮大，并能够一统天下，甚至于在某天能够为自己曾经的选择而沾沾自喜。
梦想始终要回归现实。
我们要清楚自己从何而来。市场经济的通常主张是人们所追求的私利是一个社会最好的利益，但很少人清楚市场经济在实际操作过程中的缺陷到底有多大。同样，对于我们所使用的每一种前端技术，究竟是为了解决什么样的问题而产生？如今存在哪些需要弥补的缺陷？未来应该有什么样的特性？在实际应用中和其他什么特性的语言或技术组合才能发挥到极致？这些都是我们应该心平气和去切实思考的问题。赤裸裸地竞争，不会带来什么好处。取长补短，站在巨人的肩上，才能走得更远。
如今还存在另外一个争论：拿来主义和闭门造车。在某些公司或者技术大牛眼里，现有的语言和技术都存在很多这样那样的问题，与其把现有的拿来使用，不如根据自己的意愿重新再创造一个出来。其实这也不是什么固执和偏见，只是一个成本的问题。在需要解决问题之前有没有足够的时间去再创造？是不是考虑得足够完美去适应未来发展所遇到的其他问题？既然知道了现有的不足，为什么不在其现有基础上进行完善？古人说，存在即合理。两者都没有错，只是我们在下定决心之前，还是需要多一点时间去思考衡量。
在历史的长河里，计划经济和市场经济都曾解决了属于那个时代的问题。常常我们都想成为独树一帜的伟人，却忘记了站在巨人的肩上。一种语言或技术的兴衰，也许只是少数人服从多数人的选择，不再适应当下的时代。
站在丰富多彩的世界面前，会不会感到迷茫？看着手腕上的手表和手里的手机，你还能不能确定现在的时间？
前端技术跟随着这个时代在快速发展。不仅各类模式和架构**层出不穷，而且各类工具更是如雨后春笋。无论是记事本，还是Sublime、Notepad++，再是Dreamweaver、EditPlus。现实的情况不再是我们没有选择，而是不知道该如何去选择。
本来我们要的是一个简单的东西，为何却愈加复杂？其实真正的复杂并不是工具，而是在于任务中。大多数工具最初都是为了解决简单的问题，但是随着问题的增多，我们不能零散地去做太多的小东西，于是就开始赋予原有工具更多的功能。可是当他人使用我们开发的工具时，是不是也能快速地解决所遇到的问题呢？嗯，这是个问题。一个工具并不是能很好地适合每一个人，也不能被每一个人熟练地用于提高工作效率。这不但取决于每个人认知层次和知识积累程度的不同，而且取决于具体任务的实际要求。
我们不能断然地说某一种工具会比另一种工具相比会极大提高工作效率。当你正处在入门阶段时，使用Dreamweaver此类所见即所的工具也许会好一些，此类工具有助于你快速地看到某些指令和属性的表现，在不熟悉的情况下，便于初期对各种编码形成良好的心理模型（当然运行速度是有一定的牺牲）。经过一段时间地学习，脑子里有了某些标签应该呈现的模样，就可以使用类似sublime的工具。以至于不需要再敲代码并频繁切换视图，而是凭着记忆中的模型，敲一段代码之后再去进行视图验证再调整。当想去接触更多的编程语言和编写方式时，就需要去安装使用更复杂的工具（选择性安装相应的工具插件也是不错的选择）。当然用eclipse去开发前端肯定会被认为是小题大做。但是我并不认为使用记事本是好的开发方式，除非你记住了所有的代码指令。
不是所有的简单终究要走向复杂。
由此可见，复杂的东西其实是很多简单的东西堆在了一起而已。每个人在心中都有对事物理解的心理模型，一旦所面对的事物与心理模型不一致时，我们就往往称之为复杂。任何一个工具的每一个功能都是针对特定的问题，我们解决问题就是选取其中的一个功能或者一组功能组合，并不需要所有的功能。也许每一个复杂的事情都能找到一个简单的解决办法。
绝不放慢速度，宁愿粉身碎骨。---《速度与激情》
每一个人都在渴望一种极致的体验，都喜欢速度带来的快感，并没有停止想要再快一点的欲望。带宽在增加，处理器在增加，内存在增加，硬件性能随着摩尔定律在不断提高。以至于程序猿们都忘记了软件开发一些的边界，例如内存控制，代码的执行效率，软件大小等等。
有人说，还需要考虑么？现在PC的硬盘都是将近T级了，CPU都已经4核了，更何况固态硬盘都有了，甚至手机的ROM都4个多G了。其实不然，所谓的极致体验并不仅仅是占用并用尽所有的硬件资源，毕竟每一款软件都是运行在操作系统基础之上，尽管如今的操作系统已经比以前的体积相对增加了好多。并不是PC或手机在同一时间只运行一款软件，资源也不是单一地被独享，这也不符合我们的经常“一心多用”的习惯。如果每款软件都能够考虑到与其他软件的和平共处，而不是霸道地独占资源，相信我们能够在一段时间里并发地做更多的事情。
在前端领域所表现出来的速度是显而易见的，给人在视觉上最直接的感知。画面从无到有的加载，交互操作获得的反馈，时间等得越久，好感降低得就越快，除非我们能够提供更有趣的东西去填充中间的等待。合理的规划，优秀的架构，简洁的代码，甚至于每一部分的“勤俭节约”都可以有效的提高产品的最终体验，给用户带来更多的快感。每一个产品都是众多技术融合在一起的混合体，要想发挥最大的机能，那么就需要各个技术恰到好处，这也是检验一个开发人员是否合格而且经验老道的时候。加载速度慢就用CDN，占用内存就减少数据，系统运行慢就增加服务器，在实际生产中，我们不应该连想都不想就单纯地选择这样做。造成问题往往不在于一点，解决问题往往也不在于一点。先想再做，考虑越多，一旦开始做起来，工作效率越是能够得到更大的提高。
“勤俭节约”是一种美德。
蘑菇长在阴暗的角落，得不到阳光，也没有肥料，自生自灭，只有长到足够高的时候才会开始被人关注，可此时它自己已经能够接受阳光了。很多时候，一个人作为社会新手开始工作的时候所经历的大多就像蘑菇一样，这种现象也被称为“蘑菇效应”。
作为一个新人，所面对的不止是职场的复杂关系，还有成长的众多选择。没有从业经历，没有开发实践，只字片语就凸显出了底气不足。小到前端，大到IT行业，看重的就是实际经验。自己看书学习和在工作实践扩展有着截然不同。然而现在的互联网公司又将快速发展看得很重，对新人的培养也失去了耐心。一个公司的门槛都不会是太高，想要跨进去，真正需要的是在技术知识面上丰富，技术开发实践上专业。固守或者仅通晓一门语言往往是不足的，现有的技术架构越来越复杂，越来越交错。但这并不是说非得要向全栈方向发展，作为一个前端新人，往往更加需要明确。不要奢望太多前辈会主动来指点迷津，也不要指望一点知识就吃到老。前端技术相对于其他技术，更新迭代地要快很多，几乎很短时间内就能冒出新东西来。但是和公司的技术架构的更新相比又显得比较矛盾。新人应该在职位工作上积累开发经验，在本职技术体系上扩展知识认知，不要总是怀有不得志的感觉，因为如果哪个前辈来扣一桶大粪，不，告诉你马上掌握某某重要技术，作为一个新蘑菇恐怕一时间也吸收不了，适得其反。
作为一个领导，如何养好蘑菇也是一门技术。让其自生自灭，一次性扣上足够的大粪，恐怕结果说不清哪个好。对于增强解决业务问题能力的要求是无可厚非的，但丢到角落里等其独自成长，又显得不那么人道。领导曾经也是一个新人，可能新人经历的也是当初领导所经历的，“多年的媳妇熬成婆”似乎成了每个人必须经历的修行。不需要面面俱到，还是需要指明方向，领导的经验足够新人去琢磨参考。若是等到蘑菇们自己成才，恐怕他们就已经选择跳槽走人了。若是蘑菇们一无所长，恐怕不是砸手里，就是毁掉了它们剩下的技术人生。
在前端，主观能动性很重要。
程序员的审美观决定了你用什么样的软件，程序员的兴趣爱好决定了你有哪些软件可以使用。大部分人都对这个观点表示赞同，然而软件的产生都取决于程序员么？答案是否定的。
软件也是一种产品，同样需要经历传统实业中产品创造的所有阶段。由人们生活所遇到的问题产生广泛的市场需求，由急需解决的市场需求产生去创造一个产品的想法，由产品设计者去规划这个产品的雏形，而程序员就是这个产品流水线上的生产者而已，将产品开发并进行打磨。当然，在开源领域，程序员充当了更多的角色，包揽了整个流水线的工作。
产品开发以市场需求为导向。
一个产品的成功与否，取决于它是否是当前人们日常生活所需要的。能够帮助人们解决问题，才是一个产品存在的重要价值。如果说一个软件完全是由于程序员为了解决自己的问题而开发的，那么后来得到更多人拿去使用，就说明这个程序员的需求和其他的人一样，需要解决的问题广泛存在着。再如果说，这个软件只是被程序员自己使用，那么这个软件存在的意义就不大了，起码展现不出其应该体现的广泛性。
一个产品的外形为其所提供的功能服务，而不是它长成什么样子就该去怎么使用。现在很多软件都在追求一种精简的表达方式，以至于很多人都认为“扁平化”就是精简设计的最突出代表。但是软件本身所要解决的问题和最终要达到的目标是不可以忽视的。例如，一个成熟的oa系统并不是什么精简的系统，相反有些时候更显得笨重复杂。它所实现的都是一个公司管理所需要的必要流程，取决于公司管理中人为设计的规章制度。
一个好的程序员，并不能决定一个软件产品在未来会变成什么样子。如果在初期阶段，能够站在最广泛的用户角度去发现需求，也不失为一种成功。