程序员写不好代码

‘壹’ 刚入职的java程序员会让你编写代码吗，如果编的不好或是没编出来怎么办

那肯定会啊，一般来说会根据你的大概水平给你分配任务（原则上是这样），不过实际上因为程序员有时候会比较忙，可能分配时不会很人性的考虑你的实际情况，这时候就看你自己了，该问问，该搜索搜索，总之对于公司而言，能够完成任务的员工才是合格的员工，要是一直达不到公司的要求，那么时间久了可能就遭到淘汰，这也是没有办法的事情

‘贰’ 代码不会写怎么办

1 – 测试不同的解决方案，直到感觉重复
在你研究或询问其他开发人员（=浪费他们的时间）之前，你应该尝试使用你现有的知识和思维来制定每一个可能的解决方案。

显而易见的是，太多的程序员是从询问他人开始的，自己甚至都不曾静下心来分析问题本身。不要成为这样的讨厌鬼，尽可能不要浪费别人的时间。

先投身于工作，然后再寻求帮助。

2 – 在线查找开源代码
当你投入于工作，却没有什么成果的时候，那么下一步你可以尝试开源代码。许多编程人员构建软件，是出于创造解决方案并在线发布以供大家使用的乐趣。有些人发布的代码曾被它们的程序员使用于商业项目。

GitHub是寻找开源代码的两个主要地方之一。另一个是StackOverflow。

这些网站的解决方案是采用可重用代码的形式，方便你在项目中实现。

谨记，使用其他人开发的代码总是有风险的。它可能会以你意想不到的方式改变程序的行为。备份原始代码，这是常识。

3 – 向更有经验的程序员询问
你有没有碰到过这样的情况，向其他人求助却发现你甚至不知道自己在问什么？

在询问任何人之前，你得准备好一些你无法通过网络信息搜索解答的问题。

明确的问题，才能有明确的解决方案。如果是你自己都描述得云里雾里的问题——那么你只会得到一个云里雾里的回答（并且可能会惹恼他人）。

如果你周围没有任何开发者可以询问，那么也可以在线查找。你可以在StackOverflow或MSDN社交论坛上询问，或查找特别针对于你所用技术的Slack频道。

4 – 如果一切都失败，那就潇洒放手

不要一心钻在死胡同里，实在不行，那就去干点别的事——睡觉，吃东西，等等。
你觉得这是在逃避工作？那就错了。我要告诉你的是，当你最轻松的时候，往往正是解决办法灵机一现的时候，这不是我胡编乱造的，而是有科学的证明。此时你的大脑工作在“发散思维”的模式下，而不是在“集中注意力”的模式下——你可以在这篇文章中了解之间的差异。

总的来说，这个理念就是要你忘记手头的问题，让你的意识心灵沉浸到其他的事情中。此时，你的潜意识则开始连接要点，朝着顿悟的方向前行。

我们可以做些什么以便于帮助大脑在发散思维的模式下工作呢？放轻松就好了：

散步（古代哲学家非常习惯于在走路时演讲，因为他们意识到走路有助于思考）
清理办公室或住所（完成后给自己一个奖励）
与朋友约会，和杯咖啡，聊聊八卦（如果你过于关注问题的话，那么建议和不能提供帮助的非编码人员交谈）

‘叁’ 为什么学会了JAVA语法，写代码还是毫无头绪

在我们进行编程时，有两样东西是非常重要的，一是思路，二是语法结构。有了思路，但对Java这门语言的语法结构不是特别了解，那么代码肯定是编写不出来。
或者说对于Java语言语法结构掌握的还算可以，但是解题却没有思路，代码肯定是无从下手的，这也是许多程序员常见的情况。
给你分享三个方法：

