您的位置:軟件測(cè)試 > 軟件項(xiàng)目管理 > 開發(fā)管理 >
軟件開發(fā)中的11個(gè)系統(tǒng)思維定律
作者:網(wǎng)絡(luò)轉(zhuǎn)載 發(fā)布時(shí)間:[ 2013/7/24 15:43:28 ] 推薦標(biāo)簽:

     [2]Developers make many shortcuts, copy and paste code for similar functionality to please management and deliver first version fast. They
do quick progress at the beginning, but code eventually becomes Big Ball of Mud.
開發(fā)者會(huì)走捷徑,拷貝相似功能的代碼來(lái)趕進(jìn)度,并且爭(zhēng)取盡快發(fā)行第一個(gè)版本。他們一開始進(jìn)展迅速,但是代
碼終會(huì)變成大泥球(比喻系統(tǒng)結(jié)構(gòu)不清晰)。
     6.Faster is slower(欲速則不達(dá)).
When we feel smell of success we start advance at the full speed without much caution. However, the optimal rate of growth usually is much
slower than the fastest growth possible.
當(dāng)我們看到成功的曙光,我們會(huì)全力以赴,不再小心謹(jǐn)慎。然而,優(yōu)增長(zhǎng)速率通常會(huì)比可能的快增長(zhǎng)速率要慢得多。
     [1]Managers add many people to already successful project. The overall progress becomes slower, because of communication overhead
and loss of team coherence.
經(jīng)理們往往為已經(jīng)成功的項(xiàng)目增加很多人手,但總體進(jìn)展會(huì)變慢,因?yàn)榻涣魉玫幕ㄙM(fèi)增加,以及團(tuán)隊(duì)成員之間
失去默契。
     [2]Developers quickly add new features to the system without proper refactoring and improving existing code. System becomes difficult
to understand and modify.
在沒有對(duì)代碼進(jìn)行合理重構(gòu)及改善的情況下,開發(fā)者快速的為系統(tǒng)添加新的功能,會(huì)使系統(tǒng)變得難懂,而且難以修改。
     7.Cause and effect are not closely related in time and space(在時(shí)間和空間上,因果并不密切相關(guān)).
We are good at finding causes to our problems, even if they are just symptoms and far from real root causes.
我們善于為出現(xiàn)的困難尋找原因,即使這些原因很牽強(qiáng),并且遠(yuǎn)非是真正的根本原因。
     [1]Development team stops accepting requirement changes from customers to finish a system in time. Customers are unhappy with delivered
software.
為了按時(shí)完成系統(tǒng),開發(fā)團(tuán)隊(duì)不再接受來(lái)自客戶的需求改變。因此,客戶對(duì)發(fā)行的軟件不滿意。
     [2]After few incidents with a live system, management compel developers to get approval and write detailed technical specification before
implementing any change in the system. Developers lose motivation for any improvements in the system and start procrastinating.
實(shí)時(shí)系統(tǒng)歷經(jīng)坎坷之后,管理層迫使開發(fā)者同意,并且在給系統(tǒng)做出任何修改之前撰寫詳細(xì)的技術(shù)說(shuō)明。結(jié)果開發(fā)者
失去了為系統(tǒng)做出任何改進(jìn)的動(dòng)力,并且開始拖延。
     8.Small changes can produce big results-but the areas of highest leverage are often the least obvious(微小的改變可以產(chǎn)生明顯的效果,但這種杠桿效應(yīng)大的地方往往也不明顯).
Most obvious grand solutions like changing company policy, vision or tag line often don’t work. Small ordinary, but consistent changes could
make a huge difference.
像改變公司政策、愿景或者廣告用語(yǔ)這樣顯而易見并且關(guān)系重大的解決方案往往不起作用。相反,小而普通,但持續(xù)的改
變卻會(huì)帶來(lái)大不相同的效果。

 [1]Developers have everyday interactions with customer and make most decisions. As a result, customer needs are well understood, decisions
are better and solutions are optimal.
開發(fā)者每天都與客戶進(jìn)行交流,并且做出大部分決定。因此,能夠更好地理解客戶的需求、做出更好的決定并且給出優(yōu)
的解決方案。

 [2]Developers build automated unit tests for each function in the system. As a result, design is flexible, people are confident, the system is fully
tested after each change.
開發(fā)者為系統(tǒng)的每項(xiàng)功能設(shè)計(jì)自動(dòng)化單元測(cè)試。因此,設(shè)計(jì)更靈活、人們更自信、系統(tǒng)在每此修改之后都能得到完全的測(cè)試。
     9.You can have your cake and eat it too – but not at once(魚與熊掌可以兼得,但不是同時(shí)兼得).
We often face rigid “either-or” choices. Sometimes they are not dilemmas if we change our perspective and rules of the system.
我們經(jīng)常會(huì)面對(duì)刻板的“非此即彼”選擇。如果我們改變一下自己的觀點(diǎn)及系統(tǒng)規(guī)則,這些選擇有時(shí)并不會(huì)使我們進(jìn)退兩難。
     [1]Experience managers know that we cannot increase the number of features and reduce time and cost simultaneously. However, it could be
possible to achieve if we just improve flow of ideas, find right people and avoid over-engineering.
經(jīng)驗(yàn)豐富的項(xiàng)目經(jīng)理知道增加系統(tǒng)特性的數(shù)量與削減時(shí)間和開支不可兼得。然而,如果我們完善一下想法、尋找合適的人
才并且避免過度開發(fā),這也是可能做到的。

  [2]Developers believe that they should follow either Transaction Script or Domain Model architecture patterns. However high performance
solution in the complex domain can combine both for the best effect.
開發(fā)者認(rèn)為他們應(yīng)該要么采用事務(wù)腳本,要么采用域模型體系架構(gòu)模式。然而,復(fù)合域中的高性能解決方案可以將兩者結(jié)合,
以得到佳性能。

  10. Dividing an elephant in half does not produce two small elephants(把一頭大象分兩半不會(huì)得到兩頭大象).
Inability to see the system as a whole could often lead to suboptimal decisions.
無(wú)法整體了解系統(tǒng),往往會(huì)做出次優(yōu)決定。

上一頁(yè)123下一頁(yè)
軟件測(cè)試工具 | 聯(lián)系我們 | 投訴建議 | 誠(chéng)聘英才 | 申請(qǐng)使用列表 | 網(wǎng)站地圖
滬ICP備07036474 2003-2017 版權(quán)所有 上海澤眾軟件科技有限公司 Shanghai ZeZhong Software Co.,Ltd