1. 程式人生 > >文件驅動式超敏捷開發

文件驅動式超敏捷開發

  敏捷開發大家都不陌生,他對文件的態度是偏向於反對,但是也不是說一點文件都沒有。他的說法是 代替文件。

  那麼敏捷開發為什麼會這麼認為呢?其實大家在做專案開發的時候都會有這樣的體會:

  •   時間緊任務重,哪有時間寫文件呀?程式碼都寫不過來。
  •   辛辛苦苦把文件寫好了,但是但是專案才進行一小半好不好,需求怎麼就變了呀!需求變了,程式碼都改不過來,那還有時間去修改文件呀?於是乎一開始寫好的文件就變成了一個個的坑。默默的坑著後來的人。

  於是就有了這樣的現象:

  •   當接手一個遺留專案的時候最希望的就是有文件,但是沒有文件——鬱悶;
  •   啥?!找到文件了,太好了……但是當看完了文件再去看程式碼的時候就會——更鬱悶。

         (各位前輩呀,為後來人著想著想呀!)

  •   等自己完全接手專案,流程都弄明白了之後呢?忙改程式碼做新功能,至於文件?哪有時間去想文件呀。

  於是乎文件就成了一個包袱一個累贅,有還不如沒有。

  為啥會這樣呢?因為文件和程式碼沒有直接關係,沒有“聯動”關係!

  那麼啥是聯動關係呢?我們舉個例子,PowerDeszner做資料庫設定的時候,我們不僅可以用這個工具做資料庫文件,而且設計好了之後,還可以直接建立資料庫。當文件有變化的時候,也可以自動修改資料庫。還可以反向工程,就是指定一個數據庫,然後根據資料庫裡的表和自動,自動生成文件。這就是聯動。

  如果您對powerdes不熟悉的話,我在舉一個CodeFirst的例子。CodeFirst就是先寫程式碼設計類,然後用vs裡面的來自動建立資料庫,類結構發生變化了,可以自動的去修改資料庫的表結構。這樣就可以達到程式碼和資料庫的一致性,而且有變化只需要修改一個地方(程式碼)就可以了,另一個地方可以自動變更。

  這就是我所說的“聯動”。如果所有的文件都可以和程式碼進行這樣的聯動,需求有變化了,先去修改文件,然後程式碼會自動隨之變更,那麼文件就不會成為負擔了!

  這就是我所說的“文件式驅動”!

  當然在實際中,並不是所有的功能都是先文件在程式碼。而是根據具體的情況來靈活控制的。

  這裡在舉一個WebAPI的例子。我們開啟VS201*,新建一個webapi的預設專案,我們會發現有一個help的目錄。進去一看,哇,api的使用文件!有介面名稱、引數名稱和他們的註解,還有呼叫例項。這還不是最神奇的,更神奇的是,當代碼修改了之後,help裡面的內容也會隨之更新。這樣寫介面再也不用擔心更新文件的問題了。

  這是有程式碼“生成”文件。這個僅僅是對程式設計師來說的,寫程式碼用的文件。除此之外還有給客戶看的文件,等等。如果這些都可以“聯動”起來,做到有需求的時候,只需要改動一個地方,其他的地方都會隨之更新。這是不是很爽!

  可能有人說,我這是痴人說夢,該醒醒了,別浪費大家寶貴的時間。這個當然不是無稽之談,今天也不是愚人節。下面還是用例子說話。

  公司以前用asp.net mvc做專案。後來發現開發速度跟不上,於是找了一個國外的無後端的東東 ,叫做backendless。他的思路就是,凡是伺服器做的事情(UI除外),都可以不用寫程式碼了,都由他來包辦。Backendless提供了一個平臺,在這個平臺上面配置各種服務,配置完了前臺就可以直接呼叫。這個前臺包括:web、手機web、安卓、蘋果、flash(Flex)、等,並且可以生成對應的呼叫程式碼。我們寫點前臺程式碼就OK了。

  每一個環節都有人在做“聯動”的事情。只是從整個專案的角度來看,把各個環節用一條線,從始至終的串聯起來,讓各個環節可以“聯動”。目前還沒有發現做這種事情的人(自己除外)。

  這麼做的難度很大,推廣也很難。其實大多數的情況都是隻做一塊,比如選擇日期的my97,分頁的Aspnetpager,線上編輯器,各種ORM,各種UI,單點登入,使用者中心等。他們都只做一塊,其他的不管。這樣才能夠讓大家靈活的選擇和使用。

  再舉一個蓋大樓的例子。要蓋樓首先要一個圖紙,然後請建築公司來按照圖紙把大樓蓋出來。蓋樓之前圖紙可以修改,蓋樓的時候會按照最後修改後的圖紙來施工。但是樓蓋好了,再去改動圖紙,大樓就不會受到影響了。大樓改好之後,圖紙和樓失去了聯動,圖紙不會去影響大樓了,因為樓已經蓋好了。

  再來看看導航軟體,我們輸入出發地和目的地,然後導航就會規劃一條路線出來,我們按照這個路線開車,開著開著發現前方路口堵車,怎麼辦?重新規劃路線繞過堵車點。然後我們按照重新規劃好的路線繼續行駛。路線實時指導我們的行車方向,路線變了,我們的車就跟著變。這樣就是實時聯動。

  說了這麼多,大家可能都蒙登了,我到底要說啥?還是來張圖吧。

 

  總之呢,就是不能讓文件孤單單的存在,要讓文件和程式碼和頁面互動起來。需求有變化了,首先想到的是改文件,然後對應的地方會隨之自動更新,不需要修改程式碼!

  最後說一下啥是“超敏捷”,前面說了敏捷開發,那麼超敏捷開發呢,顧名思義說的就是開發速度會更快。

