【职业素养】之心得篇

1、聪明的人把复杂的问题简单化

　　一个人真正聪明的地方是能够把复杂的问题简单化。大部分软件开发工程师在设计和编码实现一个系统的时候，往往会把一个很简单的需求，弄的特别复杂。因为，我们都希望这个系统功能完善，易扩展，易维护。但要达到这几个目标，我们就不得不人为的引入了很多复杂性。比如并发，多线程，分布式，数据库分库分表，负载均衡等等。这些时髦的高级技术，我们总是津津乐道。这种大层面的系统设计问题，本人也很难在此分析透彻。

　　以上文字说的也许都是一些空洞的大道理，但这种简单问题复杂化的情况，更多的是出现在一些小的方面。比如某一个功能的实现，某一个BUG的修复。

　　例如，最近我在处理网络协议相关的问题。在某一种特殊的协议的代码转换上，我发现了一个新的类型不满足当前的系统。于是，我开始为这个新的类型进行设计。越往细节设计，我愈发的发现，这个新类型似乎又不是那么特殊。因为我很难对它进行抽象。然后，我在整个系统中寻找这种情况的次数。我惊奇的发现，仅仅只有这处需要特殊处理。于是，我在API上轻轻松松的弥补了这种特殊情况。所花的时间，不到1分钟而已。

　　　　 if (info.getStProps() != null) {
            ......
        } else {
            PlayerBaseProps props = new PlayerBaseProps();
            info.setStProps(props);
        }
        
        if (info.getStEquips() != null) {
            ......
        } else {
            PlayerBaseEquips equips = new PlayerBaseEquips();
            info.setStEquips(equips);
        }

　　另外也会有一种声音对这种行为进行批判，重构和bad smell。

　　当我们在简简单单的解决问题和修复BUG的时候，还应当留意，这个情况是否重复发生。否则在重复的地方随便打补丁，会让我们的系统腐烂的更快。

2、换一个角度看到的世界更加精彩

　　当一个问题的解决方案难以实现或者实现代价难以承受的时候，我们应该换一个角度，去寻找可能的替代方案。

　　我是一个比较喜欢技术的程序员，当遇到问题的时候，我会乐此不疲的搜索一个问题的解决方案。比较幸运的是，我遇到了一个好的时期。现在网络如此发达，搜索引擎和博客论坛给我们带来了极大的便利。与此同时随着互联网的发展，大家的分享精神也越来越强。我总能在即将放弃的时候，找到一些满意的答案。不幸的是，也有那么几次，我提出的问题如同石沉大海。而我搜索的问题，几乎无人问津。事实上，我应该在搜索问题之前，考虑一下实现代价和可能性，或者想想是否有接近的替代方案。

　　最近我在设计一个网址收藏的系统，其中需要一项“根据URL获取网页缩略图”的技术。这种技术在各大流行的浏览器（例如火狐，chrome）都有良好的实现。我寻找了很久，也没有找到合适的答案。最终我开始反思这个功能主要是为了什么。我希望有一个缩略图能一目了然的表示一个网站，而不是陈旧的标题链接。然后我发现各个网站都有一个icon很是特殊。那ICON是否可以成为替代品呢？答案是否定的，这个图片实在是太小了，而且含义不是很清晰。在上厕所回来后，我看见了网页上的LOGO图标。我突然很是兴奋，于是打开各个大的网站，查看它们的LOGO信息。于是，我就找到了一个简单良好的替代方案。各个网站的LOGO图标的图片链接中往往都有“LOGO”，“logo”这种字符。而且LOGO图标信息丰富，并且是权威标识。

3、懒惰的程序员

　　曾几何时，听某位前辈说，世界上最好的程序员都有一个通病，就是懒惰。当然，这里的懒惰不是指天天盼着周末的那种懒惰。懒惰的程序员最讨厌的事情就是重复自己。既然我是一位给计算机发送指令的程序员，那我为什么还总要去替代计算机来完成一些繁杂的琐事呢？

　　在写这段话的时候，我正在处理java客户端与c++服务器的通信问题。我的同事在c++服务器处理游戏逻辑，而我负责java客户端的通信协议。碰巧的是，这些协议也都是同事制定的。我称之为cppStyle，noneJavaStyle。最开始，我就按照协议一个字段一个字段的敲打通信协议类。所谓的自定义协议通信，也就是通信双方根据约定的数据结构发送和接收数据。在c++服务器端，它们是一些结构体。在Java客户端，它们是一些POJO类。当我好不容易敲完这些协议类之后，同事说修改了一个字段。然后我就又改一下。反反复复，最后，我们的协议有点血喷了。我开始感觉到一种恐慌，这加班闭所难免啦。事情是这样的，协议修改，导致协议类需要发生变化。与此同时，所有的协议都遵循协议规范。我十分急切的需要一个工具。它就像一位美丽的女神，当我的同事说协议改了，她就会悄悄的帮我把协议类也改好。

　　最后，我花了两天两夜，终于弄出了一个ProtocolCoder。在Output那个文件夹下面，有将近200个类。当我手工的维护10个类的时候，我已经有点不厌其烦了，更别提200这个天文数字。

　　只是，ProtocolCoder还不够完善，没有做到完全工具化。在协议消息映射的时候，我还需要一些手工操作。这都是该死的进度闹腾的。要不然，再给我几个月的时间，我给ProtocolCoder加上可视化界面，WEB界面，版本管理，自动部署等等。当然，这里只是一个笑话。我们要记住我们要成为一名懒惰的程序员。我们花费一定的时间去完成一个工具，以代替需要花费远远超过这段时间的繁杂手工维护。ToolTime <<<<< ManualTime。

　　随着task的增加，手工manual的时间成本呈线性的增加（也许可能是指数）。当我们使用tools的时候，不管task如何增加，我们都只需要开发tools的时间和使用tools的时间。它总是可预料和可控制的。也许我们需要一个更好一点的工具，让我们看起来比较舒服。但这会让我们的开发时间和使用时间也增加。在很多时候，开发进度如此紧张，PM是不会同意的。或许你梦想你有一个god tools。它拥有完善的人工智能，能帮我们完成所有的任务。那也许你需要去问问上帝（问问它是否允许你活到工具的产生）。

转载于:https://www.cnblogs.com/onliny/archive/2012/10/17/2727859.html