为什么基础很好的程序员写的代码依旧很烂？

编程主要还是得看经验吧。。

混吃

那就是基础不好。LZ的判断有问题。

他们只是看起来基础好而已

纸上学来终觉浅 绝知此事要躬行。经验问题，或者说是懒得花时间去想，毕竟项目不等人。宁可快速糊弄完，也绝对不会慢工出细活，基本上都是这样。宁可先糊弄完日后重构也不会因为某个细节没写好而精雕细琢。起码我是这样

@WispZhan 除非是我自己的项目，可以慢慢做，反正写给自己无所谓。

第一 纸上谈兵、眼高手低 第二 随便写写

= =认识不少的，都是除开工作一点都不去动脑了

你招到学霸（除了做题啥也不会的）和面霸了吧

面试时候内容都是精心准备的吧。
经常写漏洞百出代码的人 ，不相信算法会好到什么地方去， 算法对于边际条件的考虑不周都是致命的。

以前面试人的时候不问时髦的问题， 就拿最简单的日常工作内容考察应聘者，在我们看来工作2，3个月就应该能写出来的代码，那些号称5年经验的应聘者没几个写得出来。难道遇到一个写的很好的家伙， 结果发现是HR弄错了……

当时的问题如下：
1 java题，描述一个web工程在服务器里面的目录结构；
2 java题，让hashmap内容按照key的顺序打印出来， 考察一下基本collection用法；

没啥惊人的吧，很多人以为编程就是算法……
就好比有人觉得背出英语语法大全和牛津词典就超越莎士比亚了一样。
很多人秉承这种想法，而这种人实际上水平最烂，完全连最基本的代码都写不好，不然他就会明白算法真心一点用没有。

@nbndco 所以应该去实践？

@WhatIf 如遇明主，大业必成，遇到你们这样接地气的面试，简直太棒了，但是还是觉得应该有适当的笔试，最基础的。

主要看心态。到底是应付还是精益求精

@WhatIf
hashmap中key有顺序码？

估计是赶工期，没空把代码写得漂亮.

真的是赶工期

正因为有这样的人存在，你们厉害的才能突出。要不个个都一个水平。就不用分了。

@ruoyu0088 我也没明白是什么意思，hashmap里面的值本身就没什么顺序可言啊，可能意思是说按顺序遍历走一次？按顺序来的那个应该是LinkedHashMap吧。

态度

不记得在哪里看得了，说是实际上程序员分三种：
1.编程只是一份工作，不行就换
2.编程是一种方法，只要实现了目的就好
3.编程是一门艺术，时刻都有尽善尽美的空间。
看楼主的思想，是希望所有的人都是第三种，但是很可惜，实际上大部分人是第一种，少部分人是第二种，真正第三种的人，很少很少。

你确定理解什么叫基础很好？

@joshryo hashmap 直接遍历出来无序， 换成有序的结构也行，自己写排序也行总之就是想办法实现即可。 如果直接用sortedmap或者用内置排序方法至少说明对类库不算陌生，如果自己写排序，可以顺带看看基本的循环条件之类结构如何，写算法是否严谨。
对了，之前忘说了， 当时是把笔记本直接扔给面试的人，可以上网随意查。 直接ide开了个工程让他们来写代码， 遇到最要命的人还偷偷的把我用于验证的junit test给改了 ，真不知道脑子里面放的是什么

@ruoyu0088
@WhatIf 同问，hashmap中key有顺序？

@ruoyu0088 是说然按照key的顺序显示value
举个例子吧， 你的代码收到一系列数据， 用map传过来 ， 里面key是员工号， value是员工的工作量。 现在要在你的程序里面按照员工号从小大到依次显示对应工作量。

。。。确实有很多自称工作很久的连标准库的API都不会用。。。

基本上代码里通篇都是if for switch……这不是在写 C 啊。。。也不是按行数论工资啊。。。

