不完美并不等于劣质。去网上搜一下 Pareto principle 和 Sufficient Design 就知道为啥了。
让一个人去写项目,如果这人发现项目里用了一堆过时了的代码,或者是用了 MVP 架构,又或者是项目写了很久很久,那这人肯定很想把整个项目给重写了,这样才感觉整个项目尽在掌握,如鱼得水,而不是看着就头疼。
不过呢,重写大项目一直都不是啥好事,整天流于形式写框架,却白白浪费了写业务逻辑的时间,这很没必要的。有些事情可以不用管它,别太纠结。但是呢,如果你重写的代码符合我下面说的这些标准,那你重写也不是啥坏事的说:(节录自这篇文章)
1、重写的代码真能实现需求么?
2、代码真的正确无误,而且效率还不错么?
3、在遇到并处理错误时可以做到不崩溃,或者安全地结束执行么?
4、试起来容易不?
5、如果要改动代码,能尽量又简单又安全不?
这最后一条标准大概是最难做到的,毕竟要做到模块分离和抽象化,还要写测试代码来确保符合预期效果;而且代码若还有改动,只要修改相应的一部分测试代码就行,这样才可以更加轻松地调试和改动代码。
从零开始写项目时,一定要花点心思。无论是写新项目,还是重写旧项目,都要规范地写代码。比如说,代码风格要清爽、要有可读性、要遵从一定的代码规范。但是但是,一定要小心,不要过早优化你写的代码。
写的时候只管想下一个要实现的需求是什么,而不是边写边纠结怎么缓存资源、怎么弄个复杂的数据结构来储存数据之类的事情,还有别动不动就担心执行效率。你代码越简单,其他那些要接手你代码的人就越感谢你。
刚开始写项目时,这些很重要;以后给客户写项目时也一样重要,毕竟说不定哪天客户就要你把项目交给他们来继续写呢。