转载-编程到底难在哪里？

编程到底难在哪里？ - 戈君的回答 - 知乎
https://www.zhihu.com/question/22508677/answer/1836889117
来源：知乎
看到作者分享的经验很是靠谱，转载一下，方便以后查看；
文章如下：
把编程用在兴趣领域和项目领域是完全不同的。
兴趣领域：就是直觉理解上的把一堆电子积木组合起来，代码规模普遍很小，甚至只有几个文件，谈不上什么结构、复用，能运行起来就大功告成，其中的难点一般是编程的各类知识学习，算法总结，各类算法竞赛也归于此。
项目领域：规模普遍较大，成千上万的源代码，需要多人协作持续投入多年。不管目的是盈利还是增大影响力，控制好成本才能让项目获得收益最大，而成本最大来源就是团队成员的精力不得不耗费在各种错综复杂的结构梳理和问题排查上，所以控制复杂度就成为了最重要的问题。如果你只是想对编程做到兴趣领域的程度，确实是没什么难的。现在是鼓励全民学编程的时代，针对青少年的各种编程活动甚至还很有趣。
但如果你想把编程做到职业的水平，并还想在职业方向上不断精进，那编程就难了去了。这块应该也是低代码平台和职业程序员的分界线之一，即低代码平台的开发者写的大部分代码还是会停留在兴趣领域，实现规模是若干个代码文件，生命周期很可能是“月抛型”，在平台基础上解决一些局部问题。
职业程序员的主要工作就是对抗复杂度，哪些能复用，哪些可以砍掉，结构如何分层，接口怎么定是大型项目中最高频的问题。这个现象在其他工作中都有所体现，但在编程中尤其突出，工作评价中欣赏的”思路清晰“往往指的也是把复杂系统剥丝抽茧梳理清楚的能力。

• 如果你不这么做，就会出现大量大同小异的函数、文件、概念，设计一有变动就要改很多地方，非常折磨人，成本也控制不住。
• 如果你不这么做，与他人沟通方案会很难准确传达，做着做着就变形了。并且不同人不同团队可能会各有各的理解，一个概念搞出N个对象，字段还对不齐，联调困难，外加一大笔技术债务。
• 如果你不这么做，你会在实现代码时才发现自己的想法有多少逻辑漏洞以至于很难翻译成机器语言（恕我直言，这也是很多pm和rd争端的root cause）。
  而如果你刻意地做各种封装，试图搞各种抽象层，又会发现搞出来的”可复用”函数、类仅仅过了几周，就连自己都不知道该怎么传那一大排参数了，最后还得找老代码复制粘贴，改着改着又发现这个函数在新场景下缺个步骤或要定制个什么，反正又得加几个参数… 抽象出来的东西总是”一复用就得修改或重写“，不但没复用还徒增学习成本。进退两难地多了，就只能把这些决策统称为”编程的艺术“了。
  艺术确实是艺术了点，但还是有章法可循的，我就说说我的一些心得供大家参考，也只是个人想法，可以继续探讨：

1. 只写必要的代码，不为抽象而抽象这和性能优化是类似的，在没有看清楚问题全貌之前，过早的抽象可能是完全没意义的。这个问题在java世界中特别严重，啥都没做起手就是一堆factory，repo，builder，wrapper。作为新手给代码撑撑场面是ok的，作为老手还这么做就特别掉价了。我倾向于在没有看明白整体结构前不要做过多的抽象，也不用很OO，用尽量少的代码解决问题就行。等到系统完整地跑起来了，核心功能相对收敛了，再去按需地、迭代式地做抽象。
2. 保持核心功能简单，并和扩展功能隔离基本道理非常明确，也是广泛实践过的：像客户端软件中的插件、进程隔离，服务端软件的SOA、RPC改造，操作系统中的微内核、模块化都是这种思想的体现。核心团队控制住改动周期很长的核心功能，把扩展功能开发给其他团队或使用者快速迭代，做好扩展功能的监控、上下线，可以很好地控制整体复杂度并平衡多方诉求。当然在实践中，什么算是核心，什么算是扩展，也很容易迷惑人，需要具体情况具体分析。
3. 狠抓接口设计，不要过度关注实现细节我们不可能让每个人的做法都标标准准，思路都清晰无误。如果你抓住一个人狠抓细节，不仅被抓的人会超级不爽，一点发挥空间都没有，试问你最多又能抓着几个人这么干呢？事实上，这条和上一条的隔离讲的是同一件事，只是更注重在人身上。控制好接口设计，就限制了人和人之间的影响，给一些差劲的代码争取到了改进时间。在接口层面，很多概念已经定下来了，所以人和人之间、团队和团队之间可以做更准确的沟通，而不是鸡同鸭讲。接口层面也已经可以做很多数据监控，用实际的数据去推动改进既有动力又可衡量，会事半功倍。
4. 在发现问题时要抓整体和本质，不要只解决具体case系统之所以复杂就在于很多问题只是表象，修了它们而不刨根问底很容易导致低水平重复。这个点很难，不仅发现深层次问题需要长时间的思考和总结，转化为具体方案去真正落地执行还要平衡问题的解决程度、投入的成本、对系统的整体帮助等很多因素，这应该也是leader和非leader的分水岭之一。公司一般会以case study的形式来鼓励大家对严重bug刨根问底，但还有很多问题是以非bug的形态存在的，这就需要负责人有敏锐的技术嗅觉来发现它们、得以改进并应用到更大的场景中去。
5. 定好系统的原则、目标，并持续沟通职业项目无法回避多人协作，而系统的复杂度会让很多表层的沟通在实践中谬之千里。一个系统真的可以按架构图划分地一清二楚，就按图里的那几个箭头来回交互吗？一个系统真的可以通过打比方映射到一些简单概念，从而让每个人按部就班地工作吗？真实系统不会简化到那种程度，实际开发中还是有大量的、难易不一的决策要做，如果这种决策都要“讨论”一下，那团队效率就相当地不“多线程”了。其实，在把握住整体接口的前提下，很多模块内的问题应该鼓励团队成员自行决策，全局角度则是以好理解、可衡量的目标来帮助团队成员判断自己的做法是否得当，从而提升团队效率。
6. 保持学习心态，多实践本职工作以外的东西在大公司中很容易实现技能专精，并获得丰厚的收入，同时增强自信心。但也很容易让目光闭塞，从而停止学习。真相就是：大部分挑战都来自0-1，而不是1-100的改进，在一个大平台上获得成就很容易让人产生迷之自信，并深陷局部细节无法自拔。固然，不是每个人都有机会参与到0-1的过程中，但平时工作中如果意识到自己的局部困境也应该想法设法地去寻找破局的机会。仅仅想是没用的，仅看书其实也是没用的，作为程序员最大的优势其实是实践需要的生产资料很少，后端程序员可以去学学移动端或前端，给家人或朋友的需求写写app或小程序；前端程序员可以尝试从前到后把搭建一个服务的过程全包了，多体会一下后端处理过程的重点。这样在接触本职工作时能更全面地理解自己的角色。当然，如果你有机会接触到产品设计和运营，那就更好了，一般而言这些领域的对外依赖很多，且被大公司严重垄断，很难有实践机会。