1、拆分法：将功能项目拆解成N个子功能，保证每个子功能只需要处理一个逻辑业务，返回一个逻辑结构数据，跟画家画一只兔子一样。很多功能实现过于复杂，需要牵扯到很多方面的问题，这时你只有好好拆分，把大功能靠自己的经验拆成多个独立的子功能，这样每个子功能的逻辑就不那么复杂了，自己也可以专心于业务逻辑实现。
2、预先定义法：很多功能你不知道怎么实现，但是你知道最终返回的数据结构应该是什么样子的，那你就预先把他定义出来，然后提前返回，中间业务逻辑部分都是为了填充这个预先返回的数据结构定义的。其实程序中充满着这样的技巧，各种代码都是预先定义好类型、数据结构、对象等等，然后慢慢通过业务逻辑取到值进行填充。

3、假设法：很多时候程序员需要完成对接或者功能还未实现，可以采用假设法，你可以预先定义好假设的数据，假设的数据跟需要的数据完全吻合，甚至你可以这样操作if (true) {}，这样把if里的内容全部书写完毕，然后再来处理这个true的问题，如果这个true的时机还不成熟，那说明不是你的问题了，而是别人的问题，别人应该背锅，你的绩效就达成了。

‘肆’ 怎么有的老程序员的代码写得还那么烂

代码烂一般有两个意思，一是格式乱，该有的空格没有，命名混乱，二是算法落后。看题主说的应该是前一种，这种问题的产生有几个原因，一是个人原因，老程序猿个人非常懒散，二是老程序猿的第一家公司不好，程序猿的第一家公司对程序猿的编码风格影响很大，三是当前公司不好，没有代码规范，没有code
review，四是历史原因，代码经历了好多人的手，风格很不统一，但是还能用，所以老程序猿懒得改了，怕引发其他问题。

‘伍’ 当程序员写不出代码了，该怎么办

你已经对着电脑 n 个小时了。敲键盘正成为一种负担，你在想，键盘是否就像西西弗斯推着的那块巨石。

咖啡一杯接着一杯。不敢再喝了，因为搞不好要有副作用了，心跳加速，身体不由自主地颤抖，出冷汗，但还是无法产出任何代码。

所有重新发现编程趣味的努力都徒劳无功，因为你的最后一点能量都用来驱逐大脑中正在攻城略地的话：

“我写不出代码了！”

总的来说，这个理念就是要你忘记手头的问题，让你的意识心灵沉浸到其他的事情中。此时，你的潜意识则开始连接要点，朝着顿悟的方向前行。

我们可以做些什么以便于帮助大脑在发散思维的模式下工作呢？放轻松就好了：

• 散步（古代哲学家非常习惯于在走路时演讲，因为他们意识到走路有助于思考）

• 清理办公室或住所（完成后给自己一个奖励）

• 与朋友约会，和杯咖啡，聊聊八卦（如果你过于关注问题的话，那么建议和不能提供帮助的非编码人员交谈）

最后再说一句，如果你绞尽脑汁，却仍然无法解决问题，那么不妨先放一放。通过潜意识的运作，搞不好突破性的想法就会灵光乍现。

‘陆’ 昆明Java培训：当程序员写不出代码了，该怎么办

你已经对着电脑n个小时了。
不知道该写什么代码，或者一种摔键盘的冲动正在你的胸中酝酿。
咖啡一杯接着一杯。
不敢再喝了，因为搞不好要有副作用了，心跳加速，身体不由自主地颤抖，出冷汗，但还是无法产出任何代码。
所有重新发现编程趣味的努力都徒劳无功，因为你的最后一点能量都用来驱逐大脑中正在攻城略地的话：“我写不出代码了!”

