我知道这是件很有技术性的工作，就是好奇难不难，是不是需要做复杂的运算之类的？
比如打开我的电脑一般是最小化，然后点击最大化，不管你更换多大的屏幕我的电脑都会自动满屏。就是很好奇……这是什么原理？

您问的是个硬件问题 跟编程无关 233

他那个哪里是硬件问题了

不难。经过培训普通人都可以胜任。大多其实都是复制粘贴，改改别人的代码。

你的最小化 最大化 都是 WINDOWS提供的基础功能。
编程的人 是不需要 去处理这些基础 代码的 那都是 MS的事情。

编程的人只要实现自己的功能就好了。

当然你深挖 就不得到了
比如 实现最大化是怎么实现的， 就是windows 的图像进程肯定会问系统现在 你分辨率多少 这种事情 然后 再做出判断
但是系统怎么知道 自己分辨率多少 那么问驱动。
总之约底层 越难以接触到。 大家都是踩在巨人肩膀上的。

但要有强大的耐心，长时间端坐和忍受寂寞的心态。所以编程适合宅男

不难，很繁琐
不过大量的活已经由系统做了，你调用就行

这有什么原理的
虽然我不知道windows，mac这个功能实现的机制，但随便都可以想到一种方法
1，从操作系统提供的接口可以取得当前屏幕的分辨率，比如说1920*1080
2，把当前应用的窗口大小设为1920*1080
3，将当前窗口的坐标设为0，0 (电脑里以左上角为0，0)

总的来说，如果你逻辑思维不错，理科学的还可以，不难

硬件编程是制造积木
软件编程让积木搭砌

这样比喻对吗

主要还是要有数学的底子，能想到从1加到100其实是50个101相加。

对于99%的编程工作肯定是不难的
不过幸运的是最难的1%工作往往已经有人做了，并且可以免费拿来用

所以总的来说是不难的，难的是你要坐得住，每天12小时坐得住

不过话又说回来，能坐得住自然任何事都不难

完全错误

不难，枯燥、乏味、重复，就像生产线上的工人、耕地里的农民
所以称之为 码农

这是系统提供的API
你只要写几行代码调用就可以了，也不用很复杂计算，跟机器说几句话就OK

但机器这东西很笨，你要写的非常死板严谨它才听得懂，这对大部分人就很枯燥了

[本帖最后由 endrollex 于 2019-3-2 09:32 编辑]

看你要做什么。
上层应用，系统框架API，还是底层驱动。
当然还有更底层的，越底层难度越高。
不管做什么，你都必须要有不错的逻辑能力，这是写代码的基础。

软件是有史以来，人类做过的最复杂的工程应用！你说呢

搬砖有什么难不难的，人和狗搬起砖来都没什么区别

搭积木是我见过最误导外行的比喻了。也只有外行会把软件开发形容为搭积木。

没想到泥潭这么弱智

编程这词范围太大，写OS写驱动是编程，写HTML/JAVA script也是编程，差别大了去
技术上说，写代码实现某些功能不难门槛也不高，但软件架构和算法是两个不低的坎，过去了是架构师和程序员，缺什么都能自己上；过不去是码农，随便什么不懂的都只能到处copy调用别人的代码。两者差别也十分大
再往后还有写代码之外的知识，比如做游戏引擎的要懂3D算法，写驱动的要懂硬件，写/改OS的要懂各种算法（全是数学），做各种专业软件时对应专业的知识。这是更高级的坎

只要看这个人能不能保持学习的热情，对未知事物是否有探索的热情就能知道他能不能成为一个优秀的程序员。所有优秀的程序员有一点是肯定的，碰到不懂的东西绝对会自己去查资料把他弄懂。不合格的程序员，代码黏贴了事。

不只是堆积那么简单的，你还要设计积木结构，来达成客户的需求。如果没有足够多的背景知识，积木搭到一定复杂的结构会搭不下去或倒塌的。因为每个客户需求都不一样，不是说单纯的粘贴复制就可以解决的。

设计积木结构还是搭积木，乱堆也没个样子不是，一个范畴

最大最小化是不难，但是如果你想让你程序的界面里的控件能在鼠标拖着右下角放大缩小的时候等比例自动调整的话。。。。。。嗯好吧也不难，只是要把控件塞进不同frame然后组织好上下级关系

