java代码洁癖 java程序代码

JAVA就业薪资是多少

以北京为例，对JAVA工程师岗位的平均工资、不同工作年限的收入水平进行分析对比，供大家在择业、就业的时候参考。

         

在上图中，北京Java工程师平均薪资为14830/月，取自63979份样本，较往年，增长18.5%。

其中月薪在10K以上的人群占72.7%。在薪资达到10K以上的人群中，20K-30K的人占比最多，达到了24.9%。

         

由此图我们可以看出来，北京Java工程师工资按工作经验统计，其中0-2年工资¥12690，应届毕业生工资¥6680，3-5年工资¥16090，6-7年工资¥23260，8-10年工资¥22030。

北京Java工程师就业形势分析：

在招聘待遇中，工资20000-29999占比最多，达40%。

在经验要求中，3-5年工作经验要求的占比最多，达66%，0-2年工作经验要求的占比达到了20%。

在学历要求中，本科学历要求的占比最多，达72%。

相关问答

Q1: java 编码要注意些什么

认真谨慎java代码洁癖，按照JAVA代码编写规范。看起来清晰明朗java代码洁癖，别让人看起来像一堆杂草一样。

层次结构要清晰java代码洁癖：MVC模式。

代码要优化，别一个资源用java代码洁癖了下一次调用又产生一个同样的新资源造成资源浪费，这样服务器吃不消。

还有数据库连接一定要配数据源和数据池，常用的要写在缓存中，免得数据库压力太大。

能用框架就用框架，别傻呼呼的别人已经写过了的，你又重复写。

Q2: Backbone.js 的最佳应用场景有哪些

Backbone 最适合的应用场景是单页面应用java代码洁癖，并且页面上有大量数据模型，模型之间需要进行复杂的信息沟通。Backbone 在这种场景下，能很好的实现模块间松耦合和事件驱动。 其他适用产品还有微博，网易微博的前端设计也是和 Backbone 类似的一个结构。

Backbone 的优点和一些经验 Tipjava代码洁癖：

View 的划分将页面上的视图元素解耦，粒度细化。View 间通过事件和 Model 通讯，避免java代码洁癖了 DOM 事件的滥用。

Model 和 Restful 的通讯方式对于后端人员非常友好。

MVC 架构清晰， 我有个常年写 Java 没写过 JS 的同事看 Backbone 很快就java代码洁癖了解了整体设计，虽然这时候他还是不会写 JS。

Collection/Model 抽象了以前杂乱的 AJAX 请求，CRUD 请求变得非常非常方便。

强烈建议 View - Model 单向依赖，世界会美好很多。

配上一个模块化加载器例如 SeaJS 会很爽。

Backbone 的一些缺点，或者说一些尚未实现的 Feature：

Model 层比较简单，如果要支持 One-To-One 或者 One-To-Many 等复杂数据关系时有些力不从心。还有 一个 Model 只能属于一个 Collection 这个设计，页面复杂的时候会很受局限。

Model 只有基本的 CRUD 操作，不能很好的扩展，Backbone.sync 方法写的不太灵活，要想扩展就得重写 sync 方法。

View 层没有很强的 Page 管理机制，比如通过 URL 切换改变整个页面时，页面上尚存的 View 如何处理java代码洁癖？直接销毁的话，是否要销毁关联的 Model、Collection？Cache 住？如何管理 Cache？

内存管理需要比较小心，缺乏机制避免创建重复 Model。

extends override 父类方法的时候得写一串的 SuperClass.prototype.someMethod.apply 什么的，就不能实现个 _super 方法么……

对调试非常不友好。

作者有代码洁癖（也是加分项），this.$el 大家呼唤了这么久才加上，估计今生也看不到 this._super。

更新慢。

总体来说 Backbone 还很轻，框架很漂亮但是有些细节还比较粗糙。用之前要做好对 Backbone 进行大量扩展甚至 Hack 的准备。

Q3: 为什么国内程序员都很少进行代码重构？

说到代码的重构对于国外的程序员提到的比较多，特别是大型的开源工程，基本上一个模块或者函数的实现会反复的修改，一个文件能被修改成千上万次，曾经订阅了linux内核组的邮件，每天的收到的修改文件成千上万，有时候一个文件都能被修改上百次，对于文件修改最疯狂的是google的chrome源码，重构的次数，让你觉得每天都在重写但是功能上感觉越来越流畅。为什么我们周围的程序员绝大部分时间做的不是这样的事情。

