php怎么调试行数，程序员上班一天得写多少行代码？
你们这些程序员们，真得每天都在读代码吗？多数人阅读代码的数量远远不够。难道程序员的日常，都只在读代码吗？
其实，一名程序员每日工作是这样的：大部分的时间是来改代码，写代码和看代码。有人说好的程序员每天能写出20行有效代码，就是世界级水平了，也有人说真正的程序员每天至少能写出100行有效代码才算是一名好的程序员。那么，一名程序员，究竟一天需要写多少行代码呢？
来自 CSDN 论坛的程序员们说：
每天精华代码是 1 行。代码不在多，而在于精简、高效、美观。真正优秀的程序员都拿着高工资，其本上不用怎么写代码，如果你还拼命在写代码，说明离“优秀”还有一段距离。每天把 1000 行代码减少到 100 行。很多时候都在分析问题，查看代码，写代码越来越少了。如果写的话，基本上每天 100 到 200 行，但是更多的时候在开会、开会、开会。来自知乎的程序员们说：
无须看重代码行数，程序员的价值在于思考，而不在于打字数量。真正写出来可用的代码，一天平均几十行就很好不错了。我通常是一天不到 100 行。负的。我们不生产代码，我们只是 GitHub 的搬运工。最多的时候，一个礼拜写了上万行代码，那时候每天睡觉都很香，因为累！比尔盖茨曾说过：“用代码行数来衡量程序的开发进度,就好比用重量来衡量飞机的制造进度。”近期，Google公司的AdMob全栈工程师Raymond Farias发表评论表示：“以Google工作中最有效率的一个月为例，使用Google的一款内部工具，即可以查看每天的代码增量（包括添加、删除、更改的代码行数），并根据以往的调查证明，一名高效的工程师每天能写100-150行代码。”
Google大约有4万名工程师，而在这些工程师中有些人代码产出量比较少，因为技术经理或者主管因为很多的会议或者假期并不会写太多的代码，因此，一位工程师一天100行代码，应该是最为准确的数据了。
而在国内对于一些熟练的程序员，每天需要100行代码才是正常的生产率（包括需求分析，设计，编码，单元测试和系统测试）。当然，对于缺乏编码经验的毕业生或转型的从业者来说，每天代码产出量也须另当别论了。你认为呢？
如果程序员以代码行数领工资会怎么样？
按行计费也就是回车键的灾难！
尽量自己写代码，不用系统函数和框架的功能模块，能分开的代码就不去复用，通用函数分开写，一个函数就完成一个简单的功能，绝对不复用。
和现在的编程思维趣向完全不同了，能自己干的都自己干，debug的时间大大延长，即便这样也是bug满天飞。
但是，一旦代码开发出来效率比较高，代码长度大大缩小。
8090年代的开发基本都是裸代码的开发，所以那时的代码个头不大，效率比较高，不像现在一个不大的项目，运行空间要求很高。
效率高的一个例子，Foxbase盛行的年代，数据库的效率基本没有太多的办法，但是自己开发一个mini数据库，专用的，速度提高的幅度是10倍的基数，多可怕的提高，当然开发难度的提高也是10倍的基数。如果按行计费开发成本也就大大增加了。
写了100万行代码的程序员是什么样的程序员？
程序员写了100万行代码就会变得很厉害吗？其实不然，衡量程序员厉害的并非是你写的代码多少，得看你是什么类型的程序员。下面先说说常见的几种程序员的类型：
1.COPY侠
复制粘贴别人代码的程序员并不少见，一方面是因为懒，另一方面也是确实没思路。所做的事情也就是从网上他人的代码里拷贝片段，放在项目中跑通了，这个任务也就完成了。
其实copy侠对编程没太大的兴趣，久而久之他们仅有修改代码的能力，却不会写代码。之所以干这行主要是以此养家糊口，并没有什么职业理想。
2.新手上路
有句话叫：现学现卖。
加上程序员本身就是个需要长期学习的职业，很多新手在接触到项目的时候，并不完全知道要如何实现这个功能，这时需要通过学习、寻找资料等方式来解决问题。
所谓的新手上路，程序员的目的是“完成功能”，解决目前所面对的问题。在这种工作状态下，很多程序员都是十分被动的，因此也很难有多余的时间去考虑边界条件、性能、可扩展性、编码规范等问题，因此代码bug可能比较多，稳定性不高。可能常常会出现这种情况——编程2分钟，寻找bug2小时。
3.学习选手
相较于上一种程序员，这类程序员对所在领域的语言已经比较了解，对于一般功能可以有较为清晰的实现思路。当他们接到需求时，能够通过自己的思路来实现，而且会在一定程度上考虑边界条件和性能问题。当然，他们对可读性和可扩展性考虑很少，也没有项目级别的考虑。
学习选手最大的表现在于喜欢“创造代码”，即使有现成的实现，他们也希望自己来实现一套，以达到“学习”的目的。他们不喜欢复用别人的代码，看见项目中别人实现了相类似的功能，他们会以“需求不同”的借口来自己重新实现一套。这类人一般来说对技术有着较为浓厚的兴趣，希望能够通过项目来进行学习。
兴趣是最好的最好的老师，学习型的程序员如果能坚持在技术上的尽头，将有可能成为技术牛人。
4.实现牛人
一般来说，实现型的人才都有十分丰富的经验，俗话说程序员必须得写够百万行代码。熟能生巧，因此不再追求“创造代码”来进行学习，同时对所在领域的相关东西十分熟悉，因此对需求和项目都了然于胸，他们可以快速实现需求功能，因此也是别人眼中的“技术牛人”。但他们一般仅仅停留在“完成功能”级别上，对代码的可行性、可扩展性、代码规范等等考虑较少，对项目总体的把握也较少。
大牛一般都有这样的习惯，对于开发有着足够的热情，但对于维护则不太上心。他们产出的代码最大的问题在于维护成本，可能前不久写的代码过段时间再看就会晕头转向。
5.架构把控
这类程序员比上一类型的程序员更进一步，他们经验十分丰富，对相关框架和工具的熟悉程度很高，“完成功能”、“性能”、“稳定性”这些已经不再是他们的追求，更完美的代码、更合理的框架才是目标。
对比上一种类型的程序员，他们的优势在于整理把控，在工作过程中尽量把握代码命名、注释及逻辑分离，保证可读性，也就是说尽可能的保证项目的可持续发展。但正是由于他们的工作方式，可能在“实现阶段”来看速度会慢于“实现牛人”，他们的优势只有在项目后期才会慢慢体现出来。
当然，作为优秀的程序员必须要懂逻辑，其次还有足够的分析能力和自学能力。在学习的过程中不断培养技术能力，同时扩展自己的视野，从项目的整个流程去着手考虑，将会拥有更加开阔的职业天地。
所以讲真，程序员写百万行代码实际事件正常不过的事情。
Mysql怎样优化处理？
1. 避免使用 select * 你需要什么信息,就查询什么信息,查询的多了,查询的速度肯定就会慢
2. 当你只需要查询出一条数据的时候,要使用 limit 1 比如你要查询数据中是否有男生,只要查询一条含有男生的记录就行了,后面不需要再查了,使用Limit 1 可以在找到一条数据后停止搜索
3. 建立高性能的索引 索引不是随便加的也不是索引越多越好,更不是所有索引对查询都有效
4. 建数据库表时,给字段设置固定合适的大小. 字段不能设置的太大,设置太大就造成浪费,会使查询速度变慢
5. 要尽量使用not null
6. EXPLAIN 你的 SELECT 查询 使用EXPLAIN,可以帮助你更了解MySQL是如何处理你的sql语句的, 你可以查看到sql的执行计划,这样你就能更好的去了解你的sql语句的不足,然后优化语句.
7. 在Join表的时候,被用来Join的字段，应该是相同的类型的,且字段应该是被建过索引的,这样，MySQL内部会启动为你优化Join的SQL语句的机制。
8. 如果你有一个字段，比如“性别”，“国家”，“民族”, “省份”，“状态”或“部门”，这些字段的取值是有限而且固定的，那么，应该使用 ENUM 而不是 VARCHAR。
因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。
9. 垂直分割 将常用和有关系的字段放在相同的表中，把一张表的数据分成几张表 这样可以降低表的复杂度和字段的数目，从而达到优化的目的
10. 优化where查询
①. 避免在where子句中对字段进行表达式操作
比如： select 列 from 表 where age*2=36; 建议改成 select 列 from 表 where age=36/2;
②. 应尽量避免在 where 子句中使用 !=或 操作符，否则将引擎放弃使用索引而进行全表扫描。
③. 应尽量避免在 where 子句中对字段进行 null 值 判断
④. 应尽量避免在 where 子句中使用 or 来连接条件
11. 不建议使用%前缀模糊查询,这种查询会导致索引失效而进行全表扫描
例如LIKE “%name”或者LIKE “%name%这两种都是不建议的.但是可以使用LIKE “name%”。
对于LIKE “%name%,可以使用全文索引的形式
12. 要慎用in和 not in
例如：select id from t where num in(1,2,3) 建议改成 select id from t where num between 1 and 3
对于连续的数值，能用 between 就不要用 in 了
13. 理解in和exists， not in和not exists的区别
很多时候用 exists 代替 in 是一个好的选择：如查询语句使用了not in那么内外表都进行全表扫描，没用到索引，而not exists子查询依然能用到表上索引，所以无论哪个表大，用not exists都比not in要快。
select num from a where num in(select num from b)
建议改成: select num from a where exists(select 1 from b where num=a.num)
区分in和exists主要是造成了驱动顺序的改变（这是性能变化的关键），如果是exists，那么以外层表为驱动表，先被访问，如果是IN，那么先执行子查询。所以IN适合于外表大而内表小的情况；EXISTS适合于外表小而内表大的情况。
关于not in和not exists，推荐使用not exists，不仅仅是效率问题，not in可能存在逻辑问题
14. 理解select Count (*)和Select Count(1)以及Select Count(column)区别
一般情况下，Select Count (*)和Select Count(1)两着返回结果是一样的
假如表沒有主键(Primary key), 那么count(1)比count(*)快，
如果有主键的話，那主键作为count的条件时候count(主键)最快
如果你的表只有一个字段的话那count(*)就是最快的
count(*) 跟 count(1) 的结果一样，都包括对NULL的统计，而count(column) 是不包括NULL的统计
技术交流请关注“大数据java架构师”
如何才能写出高质量的代码？
作为一名java开发工程师，对于这个问题我算是比较有感触的，所以想说说我对java开发的一些看法，纯属个人意见，不喜轻喷！
什么样的代码算是高质量代码，或者说是高质量代码的特征？在我看来，主要就是在于可读性、易扩展两方面。
首先，我觉得最重要是要可读性高。为什么这么说呢？相信做过开发的朋友都知道，互联网公司的人员流动率还是比较高的，可能出现的情况是领导突然跟你说，你去交接一下某某某同事的工作，而交接的时候一般情况主要是业务流程、功能模块来交接，大概率不会一行一行的代码去读。如果项目正常运转，不出问题、也没有需求变更（大概率需求会变更），那就是你好我好大家好，如果出了问题或者需求变更，还是之前同事的那些模块，那就必须得去啃代码了。这个时候代码的易读性就显得非常重要了。你可以试想一下，通篇没有一句注释、一个方法几百行、if/else满天飞、方法之间参数传递全是map、sql语句各种嵌套子查询、关联查询7-8个表，当你看到这样的代码，估计心里顿时万马奔腾，怒火蹭蹭蹭的往头上涌去。所以我觉得可读性是第一要素。
其次，扩展性要好。这个也很好理解，现在是信息时代，流量为王，为了提高市场占有率，普遍需求变更频繁，2周一次发布都是正常频率。在这种频繁需求变更的情况下，如果代码的扩展性不高，每一次需求都需要大量改动代码，即耗费时间还容易出错，比如漏改某处地方而引起其他功能异常。所以开发过程中要注意代码扩展性，当然也不要去过分设计，让代码晦涩难懂。
高质量代码在开发中的意义？《计算机程序的构造和解释》一书提到代码是写给人看的，不是写给机器看的，只是顺便计算机可以执行而已。如果代码是写给机器看的，那完全可以使用汇编语言或者机器语言(二进制)，直接让机器执行。所以代码一定要让人容易理解。高质量代码的好处：
好的代码读起来令人赏心悦目，比如java里的spring、mybatis等框架，读源码时常常不自觉发出惊叹，代码原来还可以这么写！
质量高意味着维护成本低，运行稳定
质量高意味着扩展性强，方便业务开发
如何去写高质量代码？对于做java的来说，我建议去看一下《阿里巴巴Java开发手册》。
手册以 Java 开发者为中心视角，划分为编程规约、异常日志、单元测试、安全规约、MySQL 数据库、工程结构、设计规约七个维度，再根据内容特征，细分成若干二级子目录。根据约束力强弱及故障敏感性，规约依次分为强制、推荐、参考三大类。对于规约条目的延伸信息中，“说明”对规约做了适当扩展和解释；“正例”提倡什么样的编码和实现方式；“反例”说明需要提防的雷区，以及真实的错误案例。 摘自《阿里巴巴 Java 开发手册》最后推荐一下阿里巴巴代码规范扫描插件，以IDEA为例，安装如下
使用如下：