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