其他

我常常思考是什麼造就了好的代碼 (good code).使用最新的語言特性、最佳的模式(best pattern)、最好的層次化設計(best layered design)、使用最少記憶體、亦或最佳的執行效能(performs the best)?很明顯，這些項目都會在設計時考慮，但它們是首先要最主要的原因嗎(the first things you think of)？或許並不是！那什麼呢?經過一段冥思苦想之後,我有了結論.顯然代碼或系統應當可裁剪(scalable),正確(correct

在別人實現的基礎上進行開發，基本是一種常態。特別是對原來的代碼陌生的情況下，有沒有什麼好的實踐方法呢？基本原則:類似重構一樣，盡量減少對原有流程和結構的修改，最好能相容原有結構。上來就按自己的相法來修改代是比較容易的，這樣做很大程度是因為理解原有的代碼需要較長的時間且有一定的難度，但這樣會增加系統的複雜度，也會引入許多不必要的風險。除非得到項目負責人的同意，否則相當然的直接動手重寫，絕非是什麼好事！那麼如何做呢？要花大量的時間從頭閱讀代碼嗎？你以為文檔寫得那麼好嗎？嗯，閱讀代碼和文檔是免不了得，

人可能出於以下原因不大情願去做一件事:  1.太簡單  2.太繁瑣  3. 太難  4. 認為沒有價值或意義 (或對工作而言，或對個人而言)  5. 時間上安排不了  6.

沒有人是完全獨立的孤島，每個人都是整體的一部分。——約翰·多恩 (至少你擁有95%以上的知識在網上都可以找到!

轉自以前在世界經理人寫的部落格.轉載請註明出處:http://blog.csdn.net/horkychen    以前總執著於學著抓大放小，於是自己也不斷的學習各種方法論和創新思維理論，努力提高自己的層次。但是最近的工作中卻狀況不斷，許多細節產生的問題而爆發出來。這一度使我困惑於對理論學習的懷疑！總不能提高的是對問題麻木的層次吧！    經過自我反思，發現根本原因是自己對於"大"與"小"的判斷有問題。什麼是"大"?

此處簡單介紹一下運用免費的UML工具Bouml產生C++代碼。在BoUML中的各個視圖和組件基本有以下的結構:   Project     -> View         -> Diagrams         ->

轉自之前在世界經理人寫的部落格.轉載請註明出處:http://blog.csdn.net/horkychen在<<德魯克日誌>>中提到了一句話:"重要的是能做什麼，而不是不能做什麼!"

轉載請註明出處:http://blog.csdn.net/horkychen測試程式時會出現找不到指定的庫或庫函數的錯誤，表示某個依賴庫不存在或版本不正確。如果使用的是動態載入的動態庫所依賴的包不存在，如果程式沒有做好異常處理的話，會讓你很難定位到問題。比如GDI+庫。假設一個程式A,調用了動態庫B,而B連結了GDI+，這時運行在Windows

Promoted Tweets是Twitter的一個廣告平台。本文作者是發現在Twitter官方的應用中並沒有顯示一些廣告，而決定分析Twitter是不是做了什麼手腳。沒有詳細的步驟，只是可以瞭解一些工具的使用和Twitter的一個小動作。 Mac上的Twitter有些奇怪的行為: Timeline上的一些內容被過濾掉了. 就是一個對比，相較網頁版本，其中"howaboutwe.com" 的內容沒有在應用程式中顯示出來。 這是一個Bug,還是Twitter自己打破了規則?

轉載請註明出處:http://blog.csdn.net/horkychen  *今天建立了一個類別:生產力。主要想集中寫一些提升工作效率的思考和實踐，用技術解決問題。據說Google都有專門的生產力部門，專司研究工具和方法，可見生產力雖然零碎，但如果能有系統的加以研究，一定會些收穫。 如果工作中有一些需要從網上擷取資料的工作，比如擷取哪些人還有多少Bug之類的事情，那麼下面的內容或許可以給些啟發。 網頁資料基本是以HTTP

轉載請註明出處:http://blog.csdn.net/horkychen循環複雜度用來評價代碼複雜度，以函數為單位，數值越大表示代碼的邏輯分支越多，理解起來也更複雜。循環複雜度可以成為編碼及重構的重要參考指標，以指導撰寫可讀性高的代碼。有關循環複雜度的定義，可以自行搜尋。《代碼大全》有如下的定義:計運算元程式中決策點數量的技術 (代碼大全2,19章P458)1.由1計數，一直往下通過程式。2.一旦遇到以下關鍵字，或者其同類的詞，就加1：  if, while, repeat, for,

隨著媒體進入讀圖時代,使用者對瀏覽網路相簿和圖片新聞的需求,必然日益強烈. 瀏覽器是否可以像EverNote Clearly那樣增強文本閱讀的方法來提高圖片閱讀體驗呢?未來有沒有可能將現在各家獨立開發的圖片slideshow工具,統一為HTML5標準標籤加以支援呢? 就好像現在的Audio, Video一樣. 也有全螢幕模式,也可以設定控制欄.只是要注意畫面切換的效果. 這一切行為可以交給瀏覽器完成,當然再支援自訂效果. 像是Web Audio那樣的機制. 至少在效率上會提高很多,

在這裡列舉幾個在Chrome下的開發外掛程式，希望可以協助提高工作效率，更主要的是拋磚引玉，更多的好工具還要不斷髮現。1. Developer Tool 第一位的自然是Chrome整合的開發工具了，幾乎涵蓋了所有你需要的功能。查看組件、擷取XPath、效能分析、更改瀏覽器UA、調試JavaScript等等。特別值得一提的是在Element中擷取xpath的功能，對於解析HTML資料會很有協助: 2. User-Agent Switcher for Chrome雖然在Developer

作者：Sanjay Ghemawat, Paul Menage原文翻譯：ShiningRayTCMalloc要比glibc

找了一段時間，發現了MSHTML沒有提供繞開列印對話方塊的方法。昨天試了下一個Windows Web Browser Control,居然可以了，下面做個記錄: m_Browser.Navigate(sHttpAddress, &vtNULL, &vtNULL, &vtNULL,

寫了一個小程式，來檢查一下List中如何管理儲存的對象。#include "stdafx.h"#include <list>#include <iostream>using namespace std;class MyClass{  public:  int nMember;  int * pMember;  public:       MyClass(void) {  cout<<"New my Class"<<endl;  nMember =

注釋的恰當用法是彌補我們在用代碼錶達意圖時遭遇的失敗。我們總無法找到不用注釋就能表達自我的方法，所以總要有注釋，這並不值慶賀。 如果你發現自己需要寫注釋，再想想看是否有辦法翻盤，用代碼來表達。 注釋會撒謊。注釋存在的時間越久，就離其所描述的代碼越遠，可能變得全然錯誤。原因很簡單：程式員不能堅持維護注釋。 程式員應當負責將注釋保持在可維護、有關聯、精確的高度。我同意這種說法。但我更主張把力氣用在寫清楚代碼上，直接保證無須編寫注釋。真實只在一處地方有：代碼。只有代碼能忠實地告訴你它做的事，所以應當減

轉載請註明出處:http://blog.csdn.net/horkychen 程式設計語言的發展和自然語言是相似的，根本上都是以滿足溝通需求為驅動力的。其中也不乏溝通的障礙，這裡做個簡單的探討！ 1. 語言是什麼語言是溝通工具，是為了交流資訊而產生的。(語言套件含說和寫兩個方面，這裡主要探討寫。) 從結繩記事到現代語言，語言(包含文字)的每一次變革都是為了促進交流而進行的。最初是不需要語言和文字的，沒東西可記。

 團隊應該一致同意採用一套簡單的格式規則，可以運用將這些規則自動化的工具。代碼格式關乎溝通，而溝通是專業開發人員的頭等大事。或許你認為“讓代碼能工作”才是專業開發人員的第一優先順序。你今天編寫的功能，極有可能在下一版本中被修改，但代碼的可讀性卻會對以後可能發生的修改行為產生深遠影響。原始代碼修改之後很久，其代碼風格和可讀性仍會影響到可維護性和擴充性。即便代碼已不複存在，你的風格和律條仍存活下來。向報紙學習看看寫得很好的報紙。從上到下閱讀，在頂部，有頭條，告訴你故事主題。然後第一段是大綱，接著細節

 6.1 資料抽象隱藏實現並非只是在變數之間放上一個函數層那麼簡單。類並不簡單地用getter和setter將變數推向外間，而是暴露抽象介面，以便使用者無需瞭解資料的實現就能操作資料本體。如下面是一個閱讀器，需要擷取當前閱讀進度。介面定義如下：   public interface PaperReader   {       double getTotalPages();       double getCurrentPageIndex();   } 而較好的方式是:   public