ps:好久沒有寫部落格了。沉寂了一段時間,好好的思考了一陣子,現在是新的開始,重新打造!後續會更精彩。

相關推薦

驅動敏捷開發

  敏捷開發大家都不陌生,他對文件的態度是偏向於反對,但是也不是說一點文件都沒有。他的說法是 代替文件。   那麼敏捷開發為什麼會這麼認為呢?其實大家在做專案開發的時候都會有這樣的體會:   時間緊任務重,哪有時間寫文件呀?程式碼都寫不過來。   辛辛苦苦把文件寫好了,但是但是專案才

驅動面向服務的敏捷開發與高效執行

  標題有點長,因為想把主要特點都加進去,結果還是漏掉了角色和工作流。   可能您看著有點暈,感覺這個有點扯。Emmmm,看個圖吧。         一條大魚,骨骼已經出來了,就差往裡面填肉了,有興趣嗎?   除了外掛功能之外,不需要寫程式碼!  

驅動程式碼設計器——程式碼是設計出來的!

  程式碼是敲出來的嗎?是批量生成出來的嗎?   No no no,程式碼是設計出來的!   如果說到程式碼生成器,大家可能會想到三層、動軟程式碼生成器、資料庫表等等。其一般的思路是,先有資料庫然後根據庫裡的表自動生成一系列的程式碼,包括實體類、持久化、業務層(空函式)、頁面程式碼等,還可以生

驅動開發模式在 AIMS 中的應用與實踐

摘要:程式設計師常會說:我最討厭別人寫的程式碼沒有文件,我也最討厭自己需要寫文件。 有一個很老的梗: 我最討厭別人寫的程式碼沒有文件,我也最討厭自己需要寫文件。 有這種想法的程式設計師應該算是一個老鳥了,對於大多數程式設計師來說,對於他們來說: 文件是什麼。 對於大規模,超大規模的專案,並且歷時很長,需要大量

搭建nfs服務器——詳細

服務器、服務、nfsnfs就是Network File System的縮寫nfs的功能是可以通過網絡,讓不同的機器、不同的操作系統可以共享彼此的文件。所以可以將它看做是一個文件服務器。這個nfs服務器可以讓pc將網絡中的nfs服務器共享的目錄掛載到本地端的文件系統中,那這個遠程主機的目錄就好像是自己的一個磁盤

滾動標簽 壓縮下載 與鏈接的優化寫法

nbsp .com .cn png 技術 壓縮 images 分享 log 滾動標簽 壓縮文件下載 與超鏈接的優化寫法

shell 表達

shell 文字表達式文件表達式 -e filename 如果 filename存在,則為真-d filename 如果 filename為目錄,則為真 -f filename 如果 filename為常規文件,則為真-L filename 如果 filename為符號鏈接,則為真 -r filename 如

mybatis源碼-解析配置(三)之配置Configuration解析(詳細, 值得收藏)