编程的本质是棘手即使是最优秀的程序员也会遭遇无法解决的软件工程问题。
碰到这样的问题，并不一定意味着你缺乏技能或知识。
编程不是一项容易的工作，我们可以通过采取非正统的方法来保持你想要的生产力水平，并确保提交高质量的代码。
如果我在一个问题上花了几个小时，却仍然找不到解决方案的话，最后我会觉得这是浪费了时间。
我不是胡言乱语——我只是觉得“没有人能够百死不悔”。
没有愤怒和悲伤。
因为我已经尝试过所有方向，只是都走不通而已。
失去希望，于是开始想辞职不干。
我觉得自己应该换工作，去做做调酒师或其他，至少研究和测试在啤酒中加点什么不会耗去我数个小时的时间。
这些都是我在不敲代码时的想法。
我开始怀疑生活，怀疑编码，怀疑人生。
有成效不?好吧，我从来没听任何专家说过“辞职和萎靡不振”可以造就伟大的代码，所以可能并没有成效。
这就提出了一个问题：我们该如何避免这种没有成效的状态?重新发现问题，重新发现你的生产力可能你已经行进在这条路上了。
那么此时你只要继续就可以了，我可能没有什么新的东西可以告诉你的。
如果你是新手，那么可能你还不知道如何重新发现生产力。
下面我要分享的内容将有助于你在编程时以一种健康的方式保持生产力，不至于筋疲力竭。
主要包括：测试不同的解决方案，直到感觉重复在线寻找开源解决方案向更有经验的程序员询问如果一切都失败，那就潇洒放手1_测试不同的解决方案，直到感觉重复在你研究或询问其他开发人员(=浪费他们的时间)之前，你应该尝试使用你现有的知识和思维来制定每一个可能的解决方案。
显而易见的是，太多的程序员是从询问他人开始的，自己甚至都不曾静下心来分析问题本身。
不要成为这样的讨厌鬼，尽可能不要浪费别人的时间。
先投身于工作，然后再寻求帮助。
2_在线查找开源代码当你投入于工作，却没有什么成果的时候，那么下一步你可以尝试开源代码。
许多编程人员构建软件，是出于创造解决方案并在线发布以供大家使用的乐趣。
有些人发布的代码曾被它们的程序员使用于商业项目。
GitHub是寻找开源代码的两个主要地方之一。
另一个是StackOverflow。
这些网站的解决方案是采用可重用代码的形式，方便你在项目中实现。
谨记，使用其他人开发的代码总是有风险的。
它可能会以你意想不到的方式改变程序的行为。
备份原始代码，这是常识。
3_向更有经验的程序员询问你有没有碰到过这样的情况，向其他人求助却发现你甚至不知道自己在问什么?在询问任何人之前，你得准备好一些你无法通过网络信息搜索解答的问题。
明确的问题，才能有明确的解决方案。
如果是你自己都描述得云里雾里的问题——那么你只会得到一个云里雾里的回答(并且可能会惹恼他人)。
如果你周围没有任何开发者可以询问，那么也可以在线查找。
你可以在社交论坛上询问，或查找特别针对于你所用技术的频道。
4_如果一切都失败，那就潇洒放手不要一心钻在死胡同里，实在不行，那就去干点别的事——睡觉，吃东西，等等。
你觉得这是在逃避工作?那就错了。
我要告诉你的是，当你最轻松的时候，往往正是解决办法灵机一现的时候，这不是我胡编乱造的，而是有科学的证明。
此时你的大脑工作在“发散思维”的模式下，而不是在“集中注意力”的模式下——你可以在这篇文章中了解之间的差异。
总的来说，这个理念就是要你忘记手头的问题，让你的意识心灵沉浸到其他的事情中。
此时，你的潜意识则开始连接要点，朝着顿悟的方向前行。
我们可以做些什么以便于帮助大脑在发散思维的模式下工作呢?放轻松就好了：散步(古代哲学家非常习惯于在走路时演讲，因为他们意识到走路有助于思考)清理办公室或住所(完成后给自己一个奖励)与朋友约会，喝杯咖啡，聊聊八卦(如果你过于关注问题的话，那么建议和不能提供帮助的非编码人员交谈)总结我在编程和生活两者之间保持了一种健康的平衡。
无论你是为了兴趣爱好、钱还是改变世界的宏图伟业而选择编程——编程都不应该是你唯一痴迷的东西，否则你会走火入魔。
最后再说一句，如果你绞尽脑汁，却仍然无法解决问题，那么不妨先放一放。
通过潜意识的运作，搞不好突破性的想法就会灵光乍现。
感谢大家阅读由java培训机构分享的“当程序员写不出代码了，该怎么办?”希望对程序员们有所帮助，更多精彩内容请关注Java培训官网免责声明：本文由小编转载自网络，旨在分享提供阅读，版权归原作者所有，如有侵权请联系我们进行删除

