好久没有写 blog 了， 最近换了工作，也换了项目，就出不少人，有老鸟，也有菜鸟，有老人也有新人。
从被别人招进写代码，到把别人招进写代码，从coding功能到构建模块，当然还没有构建过系统，但是断断续续的看见了好多的系统，见证了网传的段子好多竟然是tmd真实的。
项目的开发是需要成本的，想一想这其中，最昂贵的成本是什么呢？有人可能说是人力成本，这个很对，但是问题是这个是硬性成本，是不可避免的，干什么活都需要人，尤其是随着时代的发展，人力成本正在不多的提升，这个在各行各业都是一样的，在IT届时这样，在建筑届也是这样，现在的工人的收入和我当初在工地上干活的时候相比，已经高出了很大的一节，最早的时候，我在工地上搬一天砖才给45块钱，现在真不敢想当时自己是怎么坚持下来的，每天累得跟狗一样，真跟够一样，倒下就睡。
扯远了，我想说的是人力成本是硬性因素，不可避免，通过对各个项目的观察，我觉得真正能够弹性的影响项目进度的有两点：
1、流程 流程这个东西不好说，也很难去评定，更不好该，流程不简洁可能其中的某一个环节多余，可能会导致大量工作与资源的浪费，但是没有人能保证一定能够把这个流程改好，这需要一个很有大局观的人来主导，并且得有一定的话语权，还得综合各种因素，总而言之，不是一般人能够解决的，作为一个小职员来讲，只能在某一个流程开始制定的时候近自己的最大的努力去争取把那些能够确定不理想的地方过滤掉。
2、沟通 沟通的成本是一个比较高成本，这里的沟通并不是指简单的交流能力，一个叭叭叭的聊天的人不一定能够很好的沟通（当然一个每天屁都不放一个的人也不一定能够进行良好的沟通），工作上的沟通需要你有良好的业务能力，清晰的思维逻辑，说话得说到问题的重点。其实，这也还是其中的一方面，还要考虑每一个沟通对象的脾气秉性，沟通的语气语调，人大多数情况下总是觉得自己是对的，都不喜欢返回的意见，所以想让别人听取你的意见得有理有据，当然听取别人的意见也是差不多的过程。然而，这不是重点，如果你们已经达到了以上两点，至少，你们在沟通，比较操蛋的是人家压根就不跟你丫的沟通，你还意见个毛线。仔细的观察我们周围的没给人，当你提出反对意见的时候他们的表情，通常他们会立即进行反驳，大多情况下的这种反驳并不是一种非常理智的反驳，这种情况在女性身上表现的尤为明显，并没有歧视女性的意思，只是发现大多数的女性的理性思维能力较差（也可能只是我遇到的居多而已）。一旦遇到沟通的障碍，无形中就会浪费很多的时间。
3、没见过猪跑 这种问题通常会出现在新手身上（包括一些自以为是老手的），他们有很多的情况没有遇到，接触的项目构架非常的有限，加之自己已经学到的知识有限，所以在解决问题的时候，难免会出现一些片面的思维，这些问题本身并不算什么问题，问题时候这样的问题出现在一个在公司或者部门中与你共事且资历比你高的人身上，这时候就是一个问题了，毕竟能指着鼻子马老总的公司还是少的可怜的。遇到这种情况就得看个人处理能力了。
基于第三点不得不说的关于开发人员的问题。
多看书，多看书能增加你的眼界，你的理解能力，大多数的情况下，你所遇到的问题都能在已有的优秀的书籍上找到相关的资料，学习你所看过的项目的优秀的部分，包括框架风格，构建思路解决了那类的问题。我遇到过某工程师觉得某个项目构架如何的不好，想重新构架一下，可是没有时间，也没有足够的资源去重新的构架。我觉得这完全是他个人的问题，思路本身就有问题，首先作为一个已经成型，而且稳定的项目，他经历了时间的考验，肯定是过得去的；再者，即使你像重构，也不可能一下子重构完成，也得一步步来，整个重构？开毛玩笑呢！后来我看过他写的代码，真心话不敢恭维，就那水平还重构项目，我就呵呵了。5、6年的项目都是从bug中成长起来的，不说别的，你随便构架一个新项目，我敢打赌那些已经出现过的bug 80% 以上你还得遇到一遍，项目这种项目的重构只能是一部分一部分的来，首先得先做好手头的本质工作，不要好高骛远，不要急于求成。
好，那就写好手头的代码吧，这个总是最简单的吧？ 其实这个也不简单，我写代码的第一手的要求就是漂亮，当然要声明的我自己没有洁癖（当然也不是处女座）。我觉得这是作为一个程序员的一个最基本的素质，我从来没有看见过一个把代码写的乱七八糟的程序员成为一个优秀的程序员，而每一个我所见过的优秀的（我认为优秀的）程序员都码得一手好代码，格式漂亮（当然不是ctrl+shift+f），逻辑清晰，代码简洁，这是一个态度问题，连这个都没有还谈什么职业理想。
当然，这其中还要牵扯到个人能力问题，每一个对面向对象的理解程度，对设计模式的运用能力，怎么说能，这些都是需要悟性的，当然经验也有一定的作用，但是还是有一些简单的办法，就是遵循业界大家都推荐公共的标准，那些都是经过实践和时间的考验，即使不是最优的，也能算上优吧，反正照着去做总不会出现大的偏差。究竟怎么做比较好就得靠自己慢慢的琢磨了。