为啥从直觉上觉得老外的写的代买质量比我们的要高，我们国内的程序员绝大部分的时间是在赶进度，准确的来讲忙着增加功能和修改bug，其实也从侧面反映出为什么国内出不了android以及Linux等影响深远的 科技 创新，从全球开源代码的占比就可以看出，差距还是很巨大的。

为什么觉得老外写的代码比我们的强？

1.国内软件发展主要阶段还在解决有没有，还远谈不上强大

中国的软件经过近几十年长足的发展，已经取得了巨大的成就，特别在互联网行业已经有几个巨头跻身世界前列了，最近炒的很热的脸书的用户数据泄密事件，作为当事人扎克伯格，也在论述中提到中国有几个很厉害的互联网公司，这说明中国在互联网领域还是取得了相当大的成就，但是在一些核心的领域，或者门槛很高的领域差别还是非常巨大。

任何事情在发展的初级阶段首要考虑的是不是有没有，所以如同创业初期的公司会选择短时间内搞出来个产品，哪怕是不成熟的产品，然后快速的投入市场，根据市场用户的反应同步追踪问题，等到产品差不多稳定，并且产品在市场上有了一席之地之后，后续的事情就要考虑优化功能，对里面的代码或者产品的性能进行全方面的提升，目前国内大部分的互联网一般比较年轻，还在解决有没有的问题，相信随着时间的推移以及国内软件的发展，也会有大量的高质量的开源框架代码出来，但这一切都需要很长的时间。

所以国内的程序员大部分时间都是在赶进度和根据需求完成功能代码。

2.软件产业的底子还很薄弱， 历史 积淀还不够

举个很典型的例子，现在很多国内的程序员到了30多岁就开始考虑后续的转型了，因为后面的轻轻人会带来很大的冲击，所以大部分的30多岁的程序员都在考虑自己后路，都要考虑转型的问题。老的有经验的程序员反而转型去做管理或者合伙创业了，哪有几个还在安心搞技术，年龄大了还在搞技术的还被人鄙视，觉得自己没有出息。

但是在国外写代码是一种很常见的职业，和别的工种没有多大的差异，40，50岁了写代码也是比比皆是，做软件是一种技术工种，经验的占比是很高的，所以老程序员写出来的代码更加有深度，稳定性更高，一切的根源还是产业的发展不够成熟，需要时间和 历史 的积淀，从这方面讲国内的软件整体产业还是比较薄弱，从业人员的整体素质和工作氛围还有待慢慢的成熟，周围都是有经验的程序员在带领着如何去重构代码，如何提升代码的质量，而国内大部分的程序要还是被产品经理鞭策着增加需求和修改代码。

3.公司的文化差异

目前很多的中国技术公司更多的追求的是短期利益的最大化，在基础软件的投入远远不够，毕竟基础的投入很难短期见成效，在一个具体的场景，有一个产品主体的功能已经实现了，也能在用户那边投入使用了，一般的公司很难拿出时间来，让你做代码的重构，毕竟这种事情很难直接产生经济效益。这与公司本身的文化差异有很大的关系，重视的技术或者懂得技术的公司对于这方面相对比较重视，反之就差很多。

小时候课本上就说着我们落后100年，所以高楼大厦不是一天建成的，所以在追赶的道路很漫长，所以承认存在差距，然后努力加倍的去追赶。

Time is money. 以目前国内互联网的情况，需求应接不暇，程序员基本上都是被需求与业务赶着走，时间非常紧张，在这种情况下，程序员很多时候唯一的选择就是赶紧实现需求的功能。所以，一个项目下来，代码基本上都变得非常非常的“垃圾”。

也有很多程序员想过在项目结尾的时候进行代码的重构，基本上每个程序员也都知道重构代码的好处，但是并不代表着真正能做起来。还是那个原因，国内互联网的速度太快，需求应接不暇，做为程序员，基本上没有时间来做这件事情。

而另外一个原因是跟团队负责人有关。若团队负责人能够意识到重构的好处，那么java代码洁癖他可以为此单独划分一段开发时间出来，让大家分别负责一个模块进行重构，这都是可以安排做起来的。这也需要团队负责人如何在需求人员的需求与代码质量的进度上做一个平衡，进行统筹安排。

