-
1 # 冷葉
-
2 # 彥柯老吳
我感覺不太適合回答這個問題,因為很少照程式碼寫,也沒背過,我太懶,只是看別人的代。我拿到要做的東西,第一件事不是擼起
袖子就是幹,先在腦子裡過一遍,整理一下思路,拿個最簡單的例子。我要用集合做一個簡單的增刪改查,一個關於書的集合吧。你學了一個月,應該有思路吧
你想對書進行操作,先得有書吧,可以自定義book類,至於為什麼,就不用我說了吧。你順著這個思路往下繼續。我們平時工作的時候就發現,調bug的時間比寫程式碼的時間長,寫程式碼的時間比設計的時間長,把時間多花在設計上,寫程式碼事辦功倍,bug率低,尤其對新手來說,個人感覺會設計比照抄寫程式碼更重要
-
3 # 散居獵人
不要照著寫也不要揹著寫,看題目自己寫!
有思路?不需要思路,把問題和模型描述清楚就行了。
如果你糾結於照抄背誦和所謂思路,建議放棄程式設計學習。
-
4 # 山羊AM
都行,最重要的是多寫,首先你要想實現一個什麼專案,然後可以把任何地方的程式碼搬過來,多搬幾次就大概知道怎麼回事了
-
5 # 軫念信箱
前段時間,B 站推出的青年節演講影片《後浪》在朋友圈刷屏,看著“後浪”們豐富多彩的生活,同事們紛紛自嘲自己就是被拍在沙灘上的那一個,被生活瘋狂蹂躪。然而在程式語言界,“後浪”們掀起的波瀾則十分有限。與近年來陸續湧現的新興程式語言相比,那些出道即巔峰、一巔幾十年的“前浪”們,似乎還沒有要退位讓賢的意思。
在 TIOBE 公佈的最新程式語言排行榜中,排名前十的語言中有 8 個誕生於上個世紀 90 年代,最“年輕”的是誕生於 2001 年的 C#,而位於榜首的 C 語言距今已有 48 年的歷史。如果我們再來縱觀自 2002 年以來的程式語言排行榜,基本上也還是這些老牌程式語言的身影,尤其是 C 與 Java 這兩位“前浪”老大哥的江湖地位一直難以撼動。
數十年來,陸續出現的新興程式語言不在少數,其中不乏一些以取代某種老語言為目的而設計的,那麼這些程式語言界的“後浪”們,是否能夠追上“前浪”們的腳步呢?下面不妨讓我們來看看這些年程式設計界的知名“後浪”們。
前浪 C++(1979)VS 後浪 Go(2009)
誕生於 2009 年的 Go 語言堪稱程式語言中的“星二代”。Go 的早期作者有三人,分別是 Rob Pike,Ken Thompson 和 Robert Griesemer,每一位的來頭可都不小。Rob Pike 曾是貝爾實驗室的 Unix 團隊以及 Plan 9 作業系統計劃的成員,與 Thompson 共事多年,並共創出廣泛使用的 UTF-8 字元編碼;Ken Thompson 則是 B 語言、C 語言的作者,Unix 之父,1983 年圖靈獎和 1998 年美國國家技術獎得主;而 Robert Griesemer 在開發 Go 之前是 Google V8、Chubby 和 HotSpot JVM 的主要貢獻者。
2007 年,Rob Pike 認為 C++ 在 Google 分散式編譯平臺上的編譯過程太過漫長,於是他和 Robert Griesemer 開始探討 “簡化程式語言相比於在臃腫的語言上不斷增加新特性,會是更大的進步”。兩人一拍即合,隨即說服了身邊的 Ken Thompson,三人決定要搗鼓一門新語言。幾天後,他們在 Google 內部發起了一個叫 Golang 的專案 。很快,一個在 C 語言基礎上進行了最佳化的新語言誕生了,這就是 Go 。
作為一個設計目的就是為了取代 C/C++ 的新語言,Go 的語法在很多地方借鑑了 C/C++ 。比如用花括號作為定界符,以分號作為語句結束等等,這使得 Go 很容易就能被精通 C/C++ 的開發人員接受。而在沿襲 C/C++ 基本語法的基礎上,Go 新加入了很多針對當下流行的分散式系統的實用功能,比如超輕量級的執行緒 goroutine,在高併發的系統中,可以按照多執行緒的方式寫程式,從而保證邏輯的清晰和簡單,又可以獲得非常高的效能。而同樣的事情在 C++ 中則需要呼叫第三方框架,如果用多執行緒,會導致系統執行緒過多帶來大量的上下文切換 overhead;如果採用基於訊息的架構,雖然可以獲得較高的效率,但程式邏輯會被打散,可讀性和可維護性較差。
此外,Go 語言作為 Google 大力支援的“親兒子”,擁有編譯、測試、除錯、效能分析等一整套成熟的工具,編譯效率極高,再加上其還內建了 http、json、xml、正則表示式等很多後端系統開發中常用的庫,可以說是一門已經非常成熟的工程化開發語言。而在這方面,C++ 則需要用到大量的第三方開源工具或庫,在工程上需要花費更多的精力進行技術選型,同時也不利於後期維護。
基於上述的優點,Go 語言被公認為非常適合構建命令列實用程式和網路服務等,尤其是雲計算場景下的高併發應用,如今廣泛流行的容器引擎 Docker、容器編排系統 Kubernetes 都是用 Go 編寫的,Go 也因此被一些人稱為“容器語言”。
雖然 Go 在很多方面已經超越 C/C++,並且在雲原生相關領域佔有了一席之地,但是仍然難以撼動 C/C++ 語言在大量工業基礎設施終端的地位。C/C++ 的優勢仍然在於它的執行效率,如果是低階裝置驅動程式、核心空間作業系統元件以及其他需要嚴格控制記憶體佈局和管理的任務,C 依然是不二之選。
目前,Go 在各種權威程式語言排行榜上都名列前茅,且一直呈上升趨勢,在雲原生建設如火如荼地當下,Go 至少在“雲”這一領域已經完成了對前輩的超越。
前浪 C++(1979) VS 後浪 Rust(2010)
Rust 是繼 Go 之後另一個試圖取代 C/C++ 的新語言。2010 年前後,隨著大規模業務的拓展和分散式計算的流行,Graydon Hoare 也和 Rob Pike 一樣看到了 C++ 等傳統程式語言在高併發場景下的缺陷,試圖創造更優秀的語言來替代它們。Rust 原本是 Graydon 從 2006 年開始搗鼓的個人專案,隨後該專案得到了 Mozzila 基金會的資助,而 Graydon 本人也於 2009 年加入 Mozzila 公司,帶領團隊完善 Rust 語言的開發。2010 年,Mozzila 正式對外透露了 Rust 的存在。2013 年,Mozzila 基金會宣佈將與三星合作,使用 Rust 語言開發一款瀏覽器引擎 Servo,成為首個使用 Rust 編寫的大型專案。2015 年,Rust 首個 1.0 正式版釋出。
Rust 最初是 Mozilla 為了解決軟體在語言級別上無法真正利用多核計算帶來的效能提升而建立的,這一點與 Go 有些類似。相比前輩 C++,Rust 在程式碼安全這一特性上下足了功夫。比如記憶體安全方面,Rust 在安全程式碼裡不容許空指標、懸垂指標和資料競爭,這些問題在編譯階段就無法透過。Rust 社群核心開發者 Nichols 表示:“之前,我們只能使用 C 或者 C++ 才能編寫具有較低記憶體佔用空間的高質量程式碼。但是,在生產程式碼中使用這些語言需要你手動管理記憶體並瞭解可能導致未定義行為的所有方法。”Nichols 指出,不斷擴充套件的 CVE 程式碼漏洞資料庫證明,即使是最優秀的程式設計師也疲於應對層出不窮的程式碼漏洞。“為了確保你安全地使用記憶體,Rust 編譯器非常嚴格,這樣你就可以專注於你真正想要解決的問題。”
儘管 Rust 憑藉其程式碼安全的特性獲得了部分開發者的青睞,但由於其無論是在效能還是語法上,均不足以顛覆 C/C++,再加上其學習曲線並不平滑,因此與“家大業大”的 Go 相比,Rust 在前期的發展不溫不火。直到去年 7 月,微軟突然宣佈將擁抱 Rust,探索用 Rust 作為 C/C++ 和其他語言的安全替代方案,以此來改善應用程式的安全狀況。微軟認為 Rust 是目前業界系統程式設計的最佳選擇,原因不僅是它能夠以記憶體安全的方式編寫系統級程式,還在於其精密性。
微軟此舉讓 Rust 在開發者中的地位直線上升,越來越多的企業和個人開始關注並重視程式碼安全的問題,從而重新審視這門新語言,這主要體現在 2020 年以來圍繞 Rust 語言發生的幾件事情:Linux 核心維護者表示願意接受用 Rust 開發 Linux 驅動;AWS 宣佈贊助 Rust;微軟更進一步,在今年年初開發並開源了受 Rust 啟發的新程式語言 Verona;最近,蘋果也站出來擁抱它,計劃將部分 C 程式碼移植到 Rust 。
目前,Rust 語言的發展總體來說仍然比較緩慢,根據最新的一份調查報告顯示,大多數不願意接受 Rust 的開發者認為,Rust 目前的問題主要在於學習曲線陡峭、缺少所需的庫、缺乏 IDE 支援等。可以說,Rust 的發展仍然任重道遠。
前浪 Objective-C(1986) VS 後浪 Swift(2014)
Swift 是為數不多的成功把“前浪”拍在沙灘上的“後浪”。
2010 年,或許是受到競爭對手 Google 推出 Go 的啟示,Apple 高層也決定開發一套新的程式語言,用以替代使用了數十年的 Objective-C,而最早接到這個任務的人正是 Chris Lattner。Chris 在大學還沒畢業的時候就成為了業內知名的編譯器專家,其碩士期間發表的論文奠定了 LLVM 框架的發展基礎。在加入 Apple 公司以後,Chris 創造的 LLVM + Clang 成為了 Apple 軟體產品的編譯框架。而 Swift 語言就是 Chris 繼 LLVM 與 Clang 之後的又一力作。
Swift 是一門博採眾長的現代語言,在設計的過程中,Chris 參考了 Objective-C、Rust、Haskell、Ruby、Python、C# 等語言的優點,最終形成了 Swift 的語法特性。與前輩 OC 相比,Swift 的語法更加簡潔,例如行尾不再需要分號,if/else 語句也不需要括弧,呼叫方法時 [ ] 也不再巢狀,支援字串插入,省略了 OC 中的 %s,%d,%@ 等等。同時,Swift 把 oc 標頭檔案 .h 和實現檔案 .m 合併成了一個程式碼檔案 .swift,使得Swift 程式碼更易於維護。最重要的是,擅長最佳化的蘋果工程師讓 Swift 的執行速度能夠逼近 C++,是 OC 執行速度的近 1.4 倍。在 Swift 誕生以後,蘋果軟體的開發者只需要維護原來一半量的程式碼檔案,大大提高了開發效率,降低了維護成本。
目前,Swift 幾乎已經完全取代 Objective-C ,成為蘋果旗下 MacOS 、iOS 的主流開發語言,很多剛剛入行的 iOS 新人開發者甚至沒有接觸過 Objective-C 。不出意外的話,Objective-C 很有可能在不久的將來被人們逐漸遺忘。然而 Swift 團隊的目標似乎遠不止於幹掉老大哥這麼簡單,在即將釋出的 5.3 版本中,Swift 將增加對 Windows 和其他 Linux 發行版 PC 作業系統的支援(目前僅支援 MacOS 和 Ubuntu),至於其後續發展如何,我們還將持續關注。
前浪 JavaScript(1995) VS 後浪 Dart (2011)
Dart 是 Google 工程師們繼 Go 之後造的又一個輪子。與 Go 類似,Dart 最初也是一群 Google 工程師覺得 JavaScript 不太行,因此想要重新造一個更好的語言取代它,於是就有了 Dart 。
Google 工程師認為,JS 當初從設計到釋出的時間極短(僅為 7 個月),在語言規範和謹慎性方面存在先天不足,比如語法過於鬆散、缺乏模組化能力、核心庫不完備、程式語言範型不明確等,且難以用改良的方式來修復。事實上,Google 工程師多年來也為改善 JavaScript 的效能做出了諸多貢獻,特別是透過 V8 引擎強化了 JIT 對 JS 的編譯能力,從而讓 Chrome 瀏覽器的效能一騎絕塵。 這足以說明當時的 JavaScript 在 Google 工程師眼裡確實存在很多問題。
Dart 最初也是作為一種在瀏覽器中執行的指令碼語言而生,Google 還專門在 Chrome 中內建了 一個 DartVM 引擎用來對 Dart 進行推廣 。得益於 Chrome 龐大的使用者體量,這一舉措讓 Dart 積累了規模可觀的早期使用者群體。
原以為在 Google 的保駕護航下,Dart 能夠穩步發展並最終趕超 JavaScript。然而令 Google 沒想到的是,半路竟殺出了一個 Node.js 。Node.js 是一個 JavaScript 執行環境,它讓 JavaScript 可以開發後端程式,實現幾乎其他後端語言實現的所有功能,這意味著 JavaScript 可以與 PHP、Java、Python、.NET、Ruby 等後端語言平起平坐。從那時起,“ 凡是能用 JavaScript 寫的應用終將用 JavaScript 來寫 ”開始在圈內廣為流傳。值得一提的是,Node.js 正是基於 Google 自己的開源 JavaScript 引擎 V8 開發而來。V8 本來是用於 Chrome 對 JavaScript 的直譯器,鬼才 Ryan Dahl 把 V8 搬到了伺服器上,用來做伺服器的軟體並取得了成功。在往後的幾年裡,前端開發的模式因 JavaScript 而改變,React、React-Native、Vue 等基於 JavaScript 的明星專案迅速崛起,Dart 逐漸被人們遺忘在角落。
然而 Google 一直沒有放棄 Dart 。2018 年,Google 對 Dart 進行了底層重構,並於 8 月推出了 Dart 2.0 版本,將其重新定義為一種同時支援 Web 和移動客戶端開發、具有豐富工具箱和元件的語言。同年 12 月,Google 釋出了用 Dart 編寫的跨平臺應用開發工具 Flutter,讓 Dart 能夠在服務端編寫命令列程式,同時在前端可以編譯成 JavaScript 執行在瀏覽器中。隨後,Google 開始新一輪發力推廣全新的 Dart ,包括為另一個知名前端框架 Angular 推出對應的 Dart 版本,指定 Dart 作為未來的作業系統 Fuchsia 的官方開發語言等,Dart 社群又煥發了勃勃生機。
可以說在剛剛誕生的前幾年裡,作為一門執行在瀏覽器中的指令碼語言,Dart 是完敗於前輩 JavaScript 的。而如今乘著“大前端”的變革浪潮,要說超越 JavaScript 雖然也不太現實(畢竟“凡是能用 JavaScript 寫的東西終將用 JavaScript 來寫” ),但 Dart 在未來一段時間裡還是一個非常有潛力的“後浪”代表。
前浪 Java(1995) VS 後浪 Kotlin (2011)
Kotlin 是 Google 公司繼 Go 之後又一力捧的新程式語言。Kotlin 誕生於 2010 年,出自 JetBrains,並於2012年正式開源。Kotlin 最初的設計目的是為了建立一種相容 Java 的程式語言,並讓它比 Java 更好。
作為一門相對比較新的 JVM 語言,Kotlin 得到了 Google 公司的大力支援。2017年,Google 在 I/O 開發者大會上官宣 Kotlin 正式成為 Android 官方開發語言 。兩年後的 I/O 大會上,Google 再次加碼 Kotlin,宣佈其成為 Andoid 開發官方首選語言。
Kotlin 的語法融合了 Scala、Groovy、Python、Swift 等眾多語言的特性,如果使用過其中任意一門語言,上手 Kotlin 將非常容易。與 Java 相比,Kotlin 引入了函數語言程式設計方式,同時有各種語法糖簡化了程式碼量。但與其他試圖取代“前浪”的新語言不同,Kotlin 走的是一條 100% 相容 Java 的道路(打不過就加入)。眾所周知,Java 這麼多年屹立不倒的原因是因為其發展多年積累的龐大生態,包括豐富的函式庫、IDE、編譯器、成熟的應用生態等等。Kotlin 則可以呼叫 Java 的絕大多數庫,也就可以直接使用 Java 現有的生態,因此很多開發者選擇混用 Kotlin 與 Java。
結語
這些 21 世紀以後(2010 年前後)以取代老語言為目的而誕生的新語言中,能夠順利取代“前浪”的語言屈指可數。有的乘著新技術的東風在某一新興領域成為了行業標杆。有的在與“前浪”的和諧共生中猥瑣發育,靜待日後的逆襲。當然,更多的是消逝在了歷史的長河裡,甚至沒有泛起一絲漣漪……究其原因,如今仍然流行的語言諸如 C/C++、Java、Python、JavaScript 等等,雖然它們大多數誕生於上個世紀,但它們一直以來也都在針對新時代的需求不斷地最佳化,經歷了數十個甚至上百個版本的更迭,很多語言已經與誕生之初完全不一樣了。再加上它們數十年來積累的函式庫、IDE 、編譯器、應用生態等自成一脈的豐富體系,讓“後浪”們難以望其項背。
從商業的角度來說,在行業格局沒有發生顛覆性變革的時候,現有的熱門語言依靠多年積累的龐大使用者基礎,就足以形成壟斷。就算有更好的新語言出現,它們也可以迅速吸收這些新語言的優良特性,就像大企業兼併小企業,或者直接照搬它們優秀的業務功能一樣,讓自己變得更好,也更容易被大部分開發者接受。所以要想在程式語言界把“前浪”們拍在沙灘上,“後浪”們要走的路還有很長很長。
-
6 # 老炮說Java
這個按著已有程式碼敲好還是揹著寫好,我感覺的分階段。我就針對題主提的問題簡單說下吧。
題主說自己是培訓的,說明是剛剛學習java,揹著寫程式碼沒思路也屬於正常現象,因為缺乏經驗。
初級java在學習的過程就是模仿的過程,把javase、ee的基礎學習通透(培訓重點是把基礎理論學習好),怎麼才能通透就是相關基礎的東西多敲幾次,敲多了就成自己的東西。模仿就是學習別人的專案原始碼(包括專案,一些問題處理辦法)?前2次可以跟著敲,敲不是盲目的敲,結合題目以及自己學習到的基礎理解的敲,敲完後你要知道本題或者業務絲路,以及每段程式碼做什麼?
第三次就可以照著絲路敲了,即使某個點卡住了,也要去思考寫出來,這樣堅持多了,自然養成習慣了。
有了習慣,後面多做專案,自然而然就知道程式碼怎麼寫了(思路)。
包括工作5年多的程式設計師也經常從網上找一些程式碼或者看一些優秀的程式碼,抄襲程式碼不可恥,主要是能轉換成自己的就ok,你要把解決問題的方法抄襲過來,要不然下次換個問題又不會了(專案就是很多問題的整合)。
我幹10年了,也會經常借鑑一些優秀礦建中的程式碼設計思路,例如:spring、netty、tomcat等專案。你不模仿別人的程式碼,從來覺的自己程式碼是寫最好的,其實不然。
我會經常在我的知識文章中分享一些經驗,可以看看。
-
7 # 喜趣人生
從小白到高手的修真方法:
第一步:如果你是新手,建議先模仿,就是照著寫,因為你才開始自己是很難寫出來的,先要學習別人的寫法。第二步:學會別人的寫法後總結並思考,結合自身的應用場景進行創新。
總結:之所以能成功 ,是因為我站在巨人的肩上。這句話是由著名物理學家牛頓說的,這是牛頓寫給胡克的信中所出現的一句話,之後就被世人廣泛流傳。
-
8 # 不穿高跟鞋菇涼
Java的學習無非兩種:培訓Or自學,不知道你是參加培訓,還是看影片自學的。
如果是參加培訓的話,一家合格的培訓機構老師肯定不會說讓你照貓畫虎。老師講解是為了讓你更好的去理解,寫程式碼的時候要有自己的思考的。
如果是看影片學習的話,尚矽谷的白嫖課程還是很不錯的。不過自學的話前期可能絕大多數人會照著寫吧!建議一定要思考才行。
無論你是選擇培訓還是自學,切記不是說讓你死記硬背,還是要孰能生巧,要多思考,多練習很重要的。
回覆列表
照著程式碼寫就好了,死記硬背是沒多大用處的,關鍵在於理解,和考試是一個道理。拿設計模式來說,雖然有固定的設計模式,但是,寫法並不是一塵不變的,甚至於設計模式之間的組合使用,是考驗你的理解能力而不是背程式碼的能力。