軟體隨想-項目上線後

從開發到上線差不多用了3個月,其實第一個月就把大部分功能實現了,之後兩個月都是需求的再次確認和修改BUG,期間穿插的做別的一些事情。總的來說比較順利,一馬平川沒有任何卡住的地方,也沒有出現“大腦CPU使用率突然飆升的情況”,但瑕疵太多,在此做一下簡單的記錄。簡單介紹一下我們的作戰方式。頁面由專門的人切,只製作出部分頁面,類似的自己搞定,之後的樣式問題自己搞定,一個產品經理,兩個程式員,所有的需求都問產品經理,基本上是除了切頁面,其他的都由我們程式自己搞定。做的是一個公司內部的專案管理軟體(網站)

[XA]讀書&感想:個人對敏捷式軟體開發 (Agile Software Development)宣言的理解

首先什麼是敏捷開發呢?敏捷開發指的是一種面臨迅速變化的需求快速開發軟體的能力!敏捷式軟體開發 (Agile Software Development)宣言:·個體和互動                勝過    過程和工具·可以工作的軟體        勝過    面面俱到的文檔·客戶合作                    勝過    合約談判·響應變化                    勝過    遵循計劃雖然右項也有價值,但是我們認為左項具有更大價值。具體詮釋[註:()內為本人看法]

[XA]轉:軟體開發方法–XP(eXtreme Programming)編程講義二

接上文:[XA]轉:軟體開發方法--XP(eXtreme Programming)編程講義一No overtime.  逾時工作會吞噬開發組的精神和熱情 利用版本計劃會來改變項目的範圍和時間要求 項目進度拖延時通過增加資源來改進也不是推薦的方法   Testing  All code must have unit tests.  All code must pass all unit tests before it  can be released.  When a bug is found

有幸加入敏捷式軟體開發 (Agile Software Development)組織,希望大家來這商量一下發展該組織的想法!

