哈尔滨权威做网站,海外推广工作怎么样,怎么和客户推广说网站建设语,c 用mysql做的网站转自#xff1a;http://blog.csdn.net/B9Q8e64lO6mm/article/details/78829370 最近同一部门另一个项目组的一位程序员被“主动离职”了#xff0c;虽然我未曾与这个程序员共事过#xff0c;但是听过一两次他的内部分享#xff0c;感觉技术还是挺厉害的。后来与一个消息灵通…转自http://blog.csdn.net/B9Q8e64lO6mm/article/details/78829370 最近同一部门另一个项目组的一位程序员被“主动离职”了虽然我未曾与这个程序员共事过但是听过一两次他的内部分享感觉技术还是挺厉害的。后来与一个消息灵通的同事聊天才知道真正的原因是老大觉得A难以沟通搞得其他程序、QA都怨声载道。工作这些年身边的好多同事来了又走了主动或被动这不禁让我思考什么样的程序员算得上合格的程序员。 虽然大家都自称“码农”、“IT民工”但我相信这仅仅是自嘲或者自黑大多数程序员应该还是认可自己的这个职业的当然我算不上一个优秀的程序员因为我都不曾在开源社区贡献过代码、也不精通白板算法、对技术也不狂热、不geek。我的目标是做一个合格的程序员把本职工作做好对得起自己的薪水在生活与工作平衡996什么的我是难以接受的。 对于程序员而言技术过关当然是非常重要的这是硬实力。然而只会技术也是不行的毕竟大多数的程序员还是要与人打交道软实力也是不可或缺的。怎样才能算合格我认为有以下几点 扎实的基础 计算机领域是一个快速更新换代的领域每隔一段时间都会有新的语言、框架、思想产生追随每一个新技术很累。但仔细想想事实上并没有那么多新东西。很多新东西只不过是已有技术的封装、或者借鉴的其他领域的技术。比如缓存数据库redis、memcached其基本思想不就是操作系统中的缓存吗分布式存储中的分片与复制集不就是文件系统中RAID的扩展吗还有Google的MapReduce框架不就是来源于函数式编程语言的map reduce吗。掌握好计算机基础知识能够更本质的看待新技术。 善用工具 磨刀不误砍柴工打造好自己的工具集非常重要。 开发中会用到大量的工具不管是编辑器、调试工具还是监控工具。大家都喜欢争论哪个IDE更好然而这并没有多大意义关键在于能够熟练的使用自己喜欢的工具掌握各种快捷键高度自定义这样能够大大提高工作效率。而且对于日常中重复的操作最好脚本自动化这里推荐以下python写小工具还是很快的。 另外强调程序员必备的两个工具那就是浏览器和VPN。后者大家都懂的不多说主要是有了后者才能发挥浏览器的威力。浏览器大家天天都在用但是如何高效的使用比如在指定网站搜索、通过标题、url过滤、选择合适的关键字 还是值得研究一下对于程序员要使用好浏览器那还得具备下一个能力英语 过得去的英语 不得不承认在软件创新领域国内还是落后于国外的新的技术、一手的资料都是英文的。当新技术被广泛应用之前我们在百度搜到翻译要么是machine translated要么错误百出。看翻译的最大问题取决于翻译者本身的水平即使翻译水平都很高但同一个单次往往有不同的翻译导致看文章的时候会有困惑最好还是直接看英文原文。大多数原文除去专业词汇、还是比较好理解的而且我发现很多牛逼的项目都有非常通俗易懂的文档。 良好的编码习惯 代码是写给机器执行的同时也是给人阅读与维护的。维护者可能是别人、也可能是几个月后的样子。良好的代码规范必要的、清晰的注释可以让自己少被问候祖宗十八代。 对于代码风格网上争议也很多最重要的是保持项目内的统一。做为技术负责人一定要在项目开启之初就顶号规范当大量代码被堆出来之后就很难统一了然后做好新人的review。 保持学习 程序员这个职业相比其他职业可能还是要年轻许多。特别是在国内最老的一批程序员好多都转管理了再过10年20年我们会怎么样呢没人知道。前段时间华为35岁程序员被离职的事情给我们敲响了警钟悲哀之余只有尽力学习了拼不过体力就拼能力与经验吧 学习这个事情说起来就复杂了我觉得两点很重要基础、学以致用。 独立思考 合格的程序员解决的是问题而不是实现某个解决方案。产品经理特别是知道一点技术的产品经理的某个需求可能只是某个问题的解决方案他认为这个方法可以解决他的问题于是把解决方案当成了需求而不是真正的问题。程序员应该主动沟通多问几个为什么了解真正的问题也许能有更好的解决方案。 之前就有这么个例子给到的需求为每一个用户用户有唯一的id标示生成一个唯一的邀请码同时也要为未来一段时间可能增加的用户预生成邀请码保存到数据库。而真正的需求是老用户分享自己的邀请码如果新用户使用了该邀请码则老用户获得相应奖励。而我提出的方案很简单直接用户的唯一id生成可逆的邀请码这样就根本无无需数据库存储。 产品经理经常改需求这是程序员最头疼的事情作为程序员应该也站在PM的角度思考帮助PM分析出本质的需求这也许可以减少需求的变更。当然前提是得干一行爱一行需要对业务有一定的了解。 先思考后行动 下笔而不是先写出一堆代码然后在开始修bug。 休bug的时候多看看上下文搞明白为什么出bug修改这个bug可能带来的影响然后再修改。反面教材有两种第一种随便改改就把代码改好了但自己心里并不清楚为什么这样修改就修好了撞运气也许还有其他同样的bug也发现不了。另一种就是头痛医头脚痛医脚不仔细评估修改的影响这样往往会引入新的问题。 程序员成长的一个办法就是修bug修别人用不了的bug但前提是搞清楚bug的缘由这样才能避免类似的错误有所收获。 顺畅沟通 不是巧如舌簧、也不是忽悠达人。需要的只是耐心倾听然后清晰表达自己的意见。 现在的软件开发已经不再是单打独斗的年代大多数的软件、产品都需要多人、多部门的协作。而交流、沟通是非常耗时耗力的。沟通之前先想好目标组织好语言尽量不要发散、不要跑题对事不对人。对于重要的事情保留沟通记录最好有邮件免得说不清。 沟通是门复杂的艺术最基本是听明白、说清楚。 管理好自己的暴脾气 作为 一个程序员要被PM怼、要被交互怼、要被QA怼再变态的需求都可能有QA给你提的BUG可能也不属于你。而且还有猪一样的队友自己在别人眼里何尝不是这样呢和下属。不管谁是谁非发脾气、吵架都一点用没有吵完还是得解决问题。calm down有怒火也得等个几秒再发作也许这几秒理智思考一下就能解决问题。 负责任 能力技术能力与责任心谁更重要呢都重要。如果一个新人有培养的潜力那么责任心就更重要。两个人第一个技术能力很强但责任心很差对项目的事情也不上心第二个能力差些但责任心强是自己的问题一定负责到底即使自己不能解决也能主动询求帮助。我觉得前者对项目的危害更大特别是项目紧要时期因为能力强的人一般负责的是比较复杂、困难的功能别人上手也需要时间这个时候如果摞担子bug也不修那么就很为难了。 不负责任的典型表现就是扯皮、甩锅这不是我的bug、不关我的事。有协作的地方更容易出现问题比如前端与后端、各个部门之间。如果不清楚到时是谁的问题不妨主动一点帮助排查。 不要总是说不会 作为程序员总有一些工作是以前没有做过的也许来自产品人员的需求也许来自项目自发的优化。我见过一些程序员在面临未知的问题、挑战时总是习惯于说不会、没办法、不可能这样的程序员就算不上合格的程序员。事实上这样的程序员是给自己过早地留好退路事实上问题可能并没有想象得那么困难也许经过一番探索就能解决。如果习惯于对未知说不那么在别人看来就是能力不行影响个人形象与声誉而且总是待在自己的舒适区也不利于自我成长。 当然也不是说要盲目自信急于拍胸脯保证一定能解决这样往往是坑自己。 所以面对新的需求谨慎对待既不轻易否决也不随意承诺而是再理清需要先去研究一下评估是否能完成需要的资源与时间。 暂时就想到这么多当然我也还不达标比如容易控制不住自己的怒火与君共勉吧