估计就是没做过项目眼界太窄了。
熟知各种设计模式?知道有个毛用，也是真的知道？这可是要做过好多项目才能理解进去的。


或者
其实是加班太多了。

其实，有时候，leader和别人看到的是：多快的速度fix bug和多快的速度new feature，才没有空管你code 怎样。其实有时候我也经常第一天写完的新功能，下班回家思考后觉得有好几个地方可以优化打算第二天重构一下，谁知第二天有新的优先级更高的任务来了。

能运行就可以了，写的好老板又不会多给你钱
这样算代码质量越好自己越吃亏

楼主敢把那位牛人的代码贴点出来么? 让大家鉴赏一下....
顺便说一句, 很多码农除了看自己的代码顺眼, 其他人的都是屎

是看他写的最好的一个作品里的代码水平，还是看他的平均代码水平，或是在天天加急赶进度时候的代码水平。这3者都不一样，有的人只有第一点做得好，有的人3者都做得不错，那就真是高水平 加 有责任心的好程序员。

你认为的好 != 别人认为的好
同理
别人认为的好 != 你认为的好
只是从这个角度出发而已，你觉得完美团队，是从你的好出发，如果你负责招人，这件事很容易搞定。
如果你只是小兵，一个字。。。忍。。。

@WhatIf 想当年面试都是一张纸，一支笔，让你写代码，有的地方连伪代码都不让写。你这简直太任性话了，把面试的宠坏了。（笑

@joshryo 人性...

俺就是写sql的人。。。
不过俺是真心觉得原生的好。。。

程序员至少分俩种，一种是码奴，一种是工程师，区别是思考与付诸行动。其它行业也一样。

被需求折腾的情况下，很难按下心整理代码。此外，代码工整，是不算绩效的。还有一种情况，就是维护别人代码时，总要进行折中一些个人原则的。

一直想说的是：一些人将与自己风格不同的代码也定义成烂，是卑劣的行径。烂代码基本的特点是：命名无规则，封装层次不合理，文件拆分不合理，雷同逻辑不重构，注释与代码脱离。

程序员的基础或者说立身之本就是学习能力,不与时俱进的程序员,你从何评价基础好.

如果不是再确认下，以为来知乎了呢。

一方面是国内都比较排斥新东西，出来个什么东西开始有人喷，然后一堆人站队说老外的真烂
另外一方面因为每个人的生活状态有差别，可能在别人眼里，代码只是养家糊口，正事是别的

摊我身上得看时间，时间多就好好写，时间少，怎么快怎么来。
可不要因为代码小看人啊

碰到面霸了吧，各种面试会问到的东西，人家都背出来了

赶时间

能好好把原生sql写出来的程序员你碰到了就别放走了。

> 并且一直在用最basic的方式编程。
> 忽视好用的工具，很喜欢写原生的SQL
> 忽视很多语言的新特性和新的框架

我没看错？ 这是在夸人吧 :)
编程，主要是解决问题，而不是秀技。 能解决问题才是好。

不用原生 SQL 用什么？ TSQL？新框架就一定很好？坑就少？楼主的描述都是主观性的东西，上你和他的代码， Talk is cheap

这叫“大道至简，返璞归真”

@shenfeng
@vzch
@Actrace
@Ison

回复一下各位大神的问题。。

编程，主要是解决问题，而不是秀技。我非常的认可这一点。

我想说的是：如果原生的SQL是最好的，那为什么要有ORM？如果现有的框架已经足够好用，那为什么不断地有大牛要开发新的框架？

写原生SQL有非常大的问题是，可读性差、冗余代码，以上两条会导致后期有巨大的安全隐患 - 一团乱麻的代码多人维护的情况下更容易产生BUG。《黑客与画家》里面曾经讲到，封装的层越多，代码的抽象性越高，代码的可重用性就越好。

很多一些新的框架，例如laravel，作为后起之秀，短短几年时间已经赶超很多老牌框架，把PHP语言带到一个新的高度，这难道不足以证明这个框架的价值吗？

