讀了兩篇文章彩库，其中都提到了技術債：
技術債瑟啃，遲早是要還的 -- 《ScrumMaster精髓》第八章技術債讀后感
好文，贊职恳！所謂"出來混所禀，遲早要還的"，欠的技術債放钦，也同樣需要還色徘。關注焦點在于技術債怎么還，還債方式操禀，和還債的條件與成本褂策。我從另外幾個角度看下這個問題：
一.看產品給用戶的價值輸出形態(tài)：
像商業(yè)軟件（OA類、OFFICE、ERP之類）或現(xiàn)在的部分云服務模塊（開放API斤寂，或對外開放的SDK）耿焊，這種提供給用戶的就是以軟件或某些模塊為載體的形態(tài)；他們對于還技術債的訴求很高遍搞，這些軟件實體或模塊一旦項目立項或安裝出去罗侯，可能開發(fā)與升級的周期都比較長，在一段時間內溪猿，可能都是穩(wěn)定的钩杰，不需要調整或變化；軟件載體本身承載著給用戶所輸出的價值诊县，必須做到可用讲弄、健壯與高可靠；一些提供OA翎冲、金融客戶端的傳統(tǒng)公司對這一點訴求很高(雖然實際產品一樣存在問題)垂睬；
二.看產品與用戶之間的關聯(lián)關系以及生命周期：toB類的和toC類產品相比，toB類訴求更高抗悍。相比toB類長周期的產品而言驹饺，互聯(lián)網化的toC類產品需要不斷的跟進當下的趨勢與熱點，在不斷的運營和調整缴渊，本身可能會欠更多的技術債（如Mobike單車緊跟熱點的運營赏壹，忘關鎖賬戶欠費兩千萬的int整型溢出問題），而toB類的產品可能在很長一段時間里面衔沼，不需要做調整蝌借；某些功能的生命周期而言，toB類的無疑會更長久指蚁，更值得持續(xù)性菩佑，長期的投入，少欠技術債凝化；
三.看公司與業(yè)務階段成熟度：
（1）對于萌芽期的初創(chuàng)公司或新開辟的業(yè)務線而言稍坯，往往是在快速沖刺和產品DEMO與商業(yè)模型驗證階段，會欠一定的技術債搓劫，但換來的結果是公司以極低的成本瞧哟，快速獲取資本支持，并快速試錯枪向，驗證商業(yè)模型勤揩，這時候，欠技術債就節(jié)省了成本秘蛔；
（2）對于發(fā)展與快速擴張期的公司而言陨亡，欠技術債也是正常的傍衡，只是不想萌芽期那樣債臺高筑，而是夯實基礎数苫，基礎模塊層債務已償還聪舒，欠的只是業(yè)務條線快速擴張的債務；
（3）再到一定規(guī)模虐急，成熟期的時候，往往資源不像之前那么短缺滔迈，人手齊全止吁、產品形態(tài)與業(yè)務模式穩(wěn)定，這時候燎悍，就認真考慮償還所有債務就顯得比較急迫了敬惦。當資源具備條件，較大的新需求或設計調整相對較少谈山，產品技術架構與技術選型已經可用俄删，團隊成員技術能力棧得到沉淀，人員有一定積累奏路、項目運作模式成熟時畴椰，逐漸去調整模塊，一點一滴的優(yōu)化與重構鸽粉，持續(xù)Rebuild斜脂、Rework，持續(xù)不斷地做技術更新触机；
（4）千里之堤帚戳，毀于蟻穴。如果債務欠得太久儡首，利息太多片任，一直沒還，沒有跟上行業(yè)/市場/用戶的需求蔬胯，那么可能會慢慢就衰落了对供。
另外，從另一個角度來看笔宿，有適度的負債率犁钟，也是健康的，不足為懼泼橘。企業(yè)有負債涝动，個人有負債（大部分人的房貸），技術同樣有負債炬灭，在一定的環(huán)境下醋粟，合理的負債，是資源配置的最優(yōu)方式；
綜上米愿，在合理的階段厦凤，做合理的事情，分期付款償還技術債也是種不錯的方式育苟。
補充：
寫完前一部分较鼓，看到了這篇文章（第八章 技術債：http://www.reibang.com/p/3e65ab375cb9）
在這篇文章(作者：王子君2017 鏈接：http://www.reibang.com/p/3e65ab375cb9)中最后給出的這些指導性方法：
"依托于一套自動化構建系統(tǒng)，以代碼提交作為觸發(fā)條件违柏，觸發(fā)若干項活動自動進行博烂，如單元測試、全局變量統(tǒng)計分析漱竖、圈復雜度統(tǒng)計分析禽篱，內存碎片分析等。每項活動進行完畢馍惹，構建系統(tǒng)自動在缺陷管理系統(tǒng)中登錄相應問題躺率，并用特殊標記標識，促進開發(fā)團隊解決万矾。以代碼提交作為觸發(fā)條件悼吱，把開發(fā)團隊編寫代碼的活動與檢查代碼的活動自然地結合在一起，不成熟的開發(fā)者再也不會忘記勤众，也無法敷衍這些活動舆绎，從而使技術實踐落到實處。"
這個確實是一條方式们颜，而且筆者曾經有過2年多這種實踐吕朵。基本思路趨同窥突，但細節(jié)有差異努溃。總體來看阻问，這種方式有優(yōu)點梧税，帶來的質量提升是顯而易見的，而且是可以量化的称近，但也有一定要求和門檻第队。當你引入CI之后，在其中獲取到這些"單元測試刨秆、全局變量統(tǒng)計分析凳谦、圈復雜度統(tǒng)計分析"之后，可以通過規(guī)則與數(shù)據(jù)方式衡未，對開發(fā)團隊的代碼質量進行評估尸执，對于基礎代碼規(guī)范提升是很明顯的家凯。該方法能夠使得基礎的類和函數(shù)方法優(yōu)化，并且從基礎代碼與設計層面減少耦合如失，規(guī)范函數(shù)見調用绊诲，從代碼級別做到了規(guī)范化；建議有條件的團隊可以嘗試去做褪贵，至少在標準與規(guī)范化方面會有提升掂之。但是，這個也不是100%完美的解決了問題竭鞍。下面我舉幾點：
1.該方法中要做到單元測試板惑，而對于單元測試主要會從覆蓋率角度統(tǒng)計，但部分mock的可能需要耗費的成本較高偎快，比如涉及到系統(tǒng)底層與硬件驅動層（以前遇到過與分布式存儲跨設備網絡虛擬化與qumo與內存管理等方面的問題）；
2.部分場景做這種統(tǒng)計之后洽胶，可能需要團隊重新修改類Sonor統(tǒng)計規(guī)則（比如前端單元測試自動化）晒夹；
3.部分場景所需要做的單元測試，可能所耗費的成本姊氓，遠高于實際業(yè)務代碼實現(xiàn)好幾倍丐怯；
4.產品需求與UX設計修改頻繁，但代碼交付周期不延長的場景翔横，需要慎重考慮读跷；
5.當然還有其他的因素，部門或組織架構調整禾唁，團隊成員變動等非技術類因素等需要考慮效览；
在具體工程方法中，我曾經只實踐過TDD荡短、BDD丐枉、SBE、Scrum掘托、Lean瘦锹，個人覺得覺得CI+SBE+Lean配合起來的模式還不錯。當然闪盔，可能還有其他很多方式弯院，比如，我們會聽說很多模式泪掀，常見的Waterfall听绳、Iterative、RUP族淮、PDCA辫红、Agile等等凭涂，層出不窮，每隔幾年就會有一些新概念新方法出來贴妻；但是切油，方法學值得研究，適合自己團隊的才是最好的名惩。一切的模式澎胡，最終都一定是結合自己團隊現(xiàn)狀的改造和引入，才能達到最好的效果娩鹉；輪子不沖重造攻谁，但方法學可以改造性的引入，打造具有符合自己團隊特色的最優(yōu)主義開發(fā)路線弯予，是最好的戚宦；
我們可能會做很多嘗試，最后又回到原點锈嫩，重新去思考受楼。努力做過幾次實踐之后，會發(fā)現(xiàn)呼寸，一定是會有收獲的艳汽。越過山丘，才發(fā)現(xiàn)無人等候对雪。聽過無數(shù)道理河狐，卻還沒過好這一生。
王國維先生講的三重境界:"昨夜西風凋碧樹瑟捣。獨上高樓馋艺，望盡天涯路","衣帶漸寬終不悔，為伊消得人憔悴蝶柿。","眾里尋他千百度丈钙，驀然回首，那人卻在交汤，燈火闌珊處"------這三重境界適用于人生雏赦，同樣適用于技術債。
回到核心訴求
工程領域芙扎，選擇什么工具或者語言星岗、平臺，就像使用什么兵器一般戒洼。之前看到過有些技術朋友將開發(fā)語言比作兵器的文章：
如果開發(fā)語言是一把刀：http://www.csdn.net/article/2012-02-21/312118
如果把編程語言比作武器：http://www.cnblogs.com/Wayou/p/if-programming-languages-were-weapons.html俏橘、
比較Perl、PHP圈浇、Python寥掐、Java和Ruby 【轉載】http://www.cnblogs.com/DDark/archive/2011/12/07/2279196.html
武俠小說中獨孤求敗曾在石壁上寫到："縱橫江湖三十余載侧啼，殺盡仇寇咬清，敗盡英雄，天下更無抗手，無可奈何滴须，惟隱居深谷才写，以雕為友驯用。嗚呼驼鞭，生平求一敵手而不可得，誠寂寥難堪也衫贬。"
所有的工程學方法德澈，以及我們所使用的第三方工具，開源插件固惯，都是各種刀劍梆造，好使的工具，就可謂是一款玄鐵重劍葬毫。若玄鐵劍在手即能取勝澳窑，玄鐵重劍使得越好，便可大殺四方供常，提高工程質量。
能達到劍魔“木劍勝鐵劍鸡捐，無劍勝有劍”之境栈暇，如同掃地僧一般功力，輕風拂手箍镜，才是上上成功夫源祈。
當然，扯得有點遠了色迂。
最終香缺，我們還還是得回到具體人和事上面來。再簡化一步歇僧，畢竟图张，人才是一切的核心！
