2011-02-16 139 views
11

好了,香港專業教育學院在Delphi現在已經被編程爲3 - 4年,並認爲自己是一箇中間層次的應用設計師的概念有正確的理解。但是我如何變得更好?我剛在看一對夫婦我經常(virtualtreeview,asynccalls)使用組件的來源,並在那裏的代碼只是樹樁我。是的,我可以理解它的一部分,但其他的東西只是在我頭上。德爾福 - 如何提高

那麼,是提高我的編程abililty最好的資源?書籍,博客或其他信息來源?

+0

這個問題是「主觀的和無法回答的」。 – 2011-02-16 01:38:23

+4

也許是這樣,但我認爲這將是有用的信息,不僅幫助我自己而且幫助其他人。 – Simon 2011-02-16 02:52:48

+0

這很有用,但不能客觀回答。投票結束並轉移到程序員SO,在這些主觀問題屬於。 – 2011-02-16 08:07:14

回答

11

編程技巧就像肌肉;改善它們的最好方法就是鍛鍊它們。如果你想學習成爲一個更好的編碼人員,那麼你需要完成一個比以前更艱苦的項目。想出一個你想寫的東西的想法,但不知道該怎麼做,並開始寫作。一旦你對你不理解的概念,跑起來,研究他們,你會不斷地添加新的概念和技能,以您的劇目。

-2

virtualtreeview的代碼是可怕的。別擔心。

爲了獲得在面向對象編程真的很不錯,你可能想嘗試的Smalltalk一段時間。對於完全不同的東西,請添加Seaside Web框架。

[編輯]有幾個原因,尋找到海邊是一個好主意。這是對像HTML,CSS和JavaScript的暴行創造卓越的抽象,使得由此可以做web開發以合理的方式的一個很好的例子。它展示瞭如何創建流暢的界面,以及如何使用它們來提高效率。

經過20年的Turbo Pascal和Delphi的,我的編碼風格,使用的Smalltalk的顯著改善。早應該找到它。

Virtualtreeview另一方面包括嚴重的結構化代碼的巨大量的。沒有抽象,方法太長,數據結構不好。它具有的唯一優點是它被廣泛使用,所以如果你繼續使用那些使用得很好的零件,你不太可能遇到錯誤。

[EDIT2]而你舒服Smalltalk和海邊後,嘗試寶石,一個面向對象的數據庫運行它。這將向您展示數據庫應該如何(不可見),並讓您從此之後反對關係數據庫。

4

我認爲,如果你你會成長很多你的Delphi能力:

  1. 學習如何構建組件。閱讀Ray Konopka在Custom delphi Components上的book或他的EDN article.

  2. 研究JEDI JVCL和JEDI JCL源代碼。作爲信息來源,Jedi API庫和JWSCL也很有價值。 MSDN文檔(Microsoft)也是非常寶貴的,作爲您需要與之交互的各種Windows子系統的平臺文檔來源。

  3. 獲取Marco Cantu的Mastering Delphi書或Texeira和Pacheco的Delphi開發人員指南的副本。

  4. 瞭解測試驅動開發,單元測試,版本控制(瞭解Subversion,Git,Mercurial等多種系統),持續集成和其他專業級技術。

3

如果你想弄清楚那些不是你自己的代碼,你必須先從髒兮兮的開始。將您想要了解的代碼部分分解爲「最小」程序,並逐行進行調試。大多數情況下,這會告訴你在低層次上發生了什麼。有時候,只有這樣才能讓你明白你的需要。

但是當你被代碼構造工作的難以理解的時候,然後輸入違規行的部分到Google的答案。這通常會引導您閱讀博客文章或討論類似代碼的文章,以解釋這些概念以及代碼的工作原理。

有時我會去Google Code Search並選擇Pascal/Delphi語言進行搜索。我發現這裏的代碼給出了不同的觀點,並且經常有評論和其他信息,有助於理解這些想法。

如果我不能找出其他方法,我來到StackOverflow,這是一個很棒的資源,從Delphi知識淵博,經驗豐富的Delphi程序員的Delphi信息。如果這是你的東西,作爲一個已經中級的程序員無法解決的問題,那麼它可能會在這裏提出一個很好的問題,你會在短時間內得到一些很好的答案,我肯定會幫助你理解和學習。

10

瞭解使用您不熟悉的概念的代碼很難。我的建議是:

  • 挑選一個你不明白一個或兩個項目,並重新實現它們。從你的問題中,嘗試編寫你自己的樹(或列表)組件,並嘗試編寫一個簡單的線程框架,在這個框架中你可以派遣工作並在某個特定時間恢復工作。這些是你提到的兩個項目的簡化版本。

    作爲程序員,你邊幹邊學。沒有多少理論能夠彌補解決問題的經驗。當你解決這兩個問題時,Virtual TreeviewAsyncCalls的作者會遇到一些相同的問題。 (如果你遇到困難,請在這裏提問!)你不僅會學到他們學到的東西,而且你可能會回來重讀他們的代碼並理解他們正在做的一些事情。

    不要因爲你有工作實現周圍的概念(原始項目)和複製代碼而感到試探 - 隨時看看它的靈感,但不要複製它。自己寫。

    請記住,Mike Lischke和Andreas Hausladen都非常聰明。如果工作很辛苦,不要氣餒。許多程序員去他們的整個職業生涯只能夠勝任(因爲它聽起來你)不推自己去嘗試或學習更難的事(所以如果你不介意我這麼說的話,對你有好處的問這個問題!)