为什么要一直在使用最老的东西，还总是欺骗自己XXX就是好呢？

@wyan453351466

“封装的层越多，代码的抽象性越高，代码的可重用性就越好”？

我就呵呵了，你去找来EJB1.0用用看

额。。。写sql也能归类为代码烂？？？晕了

哈哈哈 看别人的代码都是屎

@wyan453351466
首先俺不是啥大神
其次凡事都有可用范围
封装确实某些场合下很方便快捷
但可用性牺牲的时执行效率
而且你说的“写原生SQL有非常大的问题是，可读性差、冗余代码“
这不是原生的错 严格来说应该是使用的人的错
数据库设计问题、编写人员的水平问题才是导致你说的问题的直接因素
orm确实解决了部分生产中的问题 但事实上也同时让使用者限制在框架设计者的思维当中
跳出框架工具思维 从需求出发 也许你会体会到不一样的东西
其实很多公司都会在某一个阶段开发自己的框架、工具、中间件
就是因为市面上的已经不能很好的解决自己生产中的问题了
只有适合自己的才是最好的
而随着项目挖掘的加深 也只有自己才能根据自己需求做出最适合自己的东西
你提到的laravel不也一样是作者为了解决自己问题而做出来的么
只是有很多人觉得他的方案对自己也有用 或者只是道听途说的拿来用而已。。。

有的代码由于种种原因，其实只要能跑，不 crash 就好了，就这两点要求。

你怎么评定代码很烂，没有用新框架，写原生的sql就很烂？那效率呢？稳定性呢？可读性呢？用新框架，用很新的方式编程就没漏洞，就很牛逼？

@wyan453351466 脚手架确实能够提升一部分的编程效率，但是若想编写一个属于自己的产品，基本上都无法用别人的设计思想来实现。对于一些富有经验的程序员来说，无论您的需求是什么，技术永远都不是问题，时间才是唯一的问题。
鄙人一直以来的的观点都是技术为产品服务，任何问题到了最后，最好都不是技术问题。

@surewen 赞同

只有菜鸟才会看不出别人代码写的好不好。

我认为 很喜欢写SQL代码 = 水平差 这句话在某种程度上是等价的。
在绝大部分的开发中，根本不太需要考虑纯SQL和ORM的性能差（特殊的情况下可以ORM和SQL结合），如果一个人在开发中基本不用框架或者ORM，我可以认为他差。
说开发效率，ORM比写SQL效率也高了不知道多少倍（就像一个中型J2EE的项目，一个用JPA肯定比纯SQL的水平高）。

LZ，算法很好的人写的程序非常烂的可能性还是很高的，在同样的学习的时间下，如果在其他方面有更多全方面的学习的话，代码写好的可能性高很多的。

这种现象大多是态度问题。我也看到有很多基础好的人写的代码很烂，这是因为公司的态度造成的，大家只求完成任务，不求其他，没有太多追求

还有，我觉得很多人其实是混淆了概念。
用更好的框架如果是初期的刚开始学习使用的话，可能的确会慢点。但是现在框架都是往开发速度越来越开的趋势发展，如果你熟悉和了解的话，不可能会比老的慢。而且新框架的思路理念比旧框架绝大部分是要好些的（当然Spring、RoR之类可以认为是一种新的版本）
而用语言特性、更多的语法糖也是为了更好的设计理念及部分效率出发的。

如果认为用新的东西和旧的东西在时间上有太大的差异的话，那么只是客观一直在用自己熟悉的东西而已。毕竟学习是要成本的，可是新的东西开发效率的提升也是巨大的。

每个人都倾向于自己习惯的工具和方法，越是大神越是熟悉这些基础的东西

语言特性确实也是考验程序员水平的，以Python为例，以下三段代码那个更好？

代码A：
print ",".join(map(str, a))

代码B

