编程瓶颈怎么破

‘壹’ 程序员的职业生涯通常会遇到哪些为人熟知的职业瓶颈该如何应对

会的。身边同事工资翻了一番，但自己跳槽加薪难，面试无回复，跳槽加薪不高;我想离开一线的开发工作，做一个技术管理的职位。我对自己的技术实力和项目管理能力没有信心。不愿意写一辈子的代码，想寻求职业突破(进入知名公司，拿高薪)却找不到方法，缺乏明确的职业规划。这类朋友还是比较多的，主要是想学但没有方向，这应该是广大程序员工作人群的困惑。

其实，刚开始的时候掘坦，我并不喜欢把自己的作品记录下来，更不喜欢把它写成微博，发布在公众号上。即使在公司里，我也嘲笑它，认为这只是形式主义。但在我被困住的那些年里，我一直在写作，让自己不去想那些事情。这次经历让我想到了用一种新的方式总结经验。乍一看，根据某一条目逐字逐句地输入你的工作经历似乎是在浪费时间。但在不断总结工作经验的过程中，我们对工作进行了更仔细的梳理。这实际上是一个思考的过程，在经验中寻找共性，并逐渐形成自己的工作方式。随着时间的推移，你会摆脱焦虑，找到一条适合自己的道路。

‘贰’ C语言学习遇到瓶颈怎么办

1、没有耐心学习了。毕竟C语言很抽象，学习起来很枯燥，能从头学到尾的人确实不多。

2、遇到困难的知识点了。可能在指针那里、链表那里、数组那里不理解了。这个也属正常，C语言是抽象的，尤其在这几个地方更加抽象。

3、写不出代码了。可能书是看完了，但是上手写代码，就写不出来了，但是看别人的代码又是可以看懂的。

如果题主的瓶颈期是第一个，这个我给不出啥建议。

如果题主的瓶颈期是第二个和第三个，我给出的建议是持之以恒。我想大家都听说过1万小时的理论。做任何一件事情，只要能投入至少1万个小时，那么你绝对是这个领域的专家。学习C语言也是，遇到困难了，可以查资料，可以问人，可以自己动手去实践，反正要利用一切可以利用的资源，再加上自己的主动性，我相信没有过不去的坎儿。题主有问题也可以跟我交流啊！

‘叁’ 程序员如何在35岁瓶颈期的时候，找到自己的方向

1程序员的困惑

程序员是一个神奇的职业。日复一日面对着电脑，一行一行地码着代码，给人的印象是呆头呆脑，不善于交流和沟通，加班是经常的事，仿佛永远都有干不完的活，身心都很疲惫。但事实上呢？

大多数程序员，他们热爱编程， 对很多技术充满兴趣， 总是希望学习并尝试新奇的技术， 在业余也花了很多时间学习工作中暂时用不到，但是自己很感兴趣并且很看好的技术，从进入到第一家软件公司，后来一直没有离开软件行业。

‘肆’ 程序员如何突破技术瓶颈期

对于程序员来说，在工作中除了实现自己的个人价值以外，同时也需要不断吸收新的知识来充实和提高自己的能力。今天，我们就一起来了解一下，程序员在技术瓶颈期应该如何突破。

作为一个技术人，不知道你有没有遇到过下面的情况?

“我学不到新东西”

“我感觉没啥成长”

“每天都在重复劳动”

其实，每个技术从业者，多多少少都会遇到工作或学习瓶颈期。产生瓶颈郑猜期，往往不是因为我们不够努力，而是以下原因导致的：

1、无法积累有效的项目经验，一直在做着重复的事情，成长出现断层。

2、企业的培训较为传统，多为被动接收，“营养成分”较低，对业务开发无明显提升。

3、技术书籍和网上的免费资料实效性较低，且大多理论性会大于实用性，导致无法应用到工作场景。

那么，该如何解决呢?

1、借助“巨人的肩膀”，快速成长。

