各位大神前輩好，新手發問
想請教一下程式架構和資料結構的主要差異，及重要性？
是這樣的，我在爬文時看到這篇文章，詢問資料結構的重要性
#1Tigizmt (Tech_Job)
裡面有一段討論是這樣的：
※ 引述 《a23395080 (路過看看)》 之銘言：
: 噓 ll1117: 我的程式結構比現在任何資結都強兩倍，不用管書上說什麼 10/25 17:33
: 噓 pig2014: ll117少誤人子弟，程式結構是SOLID跟design pattern，干 10/25 17:49
: → pig2014: DS屌事 10/25 17:49
想問所謂SOLID和design pattern應該是和物件導向那塊有關吧？
這個和資料結構有什麼關聯嗎？
我自己的認知是
程式的整個架構和好不好維護、能不能擴充有關；
資料結構是可以減少程式的複雜度，讓速度變快，或是為了某些演算法而生的？
本人目前剛修完大一的程設，什麼design pattern和資料結構還不太熟悉
物件導向剛學會封裝、繼承、多型；
資料結構只有寫過linked list，tree那些還沒自己刻過
想問這兩個有什麼關聯嗎？ 還是不同領域的
有重要性之分嗎？還是跟著學就好了
謝謝各位指教

不同領域 都很重要

就 程式 跟 資料 的差別 先理解這兩個名詞

資結現在是大一的課了？

你的認知大致上是對的

資結大二就會上了別急

基本的搜尋排序，就會跟資料結構扯上關係了

你的想法大致對，那種人的高談闊論看看就好

Design pattern 讓你方便維護跟擴充功能資結演算法 主要是改進程式的效能 但也方便維護

資料結構偏演算法，程式架構偏設計

目標不一樣 但這兩科有一些共用的知識

架構底下可能還會實作資料結構 兩者不能混為一談 大二會教資結但我的學校沒什麼教程式架構ㄏ

好的資料結構可以讓程式架構變的紮實，有效率，高彈性這是相輔相成的。會說不相干的只能說他沒弄懂

身體胖瘦高矮 = 資料結構, 穿搭好看與否 = 設計

資料結構就是你的材料, 程式設計就是你炒出來的菜~你要怎麼炒得色香味俱全, 首先你的材料要準備得夠充分

程式架構跟資料結構掛鉤的話，換個實作方式架構不就要整個重寫？

演算法跟設計就比較像是你炒菜的功夫了

這樣好像不太合理

如果你是講效能的話通常資料結構是硬限制上不去就得大改如果你在小公司資料只有幾百萬筆那會不會資料結構沒啥差程式結構強對應快速需求變化也許比資料結構重要但如果你在大公司不考慮資料結構大概就是完全跑不動=0分

換個資料結構就要整個架構重做，代表架構太弱好的設計應該是只影響到該改動的部分阿高內聚低耦合有沒有聽過

那不就表示程式架構和資料結構互相不影響嗎？

沒到互不影響，有時候要達成某種程式架構，一定要有某功能的資料結構

OOP是垃圾

algorithm + data structure + design = programming

先去刷題刷個十題 再學一種後端開發框架做個留言板 你就懂程式架構跟資結是指什麼了你可以完全不碰前端 用postman打api 用你覺得方便的語言做幾支api實現留言板的功能推薦python flask的網路教學隨便找幾篇照著做 幾個小時就懂了

通常會說OOO最好XXX最糟糕的 這種評論可以直接跳過

很多人以為資料結構=演算法，卻忘了為什麼它叫資料結構與架構關係很小的是演算法啊

這樣有點矛盾，演算法跟數據結構關係很大。

以前寫java的時候也是通通搞混 因為oop就是那樣 只是後來意識到就會用資料結構去形容

資料結構和程式結構也有關啊，通常封裝的原則就是越靠近操作就應該擁有相關的資料，依據這個原則設計程式基本上都不錯。但資料結構又會牽扯到算法與記憶體大小、對齊、cache、拷貝、搬移、heap、stack、資源競爭等等，怎麼可能完全跟程式設計無關？很多人認為解耦和越高的程式設計就是好設計，實在是想得太簡單太理論，實務上真的有用的是慣用手法+重複使用某些基礎元件和結構，更小範圍的使用idioms，有興趣去看一下absl和folly，他們並不是一個傳統的框架，卻集成了許多常用通用的概念元件，並且散佈在不同的大型軟體之中。如果不清楚應用，設計出天霸王型的軟體架構，企圖解決所有問題，包括不知道的需求，專案很容易失敗。類似的概念還有程式產生器這種東西，最後都淘汰在歷史洪流之中，沒有什麼都通吃的設計，只有最適合的設計。

資料結構和程式架構是兩回事..完全不同領域的東西

大一最重要的課程 是社交 談戀愛 別荒廢了

板上搜尋 "後端工程師要如何更優秀" 有些不錯的介紹

推二樓

大一不要想這些有的沒的 去辦營隊認識女生比較要緊==

推樓上 女朋友和書卷我選女朋友

程式架構是為了應付需求變化，資料結構是為了運算效率，但資料結構會影響到程式架構。

爛的資料結構會讓你必須加一堆workaround才能應付需求

其實就是2件事混在一起談。以訂票系統舉例，餵1000元退一堆50元銅板造成困擾，是程式架構的問題重複訂票造成困擾是資料結構的問題，但一般人就認為系統爛有問題

你認知是對的 反串推文少看 不要浪費生命

要說完全無關也不是 有一些程式架構 就是從資料結構來的

大二上DS就會懂了 這門課會告訴你電腦怎麼有效率的處理資料存取、排序等等 跟程式架構要探討的主題完全不同

重複訂票是數據不整合。跟數據結構沒關係。確實是系統爛。0.0

通常推文不認識的ID嗆最大聲不要誤人子弟的就是最誤人子弟的那個

資料結構有關聯 但搞成物件導向多半都很難維護 畢竟各大專案都寫自己的 然後你湊起來又會因為語言本身特性導致你綁手綁腳還要夠了解才維護的好 成本超乎想像如上面有人講的 好維護過生活不是更好?尤其註解流 資訊零散的太恐怖了 只有對原來開發者友好

程式架構跟資料結構無關 是兩碼事

實務開發上好像不會硬是區分是哪一種欸，端看需求跟問題點來決定去設計跟改善什麼

https://bit.ly/3OHMT3N 推薦這個 Clojure 相關的影片 :D

學過設計模式後 才會到達新世界的起點

重開治百病啦，還有病就加機器。現在微服務的架構，服務都能重啟 記憶體優化重要性比程式能不能維護擴展相比。我會著重在後者

痾... 物件導向只是其中一個面向你在沒有物件導向的語言一樣要SOLID 跟考慮design pattern