好久沒有寫 blog 了， 最近換了工作，也換了項目，就出不少人，有老鳥，也有菜鳥，有老人也有新人。
從被別人招進寫代碼，到把別人招進寫代碼，從coding功能到構建模塊，當然還沒有構建過系統，但是斷斷續續的看見了好多的系統，見證了網傳的段子好多竟然是tmd真實的。
項目的開發是需要成本的，想一想這其中，最昂貴的成本是什麼呢？有人可能說是人力成本，這個很對，但是問題是這個是硬性成本，是不可避免的，幹什麼活都需要人，尤其是隨着時代的發展，人力成本正在不多的提升，這個在各行各業都是一樣的，在IT屆時這樣，在建築屆也是這樣，現在的工人的收入和我當初在工地上幹活的時候相比，已經高出了很大的一節，最早的時候，我在工地上搬一天磚纔給45塊錢，現在真不敢想當時自己是怎麼堅持下來的，每天累得跟狗一樣，真跟夠一樣，倒下就睡。
扯遠了，我想說的是人力成本是硬性因素，不可避免，通過對各個項目的觀察，我覺得真正能夠彈性的影響項目進度的有兩點：
1、流程 流程這個東西不好說，也很難去評定，更不好該，流程不簡潔可能其中的某一個環節多餘，可能會導致大量工作與資源的浪費，但是沒有人能保證一定能夠把這個流程改好，這需要一個很有大局觀的人來主導，並且得有一定的話語權，還得綜合各種因素，總而言之，不是一般人能夠解決的，作爲一個小職員來講，只能在某一個流程開始制定的時候近自己的最大的努力去爭取把那些能夠確定不理想的地方過濾掉。
2、溝通 溝通的成本是一個比較高成本，這裏的溝通並不是指簡單的交流能力，一個叭叭叭的聊天的人不一定能夠很好的溝通（當然一個每天屁都不放一個的人也不一定能夠進行良好的溝通），工作上的溝通需要你有良好的業務能力，清晰的思維邏輯，說話得說到問題的重點。其實，這也還是其中的一方面，還要考慮每一個溝通對象的脾氣秉性，溝通的語氣語調，人大多數情況下總是覺得自己是對的，都不喜歡返回的意見，所以想讓別人聽取你的意見得有理有據，當然聽取別人的意見也是差不多的過程。然而，這不是重點，如果你們已經達到了以上兩點，至少，你們在溝通，比較操蛋的是人家壓根就不跟你丫的溝通，你還意見個毛線。仔細的觀察我們周圍的沒給人，當你提出反對意見的時候他們的表情，通常他們會立即進行反駁，大多情況下的這種反駁並不是一種非常理智的反駁，這種情況在女性身上表現的尤爲明顯，並沒有歧視女性的意思，只是發現大多數的女性的理性思維能力較差（也可能只是我遇到的居多而已）。一旦遇到溝通的障礙，無形中就會浪費很多的時間。
3、沒見過豬跑 這種問題通常會出現在新手身上（包括一些自以爲是老手的），他們有很多的情況沒有遇到，接觸的項目構架非常的有限，加之自己已經學到的知識有限，所以在解決問題的時候，難免會出現一些片面的思維，這些問題本身並不算什麼問題，問題時候這樣的問題出現在一個在公司或者部門中與你共事且資歷比你高的人身上，這時候就是一個問題了，畢竟能指着鼻子馬老總的公司還是少的可憐的。遇到這種情況就得看個人處理能力了。
基於第三點不得不說的關於開發人員的問題。
多看書，多看書能增加你的眼界，你的理解能力，大多數的情況下，你所遇到的問題都能在已有的優秀的書籍上找到相關的資料，學習你所看過的項目的優秀的部分，包括框架風格，構建思路解決了那類的問題。我遇到過某工程師覺得某個項目構架如何的不好，想重新構架一下，可是沒有時間，也沒有足夠的資源去重新的構架。我覺得這完全是他個人的問題，思路本身就有問題，首先作爲一個已經成型，而且穩定的項目，他經歷了時間的考驗，肯定是過得去的；再者，即使你像重構，也不可能一下子重構完成，也得一步步來，整個重構？開毛玩笑呢！後來我看過他寫的代碼，真心話不敢恭維，就那水平還重構項目，我就呵呵了。5、6年的項目都是從bug中成長起來的，不說別的，你隨便構架一個新項目，我敢打賭那些已經出現過的bug 80% 以上你還得遇到一遍，項目這種項目的重構只能是一部分一部分的來，首先得先做好手頭的本質工作，不要好高騖遠，不要急於求成。
好，那就寫好手頭的代碼吧，這個總是最簡單的吧？ 其實這個也不簡單，我寫代碼的第一手的要求就是漂亮，當然要聲明的我自己沒有潔癖（當然也不是處女座）。我覺得這是作爲一個程序員的一個最基本的素質，我從來沒有看見過一個把代碼寫的亂七八糟的程序員成爲一個優秀的程序員，而每一個我所見過的優秀的（我認爲優秀的）程序員都碼得一手好代碼，格式漂亮（當然不是ctrl+shift+f），邏輯清晰，代碼簡潔，這是一個態度問題，連這個都沒有還談什麼職業理想。
當然，這其中還要牽扯到個人能力問題，每一個對面向對象的理解程度，對設計模式的運用能力，怎麼說能，這些都是需要悟性的，當然經驗也有一定的作用，但是還是有一些簡單的辦法，就是遵循業界大家都推薦公共的標準，那些都是經過實踐和時間的考驗，即使不是最優的，也能算上優吧，反正照着去做總不會出現大的偏差。究竟怎麼做比較好就得靠自己慢慢的琢磨了。