|
每晚10点，捕获技术思考和创业资源洞察 程序是写给自己看懂，更是写给别人看的，平时要多注意代码规范，养成一种好习惯，起初好习惯是人培养出来的，后来好习惯却能成就一个人。 表妹之前报的是数学专业，想转专业学软件开发，想听听我的看法，原因是我在IT行业里混了有一些时间了，这些年来，每天如同勤劳的蚂蚁搬默默地搬砖。回想起自己刚开始从事编程的情形，感慨万千。我只是一名普普通通的码农，和优秀的程序员相比，真的是自惭形秽。 该不该支持她？先谈谈我对成为一名合格程序员的一点看法。 一、定位问题、解决问题 bug对程序员来说并不陌生，开发中我们遇到的bug，有的其他人也遇到过了，并且修复了分享出来了，这时候我们通过Stackoverflow论坛，或是Google等搜索引擎找到答案。 但是我们在工作中也可能会遇到一些疑难bug，这些bug我们在搜素引擎上找不到解决方案，特别是一些bug无法重现，可能好几天都不得其解。 做移动开发时，有次我就遇到了一个客户反馈的bug，因bug重现不了，定位不到问题，迟迟没有解决而搞得人焦头烂额。 简单描述这个bug：
刚开始怀疑是该类型手机的自身的应用锁功能导致的，后来客户反馈，他的手机只有我们这个应用会出现这样的问题，其他的应用程序正常。 最后重现问题的方法。因为之前给过客户两个不同安装包，虽然是两个不同安装包，但两个包改动并不大。 于是乎，试着卸载手头的手机的最新应用程序，先安装旧的安装包，再安装新的安装包，bug重现了。 通过解决这个bug,让我明白了，对于用户反馈的bug，我们开发者要尽量从自身找问题，冷静分析问题。 实在不知如何下手，请求队友们帮忙，别人的一句无意的话，可能能帮助你解决问题，尽可能少的否认问题的存在。 解决问题是我们的义务。公司请我们来目的只有一个，解决问题。工作中要是遇到困难，这很正常，我们需要做的是主动寻找答案和办法，哪怕办法不妥，也要想法设法去尝试解决，别轻易跟领导说，我不会。 有次听见市场部的领导安排一位同事定一个大会议室，客户下午要来讨论需求。虽然是大公司，但要定个大的会议室是很难订到的，弄不好还需托关系。这个同事问了楼层前台，前台说没有大会议时，被其他部门定了，于是他跟领导说“前台说没有大会议室了，我订不到了”，领导当时就急了，“那怎么办?让我来定吗？还是叫客户不要开会了？” 这位同事在发现自己订不到会议室后，应该做的是自己想办法解决问题，向前台说明此处会议的重要性，看看能否和其他部门协商一下。解决问题的能力是员工最关键的能力。在工作中遇到困难特别正常，在这时，我们有一项义务，就是找到解决问题的办法，而不是制造问题，让领导来抉择。 二、心理承受能力强，承受起压力，承受得起委屈 现在招聘平台对于招聘程序员岗位一般都会附上这么一项：
刚毕业的时候，到一家软件创业公司上班，公司规模不大，加上领导只有6个人。 由于自身基础不扎实，几乎每次挨训的都是我，在团队中我是属于打杂的角色。 一会用PS切图，一会儿用css写样式，一会儿用jQuery写个简单的Tab切换效果，那时候jQuery还是正火，这些活倒是没话说。只是遇到问题时，压力接踵而至，感到一阵阵的无助。 最让我印象最深的是做会员模块时，要实现在线支付功能，得与支付宝、财付通第三方支付sdk对接，在此之前，我对这些一点都不了解。 不怕你笑话，当时心里那个怕啊，虽说专业是计算机软件的，可同学中从事专业对口的的，寥寥无几啊，指望同学指点几乎不太可能。 找同事帮忙也就更不太可能了，他们都很忙，负责的模块也多，当时心里就慌了，要是没能完成任务，岂不是得丢了饭碗。好不容易应聘到的岗位，如果因此就没有了，心不甘啊。 在做程序员前，早就听老师说过，程序员最关键的是解决问题，甭管你之前学没学过，只要在你职责范围内有需求，你都得想法设法把问题处理。 想到这，心静了下来，逐个访问官网，按照官网提供的文档以及官网提供的demo，逐个对接到项目中来，领导安排我做这个模块前， 还特意给我的账号各打了10元，方便调试。 对接这两个，我用了4天的时间，虽然中间遇到一些坑，但还是算完成了任务。 通过查看官方论坛查看别人碰到相似问题的，实在没法就加入官网技术群，找技术支持帮忙。 记得周五那天演示给领导看时，领导轻轻拍了我一下肩膀，说，“不错，流程走通了”。心里甭提有多开心，这次任务给予了我足够的信心，让我继续走程序员这条路。 特别喜欢这样一句话：喷泉之所以漂亮是因为她有了压力；瀑布之所以壮观是因为她没有了退路；水之所以能穿石是因为永远在坚持。 三、养成一种好的编码习惯，该注释要注释 曾有网友调侃：程序员喜欢两件事：
注释的目的不是为了解释代码做什么——可以读取代码!注释目的是为了解释当你写代码的时候是如何思考的。 在写完代码的后面两三个月，可能我们已经不记得上述任何问题的答案，所以，要写下来，为我们后面解决bug提供了重要的线索。 项目维护工作不仅读懂源码，而且还需要在原有源码基础上作出修改。如果没有统一代码规范，很可能会出现这种现象：
不知你有没有类似这样的经历：
随着不断迭代版的维护成本越来越高，从而形成恶性循环。程序背后的架构设计或模式固然重要，但良好的命名也不容忽视。不规范的命名不仅让我们对代码难以理解，更糟糕的是，会误导我们的思维，导致对代码的理解有偏差。 相反，良好的命名规范，则可以让我们的代码更加容易读懂，也能向读者正确表达事物以及逻辑的本质，阅读命名规范的源码理解没有那么费劲，会有一种享受的感觉。 有的人喜欢对变量str1，str2，str3、，str4类似这样的命名，甚至还对其添加注释。 有的人可能认为注释越多，其他人看到的就会越好。其实不然，注释过多，或是一些冗余注释，反而会影响源码的可读性。如果我们良好的命名规范，结合了需要和命名。它可以省去许多不必要的注释。 对于方法命名，首字母一会儿大写，一会儿小写；一会儿全称一会儿简写；一会儿用驼峰命名法一会儿用匈牙利命名法。 当然，起一个好的名字确实不是件容易的事情。首先，既要有尽量多的提供变量信息，又要尽可能的保证名字短小精悍，还不能为了短小而随意采用缩写而导致阅读障碍，另外还要尽量保证以后程序更新后名称仍然能很好的描述其内容。 在编写代码中，要尽可能的遵守一个良好的命名规范，并且不停地的调整学习命名，从而逐渐掌握起一个良好名字的能力。 我们应该做的就是规范开发，减少自己出现的错误。很多时候项目的压力一部分也是由于前期开发中遗留的众多的问题。 那些看似无用的东西要经过我们慢慢地累积由量变达到质变的时候，相信你能体会到其价值所在。 程序是写给自己看懂，更是写给别人看的，平时要多注意代码规范，养成一种好习惯，起初好习惯是人培养出来的，后来好习惯却能成就一个人。 养成良好的代码规范不是为了别人，也不是为了公司，而是为了提高自己的编程修养，提高自己认识事物的能力。让自己编写的代码可维护性更好、可重用性和可扩展性更强。 四、养重视沟通 编码只是程序员工作的一部分，团队之间的沟通也不容忽视。 职场里，有的程序员在任务进展过程中不注意沟通，认为我只要最后把领导安排的任务完成了就算完事了，结果往往需要项目负责人或上级主管问起来时才想起来汇报进展；更糟糕的情况是即使在开发过程中出现了问题，也不敢主动沟通，而要等到别人问起来了才提出目前碰到的困难。这样会给别人造成极大的困扰和担心：如果我没有问，那么这个问题是不是就卡在这里？项目进度是不是就延期了。 职场上对你的职场形象造成负面影响的其实并不是事情没有按期达成，因为有时候确实有一些因素会导致事情无法正常完成，而危害最大的是你没有及时沟通问题，造成问题的搁浅和发酵，最终造成的结果与预期不符；这会给团队带来不必要的麻烦：出现问题为什么不及早反馈沟通？ 你遇到的问题，或者团队中已经有人解决了。因此，我们需要意识到定期沟通的机制对于跟进效果是一个重要的指标；那么如何搭建一个好的沟通机制呢？在这里给大家推荐一个SMART模型。
以上观点只是个人看法，有不足之处，欢迎指正，一起进步。要不要支持表妹学软件开发呢？
你可能还喜欢 |
|
|