最后我想说一个可能很少意识到的原因，那就是人员流动问题。国内互联网目前人员流动非常的大，尤其是北上深这样的互联网发达的城市，基本上是平均两年就会走一大波人，在这样的情况下，也会考验从业人员的职业道德，即我到底要把代码写的多好，要把代码的可维护性做到多好，其实这都是从业人员自身需要考验的问题，因为完成一个功能很容易，但是要考虑的全面就是另外一回事了。而人员流动带来的另一个问题就是有一些代码是很难看懂的，即有些代码在人员离开后成为了“ 历史 ”，无人敢动。这也会阻碍着软件的重构工作的进行。

从我所讲的这几种情况来看，重构其实是大家都能知道的好处，但是真正实施起来却又有现实的约束，需要负责人来做这样的统筹安排与推动。

成本太大

大多数软件产品的开发都是经过了很多开发人员的付出，如果进行代码重构需要了解产品、了解框架、了解代码逻辑，这个过程会花费大量的时间和人力成本，对于企业来说，效益是第一位的，与其花费精力进行效益不大的产品重构，不如去承接更多的项目来的实在。

领导决策

由于大部分企业的老板都是非技术人员出身，他们更关注效益和客户，为了符合企业的发展，在进行产品开发时会更多的采用新技术来吸引客户，花费精力重构代码不如开发一套新产品或者开发更酷炫的效果更具有实在意义。

代码规范不足

由于国内互联网较之国外起步较晚，很多企业发展时间较短，加之人员流动比较大等多方面的因素，很难形成标准、严谨、行之有效的代码规范，所以很多技术人员在开发时都是根据个人风格习惯在开发，等其他人接手代码时，缺少相关标准和文档，很难理解代码逻辑，花时间去了解代码、重构代码不如直接推翻重做来的方便。

客户定制化需求

部分企业创业初期对企业信息化是不够重视的，只有企业发展到一定程度才会考虑信息化建设，而由于业务的限制，大多数标准化的互联网产品都很难满足企业的实际需求，需要进行大量定制化的开发，对于互联网企业来说，即使产品开发足够完善，在实际项目中也需要进行扩展，倒不如直接在项目中进行调整。

程序员的发展限定

在国内很少有终身的程序员，大部分都会逐渐转向销售、售前、项目经理、产品经理等岗位，而这些岗位则需要了解业务、了解客户，对技术的需求反而不会太高，所以与其花时间去专研技术不如将更多的精力用在业务和项目层面。

代码能够重构对底层框架要求深度掌握、且代码框架本身要足够灵活，而国内绝大部分技术人员都是停留在对框架的使用层面、少数可以完善、结合使用，极个别的在做同语言山寨或者换一种语言重写，能够对产品体系进行把握、与时俱进扩展实在是凤毛麟角。随着国家的经济提升、IT行业逐渐成熟，在我国这么多IT公司基数下，即便是凤毛麟角的概率，重视基础框架、积累萃取、不断迭代完善的一些技术公司也会慢慢崭露头角、涌现出来的。

【国内程序员很少进行代码重构】，这个现象虽然没有什么调查统计，不过我写了十多年代码，也发现身边的程序员大多数是这样的，【宁可写新的代码，也不愿意重构老代码】。下面我也谈谈自己的看法：

系统没有问题，就是最大的功劳

我见过的大部分的传统行业的软件公司或IT部门是这样的（互联网公司不太了解），“只要系统稳定，那么就是最大的功劳”，而保持系统稳定最好的方法是什么？ 就是尽可能的不要动系统java代码洁癖！

可能很多人不能理解，但很多公司确实是这样，甚至公司对项目的考核标准中，项目有什么突破的权重很低，是否有生产事故的权重很高。所以很多“机智”的项目组成员，千方百计的不接需求，或者把需求推给别的项目组。在这种单位里面，别说重构了，新代码都写的不多。

测试覆盖度太低，重构代码没办法保证质量

代码重构，很重要的一个问题：“重构后的代码谁来保证？如果影响到原有的功能怎么办？”

这时候很有效的一个方法，是使用各种自动化的测试来保证重构代码的质量。

但是，大部分公司，不管是单元测试还是其他的自动化测试，都是不健全的，甚至是没有的。所以只要不是被逼不得已，程序员宁可重新写一个方法，也不愿意重构之前的代码。

其他

