如何理解软件
如果对软件进行下定义，软件是解决特定问题的工具。具体来说，软件的最终目的都是实现一些特定的功能和逻辑，在此之前，他需要依赖代码来实现这一目的。那么在实现最终目标前时所面对的一个个具体问题，就是编程时实际应该在做的事情。
但这种表达太过浅显。背后真正的问题不是如何解决问题，而是问题的解法太多，选择哪种解法是最有利于后期继续开发才是真正的问题，于是我们需要基于一些更高的概念来理解问题，选择更加泛用的解法，这种思想可以称为抽象，也就是初学编程时大家都会接触到的词。
解题思路
如果把软件的开发过程类比为寻找最优解,那么最先肯定需要一个题目，而这个题目肯定是始终围绕着需求旋转的，比如我需要解决大量的同屏角色交互，比如我需要一个能回放的游戏系统，而这些大问题会在具体落地时产生更多的小问题。很明显，我们期望的解题方法一定是能解决当前需求并且能更好的解决后续的问题的，而不至于到另起炉灶，重新设计一套新的解决方案。
对于程序员来说，最大的敌人永远都是时间，所以重新设计一个新的解决方案解决一个新的问题才是致命的，我们需要考虑很多方面的问题来决定代码怎么写并不是说这些情况下只能这么做，而是要选出最合适当前情况的方法，以便在有限的时间内完成项目。问题的根本永远不是这个做不了，而是在这个时间内做不了。
1. 理解问题
我们期望能更好的解决后续的问题，但很明显，我们当前对与后续会出现哪些问题是很难做到一个准确判断的，至少目前我看不到有什么方法论来指导。但是一个越有经验的程序员一定会比新手更准确的预判出后续的变更。这可能是因为他对于业务更加熟悉，因为有更深的理解，也自然更清楚后续会出现的问题。
这就是第一点，编程时实际在做什么：关注业务，理解业务，这是比写代码更重要的工作。
2. 怎么做和为什么这么做
这句话实际上依然是在表达解题思路与具体实现的关系，但是角度不同。比如在面对已经开发到一半，甚至已经开发完成的项目时，理解为什么这么做才能继续的对项目进行维护和扩展，这是非常重要的。
3. 工程
我发现项目成员间的同步是困难的，大家往往按模块划分，各自独立开发，这往往导致不同模块内出现相同问题的时候会基于不同的人而出现不同的解法。我认为这是一种对现实的妥协，而在这之上的，能尽量服务更多人的，更高维的东西就是整个项目的架构，为大家提供了一个最基础的思路，也可以认为是项目成员间最大的共识，但也仅此而已。
总结
代码可以说是编程中最不重要的以部分，或者说是实现部分。编程时真正在做的应该是给出一个完整的解题思路，而不是仅仅关注于如何实现。或者说，实现本质上就是遵从设计好的解决方法来解决一些具体问题罢了。
从更高的概念来讲，编程时实际在做的应该是设计，设计出更适合项目的解决方案，以便快速高效的面对后续出现的各种问题。解决方案越完整开发效率自然越高。
套入更通用的概念中，解题思路就是架构设计，解决方案就是项目框架，最后才到具体的业务代码。
似乎有种普遍把程序员当作工具人的感觉，但实际上，项目初期最核心成员应该是对业务最熟悉的人，只有这样才能真正为项目打下牢固的地基，而后来的程序员或许可以是工具人，因为有了对整个项目成熟的解决方案之后，他们确实可以做到只关注当前的问题而不需要深入的了解业务。这是一种容易被麻痹的状态，实际上离开了这个解决方案，他依然无法独立的进行开发。写到这才后知后觉的发现为什么之前脱离公司开发的项目感觉到那么困难，现在想想，似乎处于一种为了写代码而写代码的状态，就是因为没有真正的去思考过需求是什么，就开始照抄公司的设计，实在是笨方法。
张华麟
自由的制作游戏。