为啥从直觉上觉得老外的写的代买质量比我们的要高，我们国内的程序员绝大部分的时间是在赶进度，准确的来笑山老讲忙着增加功能和修改bug，其实也从侧面反映出为什么国内出不了android以及Linux等影响深远的 科技 创新，从全球开源代码的占比就可以看出，差距还是很巨大的。
为什么觉得老外写的代码比我们的强？
1.国内软件发展主要阶段还在解决有没有，还远谈不上强大
中国的软件经过近几十年长足的发展，已经取得了巨大的成就，特别在互联网行业已经有几个巨头跻身世界前列了，最近炒的很热的脸书的用户数据泄密事件，作为当事人扎克伯格，也在论述中提到中国有几个很厉害的互联网公司，这说明中国在互联网领域还是取得了相当大的成就，但是在一些核心的领域，或者门槛很高的领域差别还是非常巨大。
任何事情在发展的初级阶段首要考虑的是不是有没有，所以如同创业初期的公司会选择短时间内搞出来个产品，哪怕是不成熟的产品，然后快速的投入市场，根据市场用户的反应同步追踪问题，等到产品差不多稳定，并且产品在市场上有了一席之地之后，后续的事情就要考虑优化功能，对里面的代码或者产品的性能进行全方面的提升，目前国内大部分的互联网一般比较年轻，还在解决有没有的问题，相信随着时间的推移以及国内软件的发展，也会有大量的高质量的开源框架代码出来，但这一切都需要很长的时间。
所以国内的程序员大部分时间都是在赶进度和根据需求完成功能代码。
2.软件产业的底子还很薄弱， 历史 积淀还不够
举个很典型的例子，现在很多国内的程序员到了30多岁就开始考虑后续的转型了，因为后面的轻轻人会带来很大的冲击，所以大部分的30多岁的程序员都在考虑自己后路，都要考虑转型的问题。老的有经验的程序员反而转型去做管理或者合伙创业了，哪有几个还在安心搞技术，年龄大了还在搞技术的还被人鄙视，觉得自己没有出息。
但是在国外写代码是一种很常见的职业，和别的唯弯工种没有多大的差异，40，50岁了写代码也是比比皆是，做软件是一种技术工种，经验的占比是很高的，所以老程序员写出来的代码更碰升加有深度，稳定性更高，一切的根源还是产业的发展不够成熟，需要时间和 历史 的积淀，从这方面讲国内的软件整体产业还是比较薄弱，从业人员的整体素质和工作氛围还有待慢慢的成熟，周围都是有经验的程序员在带领着如何去重构代码，如何提升代码的质量，而国内大部分的程序要还是被产品经理鞭策着增加需求和修改代码。
3.公司的文化差异
目前很多的中国技术公司更多的追求的是短期利益的最大化，在基础软件的投入远远不够，毕竟基础的投入很难短期见成效，在一个具体的场景，有一个产品主体的功能已经实现了，也能在用户那边投入使用了，一般的公司很难拿出时间来，让你做代码的重构，毕竟这种事情很难直接产生经济效益。这与公司本身的文化差异有很大的关系，重视的技术或者懂得技术的公司对于这方面相对比较重视，反之就差很多。
小时候课本上就说着我们落后100年，所以高楼大厦不是一天建成的，所以在追赶的道路很漫长，所以承认存在差距，然后努力加倍的去追赶。
Time is money. 以目前国内互联网的情况，需求应接不暇，程序员基本上都是被需求与业务赶着走，时间非常紧张，在这种情况下，程序员很多时候唯一的选择就是赶紧实现需求的功能。所以，一个项目下来，代码基本上都变得非常非常的“垃圾”。
也有很多程序员想过在项目结尾的时候进行代码的重构，基本上每个程序员也都知道重构代码的好处，但是并不代表着真正能做起来。还是那个原因，国内互联网的速度太快，需求应接不暇，做为程序员，基本上没有时间来做这件事情。
而另外一个原因是跟团队负责人有关。若团队负责人能够意识到重构的好处，那么他可以为此单独划分一段开发时间出来，让大家分别负责一个模块进行重构，这都是可以安排做起来的。这也需要团队负责人如何在需求人员的需求与代码质量的进度上做一个平衡，进行统筹安排。
最后我想说一个可能很少意识到的原因，那就是人员流动问题。国内互联网目前人员流动非常的大，尤其是北上深这样的互联网发达的城市，基本上是平均两年就会走一大波人，在这样的情况下，也会考验从业人员的职业道德，即我到底要把代码写的多好，要把代码的可维护性做到多好，其实这都是从业人员自身需要考验的问题，因为完成一个功能很容易，但是要考虑的全面就是另外一回事了。而人员流动带来的另一个问题就是有一些代码是很难看懂的，即有些代码在人员离开后成为了“ 历史 ”，无人敢动。这也会阻碍着软件的重构工作的进行。
从我所讲的这几种情况来看，重构其实是大家都能知道的好处，但是真正实施起来却又有现实的约束，需要负责人来做这样的统筹安排与推动。
成本太大
大多数软件产品的开发都是经过了很多开发人员的付出，如果进行代码重构需要了解产品、了解框架、了解代码逻辑，这个过程会花费大量的时间和人力成本，对于企业来说，效益是第一位的，与其花费精力进行效益不大的产品重构，不如去承接更多的项目来的实在。
领导决策
由于大部分企业的老板都是非技术人员出身，他们更关注效益和客户，为了符合企业的发展，在进行产品开发时会更多的采用新技术来吸引客户，花费精力重构代码不如开发一套新产品或者开发更酷炫的效果更具有实在意义。
代码规范不足
由于国内互联网较之国外起步较晚，很多企业发展时间较短，加之人员流动比较大等多方面的因素，很难形成标准、严谨、行之有效的代码规范，所以很多技术人员在开发时都是根据个人风格习惯在开发，等其他人接手代码时，缺少相关标准和文档，很难理解代码逻辑，花时间去了解代码、重构代码不如直接推翻重做来的方便。
客户定制化需求
部分企业创业初期对企业信息化是不够重视的，只有企业发展到一定程度才会考虑信息化建设，而由于业务的限制，大多数标准化的互联网产品都很难满足企业的实际需求，需要进行大量定制化的开发，对于互联网企业来说，即使产品开发足够完善，在实际项目中也需要进行扩展，倒不如直接在项目中进行调整。
程序员的发展限定
在国内很少有终身的程序员，大部分都会逐渐转向销售、售前、项目经理、产品经理等岗位，而这些岗位则需要了解业务、了解客户，对技术的需求反而不会太高，所以与其花时间去专研技术不如将更多的精力用在业务和项目层面。
代码能够重构对底层框架要求深度掌握、且代码框架本身要足够灵活，而国内绝大部分技术人员都是停留在对框架的使用层面、少数可以完善、结合使用，极个别的在做同语言山寨或者换一种语言重写，能够对产品体系进行把握、与时俱进扩展实在是凤毛麟角。随着国家的经济提升、IT行业逐渐成熟，在我国这么多IT公司基数下，即便是凤毛麟角的概率，重视基础框架、积累萃取、不断迭代完善的一些技术公司也会慢慢崭露头角、涌现出来的。
【国内程序员很少进行代码重构】，这个现象虽然没有什么调查统计，不过我写了十多年代码，也发现身边的程序员大多数是这样的，【宁可写新的代码，也不愿意重构老代码】。下面我也谈谈自己的看法：
系统没有问题，就是最大的功劳
我见过的大部分的传统行业的软件公司或IT部门是这样的（互联网公司不太了解），“只要系统稳定，那么就是最大的功劳”，而保持系统稳定最好的方法是什么？ 就是尽可能的不要动系统！
可能很多人不能理解，但很多公司确实是这样，甚至公司对项目的考核标准中，项目有什么突破的权重很低，是否有生产事故的权重很高。所以很多“机智”的项目组成员，千方百计的不接需求，或者把需求推给别的项目组。在这种单位里面，别说重构了，新代码都写的不多。
测试覆盖度太低，重构代码没办法保证质量
代码重构，很重要的一个问题：“重构后的代码谁来保证？如果影响到原有的功能怎么办？”
这时候很有效的一个方法，是使用各种自动化的测试来保证重构代码的质量。
但是，大部分公司，不管是单元测试还是其他的自动化测试，都是不健全的，甚至是没有的。所以只要不是被逼不得已，程序员宁可重新写一个方法，也不愿意重构之前的代码。
其他
进行代码重构不是一件容易的事情，务必需要对需求熟悉；对代码 历史 变更熟悉；对代码框架，模块熟悉；对产品更新迭代做好风险把控，时间成本把控……
进行代码重构需要能力非常高，责任心非常强的人进行，甚至需要一个优秀的团队完成。
为什么要代码重构？理由一大堆，我认为主要有两条，一是原代码已不适合扩展新需求，二是原代码已拥肿不堪，乱七八糟。
为什么很少重构？除了上述分析外，还有其他因素，如人员流动快，原团队原作者早已不知何去何从了。又如需求和业务繁多，完成工作开发都累得半死不活，日理万机似的，哪有时间和心情重构？
谢谢大家。
1.国内程序员技术能力不足以进行代码重构
大量的软件从业人员连编程规范都不熟悉，怎么可能做代码重构？更多的人只会写写hello world，只会拷贝粘贴小段代码，连if else这种语句都写不清楚甚至漏掉逻辑，连面向对象的编程思想都没有，谈何重构？
2.国内程序员的沟通能力说服能力一般。
进行软件重构，必须说服经理，让经理相信重构会带来软件质量的提高和故障率的逐步降低，这样经理才会安排人力进行重构。
3.国内软件开发更注重bug的及时解决
国内软件开发大量的人力被分配到解决短期的某个bug，没人抽时间思考如何长久的彻底的解决软件缺陷，其实解决bug不重要，找到软件的缺陷或者性能低下的地方才重要，这些才是重构的点。国内加班加点疲于奔命式的开发，没人考虑bug率是否长期内能够收敛，总是先解决眼前的问题再说，处于一个永远解决bug的死循环里。
这种工作模式是愚蠢的，不是smart的。
软件开发，一定要动脑子，不要蛮干，这不是耕地，力气大就耕的多。
重构代码的目的说白了，就是让软件开发人员更自由。
谢谢楼主的问题，这是一个我特别想回答的问题？
为什么？因为，第一，我是一个对代码有洁癖的人，受不了一坨，一坨那样的代码。第二，我是一个践行Clean Code 的人，给大家我主要负责的一个项目的一组数据（JAVA），总代码量20万行,UT coverage(单元测试代码覆盖率）82%，代码重复率0.5%，代码规则(sonar）违反（Code issue）0,甚至连最低的违反都没有。
也正是因为我的项目在实践Clean Code上的数据，我经常去给不同的团队做分享，也对团队对这个重构不太上心有一些理解。
大致以下几个原因。
第一，也是最多的，交付压力，大部分人都会抱怨，你看我们有这么多新功能，还有那么多bug,根本忙不过来，哪有时间重构？
第二，重构意识不足，老板，管理人员总是希望这个我们要有，那个我们也要实现？为什么？因为别人有，别人有我们没有可能会造成用户流逝。即使有一些有见识的程序员和老板反应这个重构问题，但是重构从来不是高优先级的。毕竟，现在的软件的生命周期可能很短。
第三，人员流动性大，这个是我听过最奇葩的一个理由，我问一个来听培训的哥们，说你代码写成这样，以后怎么维护？这个哥们说，我也知道难维护，但我明年就跳槽了。
第四，设计上就不需要重构，曾经给一个保险公司做分享，我本人也是做金融相关产品后台的，我就问你们这样写代码，可能三四年以后就非常难维护了，还是要尽快重构。他们的回答是，我们不重构，我们只重写。什么意思那？就是一个系统，三四年以后在写一遍。
第五，程序员本身的问题，可能第一写单元测试，修改命名，修改代码结构，是一件很没有成就感的事情，也是一个没有多少附加值的事情。毕竟现在你去找工作，这个代码质量方面的问题会问得很少。
第六，我见过的我不能反驳的一个回答，我的英文太差，不能很好的命名，而我也不想学英文。
第七，反正我已经实现了功能。
最后，用一句话来提醒程序员们，重构是多么重要。
出来混迟早要还的，挖了坑迟早要填的。
在国内，【重构】这件事是程序员最喜欢做的事，而不是公司喜欢做的事。
但程序员喜欢并不能影响公司的决策，所以，国内的现象就是软件系统很少有重构。
其根本的原因在于，国内的公司所推出的系统大多没有重构的价值。
1、国内的互联网公司存在这样一种快节奏，那就是发现一个有价值的创意，就马上进入开发，开发完成立即上线，并立马推广使用。这是一种快速试错的模式，一旦发现系统在 社会 中没有引起反响，那就马上把系统再下线。这种情况下的系统哪来的重构价值呢？
2、即使一个系统上线成功了，也积累了大量的用户，貌似为了系统的稳定性和性能，可以有重构的机会。但事实上不是，国内公司仍旧不会选择重构，因为重构带不来新的价值。所以，公司多数都会在系统上添加新的功能来吸引新的客户，而不会考虑重构现有系统。
总得来说，引起重构的原因在于能够有持续的价值。没有价值的事，企业当然不会做，仅是程序员的一厢情愿而已。
你只是见到了你所在的公司现象，不代表所有，也不能代表大部分的。
代码重构还是存在的现象
代码设计烂，经常出问题、扩展麻烦、维护心累、数据混乱、结果不清醒、模块划分混乱
就可能要考虑到重构了
呵呵，
老大说：
你赶紧去修复一下这个bug，
还有几个功能没有实现，加班搞一下，
pm 说：
这个功能改一下，
还有这个，界面重新调整一下，
这个业务流，现在不一样了，
客户需求需要多几个功能，
老板说：
这东西下周能出来吗？
昨天刚领一个线上P0级重大事故，持续时间1小时，影响范围全站 ！准确的时间点是下午17点开始，具体问题定位且听我下文细细道来。
先说感觉，那感觉真是太刺激了，本来下午五点，昏昏沉沉的，瞬间一个激灵就清醒了（想象一下高中课堂，你在打瞌睡，突然老师走到你面前给你一下子的感觉），原本准备再过一小时吃晚饭了，吃完晚饭再摸鱼到21点就可以下班了呀，别问我为啥到21点，问你就不是程序员！
带着无比紧张且颤抖的心情开始定位问题，先来个错误日志尝尝鲜：
整个事情的发酵是这样的：
1、下午五点开始有少量的慢sql报警，没有人当回事，因为这种事情总发生，虽然大家都知道在实际开发中如何避免慢sql，但是整个团队要想完全避免慢sql却很难；
2、五点十分左右，开始零星有用户反馈指定功能不可用，SLB开始报警，技术开始介入排查；
3、十五分左右，客服部门电话开始爆炸，用户密集反馈指定功能不可用，技术部开始重视；
4、二十分左右，所有服务大面积出现接口无法响应，整体服务不可用；
5、我们一开始定位觉得是MySQL的问题，因为前面有mycat的慢SQL报警，后来定位并不是MySQL，因为MySQL的内存、连接数、流量这些指标都很平稳；
6、最终在五点三十分的时候我们定位到是ES出问题了，因为所有的Java服务不可用最终都指向上面的错误日志，dubbo提供的服务线程池满了，再有请求进来直接拒绝了，查看这个服务的代码，最终查询的是ES，此时的ES进程已经处于假死状态。
那接下来大家说怎么办？如何快速的恢复线上服务？
重启！
是的，只有重启大法此时是最快的解决办法，你不可能说保留ES事故现场，让我用arthas之类的工具来现场分析jvm内存情况。
然而重启之后服务依旧是不可用，接口还是无法响应， 大家知道这个时候是什么原因吗？为什么重启了ES服务还是不行？
后续继续重启报错dubbo日志的相应服务，当这些服务全部重启完毕后，我们的服务终于恢复访问了，这个过程持续了十几分钟，确切的说，直到17点五十多分，我们的所有服务才恢复了访问。
接下来就是事故总结、相关责任人、产生问题的原因、接下来的优化方案，全公司邮件通报！
你说这个难不难？本身并不难，难的是事情紧急且重要，这个时候你慌了啊，乱手乱脚的，大家你一言我一语的，如何冷静提取有效信息然后尽可能快的解决生产的重大故障才是最难的！
最后，当一切都恢复平静的时候，你会发现：“卧槽，好累啊！”。
虚脱的感觉！
最后祝大家程序员节日快乐，今年可是程序员的本命年哦
2020 = 1024 + 996 = 404 + 404 + 404 + 404
这种感觉能难受，很压抑。
技术难题，对于程序员来说，是经常有的事，关键是如何面对吧。
说下我的事情，虽然也会写点代码，但并不是以此为正业，所以对于真正的程序员来说，可能说法会有点偏颇。
遇到难题时，一般都在网上搜索解决方法，一般来说，都有很优秀的程序员分享他的劳动成果，所以一般都能解决问题。但也真正碰到难的问题，一个就是循环的问题，无限极菜单问题，当时都是找了很久，看了很多遍才明白过来，当时自己是几天都不太开心，也不太想说话，总是在测试着程序。挺烦也挺不开心的。只是最后做出来了，心情就好多了。
这是我的一些经历，当然，如果全职程序员，可能压力就更大了。
如何形容这种感觉呢？焦躁，紧张，失落，无助，亚历山大...
再多词可能都描述不清楚。本人在工作中经常遇到难题，有些问题一两个月都搞不定。埋毁蠢遇到这种问题，估计只有下面这张图的表情能描述此时此刻的心态了。
程序员遇到的难题其实分为两种，一种是没有办法定位清除的余厅问题，另外一种是定位清除了，但是没办法弯陪，或者很难解决的问题。
难定位的问题所谓难定位的问题，其实就是你根本不知道这个问题是什么。比如系统突然挂掉了，你从现有的信息根本不能确定问题在哪。这个时候你剩下的可能只有满脑子的问号了。
如果系统只挂了一次，后面不再出问题，那就很难找出问题的根源了。不过这样也有好处，那就是问题的影响的程度相对较轻，毕竟不容易出现。所以在软件开发中通常不是什么问题都解决的，因为不是所有问题都能搞清楚是什么问题，谈何解决呢！
难解决的问题难解决的问题是问题搞清楚了，但是基于现有架构很难，或者没法搞定。遇到这种情况，通常先是很高兴，兴奋，然后就只剩下无奈了。
当然，从技术层面来说并不是完全解决不掉。只是如果要解决需要涉及架构调整或者其它方面的改动，修改调整的内容太多。这种情况下就要考虑利弊得失了。
如果改动太大，可能会引入很多新的问题，可能得不偿失。因此，遇到此类问题可能会采取一些规避方案。
当然，在开发和运营当中遇到各种问题是很正常的，关键是遇到不同的问题采用不同的策略。首先保证的是业务的正常运行，然后是考虑是否需要彻底解决。这样慢慢调整，心理压力会小一些。
作为一个工作多年的老码农，在工作也遇到过一些艰难的技术问题，就以切身体会谈谈对这个问题的看法。
首先需要明确一下，问题是否困难除了取决于问题本身之外，还在于解决问题的人的水平，也许对你很难的问题，在别人看来不过是小菜一碟。明白了这一点，那么这些技术问题也就成了考察程序员水平的试金石，有些人可能会因此气馁，甚至放弃；而有些人则通过解决问题学到了很多新的技术，也让自己进一步成长。
记得多年前看工作中要用到一款开源库，那时候刚学完C++不久，自以为对面向对象了解甚深，然而学习这个库时却是一头雾水，最后在经过泡论坛，然后又认真的学习了面向对象设计模式，后来不但能使用那个库，更重要的是对面向对象编程有了更深的认识！
后来还有很多类似的事情，刚开始时感觉无比困难，但是通过自己的努力，或求助他人、或查阅资料，当最终问题解决时，你会发现自己又牛逼了一些，然后再遇到一些新的问题，如此循环……
其实编程也是一个学习的过程，就如同爬山一样，每一阶段都会有一些山头，只有当你爬上山头才能欣赏美丽的风景，但是当你爬上一座山头的时候，就会发现更高山峰！只有当你爬上最高峰，才能“一览众山小”，可是到那时，你可能会向往地球之外的天地！
很难解决一般就是遇到某些瓶颈了，不同瓶颈的感觉是不一样的，但无非可以归结为下面几类。
成本原因
不让马儿吃草，还想让马跑。这个是有些不太理解互联网的一些领导的错误观念，他们会给你安排一个老旧台式机，想要让你承载几万、几十万并发的秒杀系统，你当然很难解决。
外界的评论可能是，“这帮程序员是吃干饭的么？这系统也太垃圾了！”
老板的评论是，“我这台式机也不少钱呢。”
程序员的评论是，“这抠门老板不会是个傻子吧。哎，再优化优化吧。”
当然，有些情况也是能够理解的，公司明白需要更好的设备，但是由于成本控制，不得不在某些方面节省。但换句话说，设备成本是占不了一个大头的，可能有其他方面的成本更加需要收紧。
如果是因为成本原因，我们的心情可能是无奈，又有些不能施展拳脚的束缚感。
历史 原因
举个例子，系统用了5年了，迭代了N个版本，在面对新的需求的时候，就会出现需求限制于系统的情况，常常会有程序员说，这个实现不了，那个不符合现在系统规则。其中很大一部分是这些年的积累，欠下的技术债造成的。俗话说，大船难调头。
这种情况更多的出现在刚创业之后的几年，由于一开始的快速迭代，追求先把业务流程跑通，先生存再规范，会让一开始的软件开发流程并不那么规范，如果在1-2年内没有进行重构，那么积攒的3-5年的技术债就会慢慢把你压得喘不过气来。
解决这种情况，一是需要时机，给出足够的空间和时间让技术团队重构，二是需要魄力，你得有成功的把握，不能干着干着说不行了，咱们还是回到原来吧。
如果是因为 历史 原因，我们的心情可能是期待和渴望，又有些对现状的无奈。
能力原因
虽然说专家很厉害，但说白了，大部分企业需要的研发人员，还到不了需要专家的级别。所以，一般而言，没有什么技术是攻克不了的。如果真的遇上了，那就说明你的公司已经到达了一个新的层次，从而需要那个层次的人员来解决，可以通过外聘或者顾问的方式，引进新的技术。
如果是因为能力原因，我们的心情虽然有些力不从心，但又为公司在新的台阶而高兴。
不管怎样，程序员是一群追求美好的人，不管是外部限制还是内部限制，不能解决的难题对于技术人员来说总是很憋屈的。
不能着急，慢慢分析，找到问题点，没有解决不了的问题
程序员的技术问题，排除架构师技术选型错误以外，都是程序员的功夫不到家所致。
1,面向百度的程序员会第一时间问度娘，各大社区求助大神。
2,面向源码的程序员会第一时间查看源码实现，查找api文档，思考解决方案。
3,不管技术如何发展，架构如何延伸，不变的是基本功，再先进的组件都是由基础语法书写出来的 。
练武不练功，到老一场空，共勉！
首先说下这个很难的技术定义，个人认为在你知道之外的知识都是很难的，一旦你深入了解其使用方式，原理，甚至阅读了他的源码，你会觉得有的时候会恍然大悟。程序员是一个不断要学习的岗位，就要面临很多从未知到已知技术的时候，每当遇到这样的情况时候，总有种不解决了这个问题，睡不着觉的感觉，心里不踏实，总是想尽各种办法去解决这个问题。甚至可以一直追查这个问题。也许这就是一种执拗吧
我老公最近就遇到一个大石头需要敲碎，我作为一个旁观者，都挺心疼他。
他还在读博，最近遇到的问题是他一个项目上的问题，也跟他的毕业设计相关。他刚读博的时候确定了一个方向，去年开题的时候他觉得这个方向没有什么前景，真的是考虑了好久要不要换，如果不换，就是安稳的毕业，换的话接下来的一年多时间他会很艰难，很多新的问题需要一一克服，最后他决定换了，他说他读博就是为了提高自己，还是想挑战一下。
年前，系统板设计好了，然后最近做好回来了，开始调试，说这个板子跟个石头一样，不工作。本来就是礼拜一到礼拜六待在学校不回来，周日是休息的。现在放假回来都是在啃变压器的东西，早上起的很早，晚上又很晚。真的挺心疼的，他还安慰我说，他又要进步了。挺担心他的身体的，我特别希望时间能快点过去，能顺利毕业。他却不希望，总觉得时间过的太快，没有时间搞研究。
今年的生日愿望，希望他科研顺利，身体 健康 。
以我的从业经历，说说遇到很难的技术问题是什么感觉吧： 兴奋、充满挑战性 。尤其是在开发中遇到了技术难题，很多情况下真有种可遇不可求的感觉。
我认为能遇到技术难题，至少证明这个工作是有价值的。 这种价值体现了两个方面，一是你的工作在整个产品开发中占据重要地位，甚至是核心地位。二是你的认知和经验，仍然有成长的空间。如果你的工作一直没有遇到难题，轻而易举地就解决了一切，那么很可能是你没有机会深入重要的核心部分，或者你的工作性质可替代性很高，简单重复性很高。
分解法。 把技术难题拆分，尽量的单元化、模块化，这样有利于逐步攻破，逐步解决。主要是降低技术难度，寻找真正的难点所在。如果问题无法拆分，就是那么一个点，那么需要逆向思维，可以先把问题扩大，看看涉及面有哪些，然后再缩小范围，锁定关键之处。
刨根法。 把技术难题抽象化，理论化，从根本的源头去解决。很多技术问题，从基础理论的角度去看，其实真的不难，只要你能定位到相关的技术点，困难点，知识点，就很容易进行快速解决。解决的终极办法就是从理论上彻底解决，做到知行统一。
讨论法。 三人行，必有我师。很多情况下，所谓的技术难题，在别人的眼中，也许并不是难题。很多情况下，小组讨论，交换意见，方案互补，就可以解决难题。有些情况下，还需要和供应商一起讨论，主要是补充信息的错漏。经常出现的芯片问题，很多情况下供应商都更加有经验。因为供应商有更多的使用客户，有很多解决问题的经验。最主要的是，芯片是他们设计的，他们更加清楚缘由。
没有绝对的技术难题，有的只是尚未解决的技术难题。
桂林一大巴撞上限高架被削顶，直接导致了1人死亡，6人受伤，现场伤者都已经被送往医院接受治疗。
大型车辆被限高架削顶的新闻时常可以看到，而且这类事故每次都会造成人员伤亡。
此次桂林市旅游大巴被限高架削顶又再次引发了滚竖轿网友们对于限高架以及大车司机行车安全的探讨。
首先了解此次事故的具体细节。
一、突然“被剃光头”的旅游大巴这起事故发生在广西著名旅游城市桂林市的西门桥附近，事故时间大约是在4月17号的晚上8点。
当时事故车辆上坐满了乘客，大家都是出来旅游的游客，而且其中以中老年人居多。
车辆本来一直在正常行驶，突然“嘭”的一声，整个车身遭受到了猛烈地撞击，车子晃晃悠悠的停了下来。
车上正在闲聊、睡觉的乘客在呆愣了几秒后齐的发出了惊呼声，然后其中有44人在一片惊慌失措中自行逃下了大巴车。
二、事故后果事故发生不久后，就有公安车辆、救护车、交警的车赶赴到了现场处理事故。所有受伤乘客被送到了医院接受检查治疗，而大巴车司机更是现场就被公安人员控制带回了局里。
据相关部门通告称，这起事故已经造成了1人死亡，6人受伤，值得一提的是受伤的6人都比较幸运，伤情都没有性命危险。
三、大巴车撞上限高架原因分析此次事故纤拍中乘客们的安危让人牵挂，大巴车撞上限高架的原因同样也是网友们十分关注的。结合过往案例，此次大巴车撞上限高架可能有以下原因。
1.大巴车司机行车不规范
导致这一事故发生的最根本原因是大巴车司机走错车道后未及时更换正确车道，而是继续高速行驶。
在事故发生路段，有几处限高指示牌，下边是大车道限高4m，上方辅路是小车道限高3m。
旅游大巴车属于大车，本应该走下方的大车车道，但是司机却选择了上方的小车车道。
而且司机在上了辅路车道后，并没有及时掉头更换车道，而是继续保持高速行驶，最后撞上了限高栏。
大巴车司机走上辅路可能是对当地的路线不熟悉，不小心走错车道，可能情有可原。
但是作为旅游大巴车司机，应该具有高度的责任心和细心，毕竟每一次出行都要为车上几十个乘客的安危负责任。
发现自己走错车道后，大巴车司机应该不怕麻烦及时掉头更换车道，而不应该抱着侥幸的心理继续前行。
2.天色太暗，没有发现限高牌标志
事故发生时间是在晚上八点，当时天色很黑，而且事故路段光线不足，因此司机可能没有注意到限高牌，所以开上小车道后也没有减速行驶，最终导致事故发生。
这个可能性是很大的，因为在出事路段曾经也发生过类似事故。
四、如何预防类似事故发生1.司机提高行车规范意识
要防止这类事故发生最重要的就是司机要提高安全意识，开什么车走什么车道，不要不把限高问题放在心上。
尤其是长途大巴车司机和旅游大巴车司机，他们开的是大车，车上乘客数量多，每次出行更要注意行车规范。
同时旅游大巴车因为比较特殊，经常会去不同的城市，作为司机一定要提前熟悉所经过的道路，设置好导航，开车时做到专注仔细才不至于发生事故。
2.改善限高架
（1）为什么大肆要设置限高架
设置了限高架的道路都很特殊，一般是在铁路或者桥梁前面。
限高架能够防止大车撞击铁路或者桥梁造成特大人员伤亡事故，因此限高架有存在的必要性和科学性，我们不能够因为几起大巴车撞击限高架就质疑限高架存在的合理性，否则就会因小失大。
（2）让限高架更醒目
限高架十分重要，所以都是经过专业部门设置的，白天绝对够醒目，这毋庸置疑。但在某些光线条件不怎么好的路段，到了晚上限高架可能就不够醒目了。
针对这点，可以加大限高牌的尺寸，加大限高数字标识，保证司机上车道时就能看到限高牌。
同时还可以增加声音预警，比如在限高牌附近加装喇叭，播放限高警示语提醒过路司机。
3.导航系统提前预警
车辆导航系统对于辅助司机出行十分有帮助，预防车辆撞击限高架同样可以借助导航系统。
如果导航系统能够在司机开到有限高架的道路附近时，提前语音播报提醒司机选择正确车道，想必会很有用。
如果你还有其他好点子，欢迎在下方评论区留言分享！
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）