各位大神前辈好，新手发问
想请教一下程式架构和资料结构的主要差异，及重要性？
是这样的，我在爬文时看到这篇文章，询问资料结构的重要性
#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