一對夫婦的其他想法:

  • 學習另一種語言。德爾斐偉大,但你用語言「思考」,所以如果你學好另一種語言,你會接觸到其他概念或思維方式,或不同的方式來做同樣的事情。這真的打開你的想法。

    例如,C++是偉大的使用RAIItemplate metaprogramming(這比什麼德爾福的模板,讓更強大的),頗有些令人驚奇的事情在各種額外的庫如boost,並搬起石頭砸自己的腳:)一個功能語言將徹底改變你的想法(我必須承認在這裏有點虛僞:我已經接觸到他們,但不知道'我自己',我想。)Objective C可能會有所不同採取什麼面向對象的方式(它和C++都是面向對象的基於C語言,但非常不同)。你明白了。

  • 查看這些特定項目:此頁面上的一個答案建議逐行檢查它。我發現要理解我以前沒有用過的代碼,這可能是壓倒性的。我曾經在Embarcadero工作人員的博客上看過一些建議,使用profiler,因爲它會給你一個很好的高級視圖(a)程序的所有類/方法/部分和(b)哪些是最常用的,可能最重要的部分,以及它們如何結合在一起。我不能讚揚這個建議,但我認爲這是很好的建議。我建議使用AQTime

    因爲這個原因我找到了'find Foo,study the source'這樣的答案,無益:你是一個編碼員,當然你會看到源代碼! 如何查看來源,這是一個更有趣的問題。

  • 最後,如果你已經到了「查看幾個[項目]的源頭並且代碼在那裏只是樹樁[你]」,或者如果你做了以上的一些操作,不明白的東西,在這裏問!

[*]腳註:我不主張不 知道基本的理論,只是 ,有一個知識/信心 你這樣做你自己,非常必要的東西 得到。

4

的最佳方式(對我來說),以瞭解代碼是如何工作,我不能看着單獨的代碼遵循的是獲取下來,髒,觀察有問題的代碼。放下多個斷點並在代碼運行時開始跟蹤代碼。

您越是這樣做,您越能夠從後續跟隨代碼的能力提高。

此外,你還沒有那麼做,我會強烈通過以下本書的建議讀:

設計模式:可複用面向對象軟件的基礎(ISBN 0-201-63361-2 )

寫於1994年,它是今天仍然是相關的,因爲它是當時(如果不是更多)。

它最重要的是,它教你識別代碼特定的模式,給你一個詞彙來形容整個代碼段做,只是一個單一的術語。

在模型中,您可以深入瞭解一些複雜的代碼片段以及它如何交互,您不再需要保留所有細節,而是可以在您的腦海中構建更高層次的抽象將自己的代碼描述爲基於特定設計模式的功能塊的交互。

這自然假設有問題的代碼被設計得很好。有時候,一些代碼簡直是一團糟,可能會使意大利麪條嫉妒,並且無法遵守和理解代碼並不是你的失敗,而是編寫代碼的人。

2

編程很複雜。

典型RAD應用程序具有與在事件處理程序代碼的形式,數據模塊使用查詢,而不是一個單一的類。

你可以寫幾百個應用程序一樣,學習無非就是如何使用各種組件和它們的屬性和事件等。

這是德爾福的主要問題,它很容易和自然做的事情錯了。 RAD = BAD。 不幸的是,大概90%的應用程序都是這樣寫的。

那麼這種方法有什麼問題?它缺少任何架構。爲什麼那麼糟糕? 它不會變化。當您的需求發生變化時,您將不得不進行比正確設計的應用程序更多的更改。

現在人們普遍認爲應用程序應該被分層結構化。

層的典型的分離是

  • 業務對象/規則
  • 數據映射/持久
  • GUI

隨着分離乾淨商業層可以具有的Win32 GUI,Web GUI中,移動設備圖形用戶界面...

乾淨分離的持久層,你可以哈相同的業務和GUI層從Interbase轉換到Postgress。

寫測試也容易得多。

現在讓我馬上警告你,這是一條漫長而艱難的路。這將需要多年的時間來掌握,你永遠不會完全完成。

當你讓你的應用程序設計良好,具有這些層設置,你得到它的工作,你興奮地展示給你的同事,他們會給你一個奇怪的表情,說:嗯,我剛落,這個查詢在表單上執行,看起來是一樣的。但你會更清楚。

我不同意學習另一種語言的建議。也就是說,恕我直言,只是繞過這個問題。正確組織和構建您的應用程序的技能是語言不可知的。任何真正的面嚮對象語言都是足夠的,所以在這一點上不需要學習另一種語言。

我也不認爲看VirtualTreeView或類似的控制源會教你很多。您將瞭解到Winapi,但儘管有用,但這不會有助於應用程序設計。因此,總結一下,google瞭解關於應用程序設計,業務對象,體系結構,OPF,模式和測試的資源。

0

我不確定對您的問題有一個簡單的答案。

不斷磨練你對基礎知識的掌握的一種方法是通過練習和重複。一個有趣的方法就是所謂的code kata,它從武術中獲得靈感。

這個概念本身是語言不可知的,而且我非常喜歡TDD。 Julian Bucknall好像也是粉絲。有些人甚至record their katas。快速谷歌搜索變成了很多不同的參考。

0

如果您作爲團隊的一員工作,請使用Code Collaborator或ReviewBoard等工具參與同行代碼審查。您不僅可以從別人那裏學習,也可以從代碼中學習他們的意見,但是您會對自己的工作產生批判性看法,並且會很快開始更好地編寫代碼。