软件工程师的成长除了个人能力的提升之外，更重要的是形成正确的理论体系，一整套的问题解决方案；在这漫长的成长之路上，一些思维误区值得我们的重视。

1. 分析麻痹

软件的模块之间存在着各种复杂的依赖关系，又因为软件的易变性和不可见性，各个模块之前的关系更加难以定义清楚。当面对软件的维护和修复任务时，一种消极的态度是面对纷繁复杂的系统，囿于其中的依赖关系，无法前行，而短时间也无法将整个框架流程看清楚。这就导致了在问题面前优柔寡断、裹足不前。而事实上，很多问题都是在一步一步的解决中拨云见日、豁然开朗。

与上述在依赖问题前踌躇不前相对的就是过分积极的行动派。分析不清楚，索性舍弃分析，横刀立马，见招拆招，这样往往能在短时间内见到小小的成效，但如果没有一个大局观念，对项目没有一个整体的把握，往往会是南辕北辙，做很多无用功甚至使情况变得更糟。

初学C语言时，按照书上的例子一点一点写函数，每个函数只考虑自己的功能实现，丝毫不顾及与其他部分的调用配合，在功能增加，函数增加的时候，参数总是要修改很久，有些甚至结构都要修改。后来做了几个小练习，觉得手很热，，就想一步到位：解一道题目，脑海中想明白之后，从头到尾一气呵成。妄图分析清楚全部的脉络，然而事实总是自以为的清晰的脉络混乱不堪。到头来还是要返工。

现在我一般先设计好程序整体的结构，使用空函数补全结构，再填补空函数，使他尽可能的独立、接口尽可能兼容性强。总结起来还是老生常谈的问题：既要埋头苦干也要抬头看路。即便如此，这之间的权衡也够一个软件工程师细细体会领悟了。

1. 过早优化

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.”

— Donald Knuth.

关于这个问题Donald Knuth论文中的这段话已经很好地诠释了优化的核心，找到瓶颈，做全局的性能分析，而不是把时间浪费在对程序中非关键部分的速度的无限思索，相反的，这些对效率的尝试实际上在考虑调试和维护时会产生强烈的负面影响。

听过很多道理，还是过不好这一生。上述问题试问哪个软件工程师心里不是和明镜一样，知道自己某些时候的精益求精对软件性能毫无提升，甚至为了追求某些极致又产生了一些不必要的风险。那我们为什么还要做呢，我说，是因为爱。

这个道理是我在高三那段时间想明白的，那时每周都要写三四篇不低于800字的议论文，题目往往是列出时事热点，请你谈谈自己的看法。大多数情况下，分析出立意，三个小论点，每个论点配一些事实论据，配一些理论论据。开头结尾套用一些名人名言，速成一篇不上不下的、自己不会再读第二遍的、之后从来不会想起的文章。而也有少数情况下，那个题目正好对我的胃口，正好是我最近频频思考的点。这时文思泉涌，而面对如瀚海星云般的精辟观点与无数旁征博引的古今中外论据，我反倒谨小慎微，悉心辩驳每一条观点、筛选每一条例子，想用尽一切珍贵的辞藻给我的文章，尽管那几句诗词换上通俗白话也不会对我最终分数产生影响。

但是我爱，我爱我的文章，我也爱我的程序。那时我们追求的不是精益求精的技术指标。而更像是艺术。

就是艺术！