3哪个语言更好，更有用，应该先学？C，C++，java，Csub，python，PHP，VB?
我们知道，我们要装修房子或维修家电，我们需要一种神器，钳子。钳子有很多种，管子钳，尖嘴钳，钢丝钳，剥线钳，还有我们
常见的网线钳。
那么。这些钳子中哪个最重要，哪个最有用，哪个更高级，哪个钳子是所有钳子的基础呢？哪个钳子能替代其他所有钳子呢？显然
，哪个都不行。
那么你该学习哪一种钳子的使用呢?显然，如果你毕业以后如果确定你要成为一名电工，那么剥线钳和钢丝钳最适合你。（我瞎猜的
哈）
但现在我们的问题是，谁能确定毕业以后应该从事哪种职业呢，那么没办法，我们只好从最基本的钳子开始学，因为发明那些钳子
的大神以前都是用最基本的钳子出身的，所以我们学这种。
不一定就是对，但应该不会错，仅此而已。
所以，争论哪种钳子最有用没有任何意义，你是程序员，是因为你具备编程的思想，而不是因为你会哪种语言，那些都是工具，是
你手里的钳子。只要你有思想，遇到什么情况，使用哪种钳子，哪怕这种钳子你之前没用过，拿起来，研究研究，用，就好了。
我国某大型通讯企业 华东区 某位面试官 很喜欢问 哪个语言好 这类没正型的问题，他这样问有三个原因
1 他想知道你对你主语言优点的了解。
2 他想知道你对你的主语言外其他语言的了解。
3 他脑子有点问题，大学时候因为这个事受了点小刺激。
所以，初学者争论哪个语言更好这类问题是挺好的一件事，争论才能加强理解嘛。入职第二年还在争论也正常，刚工作，体验到语
言的精深之处了嘛。但是如果第三年还在争论，那可能就需要一些帮助了。
当然，对刚入行的你，绝大多数程序员朋友在工作第一阶段使用哪种语言不是自己决定得了的。
记住，当你不再讨论哪种语言更好更优雅更有用应该先学之类问题的时候，也是你开始有权参与讨论当前项目应该使用哪种语言的
时候。
4 程序员加班多吗？累吗？
这个我觉得大家挺关心的，以自己的经验来说说。
软件工程师这份工作，至少我工作那时还是说出去挺好听的。尤其是父母那代人里，一听，弄高科技的嘛:),当然现在差点了。
这行到底加班多不多其实也没个共性，同一个行业有的公司天天加班，有的公司按时下班。同一个公司这个组就加班，那个组就按
时下班。同一个组这段时间就加班，那段时间就不加班。这个其实跟活多活少，直接领导的风格都有关系。
以我来说，我跳过一次槽。刚毕业那个公司加班比较少，有忙的事时候加班，一个月大约到不了五六个小时。
（为让大家理解，程序员正常不加班的平均月工时是 21.75天 * 8小时 = 174小时上下 年假少算的话大约 180）
后来我跳去的公司，我们被组成一个特别小组参与一个项目的攻关。这个项目还是非常有难度的，最开始我们只有20个人，大约要
理解和维护600W行代码。那段时间是我职业生涯最痛苦的，每天工作到1点左右，持续大约四个月。那时每月加班大约120个小时左右。
最高似乎逼近过200个小时。这就相当于一个人干两份活了。万幸我们的加班费制度很完善，所以那段时间有一种打网游刷钱的感觉啊。
那段时间的努力没有白费。我们的能力，就是从那时开始被领导认同的。后来我们组建了一个部门，200人左右来维护这个项目，最
开始那批人熬住没走的就成了骨干和干部。这时人也多了，项目就不那么紧了，除了一些喜欢下班后工作的家伙（这样的不少），我们
的加班大约保持在10-70个小时都有，以后就开始持续降低。我一般认为10-20个小时就算比较正常可以接受的。
这时，以之前狂加班的兄弟为骨架的部门，加班后遗症开始显现。这种后遗症困扰了我近两年。这个我就不多说，这就涉及到很多
项目管理上的知识了，不在我们讨论之内。
当然，码农俗话说，忙半年闲半年。即便是在忙的时候，也免不了大家在一年中有那么几个月大眼瞪小眼无所事事晚来早走闲着难
受满院乱晃的岁月，这是软件生产的流程决定的，不知道别人是不是都这样。
PS:如果让我一直设计和编写代码，有时真的觉得时间过得飞快。真有时恨下班时间太早，想再干一会等到看结果，这不是无聊鸡汤
吹牛X,大约是一种职业病吧，我爱这个职业，也是因为这个。
再PS:其实我已经有半年没有加班了。
再再PS:我们这边对代码量要求算不高不低，C/C++200行一个月，java项目（主要是安卓）300行左右（这个有的部门标准使我们的N
多倍，N大于20），OC我接触他们那边少，不过也就两三百的样子，多的时候也过不去两千。基本上，一百人的团队，一个月产量过五万
行效率就挺高了，过十万就是比标准速度快了一些了，过三十万，技术主官就会奇怪的问，怎么你们现在写代码都不需要用脑子了吗？
如果你这个月的工作内容只是写代码，而不需要过多思考，完成一个月的工作任务大约一个小时左右吧。当然CV超人们不包含在这个数
据中了。
5 文档和编码规范
程序员最讨厌是四件事：写文档 写注释 没文档 没注释
其实一句话，文档是程序员工作的一部分，很多时候比代码还要重要。当然也许你会辩驳说文档不是程序，文档不是最终产品云云。
那我们说的现实点，假设情况很极端，代码好文档不好的程序员通常比不上文档好的兄弟升职快。代码好文档不好的组也没有文档好的
组效益高。我和大家一样都不喜欢这个现象，但这是事实。
另一个角度说，文档不好，就意味着项目流程不好，也可以理解为项目经理对项目的掌控性不高（也有可能是特别高，这是特例），
这样的情况下基于项目的协同性，节奏感考虑，这个项目的质量一定不会高。项目规模越大越是如此。当然这个又扯到管理上了。从开
发角度说，写文档注释哪怕只是给自己看，没坏处，这个早有论断了，咱就不讨论了。
至于编码规范， 我大学的时候曾经特别喜欢C语言混乱代码大赛的那个输出歌词的著名代码，并真的一字一行的把那个代码解析了
出来。直到上班快两年了，才明白写代码别人不认识并不叫什么本事。
你所在公司的编码规范建议你务必遵守，往小了说，良好的格式方便阅读。往大了说，避免很多错误。例如功能宏有do while(0)包
括，有if就一定有else，一行代码只做一件事，数字写在==的左侧（这个我总忘），不要使用递归等等等等。还有无论你对运算符的顺
序多么的了解，请使用括号，如果你的笔试题这样写
a+++b或者 r = a+ 26 | b * abc(c);
如无特殊情况，你会被无情的淘汰掉。可能你对优先级烂熟于胸，但大家都不会犯错，我会选那个用括号的。因为他更安全。记住任
何炫技的行为都可能带来灾难性的后果。
我说的特殊情况是指，如果两个女生面试，一个有着高超而又危险的技巧，一个拥有稳定又良好的规范。那么我想大家会毫不犹豫的
，选择胸大的那一个。
哈哈，玩笑，两个女生竞聘一个程序员岗位的事情实在是比较少见啦。当然，决没有歧视女程序员的任何意思，我们首席技术官和以
前一手带我的老师都是女的.....
|
收藏
淘帖
踩