print ",".join([str(i) for i in a])

代码C：

t = ""
for i in a:
____t += (str(i) + ',')

print t[:-1]

公司一般都是追求又快又好，这就需要花更多的时间提高技能。

@9hills 第三种，简单明了，即便是不懂python的人也能看懂。

@tabris17 如果只学了一周Python，写第三种情有可原。。可能都写不出来，而是在for循环中加个判断是否是结尾。。而不是 t[:-1]

但是如果简历上写Python是熟练，那么写第三种直接不要。第二种勉强，第一种及格

@monsoon 用orm调试找错，蛋疼

原生sql才能把数据库的威力发挥到最大

@lbp0200
这的确是可能的。
如果是复杂到需要调试的，肯定要考虑是否使用纯SQL来（大型的ORM框架里都会提供接口的）。
但是大部分情况下，我们可能只需要查几个字段、关联几张表，这时候ORM带来的开发效率是巨大的（很多框架都约定大于配置了、提供一个接口就可以简单实现）。

现在也有人批评 CoffeeScript 之类的转译语言在遇到有些问题而难以调试（尽管可以Sourcemap），我想更多的人不会考虑这些，因为世界上绝大部分的东西不是只有优点而没有缺点的。如果某些方面可能没有优势，这方面可以用其他东西去替代（ORM中夹杂SQL），也可以用其他手段来减少如到这样的情况（单元测试、更小的组件）。

原生SQL有何不妥？毕竟上ORM，要做的事不会少，甚至更多。就像常见的Hibernate和MyBatis，前者学习门槛很高，但是熟练后基本上都是自动生成的，移植性也好；后者要自己完成SQL语句的编写，考验SQL基本功，但是性能上有优势。新的框架也不一定就好，现在仍然有很多地方使用Struts 1而不是Struts 2，在Struts 2漏洞满天飞的时候，Struts 1不受影响，旧框架也能很好的提供服务。

https://spring.io/guides/gs/accessing-data-jpa/
写ORM不可能这么简单

Hibernate 的确很复杂（因为绝大部分的Java的框架都很重），但是现在的Spring Boot或者Play Framework之类封装后写JPA基本都不用什么配置.
其他动态语言的ORM写起来更简单。

偏激的我讽刺一个性能的例子：
Java开发者都在做企业级项目，用户量都是几千万，金额都是几个亿的项目。自然是不能用RoR之类看上去是绣花姑娘一样的框架。
开发者的团队朋友都再三叮嘱他：千万别用ORM，我们要做的项目可是要每秒能响应几千万个请求的打项目。

开玩笑的，别太当真。我也是太认真了，其实对立的观点还不然来下卖萌的好。驳到他人一点价值都没有。

也或许是你并不理解比人的代码。

@WhatIf 第一个问题有点莫名其妙。第二个问题就太扯了吧，没区分度

懒

家里基本都是猪圈

@jerryouyang 不知道莫名其妙在什么地方？考察一下对于最基本的web项目在服务器上的部署而已。 一个号称做java web开发的，连web.xml是干嘛， 连jar包放在什么地方， 连项目怎么在服务器上运行起来都不知道的人，至少我认为都是不合格的。 实际情况是，发现太多的3到5年经验的人根本不知道怎么回答，这个真的很可怕。

对于代码质量， 下面是我的想法。
-----------------
代码质量分几个因素.我认为最重要的几项是:
1.可靠程度.程序是否处理了所有的可能性，比如是否处理了可能出现的错误? 是否处理了可能出现的SQL注入?
2.可维护性.代码结构是否合理？代码是否可读易读？ 类、变量、函数命名是否合理？注释是否合理？
3.算法设计合理，性能优秀。