进行代码重构不是一件容易的事情，务必需要对需求熟悉；对代码 历史 变更熟悉；对代码框架，模块熟悉；对产品更新迭代做好风险把控，时间成本把控……

进行代码重构需要能力非常高，责任心非常强的人进行，甚至需要一个优秀的团队完成。

为什么要代码重构？理由一大堆，我认为主要有两条，一是原代码已不适合扩展新需求，二是原代码已拥肿不堪，乱七八糟。

为什么很少重构？除了上述分析外，还有其他因素，如人员流动快，原团队原作者早已不知何去何从了。又如需求和业务繁多，完成工作开发都累得半死不活，日理万机似的，哪有时间和心情重构？

谢谢大家。

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 说：

这个功能改一下，

还有这个，界面重新调整一下，

这个业务流，现在不一样了，

客户需求需要多几个功能，

老板说：

这东西下周能出来吗？

Q4: 如何在Centos上搭建PHP+JAVA的服务器

一、需要解决中央控制端到各节点服务器之间的通信。

这个其实牵扯到一个通信协议的问题，各语言都有自己的socket，thread的库，直接调用即可。但是这个通信协议就需要自己来完成了。既不能太简单，太简单了，明码传输，如果别人获知了这个接口，就很容易执行一些令人讨厌的操作。也不能太复杂，太复杂了等于是给自己找麻烦，所以简单的数据包编解码的工作或者用token验证的方式是需要的。通信协议起码要两种，一种是传输命令执行的协议，一种是传输文件的协议。

二、跨语言的socket通信

为什么要跨语言，主控端和代理端通信，用什么语言开发其实无所谓。但是为了给自己省事，尽可能使用服务器上已经有了的默认语言，Ambari前期采用php+puppet的方式管理集群，这不是不可以，puppet自己解决了socket通信协议和文件传输的问题，可你需要为了puppet在每台服务器上都安装ruby。我是个有点服务器和代码洁癖的人。光是为了一个puppet就装个ruby，我觉得心里特对不起服务器的资源。所以我自己写了一个python的代理端。python是不管哪个linux系统在安装的时候就都会有了。然后主控端的通信，可以用python实现，也可以用php实现，但是考虑到对于更多的使用者来说，改php可能要比改tornado简单许多，所以就没用python开发。hadoop分支版本众多，发布出去，用户要自己修改成安装适合自己的hadoop发行版，就势必要改源码，会php的明显比会python的多。php里面的model封装了所有的操作，而python只是个操作代理人的角色而已。

所以也延伸出一个问题，什么语言用来做这种分布式管理系统的代理端比较合适，我自己觉得，也就是python比较合适了，操作系统自带，原生的package功能基本够用。用java和php也可以写agent，但是你势必在各节点预先就铺设好jre或者php运行环境。这就跟为什么用python和java写mapred的人最多是一样的。没人拦着你用nodejs写mapred，也可以写，就是你得在每个节点都装v8的解释引擎，不嫌麻烦完全可以这样干。原理参看map/reduce论文，不解释。perl也是操作系统原生带的，但是perl的可维护性太差了，还是算了吧。

所以这就牵扯到一个跨语言的socket问题，理论上来说，这不存在什么问题。但这是理论上的，实际开发过程中确实存在问题，比如socket长连接，通信数据包在底层的封装方式不同。我没有使用xml-rpc的原因之一就是我听说php的xmlrpc跟其他语言的xmlrpc有不同的地方，需要修改才能用,我就没有用这种办法。最早是自己定义的操作协议，这时就遇到了这些问题，所以后来直接采用了thrift方式。就基本不存在跨语言的socket通信问题了。

三、代理端执行结果的获取

无论命令还是文件是否在代理端执行成功，都需要获取到执行结果返回给中央端。所以这里也涉及一个读取节点上的stdout和stderr的问题。这个总体来说不是很难，都有现成的包。当然这个时候你需要的是阻塞执行，而不能搞异步回调。

还有个问题是，我要尽可能使用python默认就带的包，而尽量不让服务器去访问internet下载第三方的包。

还有代理端最重要的一点，就是python的版本兼容性。centos5用python 2.4，centos6用python 2.6，ubuntu基本默认都是2.7。所以一定要最大限度的保证语言的跨版本兼容性，要是每个操作系统和每一个版本我都写一个代理，我一个人就累死了。

java代码洁癖的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java程序代码、java代码洁癖的信息别忘了在本站进行查找喔。