‘柒’ 对程序员来说最难的是写代码吗

谢邀。我是一名Java后台开发，还是一名工作没多久的“码农”。写代码作为工作的一部分其实不算难，甚至程序员写代码的时间比其他事情花的更少。我就分享一下咱们Java后端开发的小体会吧:

初级程序猿大部分都是写增删改查的业务代码，增删改查最需要技术含量的是查，归根结底都是写SQL语句，有的业务逻辑复杂一点就SQL语句复杂一点，或者数据库里不好处理就在Java代码里处理。只要数据库学的还行，MySQL比较会用，Java功底有一定基础，基本上都能胜任敲代码的工作。

文|热心哥哥宇文笑

文|热心哥哥宇文笑

业务复杂
，有的系统尤其是一些toB的系统，比如一个上市公司的超市人力管理系统，这是非常复杂的，人事组织，薪资社保，还要针对不同地区分公司不同类别的员工进行不同的代码处理。

业务复杂

需求变动频繁
，有些项目的顾问或者产品经理没把控好，导致需求被客户拖着走，搞产品的可能觉得也就变化一点点东西，实际上有的功能代码需要后端重写，数据库的表结构一变，那改动也是得跟着变。咱们敲代码的朋友最不喜欢的就是返工，我们宁愿去接受更多的开发新任务也不想再去重写自己以前写的代码。（不用说什么重构，这些业务代码重构其实并没有什么技术上的突破）

需求变动频繁

代码优化
，其实比较难得住人得，尤其是难住我们这些刚入行的程序员。有的业务数据量庞大，就得先考虑数据库优化，代码多线程优化，总之优化代码倒是一件比较进阶的拆事，比敲代码难。

代码优化

来说说，作为程序员的你，最难的什么呢？

‘捌’ 如何提升程序员的代码编写能力

一、先列三个常见的开发场景：

1、拿到一个模块详细设计文档，大部分程序员的通常做法就是开始搭建界面代码，然后从第一个按钮点击事件或页面Load事件开始写第一行业务代码。写的差不多了，就运行一下，发现哪里不是自己想的那样，就改改，直到改到是自己预想的那样。

2、做完了一个功能模块或几块相关联的功能模块，输入111asd，发现新建正常、保存正常，就提交给测试人员。测试员用测试用数据、测试场景用例来测试，发现有问题，就登记bug。对于严重的影响下一步测试的BUG，测试员就用内部IM通知这个开发人员。对于不影响继续往下测试的BUG，测试员就登记下来，等程序员有空时处理。

3、程序员一般工作不希望大家打扰，所以开发起来就是开发。等手头开发告一段落，就看看BUG库。发现有与自己有关的BUG，就从第一个BUG开始看起。就开始通过IM和测试员掰扯起来（这不是个BUG啊、业务逻辑不是你想的那样啊、我这里不能重现啊、你给的信息描述不清晰啊），于是IM几来几往，甚至跑过去当面交流一番，甚至会拉扯上产品经理一起讨论，更甚者需要项目经理或产品经理发起一个会议来集体讨论一下

这是不是很熟悉呢？这就是大部分程序员开发的三个步骤：写代码、自测、修复BUG。

二、说好的代码设计、代码测试呢？

代码设计？那不是都有开发平台么，已经固化了啊。那不是维护旧功能做完善修改呢么，又不是写新代码，只能在现有代码基础上修改啊，你又不能大幅重构。

代码测试？你丫需求讨论期、产品设计期、设计评审期那么长，都把研发项目时间占光了，就留下2个星期让我们写代码，我们哪里有时间搞那么深的测试。还想让我们搞结对编程？还想让我们搞测试驱动开发？

而且你看测试，什么功能测试、集成测试、性能测试、安全测试、安装部署测试、升级测试、迁移测试、UAT测试，一大堆测试，测试也需要很多时间。

一个项目，需求讨论、产品范围规划与评审、产品设计与设计评审占了一个半月，开发+自测就一个月，测试占了一个半月，这就4个月了啊。

三、为啥程序员写代码总是写写测测？

刚才大家也都看到了，大部分程序员都是从界面代码开始写起，而且写一写，就运行一下看看。为什么会是这种开发方式？

