我真的很怕和公司另外一个程序员合作开发项目，也不是说他代码写得不行，而是他写的东西给人的感觉就是太“潦草”，是的，“潦草”！只能用这两个字来总结他的工作风格！可能很多人不能体会“潦草”是什么意思，下面我就说两个例子，看看各位的公司有没有这样的程序员！
同事代码很随意
我们公司之前有个项目，甲方已经验收完了，但是之后又需要新增一些功能，可以认为这是一次二次开发或者二期开发项目吧。新增的功能整体来说不难，也就是增加几个系统参数，然后根据系统参数修改一些业务逻辑。因此，需要在软件的系统参数界面增加几个参数的配置项。
因为收到这个甲方二期功能的时候，我手里正好在忙其他项目，且新增功能比较简单，公司就把活交给了另外一个程序员，而且我也告诉他该怎么怎么做，认为应该没啥问题。
可中途这个程序员因为不太了解项目的整体架构，所以问了我几个问题，我在看到他写的东西的时候，脑袋一下就懵了！其实也不是什么大事，就是他在系统设置的界面上新增了几个按钮和文本输入框，但是这几个按钮和文本输入框的风格跟之前我写的那个风格完全不一样，显得很突兀。而且界面排版也比较随意。
我以为他只是先把功能写出来，界面后面会优化，但为了保险起见，还是跟他提了一嘴，结果他回我：“这就是最终界面！”。
我：“.....”。
就这么着，之后这样的问题出现了好几次，所以，只要是公司安排我和他合作开发什么东西，我都会比较排斥。如果说他写的代码“能运行就行”我还能忍受的话，软件界面风格不统一，我是实在忍不了。
这是我现在公司的一个程序员的例子，而我之前在游戏公司做开发的时候，遇到一个计算机专业的研究生，也是跟他差不多！
即使是研究生写代码也很“随意”
首先，这个计算机专业的研究生代码功底那是没得说，但是他也是只注重效果的实现，在软件的界面布局和界面风格统一上，真实一点也不上心。
这个研究生本来是在游戏引擎的开发部门，后来得不到重用，公司又给他安排到了游戏客户端部门，但是仍然得不到重用。
我在游戏公司的时候是在策划部门做游戏脚本策划，虽然我属于策划部，但是，脚本是偏研发型的岗位，因此我们组脚本策划比较难招人。
正好有这么一个情况，我们部门负责人觉得很奇怪，按道理这么一个人才不应该被埋没才对，所以就把他给要到了我们部门写游戏脚本，时间长了以后我们才发现，他得不到重用，那是对的！
游戏脚本之所以被安排在策划部，主要还是为了提高效率，方便策划部门在出了方案后能够很快得出结果，而脚本策划当时前后端脚本都需要写，因此我得以看到了他写的游戏前端的样子。
就看到他写的每个游戏前端界面都没有什么统一的风格，字体、按钮、窗口风格也是想到哪里用到哪里，显得很“朴素”，没什么美观度可言。尤其是一些按钮，每个界面的位置都不一样。
如果这么说大家不理解的话，那么举个例子，要不是我们的游戏界面是用编辑器可以直接拖拉拽拼凑生成的话，那么他写的界面就像HTML界面没有使用Css！毫无规律和美观可言。
当然，他的“潦草”也不仅仅体现在写游戏界面上，所以，到最后，我们组的负责人最后也对他失去了信心。
程序员应当对细节敏感
如果一个程序员只注重代码实现，不关心其他事情的话，那么很显然，他只适合去敲代码，而且偏后端开发，前端的东西就不要碰了，因为真不适合他。
但是，根据经验，一个对前端细节不注重的程序员，在后端细节上，大概率也会出现同样的问题。但不是绝对哈！
其实，这就是我经常说的细节敏感性，有些程序员在写代码的时候会脑补自己写的这段代码在实际使用过程中可能会出现的问题，并且将一些问题在代码中给它事先处理好，有些细节把控，可能是作为一个程序员的基本素养，要刻在骨子里的。
最典型例子就是，当代码报错后，我们该怎么去处理这段错误呢？
一些写代码写得比较“潦草”的程序员可能就会直接弹个窗，直接把代码报错的内容给弹出来，展示在用户面前。但是，可以不可以直接把代码报错写在日志里，然后告知用户这个功能有问题，让他联系相关IT人员？当然，这只是一种方案，不是最好的，但比直接把错误内容弹窗给用户，要好得多！
结语
因此，即使一个程序员的代码功底很好，对于细节把控不在意的话，他很难成为一个公司喜欢并且写出来的东西客户也喜欢的程序员。
有些程序员在前端布局、风格上会依赖于公司的美工，虽然这种依赖并不是完全不合理，但程序员也需要自己对细节进行把控，而不是离开了美工，自己就无法掌控细节了。
不知道，各位的公司有没有这样的程序员呢？欢迎讨论！