对项目开发中的一点感悟

我也只看不说话。因为水平不到位，不敢乱发言。

LZ开发经验1年以下。 。
   欢迎拍砖。

第三点我觉得应该具体问题具体分析，不能一棒子打死；第六点我同意楼主的观点，另外我觉得写注释的主要目的不是为了自己，而是为了方便项目内部交流甚至方便客户，另外也为了将来维护的方便。

------------------------------------------------------------------------------------------
另外，对于楼主在第四点中提出“或者把这个业务分为有层次的任务，每个层次只处理有限的业务”，这个“有层次的任务”指的是什么？充血的领域模型吗？如果不是，那么业务逻辑实际上还是趋向于过程化的。

最后为楼主说一句：良好的设计，成员整体素质和成员间沟通的确很重要。但因为种种原因难以达到这些时，作为应对措施，楼主的建议还是比较中肯的。

LZ所在的项目肯定是 每个组员都在单干 。


公共模块应该做什么应该是前期都要分析的，而不是在写代码的时候抽取才考虑的。

我们这个项目确实没有什么设计的，大家都是分了模块自己设计。

一、我没有说清楚，我说的是不要去共享别人需要参数的链接和内部跳转

二、当然共用引用的头文件，菜单页面，顶部页面是必须的，我打个比喻像进入一个系统的时候进行的初始化工作最好还是不要去用相关模块的页面，我觉得自己copy一份会更好些。

三、你只是说了不认同你为什么不认同呢，其实公共模块的抽取我也觉得应该是在前期把共用性比较明显的抽出来，还有就是在项目后期针对工程中确实有共性的东西做成公共的。在项目进行的工程中，我们项目中做了很多共用的东西，给人危险的感觉。也许现在是业务比较相同，但是随着项目的推进，也许就会有差异产生。

五、我这里说的接口是类中的可以公开的方法。

六、我强烈主张写注释的，即便是自己写的代码，半月之后也不能很快明白的。

七、通用不一定是简单的，而是最常见的，最容易被大家接受的。

层次这个词可能我说的不是很确切吧。

举个很俗的例子：
组装汽车，
汽车：发动机，车皮
发动机：燃烧机，活塞
车皮：车门，车窗

我说的意思，组装汽车的时候只是验证发动机是否有用啊，发动机是否合适，车皮是否和趣味啊等问题
组装发动机：复杂发动机的性能啊，推力啊等问题

每次只处理这个层面的问题，至于底层实现交给底层的方法来做

我不知道说清楚了没，就是在一个程序段只处理核心的部分

不好意思，做开发快两年了，第一次做7-8人，半年的大项目（别笑哦，对我来说这个确实是个大项目），水平比较菜。

我的感觉是我们在边做项目边重构以前的。（重构我理解是再次去设计架构以前的程序段）

写的很不错
支持一个，前面的大牛们强烈不支持1，2条，是不是从代码的重用方面来讲的呀，呵呵！不懂！~