那是因为大部分程序员缺乏在脑子中的整体建模能力。只能做出来一点，真实的感觉一下，然后再往下。

有些是产品经理的上游就有问题，没给出业务流程图（因为产品经理也没做过业务），也没画清楚产品功能操作流程图。

为啥没给出业务流程图？因为产品经理不熟悉业务，另外，产品经理也没有流程建模能力啊。为啥没画清楚产品功能操作流程图啊？因为不会清晰表达流程啊。

很多产品经理、程序员，都缺乏分类、分层、相关、先后能力，更别说总结、洞察能力。

这是基本训练，是一个做事头脑清醒的人必备的技能，这不是一个程序员或产品经理或测试员的特定技能要求。

我经常看书就梳理书的脉络，每看一本就写一篇总结。我过去闲扯淡还梳理过水浒传、红楼梦的人物关系图呢，其实就在事事上训练自己的关联性、层次性、洞察性。

我经常面试一个人时，我会问这样的问题：“你把我刚才说的话复述一遍，另外你再回答一下我为什么会这样？”，其实，我就在看一个人的细心记忆、完整梳理、重现能力，我也在看一个人的梳理、总结、洞察能力。

我个人写代码就喜欢先理解业务流，然后理解数据表关系，然后理解产品功能操作流，大致对功能为何这样设计、功能这样操作会取什么表、插入或更新哪些表，哪些表的状态字段是关键。

然后我写代码的时候，就根据我所理解的业务流、功能操作流、数据输入输出流，定义函数，定义函数的输入与输出。

然后，我会给函数的输入值，赋上一些固定值，跑下来看看能否跑通这几个关联函数，看看还需要怎样的新增函数，或者看看函数的输入输出参数是否满足跑通。

剩下的事，就是我填肉写详细逻辑代码了。

当然，大部分人没我这样的逻辑建模能力。怎么阅读理解也想象不出来，也没法定义函数。毕竟有逻辑建模能力的程序员都很少，100个人里有10个，已经是求爷爷告奶奶好幸运了。

那怎么办呢？

我建议是分离分工配合，这就是现实中没办法的办法。让有逻辑建模能力的人来设计函数框架、来设计工具来设计代码模板，然后让没有逻辑建模能力的人来填肉写详细逻辑代码。

我们可以先从最紧要的模块开始这么做。不紧要的模块，还让它放任自流，让熟练手程序员继续涂抹。

我曾经还让有头脑的程序员做榜样，给大家分享他是怎么规划函数的，怎么做维护性代码的代码结构改善的。但是发现效果并不佳，其他人并没有因此能做代码设计。可能逻辑建模能力是个人的基本素质，是从小到大训练成型的，不是你一个大学已经几年的人能够短时间内可以训练的。

所以啊，还是让能走的人先走，让从最紧要的模块开始这么做。

不必担心这样做后，因为过去一件事被分工（一个做代码框架一个填肉）成两个人做了会降低工作效率。我们很多的工作效率低就是因为半瓶子醋搞出来的，来回反复修改。

真是应了刘德华在电影里说的那句话：说你又不听，听又听不懂，听懂了又不做，做又做不好，做不好还不服气。

四、为什么大部分程序员不做代码测试或白盒测试或单元测试呢？

还是因为没有代码设计。因为没有函数啊。所以，一个按钮功能有多复杂，代码就有多长。我见过2000行的函数，我也见过1000多行的存储过程和视图SQL。怎么做白盒测试啊，这些代码都粘在一起呢，要测，就得从头到尾都得测。

所以啊，先学会设计函数，先写好函数，这就求爷爷告奶奶了。很多开发了5年的熟练手程序员，可能都未必会写函数。

函数的输入输出值就很有讲究。很多人都写死了，随着版本迭代，发现过去定义的函数参数不够用了，于是就新增了一个参数。然后，相关性异常就爆发了，其他关联的地方忘改了，到底哪些有关联，怎么查啊，本系统没有，没准其他系统就调用你了，你根本不知道哪个神经人曾经COPY过你的代码修吧修吧就改成了他的功能呢，而且里面的很多代码他看不懂也不敢删，只要他实现的功能正常了他也不管了。于是，你改了你这个函数，他的系统就莫名出错了。