决定程序员上限的不是什么逻辑和算法能力，而是英语阅读能力，和fq。不要跟我提算法，算法是理论科学家写论文发表到期刊上的东西，然后被世界排名前几的超级大公司里负责维护开源社区的大佬写成了代码，而我们程序员是工程师，只会用这些现成的东西就行了

盖房子难吗？

写代码和用砖石水泥砌墙是一样的难度，是个人都能学会

难的地方是定制砖块尺寸标准和和水泥砂石的选择，调配混水比例，钢筋结构还是吊索结构等等标准，更高深的选择地点，地质勘探，建筑设计，架构图纸，装修风格，通风，采光，人流进出流动等等这些，能做到且做好的只有程序员里的5%左右，有些一个人也没法做成，需要团队甚至全球范围的开源，经年累月的制订开发调试除错，软硬结合的驱动，底层架构的机器码编译等等，拓展开没几年说不完，而且几年后又是一个新的世代，永远有闹不完的进步

这才是写代码的真实，底部扁平入门容易，中部陡峭，满眼是高山仰止的各路大神，靠近顶点就只剩几根细线不见顶的顶尖，的金字塔

数学和逻辑思维好就可以。

Posted by: vivo vivo NEX S
我觉得应该是前期学习曲线很陡峭 后期才会平缓的技能

编程里面又有三六九等，不能一概而论难或不难。只能说很有深度。

认同保持持续学习的能力和编程分三六九等

以普通人能接触到的软件工程 我们可以划分很多个层次 最底层的os负责与硬件沟通，最上层的应用直接面向用户提供人机交互，这中间可以按照不同维度划分很多层次，对程序员来说不同层次的开发需求不一样，有的注重性能，有的注重稳定等

编程不仅仅是为了实现需求，作为一个工程，涉及架构、思维、更新迭代等等很多方面

难啊

一个稍微大点的软件就需要架构，架构差了维护费劲问题多效率低可移植性差，架构的能力可以算逻辑的一部分。不会架构还能叫工程师？
至于算法，大佬只能做些通用算法，你碰到具体问题时需要各种特定领域的专用算法，这个能靠copy？

我不觉得架构属于逻辑的一部分，架构更重要的是遵守规范，不要自说自话自以为是脱离规范和标准去玩发明，沉浸在自嗨的小圈子里，应该抬头看看学习参考下别人在类似的情况下是怎么规划的。

举个例子，Nordic的softdevice蓝牙协议栈，全闭源，开放了几个机制帮助实现低功耗蓝牙（ble），我们要做的就是遵守规范，使用官方提供的机制，清楚什么事件属于中断上下文，要避免哪些操作，要怎么做才能不和协议栈冲突，怎样将功耗降下来，都有严格的规范

至于算法，大佬只能做通用算法？不要侮辱大佬了。还是那句话，不要自说自话去搞发明创造，能融会贯通地把现成算法用好，把参数调到满足自己需求，已经可以了。

还是举个例子，谷歌的catographer，开源的，但是轮得到我们去改代码吗？当然不，但是装上就能用了？当然也不是，需要设的参数一大堆，需要在实际测试中逐步调整，并且需要把所有传感器的输入输出数据格式进行匹配

你這一問就知道給你編程很難。

现在比起以前来说门槛下降很多

喷了，只会照抄和调参数就能解决问题还要架构师这种人做什么。
另外你是不是把算法想得太高大上了，只有规模大了才叫算法？小到数据结构求最大公约数全是算法，只实现功能或许不难但各种具体环境下能否高效完全另一回事。

照抄调参数都不会，就别往高大上去琢磨了，架构师？我还真看不起，可能我圈子小吧

数据结构？最大公约数？这也叫算法？整个linux内核只用两种链表，一种单链表专供哈希表使用，还有一种双链表，处理了所有的问题，注意人家是纯c，没有模板的，代码简单到爆炸

linux用的数据结构挺多的啊，另外最大公约数为什么不叫算法？最大公约数的算法非常漂亮

数据结构是不少，但链表就这两种，被大范围使用，哪儿哪儿都能看见，而且两种链表写在一个头文件里，没有第二个文件。树基本都是红黑树，一个头文件一个c文件（一行注释没有）结束

重点不是叫不叫算法，而是有没有必要拿出来说，或是换种说法，有没有必要天天去自己发明一个漂亮的求最大公约数算法？