杰出软件工程师，我暂时还没遇到过，但是高级软件工程师平时倒是接触了不少，大概有如下特点：
✔ 面对疑难杂症不放弃，敢于挑战
像最近我们就遇到了一个难题，用户服务的某台机器，只要发送到这台机器的请求，有概率性会被锁住。业务小组的开发同学分析了半天也没找到原因，我就让技术小组的骨干去分析一下，结果他在座位上一座就是好几个小时，纹丝不动，下午六点钟，是那个姿势，晚上八点还是那个姿势，到了晚上11点，他还是那个姿势，始终是同一个pose，我怀疑晚餐和厕所，他都省了， 。
他正在专注的解决问题，同时他对这个问题也感兴趣。直到隔天早上10点钟，他跑过说，问题找到了，然后就扔一份巨长的分析文档给我，看了文档里的内容，我惊呆了，因为文档里已经包含了JAVA JVM和操作系统底层细节的东西了。
具体的故障原因，这里不细说。我想说的是，真正的技术人，就是喜欢和敢于挑战难题，并对此乐此不疲，可以不眠不休，他就是对这块感兴趣。
✔ 可以因为一个if else，可以跟你吵半天
技术部门平时是有做代码review的，尤其是关键系统的核心代码，那是一行一行代码审核的，因为核心代码只要有一行出问题，就是大故障。可能是用户无法使用系统，用户无法下单支付等。
日常开发中，一个if else，表面看起来挺简单的，但是如果这个if else是关键业务模块里的代码，那还是需要十分小心的。
有技术范的同学，自然也知道这个道理，在写代码的时候，都会特别的设计和思考一些细节性的东西。那么当做code review的时候，如果有人发起疑问，这里为啥要这么写的时候。哇，他的话匣子立刻便开启了，开始跟大家讨论细节，有时候语气会重一些，但是我觉得这个没有关系，做技术的嘛，只要他用自己专业视角说出这么做的原因就行，吵就吵。
他说他的，你说你的，只要都是从自己专业的视角发起就行，至于最终的结果，我们就综合判断一下，当前采用哪种最合适就行。
这里想说的是，有技术范的人，他注重代码细节，他知道好代码是怎么样的。
✔ 代码容错能力好
在他的代码里，真正的业务逻辑代码不多，但是异常处理的代码却非常的多。你过去问他为啥一定要有这么多的异常流处理，他会回复：【长期稳定性。】
自己写的代码，当前稳定不算啥，能长期稳定跑下去，才是好的代码。代码想长期稳定跑下去，势必需要考虑各种异常场景。
✔ 面对疑难杂症不放弃，敢于挑战
像最近我们就遇到了一个难题，用户服务的某台机器，只要发送到这台机器的请求，有概率性会被锁住。业务小组的开发同学分析了半天也没找到原因，我就让技术小组的骨干去分析一下，结果他在座位上一座就是好几个小时，纹丝不动，下午六点钟，是那个姿势，晚上八点还是那个姿势，到了晚上11点，他还是那个姿势，始终是同一个pose，我怀疑晚餐和厕所，他都省了， 。
他正在专注的解决问题，同时他对这个问题也感兴趣。直到隔天早上10点钟，他跑过说，问题找到了，然后就扔一份巨长的分析文档给我，看了文档里的内容，我惊呆了，因为文档里已经包含了JAVA JVM和操作系统底层细节的东西了。
具体的故障原因，这里不细说。我想说的是，真正的技术人，就是喜欢和敢于挑战难题，并对此乐此不疲，可以不眠不休，他就是对这块感兴趣。
✔ 可以因为一个if else，可以跟你吵半天
技术部门平时是有做代码review的，尤其是关键系统的核心代码，那是一行一行代码审核的，因为核心代码只要有一行出问题，就是大故障。可能是用户无法使用系统，用户无法下单支付等。
日常开发中，一个if else，表面看起来挺简单的，但是如果这个if else是关键业务模块里的代码，那还是需要十分小心的。
有技术范的同学，自然也知道这个道理，在写代码的时候，都会特别的设计和思考一些细节性的东西。那么当做code review的时候，如果有人发起疑问，这里为啥要这么写的时候。哇，他的话匣子立刻便开启了，开始跟大家讨论细节，有时候语气会重一些，但是我觉得这个没有关系，做技术的嘛，只要他用自己专业视角说出这么做的原因就行，吵就吵。
他说他的，你说你的，只要都是从自己专业的视角发起就行，至于最终的结果，我们就综合判断一下，当前采用哪种最合适就行。
这里想说的是，有技术范的人，他注重代码细节，他知道好代码是怎么样的。
✔ 代码容错能力好
在他的代码里，真正的业务逻辑代码不多，但是异常处理的代码却非常的多。你过去问他为啥一定要有这么多的异常流处理，他会回复：【长期稳定性。】
自己写的代码，当前稳定不算啥，能长期稳定跑下去，才是好的代码。代码想长期稳定跑下去，势必需要考虑各种异常场景。
展开
评论
13