所以，我一般会定义几个对象来做参数。另外，我也很注重函数的日志、函数的异常保护、异常抛出、异常返回。另外，我也很注重参数输入值的合法性校验。

所以啊，应该开发Leader们先制定函数编写规范最佳实践，输入输出参数怎么定义比较好，函数的返回值如何定义比较好，函数的日志记录应该怎么写比较好，函数的异常保护、异常抛出、异常返回如何写比较好。先教会一般程序员，先从会写函数开始啊。

当然，你光有一份规范，程序员们还是不理解、不实际应用啊。所以，还得Leader们做好典型的代码模板，里面是符合函数规范的代码框架，只有这样，一般程序员们才会照猫画虎适应了函数设计的编程习惯。

所以啊，我专门重新定义了leader的明确职责，其中第一个重要职责就是：负责工具/框架/模板/规范的制定，并且负责推广且普及应用落地。

你不明确定义Leader的这个重要职责，你不对这个职责做明确的KPI考核，谁尿你啊。你以为好的工具/框架/模板/规范是靠人们的热情、自发产生的么？我们还没有那么自觉高尚啊。

五、为什么大部分程序员不写注释啊？

我经常说一句话，千万别多写注释。为啥？

因为我们经常遇到的问题不是没有注释，而是更糟的是，注释和事实代码逻辑是不相符的。这就出现常见问题了：残存下来的设计文档是一个逻辑、注释是一个逻辑说明、真实代码逻辑又是一个，钟表多了，你也不知道正确时间了。

所以啊，产品文档、注释、真实代码，三者总是很难一致同步。我为了几百人研发团队能做到这个同步花了大量心血和办法，但我最终也没解决了这个问题，还把Leader们、总监们、我都搞的精疲力尽。

索性回归到一切一切的本源，代码，就是程序员的唯一产出，是最有效的产出。那么，让代码写的不用注释也能看懂，咱得奔着这个目的走啊。

为啥看不懂，不就是意大利面条式代码么，又长又互相交杂。

OK，我就规定了，每个函数不能超过50行。用这一个简单规定和静态代码检查插件，来逼迫大家尝试着写函数。有的函数属于流程函数，是串起其他函数的，有的函数就是详细实现函数，实现一个且唯一一个明确作用的。

有了流程函数和功能函数，而且每个函数不超过50行，这就比过去容易看懂了。

六、为什么大部分程序员不抽象公共函数啊？

我经常说一句话：千万别抽象公共函数啊。为啥？

因为大部分程序员缺乏抽象洞察能力。特别是有些积极热情有余、爱学习爱看书、半瓶子醋晃悠的二杆子，看了几本UML、重构、设计模式、整洁代码之道，就跃跃欲试了，还真敢给你抽象公共函数了。

一开始，他觉得80%相似，20%不相似，于是在公共函数里面简单写几个if..else做个区隔就可以。没想到，越随着版本迭代，这些功能渐渐越变越不一样了，但是这个代码已经几经人手了，而且这是一个公共函数，谁也不知道牵扯多少，所以谁也不敢大改，发现问题了就加一个if..else判断。

没想到啊没想到，这个本来当初公共的函数，现在变成了系统最大的毒瘤，最复杂的地方，谁也不敢动，除非实在万不得已，手起刀落。

所以，我平时告诫程序员，纯技术的、纯通用的，你们可以尝试搞搞抽象公共函数，对于业务的，你们还是简单粗暴的根据Leader们做的代码模板代码框架，乖乖的复制、修改、填肉吧。

你们啊，先从做模板做代码片段开始吧，咱们放到咱们内部代码片段开源库里，看谁的代码片段被别人复制的多，说明你的代码抽象设计能力越好了。那时候，我就大胆放心让你撒丫子跑了。在没有学会跑之前，给老子乖乖的复制、修改、填肉吧。

‘玖’ 为什么程序员总是写糟糕的代码

因为程序员都比较懒