小编自述

卑微的程序员

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。 意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。 试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。 所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。 结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。 程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George 前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题： ◆“要保证这个问题不会再出现，我该怎么做？” ◆“要想少出些Bug，我该怎么做？” ◆“要保证Bug容易被修复，我该怎么做？” ◆“要保持对变化的快速响应，我该怎么做？” ◆“要保证我的软件的运行速度，我该怎么做？” 如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

我们应该正确的认识自己

从公司角度来说，如果，你真要个好的架构，来开发一个公司的系统，如果是自己公司的程序员，类似于BAT，他们招的大神们一开始的目标便是高并发，大数据量，就会考虑分布式框架，好的服务器，es集群，自主研发的MQ等，他们不在乎时间，有充分地时间去完成这个巨大的框架架构研发。。。可是那种公司根本不多，现在承接项目的多半都是帮别人开发的研发公司，他们只关心你结项的速度，对于你的框架架构，你说你用的什么什么技术，什么框架，什么方法，以后维护简单的要死，然后老板（或者经理）就会给你来句你项目：“这个月搞的定吗？？？”，然后跟人事说:“这个人你注意下，可以干掉了”，现在我开发就是springboot，异步线程池，OK搞定下一个，一行优化，一行注释都不会加，就图个速度，然后早点下班，回家自己做个项目，自己学自己技术