類型 version 創建對象 越來越大 ... 所有 類名 對象 and 1. 簡介 1.1 系列內容 本系列文章講解的是mybatis解析配置文件內部的邏輯, 即 Reader reader = Resources.getResourceAsReader("mybat

驅動你的專案管理,步步為營

千百年來,我們都生活在追求契約精神的社會。即便人情在國內佔很大比重,歸根結底,逃不開契約的約束。在專案管理中,專案經理常常處於弱勢地位,被各方擠壓,更應注重專案契約,用文件驅動專案管理,逐步走向成功。 用文件驅動專案管理的遵守的基本規則: 1)凡是沒有相關干係人簽字或蓋章的文件一律不算數。

沒有功能需求設計?對不起,拒絕開發

在很多軟體公司,特別是一些創業型的團隊中,對於這樣的情景可能大家都很熟悉:專案經理或者產品經理(產品狗)口頭或者簡單記錄一下軟體產品的大致要做的功能,直接就讓研發團隊的兄弟(程式猿)去狂擼程式碼。然後他就去喝茶撩妹或者回家陪老婆了… 這種擼起袖子就開乾的方式,看似簡單高效,便於直接溝通,能夠快速迭代。卻不知

:三分鐘瞭解敏捷開發

小灰經過千辛萬苦,終於拿到了心儀的offer, 今天小灰上班的第一天…… 下班後,小灰找到同學大黃來請教…… 場景一:小灰在餐廳 場景二:無奈的專案經理 什麼是敏捷開發? 敏捷開發(Agile)是一種以人為核

Golang 爬蟲-廣度優先(獲取html中的連結)

package main import( "fmt" "net/http" "io/ioutil" "regexp" "strings" ) var href_reg *regexp.Regexp var hrefs_been_found map[string]i

【技術】jeecg3.8-maven 開發環境搭建入門

JEECG 微雲快速開發平臺(3.8)Eclipse-Maven版本手把手入門手冊 官方標準開發工具: 1. IDE         Eclipse Java EE IDE for Web Developers.         Version: Helios

在沒有需求下,怎麼去開發好一個SDK

事情還得在兩天前說起,部門經理拉我去單獨聊天,跟我說公司現在需要做一個平臺型的SDK。因為公司接的遊戲都是租用著別人的SDK,要給租金不說,處理突發事情也不夠及時。所以,希望我來開發一個屬於公司自己的SDK。當時,我一聽,這挺好啊,那就做吧。就問要需求文件,經理居然回我,需求

discuz!7.2升級discuzX3.2,流程(有二次開發

由於官方給出的教程大多需要備份原來的資料庫以防升級失敗,風險較高,所以本教程不論升級成功與否,對原來的discuz資料庫是完全沒有影響的。 如果discuz與第三方站點有同步登陸等聯絡的,升級之前需要先將discuz與第三方站點解綁,保證discuz關閉後對與之關聯的第

nginx配置nginx.conf詳細講解

技術 lang 讓我 crt 哈希 zip解壓 rgs error pack #nginx進程,一般設置為和cpu核數一樣worker_processes 4; #錯誤日誌存放目錄 error_log /data

2018-2019-2 20175126謝航 實驗三《敏捷開發與XP實踐》實驗報告

有用 complex 包導入 彈出菜單 幸運 stand 回滾 system let 一、實驗報告封面 課程:Java程序設計 班級:1751 班 姓名:謝文航 學號:20175126 指導教師:婁嘉鵬 實驗日期:2019年5月2日 實驗時間:--- 實驗

如何真正實現由驅動的API設計?

前言 本文主要介紹了一種新的開發思路:通過反轉開發順序,直接從API文件中閱讀程式碼。作者認為通過這種開發方式,你可以更清楚地知道文件表達出什麼以及它應該如何實現。 如果單從API文件出發,由於資訊量不足,通常很難了解它具體想實現的功能,正因為有這種假設的存在,使得經常在開發之後才會想起對文件進行完善

石墨技術總監:敏捷思想在產品週期的延伸

  李子驊--石墨文件技術總監。 一個產品有需求的提出、評審、確定,以及實際的開發測試和交付這幾個階段。從2001年敏捷被提出開始到現在已經有越來越多的專案在使用敏捷。現在的敏捷已經變成一種常態,這個時候討論敏捷實踐中被大家的忽略點就變得非常有意義。 今天我們會圍繞兩個關鍵的點來討論:一

預設解析--手機web app開發筆記(二)

首先我們啟動HBuilderX2.0 ,介面如圖2-1所示 圖2-1 軟體開發介面 單擊“檔案—新建—專案”,彈出新建專案管理介面,我們在裡面進行了專案型別選擇“5+APP”、專案名稱填寫“程式設計之路”、