在當今的科技界，開發者為王，這是我們所知道的。但是，如果你讓開發人員管理你的應用程式開發政策，你可能會感到吃驚，因為我們還有些話沒說。
應用程式開發可以成為您業務的關鍵因素，而可促進開發出市場主導的移動端應用程式的奇才或隻是能編寫正确的定制代碼來使業務發展起來的奇才，這些人都非常值得公司進行投入。但事實是，我們的開發人員并不總是這樣直率，并且有一些想要保守的秘密。
事實上，我們沒有告訴你事情的全部，這都是可以了解的。畢竟，你是老闆。難道你會把所有事情都告訴老闆嗎?如果您是首席執行官，您是否會在董事會上就每個決定說出自己的想法?是以當我們這樣做的時候你别這麼吃驚。
有時候你知道的越少越好。您不需要知道我們隐藏java更新的目錄。隻要備份進行了加密，您也不必關心其密碼。如果我們沒有征得每個利益相關者的準許就更換使用不同的工具，你可能并不會生氣。
但其他事情可能會有所影響。其他一些情況或許隻會影響公司的命運和我們的薪水。是以這裡有9件事情進行披露，我們并沒有告訴你，是因為這會使企業産生困擾。
我們的工作思路并沒有你們認為的那麼多
開發人員都很聰明，并且我們中的一些人簡直就是天才。但是，我們确實有一種傾向，讓人覺得我們知道有關這些1和0的所有事情，這有時讓我們感覺有些過頭。
當然，我們掌握程式設計整個流程的基礎知識。我們可以編寫一個循環或向資料庫發送查詢。即使我們第一次遇到某一種語言、代碼庫或開發工具，這些基礎知識也可以讓我們将工作向前推進，但是你很少詢問我們的基礎知識。您希望我們修複一個流程中的功能，如果我們知道該流程中涉及的所有代碼實際的位置，那我們或許會很幸運。當我們找到代碼的位置，再進行修複，這可能會變得很容易或者也很難。直到我們将代碼下載下傳，重新寫幾行代碼，并執行一下，才能真正知道結果。這不隻是工作範圍的擴大，也打亂了你的時間表。有時在開始階段，我們無法估計涉及的實際工作量。
但是在會議上誰想說“我不知道”呢?誰想告訴老闆他們對如何開始工作或使用何種工具最适合毫無頭緒呢?是以我們憑空進行了估計或制定了解決方案，并且希望我們是正确的。如果我們不正确，我們必須給出一些聰明合理的解釋，如“磁通電容器過載”，并且着手去做我們最不喜歡的工作，即閱讀手冊。
你的技術債比你想象的要大很多
在開發現有應用程式時，管理層會做出一個選擇：催促開發團隊想出對策，或者要求他們對整個堆棧進行重新設計。快速應對政策通常是不錯的，似乎成本較低。通過快速應對政策，您可以立即解決問題，我們會盡力滿足您的需求，大多數情況下我們都喜歡這樣做。
但随着時間的推移，各種修修補補的地方逐漸累積。一些聰明的開發人員創造了一個詞叫“技術債”，以涵蓋那些本應該完成的全部實際工作，但是由于決策延遲而使用了臨時性補救措施。
當然，這不是一個準确的術語。你不需要償還債務。如果你很幸運的話，你可以始終保持軟體的運作，而無需重新修改所有内容。但最終，一些重大事件的發生将會打破一切，并且不能輕易地進行修複。通常這些事件會涉及一個合作密切的業務夥伴，他們通過一些軟體包最終更新到最新版本，而突然我們的代碼無法運作。突然間一切都崩潰了，我們的代碼不再與我們的合作夥伴進行互動。有時候，我們的合作夥伴将對我們感到遺憾，并繼續運作他們舊的通道，但這種情況隻有在我們可以給合作夥伴帶來收入時才可行。如果我們隻是一個不創造價值或一個小賬戶，那麼合作夥伴将會跟我們說再見了，這就是我們的工作。
我們感到無聊，隻是做一些無聊簡單的工作
一個企業最大的問題是擁有聰明的開發人員，他們知道代碼的全部問題，但并沒有興趣為此做任何事情。在修複故障或做一個功能改進上，這樣的開發人員可能會比那些聰明但不了解代碼庫的年輕員工快10倍。有無數的原因令我們感到無聊，有時代碼是用幾年前就過時的舊語言編寫的，有時是我們忘記最初辛辛苦苦編寫的代碼，有時是将表格加寬一些或者背景更藍一些，這樣的簡單工作，我們都想要一個新挑戰。
一次又一次辛苦地鑽研着相同的代碼，對這種無聊束手無策。讓開發人員在最新和最好的架構中重寫代碼會減輕這種無聊。正如艾茲拉·龐德(ezra pound)所說，詩人的工作就是讓它重新變成新東西。也許這是管理者的工作。如果你們想讓我們留下來繼續工作，或許至少應該這樣做。
我們癡迷于自己的代碼
你看到過我使用indexof函數的巧妙方法了嗎?隻需一行代碼，但它可以完全解析cookie字元串。如果你再給我幾天時間，我可以用這個聰明的方法來解決更大的問題。
我們喜歡用我們自己特有的方式來程式設計。我們已經習慣于舒适狀态，我們喜歡一次又一次地使用相同的語句。你知道這個笑話，當你去見外科醫生時，每一種疾病都需要做手術切除，而每一項任務看起來像木匠帶着一把錘子來處理一個釘子?這就像我們一樣，但是我們自己擁有特别的語言角。函數語言?面向對象代碼?彙編代碼?我們已經選擇了我們的語言，我們已經準備好實施我們喜歡的解決方案，無論該方案對公司是否有意義。
在最好的日子裡，這不是問題。優秀的開發人員不要讓他們特定的選擇變成教條。通常我們擁有很好品味，可以欣賞一個不錯的點子。我們應該足夠地靈活，并能認識到許多程式設計技術幾乎是可以互換的。我們也應該足夠聰明，認識到沒有完美的解決方案，每一個優秀的功能或很棒的方法都有缺點。
但在最糟糕的日子裡，我們已經做好進行内戰的準備了。我們中的太多人将那些做出不同選擇的開發人員妖魔化，并進行诋毀。管理者需要謹慎處理此事，但這可能令人為難。當程式員随便地做出嚴厲的批評時，很難弄清楚這隻是一種不同的技術，還是“腦子出問題”的技術。而當您不知道開發人員是否重新工作，或是對其工作固執己見時，可能很難為該業務做出最佳決策。
我們癡迷于這個月的時髦東西
你看到在slashdot上新的開源項目嗎?你看過在infoworld上的這篇文章了嗎?我們絕對需要下載下傳那個代碼，編譯并将其內建到我們的堆棧中。這将使我們的軟體運作得快很多，也會出問題。這比上個月寫信告訴你的那個聰明的新想法好多了。昨天就這樣，上周也是這樣，這是實打實的。
進步是科技産業的重要組成部分。通常情況下，這是好事，會使裝置運轉越來越好。這一切您隻需登上時光機器回到過去，就能了解科技進步了多少。
但是開發人員經常把這個做得更誇張。我們喜歡新點子和更好的代碼，像一個新車主喜歡那些很棒的配置。谷歌公司命名其浏覽器為“chrome”并不是巧合。
控制這種本能是一項挑戰。如果隻是為了改進的話，你不想經常說“不”，因為我們的這種癡迷經常是基于一些實際的需要。但是，如果我們追逐每一個新的想法，那麼我們都将無法把握什麼是最适合我們的業務。或者更糟的是，我們會将一部分業務置于危險境地。
我們經常太懶惰而不想推進業務發展
比起追逐每一個新想法，唯一一件更糟的事情是不追逐任何一個新想法。有太多開發人員變得如此憤世嫉俗，他們不會嘗試改進任何事情或研究可以産生重大業務成果的新工具。
是的，這個月的時髦東西很快就會被取代。是的，通常這隻是幾年前的一個舊東西翻新一下，做了一些小的改進。是的，我們得到的代碼運作順利。是的，因為它是新的和有所改進的東西，我們就用其他東西替換現在運作良好的東西，這是很愚蠢的。但是，如果我們經常忽略發展進步，我們終究有一天會意識到我們已經落後了很遠。
我們經常以自豪和過于專注于某些技術細節來掩飾這種懶惰。你知道multics是最好的作業系統，比windows更安全嗎?或者solaris是unix系統中最好的版本?如果不是mac使用者隻是喜歡點選圖示，或許真正成功的是加州大學伯克利分校軟體(bsd)，而不是apple的那個古怪的系統。我們知道我們初次嘗試做的東西還是最好的。
這種懶惰是“非我發明”的一個近似的表達，往往會拖慢發展進度。網際網路上有很多聰明人，但不知何故，所有精彩的想法都來自于不太聰明的人。如果我們自己沒有想到，那就不值得做。
對抗這種懶惰的方法是使偶爾有野心的開發人員專注于其中。即使采用一些新技術的規劃，也沒有太多的商業意義或沒有希望真正改變任何東西，但這會讓辦公室内的所有人興奮起來，這就可以了。讓大家興奮一點，畢竟，這種事情，可以使公司在機器學習、物聯網網際網路或其他方面取得成功。
我們甯願來創造新東西，也不願做維護工作
我見過最好的團隊之一，每一年都會重寫他們的應用程式。他們花了頭三個月從頭開始重寫了所有程式。然後他們海邊度假，到9月他們正在計劃明年的重寫工作。
他們為自己的代碼深感自豪，他們的代碼是精心設計且子產品化的，通常是用“正确的方式”進行編寫。他們對工作的自豪感也展現在代碼中。代碼并不是随意拼湊在一起，而是實實在在的工作成果。
但是這種方法在時間、金錢和情感能量上都付出昂貴的代價。團隊的規模大于隻是從事漏洞修複及維護的團隊。他們始終在思考哪些東西可以進行改進，哪些會變得昂貴而導緻無法持續。無論我們怎麼說，有時最好的方式是，建立堆棧并選擇一小部分開發人員來進行維護，将其餘人員轉移到新團隊從事新項目。
不是每個應用程式都需要重寫
我們中的一些人喜歡以“正确的方式”重新設計和重建一些東西，我們沒有這樣做。我們通常在隻能通過完全重寫才能解決故障時，才會這樣做。有時候我們100%沒有故障。
但是，隻是因為它很好，但并不意味着它有商業意義。如果30歲的帕斯卡爾或科波爾正在做這項工作，為什麼會搞砸呢?新功能是否增加了很多重要内容?更糟糕的是，沒有什麼東西是存在于真空中。修複了x就會破壞到y和z，因為他們依賴于x。這些又将引發a、b、c和d中的小錯誤，這就像一個連鎖反應，造成好心沒好報。
有時進步會使情況變得更糟。我記得有一位經理向那些挑剔的、癡迷于術語的程式員們做出讓步後非常生氣，這些程式員堅持認為現在是時候替換幾十年前在綠色螢幕上顯示大寫字母的大型機代碼了。新代碼與最新最好的開放源代碼庫相容。二進制代碼比舊版本代碼好上1000倍，然而卻速度慢了10倍。我聽了一位工程師對速度變慢的解釋，因為新的應用程式“做了更多工作”。而更多的是，他的意思是在彩色背景上生成了truetype字型。
我們不了解商業案例
我們可能對資料庫、協定和新的程式設計語言非常精通，但是我們大多數人對普通人為什麼會這樣做并不太了解。這意味着制定一個讓客戶滿意和進行消費的政策，我們不是最佳人選。我們可以維護資料庫正常運轉，但我們不知道如何能留住顧客。
一個明智的選擇是利用大資料和有效的衡量名額。這些大資料和名額會将交易歸結為數字，而數字是我們所能了解的。大資料和人工智能的真正好處是，它建立了一個語言架構，是以在一線工作的商務人士可以與背景開發人員進行溝通。
不要害怕對這些名額進行擴大。原始銷售數字是顯而易見的。尋找一下諸如品牌參與度和品牌認知度等方面的衡量名額。這些名額并不總是完美無缺，但可以幫助我們了解産品外觀和情感聯系的重要性。
本文轉自d1net（轉載）
![Ambari介紹和架構原理[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)