还有一些被过度关注，但我认为其实不那么重要的东西:
可扩展性。有时候我们为程序设计一定的可扩展性，以应对未末新增的业务。但我认为在很多时候，我们预料不到未来的业务是怎样的，追求可扩展性成为了过度设计和做无用功。在很多情况下，等新需求到来时，再对已有代码做重构也并不晚。
设计模式。这一点和前一点有点类似，我见过很多代码，为了使用设计模式而使用设计模式，同样是过度设计和做无用功。
-----------------
对于新的语言特性、框架、工具， 我认为它们往往不是关乎代码质量最关键的东西。是否使用它们，需要评估它们的可靠程度、学习成本和收益才能决定。如果一个程序员倾向于保守， 我认为其实无可厚非。

@WhatIf 如果你先问对方使用过/熟悉什么框架，有没有亲自开发/部署过服务，然后再问一个这个框架下 web 工程的目录结构一般是什么样子，这样就显得比较合理了。原因：一是框架太多了，什么 struts,sprintmvc,play ，各个都不一样，不是各个都有类似于 web.xml 这样的文件；二是即使是用的同一套框架，有些公司也会进行二次开发，导致实际开发环境与开源版本相去甚远；三是有些顶级公司根本不用开源框架。有一个共识是，国内很多公司的面试官的面试水平也参差不齐。但是少有人能反思。

这句话“最basic的方式编程”本身就存在问题，不知道楼主有木有这总感觉呢？
编程是一种习惯，习惯会成为自然行为，有些人就是不喜欢jquery，就是喜欢用原生Javascript实现jquery的功能，你能说人家这种方式是最basic的吗？
再者以前我一个同事明明很熟悉Net的 EF和linqToSql可是人家在产品应用就是喜欢写原生的sql语句来操作数据库，不知道这又算不算最basic的编程方式呢？

很多新的东西并不是好的，一些看似能简化工作的工具和框架有时候并不一定适合，新东西的存在是为了更好的解决某些场景下事务操作，但是并不意味的就是一种取代和推崇~

初学, 越来越觉得自己写得是垃圾, 先来我能这样看也说明自己入门了. 但不知道下一步该如何提高.

@monsoon
我觉得我们在讨论一个问题应该更多的将场景考虑到里面，我很赞成你的ORM在性能上并不比SQL差，但是前几年，我真的不敢ORM，因为那时候它真的糟透了了

编程需要经验 很多代码都是Magic

@jerryouyang web.xml当然所有java ee web框架必须有啊， 这个是servlet规范。
你说的当然也会问， 熟悉什么就问什么，只要说的清楚就行。 总之， 我们想要了解的是：他是否知道最擅长的东西的日常工作是怎么做的，以及他过去是怎么做的。　
那个题目的具体形式是：用你习惯使用的方式做一个用户登录页面， 无所谓连不连数据库，无所谓页面美化，但是要在服务器上可运行。

楼主你就知道自己代码一定很美？给别人指出来呗。你自己觉得自己代码好看人家说不定觉得是一坨屎捏

一，搞清楚作者在解决一个什么样的问题（比如基础工具类，长期内都不会再有人修改或维护）
二，搞清楚作者有没有完好的解决这个问题（没有逻辑漏洞，没有性能或安全问题）
三，搞清楚项目的平均代码水平（是不是整个项目大部分代码风格都是这样的）
四，搞清楚项目的未来计划（是不是这个项目很快就会被新的项目替代）
五，搞清楚时间作者的时间成本（是不是被要求在极短时间内写出来的）

作为一个开发人员，上下文这么关键的东西都没有给出就来提问，想来楼主的逻辑思维能力也还有飞跃性的提升空间…

框架？之前没有怎么办？难道是凭空飞出来的？上帝给的

代码经验是时间堆起来的，要真正喜欢才会想去优化，像艺术一样完成它

我觉得你们可以找个空闲时间，互相看看对方的代码风格，然后尝试写写，都互相感受一下