学习资料非常关键，真正经典的素材只占1%。如果希望得到快速成长，或是成为技术领域高手，那么就需要借助“巨人的肩膀”。比如，如果可以接触到BAT、或者国外大公司的资深技术人，你的学习效果就会事半功倍。

2、利用碎片化时间，提升专业能力。

一旦进入职场，我们很难有成块的时间去系统的学习一门知识，良好的状态是利用自身碎片时间，学习与业务紧密相关的实战知识。网上下载的资料，或者一些技术书，可能无法在碎片化时间消化。

3、每个角色都要懂其他角色的东西，才能成为优秀的角色。

虽然研发团队角色不同，如产品、研发、测试。但是这些角色都是相互交叉影响的。如果对其他领域没有一定的认知，就会听不懂他们的诉求本质和技术方案，耗费沟通罩悔成本。而能在多方配合的沟通场景中，北京北大青鸟发现通过学习到的多样技术能力，直面解决技术问题，就可以在技术成长之路上得到提喊闷型升，成为一名优秀的技术leader。

有没有“拿来就用”的解决方法呢?

以上推荐的3点解决方法，可以总结如下：

1、学习使用有价值的经典学习材料;

2、持续学习，碎片化汲取“营养”;

3、保持在多领域对技术知识的拓展。

‘伍’ 工作一到五年的Java程序员遇到瓶颈应该如何提升

工作了5年的Java程序员，该如何提升,做了3~5年Java开发，你已经积累了不少项目经验，扩宽了技术广度，也许已发力成为团队管理者。到了这个阶段，大家却常有这种感受：感觉自己卡在瓶颈进步缓慢，技术水平很难像早期一样实现大幅突破？
其实大家往往忽略了这一点——提升自己的架构认知（工作5年左右程序员必须重视架构认知的提升，这会很大程度上推动你今后的成长）。架构的本质在于面对业务场景给出优雅的解决方案，使得业务能够快速迭代和持续交付，从而达到降本增效的目标。提升架构认知高度，就像达克效应所描述的一样，要敢于从愚昧之巅跳到绝望之谷，通过爬升开悟之坡，从而达到架构认知的巅峰时刻。到达巅峰时刻也就掌握了架构背后设计的哲学，面对具体业务场景在架构层面你便能够轻松应对，以无招胜有招。
提升架构认知，要紧抓3个关键点：业务洞察力、技术视野、原创力（执行力）。
1.业务洞察力是技术战略层面的问题，在当下能够做出合理的判断，清楚公司做什么事情收益最大；

2. 技术视野即技术选型能力，是技术战术层面的问题，在清楚做什么事情后，需要进一步解决怎么做的问题，也就是能够给出合理的技术选型方案：是完全基于开源的方案，还是基于开源二次开发的方案，还是完全自研的方案；
3. 原创力（执行力）是技术落地执行层面的问题，一旦技术设计方案确定后，需要能够快速Rush完成。
这3点层层递进，最重要的是先把技术战略问题思考清楚，然后再进一步解决技术战术问题，最后是快速落地执行的问题。
工作5年左右的程序员，在原创力（执行力）层面比较有竞争力，往往欠缺技术视野以及业务洞察力。后面2点更加重要，这2点解决的是架构设计哲学问题，是架构师能够持续拥有竞争力和影响力的立身之道。

举个场景的例子来详细说明：一提到分布式锁问题，大多数人想到的方案是基于Redis的Master-Slave模式来实现。这个实现方案行不行？分布式锁本质是一个CP需求，基于Redis的实现是一个AP需求，乍一看基于Redis的实现是无法满足的。脱离业务场景来谈架构都是耍流氓。
从技术战略的需求层面来看，如果分布式锁在极端情况下获取锁的不一致，社交业务场景能够接受，那么基于Redis的实现是完全可行的。如果业务是交易场景，分布式锁在极端情况下获取锁的不一致性无法接受，那么基于Redis的实现方案是不可行的。在锁强一致性的场景下，需要采取基于CP模型的etcd等方案来实现。