一直以來對敏捷式軟體開發 (Agile Software Development)的一些方法、原則感興趣,有很多想法,但是由於工作上用的比較少、而且沒人交流,所有那些只是存在於理論層面,希望與大家共同把這些理論知識運用到工作或實踐中去,但是對於該組織的發展不是很瞭解,希望創始人 Milestone及各位團隊成員、有興趣的同仁來發表下意見,希望能把咱們這個虛擬團隊發展壯大!我去年看過了大作《敏捷式軟體開發 (Agile Software

軟體人性化設計與技術含量的關係

        要更好闡述軟體人性化設計與技術含量的關係,個人認為應從開發軟體的目的開始談起,我們這裡所指的軟體應是給廣大使用者使用的商業軟體,而絕大多數商業軟體的開發目的都是給使用者帶來更大的商業價值,比如提高他們的業務處理能力、效率、準確率等,歸結起來也就是提高軟體使用者的生產效率,然而作為開發商業軟體的軟體企業或個人是通過商業軟體的開發來達到取得價值的目的,兩者相輔相成、緊密相連,不應該成為矛盾。

談軟體協作:君子和而不同,小人同而不和

我們知道現在的軟體開發最大的問題就是變化,其實這也不是軟體本身的問題,我更覺得是軟體的特點。因為他不像建築,畫個建築圖,一般不會偏到哪裡去。然而很多需要軟體的人,他可能希望軟體能達到什麼目的,至於具體是什麼樣子,他自己也不知道。大部分都是看到一部分想起一部分,自己也不斷的修正。這也是為什麼最近敏捷大行其道。我甚至服務過一個客戶,做一個公園系統,為的是送一張免費的VIP卡給業主,最終目的是賣房子。既然軟體的需求是不固定,也就是不斷變化,所以我們簽合約的時候往往有兩種方式:1.固定價格這種就是一開始

中小企業需要什麼的軟體服務?

首先說明,軟體業是一種服務行業。軟體業已經從以前的陽春白雪慢慢走入尋常百姓家,大型公司專屬應用程式現在多已經很普遍了,但是中小型企業的應用卻還是不夠好。那麼是中小型企業不想要軟體服務嗎?還是現有的軟體服務不能滿足他們的需求?中小型企業需要什麼樣的軟體服務呢?幾種失敗的案例:1:定製軟體   有軟體商找到潛在客戶:“我們的軟體可以完全根據你的要求來開發,做到完全無縫聯結,貼心舒適”   客戶:“哦,太好了,什麼時候可能用?下個星期可以嗎?”   服務商:“這個不可能。你先支付x萬,我們調研1個月,

外刊IT評論:軟體編程21法則

任何一個有經驗的程式員都知道,軟體開發遵循著一些不成文的法則。然而,如果你不遵循這些法則也並不意味著會受到懲罰;相反,有時你還會獲得意外的好處。下面的就是軟體編程中的21條法則:   任何程式一旦部署即顯陳舊。 修改需求規範來適應程式比反過來做更容易。 一個程式如果很有用,那它註定要被改掉。 一個程式如果沒用,那它一定會有很好的文檔。 任何程式裡都僅僅只有10%的代碼會被執行到。 軟體會一直膨脹到耗盡所有資源為止。 任何一個有點價值的程式裡都會有至少一個bug。

簡單的遠端控制軟體

給客戶開發了一套軟體,並部署在客戶的伺服器上。為了方便維護,開了遠端控制。不過客戶使用的是聯通的網路,公司是電信網路,遠端控制很慢,於是考慮如何降低網路流量,將遠程伺服器的螢幕解析度降低、顏色數降低,不過操作還是很卡。考慮到一般操作不需要即時重新整理螢幕,只有點擊滑鼠或者輸入字元後需要擷取最新的螢幕映像,於是按照本思路自己寫了一個遠端控制的軟體。 關鍵技術:控制方式:使用B/S方式,用戶端直接用IE訪問。伺服器端直接通過HTTP協議接收指令,經過搜尋,Net直接提供了HttpListener用於

對於軟體過程和專案管理的一些雜亂的想法

我的理解,項目,是為達成一個或多個目標,在某些條件的限制下,做出的計劃和工作。從理論上講,目標、條件都是客觀的因素,只要把握客觀因素,在分析達成的可行性後,目標就一定會達成。但是,事實上卻並非如此。因為,客戶對於目標的理解、與項目人員對於目標的理解,以及項目成員間對於目標的理解,存在或多或少的偏差。而對於存在的條件限制,由於條件比目標往往來得更加隱蔽(人總是喜歡好的東西),就導致了更多的不同的理解。客戶對於自身業務,通常情況下是比較熟悉的,那麼客戶對於目標和條件的理解,就取決與這個客戶的素質和能

激動 – 《贏在測試:中國軟體測試先行者之道》

今天睡了個懶覺,起來開啟Google Reader看到一本關於測試的新書:《贏在測試:中國軟體測試先行者之道》,很激動,因為第九章是華姐的“服務的心”。相信這本書會對所有測試的同行有所啟示,因為那些都是非常寶貴的經驗。這裡有一篇別人寫的讀後感(書中被採訪者之一):如何成為一個優秀的測試工程師  內容簡介本書是一本傳承軟體測試經驗和人生經驗的書。作者採訪了11位軟體測試領域的專家,他們是微軟、IBM、Google、東軟和金山等知名公司的進階測試管理員,

介紹一款資料管理軟體EverNote

原來一直用OneNote來做資料收集。資料收集軟體很重要的一點就是需要的時候要能很容易地找到所需資料。OneNote是通過[筆記本]=>[工作區]=>[頁]的嚴格階層來管理資料,有個假定就是資料是可以納入一個樹狀系統並且各個節點之間沒有交叉。但這個明顯是有問題的,比如我有兩個資料夾,一個是[李白],一個是[邊塞詩],那李白的《關山月》(明月出天山)應該放到哪個檔案夾下去?或者在[李白]之下再建立一個[邊塞詩]的檔案夾?那是不是還要在[王昌齡]下也要建立一個[邊塞詩]目錄?如果以後再想

商業軟體編程很無聊

原文是ThoughtWorks一哥們在06年寫的But Martin, Enterprise Software IS Boring,中文世界裡Google前幾頁主要都是g9的那篇 商業軟體編程很無聊 ,沒找到原文譯本因原文在牆外,就拷貝到牆內一份  But Martin, Enterprise Software IS BoringMartin Fowler writes about Customer Affinity, a factor he believes distinguishes a

基於自然語言的軟體工程和程式設計(下)

軟體發展至今,無論是程式設計語言,還是軟體工程,乃至是互連網的趨勢發展,都是飛速發展。於是,我們便迷茫於這樣形形色色的語言和概念之間,無所適從。其實,我們不妨返璞歸真,回到最初,讓我們從語義出發,來討論這形形色色的種種,你是否恍然大悟呢?前文索引:基於自然語言的軟體工程和程式設計(上)基於自然語言的軟體工程和程式設計(中)10.

從設計原則談軟體開發(三)

        今天被一個女生拒絕了,大受打擊。來這繼續把這個系列寫下去。        之前寫過了OCP(開放封閉原則),SRP(單一職責原則)。今天的東西就稍微簡單一些了。       

從設計原則談軟體開發(一)

      幾天一直在研究著一些設計模式,作為初學者,我想很多人可能都會有這樣的感覺,就是很多設計模式看上去都大同小異。那是因為我們並沒有過多的項目經驗,因此並不能想象到何處應該應用何種設計模式。     

實效的軟體開發——談些常見的錯誤觀點

上周六,公司進行了一次技術培訓,培訓的內容無外乎就是常見的一些重構,敏捷開發的觀點,當時因為有些事沒有去聽,但之後聽同事說了一些關於培訓內容的情況,也看了看培訓的大致講義,其實就是將重構等一些經典書籍的簡單匯總,談了些常識,原則性的東西。那麼在這裡,我不是反對他的觀點,當然,我也沒有這樣的權利反對,只是語言是最容易產生誤會的,我只是糾正同樣一句話給人帶來的錯誤認識。1. 代碼和注釋的關係在培訓上,應該是說了這樣的話,好的代碼是不需要注釋的。這裡我就談談我對注釋的看法。注釋的產生有三個目的:A.

從設計原則談軟體開發(四)

        上一次說LSP(李氏代換原則),寫的有些著急。很多東西都沒有寫出來,這次首先來補充一下。        其實就是補充一個例子。這是《JAVA與模式》中的一個例子,是說正方形是否可以繼承自矩形。我相信基本任何一個讀過小學的人幾乎都不會不假思索地(包括我)說,正方形就是特殊的矩形,當然可以繼承了。但是卻恰恰相反。理由如下:在矩形中應該有這樣一個方法,是改變矩形的長和寬,這個時候假設有一個方法是void Change(double 長,double

縱談軟體預構(二)——需求確立

         今天從服務談起,21世紀的今天,事事講究服務,在IT界,服務這個概念也日漸興起,越來越多的概念都涉及到了這個詞:Service。從Web service,到SOA,Service可謂是無處不在。         在我眼中,軟體業就是一門服務行業,軟體開發的目標用最簡單的一句話來概括——用最短的時間開發出最好的軟體,這句話是我整個“軟體預構”系列的核心,重點依舊是那兩個詞:最快,最好!         好了,中心確立,那現在就從這兩個點展開談起。         先說快,談到快,

縱談軟體預構(一)——開篇

      非常偶然地學到了一個概念,叫預構。接下來的時間,就對預構的各個方面做下簡單的探討。      首先,我們先來看下什麼叫軟體預構。聽到軟體預構這個詞,相信很多人第一個想到的詞都是“軟體重構”,我也不例外。但是這兩個詞完全是兩個概念。     

總頁數: 852 1 .... 340 341 342 343 344 .... 852 Go to: 前往

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.