前一篇提到了 PHP 8 Array 的基本概念,對 PHP Array 還不熟悉的人,可以先閱讀前一篇哦。
這篇接著要來介紹 10 個 PHP Array 的實用方法,讓你對 PHP Array 有更深入的了解,知道 Array 可以用來解決什麼問題,也提高對 Array 應用的熟練度。
本篇將會依序說明及介紹以下十種作法與方法:
前一篇提到了 PHP 8 Array 的基本概念,對 PHP Array 還不熟悉的人,可以先閱讀前一篇哦。
這篇接著要來介紹 10 個 PHP Array 的實用方法,讓你對 PHP Array 有更深入的了解,知道 Array 可以用來解決什麼問題,也提高對 Array 應用的熟練度。
本篇將會依序說明及介紹以下十種作法與方法:
Array 是什麼?簡單來說,Array 是一種資料結構,用來儲存大量相似的資料。
如果沒有 Array,當你要儲存多個類似的資料,例如,三個數字,你必須要宣告並使用三個變數。
$num1 = 10;
$num2 = 20;
$num3 = 30;
但是透過 Aarry 的協助,你只需要使用一個變數。
$nums = [10, 20, 30];
當然 Array 不只讓你更方便地儲存資料,Array 作為 PHP 的核心資料結構,也提供了許多方便的方法,讓你可以更彈性的操作 Array 中的資料。
南北海道、東北之旅的第一天,從台北出發。
搭乘機場捷運到桃園機場,搭乘台灣時間 10:05 的班機班機,抵達北海道新千歲機場的時間是日本時間 15:00,搭乘時間約 4 小時。
由於預期今天搭飛機,會比較累,所以沒有安排什麼行程,就是先到飯店,然後吃成吉思汗!
新千歲機場很大,也有一些地方可以逛街,但因為趕著前往市區,所以就沒有多做停留。
從新千歲機場前往 JR 札幌駅,可以搭乘JR快速エアポート,只要 40 分鐘即可到達JR 札幌駅,而且大概每15分鐘就有一班車,很方便。
早些年的 AI 其實很笨,不太能理解人類真正的意思,但經過學者跟工程師們多年的努力,聊天機器人已經有很大的進展了。尤其是最近微軟推出的 ChatGPT,據說聰明到已經可以顛覆整個產業了!?
甚至傳聞 ChatGPT 已經足以取代軟體工程師了!事實真的是這樣嗎?難道我這次真的要失業了嗎?
這篇就來玩一個簡單的測試吧,來測試 ChatGPT 是不是真的有傳聞中的那麼厲害,是不是真的可以取代軟體工程師!那就廢話不多說,直接出動 ChatGPT 啦!
打開 ChatGPT 後,我直接問了這個問題:
請問我要如何在本地使用Docker建立起Laravel的開發環境?
問完後,不用幾秒, GPT 立刻就回了我一大串,如下面的截圖,洋洋灑灑的列出了六大步驟(完整原文貼在圖片下方)。
我自己認為,程式當然有比較需要天分的部分,像是演算法。
比較簡單的演算法、資料結構還可以理解,像是排序、最小路徑、Stack、Heap 這些常見的東西,都還可以理解。但是在深入往下探討,什麼 NP、NP-Complete 我是從來沒有搞懂過。
這就是為什麼我後來也放棄繼續唸研究所,因為資訊相關科系,研究所都是偏數理的,尤其是AI、資料相關的,非常仰賴數理能力,我自認沒興趣也沒能力,就沒有繼續往下走了,選擇直接就業。
回歸正題,所以說,你需要是一個天才,才有辦法寫程式嗎?
在一個時程已經落後的軟體專案中增加人手,只會讓他更加落後——人月神話
本書的第二章,章節名稱:人月神話,正是這本書的書名。這個章節能夠作為書名,代表他的重要性。
書中認為,軟體專案進行不順利的原因,大多是因為缺乏良好的時程規劃。其中最重要的觀點是,有許多專案管理者,錯把工作量跟專案進度混為一談,進而以為在時程延誤的時候,可以透過加人的方式來趕上進度。
一個專案有固定的工作量?是的,但這是最樂觀的時候。軟體專案有太多意料外的事情可能會發生,導致工作量可能會發生變化。
我們先撇開意外不談,來看看所謂的人月 (man-month)。
人月是用來衡量工作量的單位,指的是一個人工作一個月的產出。如果說一個專案需要 6 個人月,那代表需要花一個人 6 個月的時間,才可以完成專案。
漫長的疫情就該後來一場日本北方國度的旅行,看看不一樣的風光。
初秋時期(9月中)的北海道、東北,是旅遊的淡季,沒雪景、沒楓葉、沒銀杏。但也相對的遊客也比較少,適合討厭人擠人又想感受日本街景、食物、服務的朋友們。
訂機票的時候一個奇怪的念頭閃過,決定從新千歲機場(CTS)進,仙台機場(SDJ)出,中間會橫跨南北海道跟東北各個主要城市,是一趟大長征。
這趟旅程不開車,主要以大眾運輸為主。
行程規劃上,重點放在札幌跟仙台兩個城市,札幌規劃了四天,仙台規劃三天。
大型系統的軟體開發工作就像掉進了焦油坑裡。
當你掉入焦油坑中,越是掙扎,焦油就纏的越緊。軟體工程某種程度就像是這樣的東西
首先,先來個大哉問吧,你知道軟體工程是什麼意思嗎?
如果你認為,軟體不過就是寫寫程式而已,並沒有什麼工程的成分存在,那麼你不妨可以想像一下,為什麼有那麼多的「程式」天才,每年從台清交成的資工系畢業,卻沒有多少個成功的「程式」?
這個問題的關鍵在於,在市場上,真正有價值的,並不是程式,而是通過繁瑣的程序,最後終於成功上線的「軟體系統產品」。程式天才可能擅長設計程式,但他們卻不擅長處理更現實層面的工程問題。
不知道大家有沒有聽過一個玩笑話說,學校作業寫的東西就是玩具而已?其實我認為這個比喻還蠻有趣且適合的。
曾經待過一個新創團隊,因為產品才剛起步,所以團隊採取了敏捷模式。
一天上午的例行會議 (Stand-up meeting),一位資深同事氣沖沖的,說要告訴大家什麼才是正確的開發模式,似乎累積了長期的怒氣。
他不斷地強調,需求一直改變是不行的,大家沒辦法做事,需求必須要被固定下來。
但是啊,不就是因為,需求一直改變,團隊才採用敏捷的方式開發嗎?
敏捷這個概念本身並不難理解,但是能不能接受又是另外一回事。
轉職 PM 是很多軟體工程師正在考慮職涯發展的目標之一,不過問題是,究竟軟體工程師有沒有辦法轉職 PM 呢?
其實軟體工程師是一個還不錯的職業吧,薪水高於平均,工作風險低,生活品質也還可以,所以一定是有一點什麼原因,或遭遇一些問題,工程師才會開始考慮轉職。
這篇來聊聊,到底有哪些理由,會讓工程師想不開,想要轉職,再來講講 PM 的職責,看看是否跟你想像的一樣?最後來說說轉職 PM 可能會遇到什麼問題。
工程師的未來發展性,其實還挺不錯的。在大公司,可以從普通工程師、資深、主任、副理、經理、總監、一路當到技術長等等,所以若是從發展潛力的角度來看,應該不會是想轉職的理由,比較多的應該會是職務適性的問題。