算法好，代码写的差不是很正常？
人家只需要论证一个模型的可行性，接下来都是码农的活。好吧，有些抬杠了，只是想说，如果真热衷算法的，代码差是正常的，人家是搞研究的，码代码只是实现这个模型的需要。研究所里一般将这类活交给各导师的学生去实现。

说起框架，明确说，7、8年经验的老码农，对新框架的熟悉程度一般不如1、2年经验的新手，更甚者自备一套自己的框架，用不用框架是要看你实际需求。

另外，别否认了，拿出昨天自己写的代码，今天看也是一坨屎，影响判断的有很多外在因素。

话说太多，也不如代码直接 show 出来，描述一下需求，环境，让大家瞧瞧是否真的烂。

在一些场合,SQL和JDBC的这套, 反而可能是更适合的. 最近的一个项目中, 在进行性能调优的时候发现, SQL和JDBC的性能比Spring Batch的要好...

另一个问题确实也有其他人提到, 面试时候所展现的能力和实际工作的能力还有很大不同....

综合起来看, 只要技术水平在平均线上, 负责肯干的话, 一般以后的工作中都不会拖后腿

这个问题暴露了楼主喜欢钻研新的技术甚于解决当前的问题。多学几门框架和语言不能提高你代码的质量。解决问题的思路或者说建模，才是一个程序员最重要的能力，这个能力从这个问题的角度体现在如果现有的框架和技术能解决当前的问题，就绝对不会冒着风险去学习新的框架和技术。ps：好代码真的存在吗？

如果不是通篇不用花括号,变量随便写甚至签名到处有的代码一般也没啥,
原生SQL有何不妥?ORM能降低日后维护的难度么?试试做企Z业F项目?三天两头改需求,我宁可一个个项目重新封装一个API类也不写ORM.

另外新特性新框架有考虑过后续维护人员的感受么?
(我们经理说: 你走了项目就没人会维护了,以后还是别这样写了.)

PS. 注入问题在PHP+MYSQL组合中用PDO解决...暂时看着没啥问题,不知道大家有何看法.

写的不够多吧。
另外，可能风格问题。

一个人很懂建筑，为什么砌墙还是东倒西歪。

@WhatIf 还可以google那做不出来的估计还是换行吧。

学习好！=技术好！=能力高

这个还是和情怀有关吧，粗线条的人不在意细节，也或者吃亏不够多。

基础好不是绝对。而是实战经验让他根本都没思维和如何提高自己，得过且过的绝对不会基础好

先说说反面，楼主你认为他不好的地方可能并不是他不好，可能反而是你错了。例如写原生sql可能没什么问题，反倒是滥用ORM我认为会增加程序复杂性。有许多场景代码是根本没有可移植性的，用了ORM也移植不了。basic方式也有简单的好处，这个不能一概而论。
再说说正面的，楼主确实说得是，这个概括地说就是工作的态度问题。其实工作方法是最容易教的，反倒是态度基本很难改。工作方法你一说，他一听，再做一遍，新算法他就会了。他会了他就不用，为什么呢？其实这个好理解，他为什么要花费训练成本去使用新方法呢？旧方法一样能用啊，还省训练成本。工作从来不是大多数人的追求，绝大多数人追求吃、喝、玩、乐，楼主你下班回到家干什么，下班后到家每天的娱乐活动是加班吗？想必不是吧。大多数人对工作是不求好的。你怎么能让一个下班后不工作的人下班后去自愿工作呢？基本不可能，人家追求就不在这。
程序员的根本追求是什么？就是不写程序，还拿薪水。编程这项工作是很难量化的，程序员写烂代码难以被考核，编程这项工作是有这种养烂程序员的土壤的。
我刚开始实习的时候，我所在的项目组一共3个人，一个我无实际工作经验，一个2年经验的程序员，一个2个月经验的实习生，我去的第二个星期我就贡献了全组80%的代码。其实你、我这种人才是少数的奇葩，烂程序员（主要是态度烂）才是多数人的常态。

你说的什么语言啊

推荐《代码大全》