我自己看书然后做了一些方便工作上用的东西，但是经常出现这样的情况：做着做着出了一些问题或者想改的更好点，想改一个地方，然后改来该去发现几乎全盘推 到重来了，之前的功夫全白费... 求问下，正规写代码的同学们是怎么做的？ 怎么开始，怎么修改增加新功能.......
软件工程专业最少要学2年，能搞懂最少最少需要5年。如果要直接从代码出发，你可以学习 Kent 的有关“极限编程”的书，极限编程技术是我见过的最不讲理论——但是又最能自动产生软件工程最佳实践——的软件工程方法。
传统的结构化方法，例如画各种流程图，各种数据流、控制流分析方法，都要学一阵子。然后面向对象系统分析和设计方法，甚至包括 UML 画图，你又要学一阵子。
没有什么开发靠抄代码而来。写代码是最低级的事情，就好像搬砖。软件程序设计师最终要学习软件工程。
全盘推倒重来”这往往跟结构化设计方法、自顶向下功能分解、函数式方式有关。真正的面性对象系统分析设计方法既不是自底向上拼凑的，也不是自顶向下分解 的，而是“自然而然、衍生扩展”的。仅遵循结构化方法的人讲究的是“规则”而不是“道”，所以总是在遇到问题时会推倒重来，而不会随时重构随时灵活改变的 思路。
如果你是“改来该去发现几乎全盘推到重来了”，那说明你还需要继续这种过程，不要着急，因为你起点还比较低。
一个熟练工，即使写代码时不预先考虑软件工程，软件设计，也不至于会全盘推到从来。高大的发箍要全部推到从来时，你只需要继续，直到你较少发生全部推到从来的情况。
这个时候，你可以开始系统的学习一下软件工程和设计了。而你现在去学软件工程，对你提升不大。
经验的积累不是一朝一夕的
推到重来，是必须的经历。功夫没有全白费，至少在重来的时候之前犯过的错误就不犯或少犯了
多读多看多写，没有捷径可走
对了，你也可以找一个框架，像做填空题那样去填填代码。大多商业项目都是做出来的
但这不叫写程序
看起来，你更多的是将一整个业务逻辑放在了一个方法中。
我们提倡多个简单的方法，组合成一个业务逻辑。
当其中部分逻辑需要修改时，只需要修改多个简单方法中的几个。
比如说，
一个转账功能，不考虑事务的前提下，
分为2个部分，一个是A账户减资金，一个是B账户加资金。
这就是2个方法。而不会捏成一个。只有在业务逻辑中，进行调用时，才体现出了转账这个概念。
其实写程序就是把你想要的业务逻辑用电脑表示出来，只有把业务逻辑弄好了，其实写代码是简单的。比如说汽车衡称重，其实就是从串口读个数保存就行了，但是业务就不是那么简单了，要考虑好多，只有把业务缕清了然后把业务转换成各个模块，那么做起来就简单也明了了。
这个没有办法解决。和下棋一样，任何上段位的棋手，都是不断下棋，不断复盘，不断总结
那怕是最新的阿尔法狗也一样，他是不断自我训练的结果。
对于阿尔法狗，可以通过百万次的训练
对于人类，在厉害的程序员一辈子也就500个项目把，所以对于人类你要么一次比一次好，一次比一次做跟复杂。要么一次比一次简化，简化到不能简就是最好
所以我们如果做不到阿尔法狗那样，那就只能反着来。承认自己不是神，承认自己看不到所有的事情。忽略所有非必要的点，只做充要条件。把一切非必要的东西让给后续实现，而不要越俎代庖
阿尔法狗之所以被我们叫做厉害，那就是因为在围棋领域讲的是策略。
我们一向认为在策略问题上，那是人类的专长。
同样我也一向鼓励程序员去下围棋，下围棋的过程和写代码的过程其实差不多，局部那是算法，大局那是策略。同样如果说一个你认为很NX的程序员，他们在设计系统的过程中实际跟围棋棋手用的方法和策略没啥区别。
有些东西在前面无需考量，前期需要总体规划，保留变化。不用每个子都争。
建议你不要每种都争，适当放弃。只要他后续能扩展成你放弃的那种变化就可以了。python好，why？因为他不是大而全，他只是保留了手段，他说我没有的C++有，我让
c++给我扩展，同样他也保留了手段，你net是吧，没问题！我没必要一开始就支持net，但我保留支持，你要用可以啊，你可以扩展ironpython。
下围棋是一样的手段，星-小目足以。玩滴大你可以雪崩定式，玩滴小你全脱先，留5目就好，东西保留，看情况扩展就是
这个过程在刚开始时 是必然的会存在的，以前我也是这样，同一个项目要重复来个好几次。后来，我师父交给我一个好方法，在你写代码之前先整理思维导图，先 将你的项目逻辑整理清楚（越细致越好），整理的时候想下如何实现（千万不要认为这是浪费时间，no 试想一下，在你几次重新来过 你浪费了多少时间，这样 不仅可以增加你项目的逻辑性还能对你的项目进行备份，因为人的记忆是会随着时间的增长 而忘却一些事情，等到后面需要改动项目，你可能都已经忘记是否有这 个功能，这个时候你写的思维导图就派上的用场），真的很实用。刚开始 可能很不习惯，但是请记住 一定要坚持
其实现代软件的基石之一就是放弃变化，保留变化。
我们只需要承认我们不如阿尔法狗就成，局部可以放弃，只有后面可以变化成局部就好。
我手下一个程序员经常会抱怨，微软这不好，那不好。这个玩意微软都不做，非要程序员自己做。微软这个异常不处理，非要他自己处理。
得，我只能说，微软之所以是微软，就是因为人家会放弃那些局部的，他会让你自己处理。假设微软每次都把局部实现丢到框架里，你觉着那个框架还能用么？我说那样更难用，因为微软也不是神，他也不知道你后面怎么用。他只能保留你后面可以那么用的权利
商业上通常是找一个合适的平台来搞二次开发；个人大多数是找一个合适的框架来继续开发。
所以，
第一步：还是要调研，把问题弄清楚，估算一下开发量和数据量等等；
第二步：选择一个合适的平台或者框架来做这个事情；对于个人开发来说，OSGi是个不错的选择，网上小蜜蜂论坛发帖机有C#的OSGi框架，但对于商业行为来说，OSGi之类的还是太底层了，需要选择一个业务相关的平台或者框架；
第三步：设计；
第四步：编码；
第五步：测试.