信息系统项目管理知识学习记录

软件工程—思考项目开发那些事（
weixin_33946605）

1.那些逃避开发的管理者，因为他们离真正的产品实现太遥远，他们离软件开发领域真正的问题太遥远，管理一旦忽视代码质量问题就会慢慢找上你，你的项目往后的质量越无法控制，度量、开发进度都会遇到瓶颈。

2.当你的代码质量越来越差的时候你就失去了对项目进度的控制。变更是无法避免的，你的代码无法面对这些复杂的变化，因为你的代码不是设计出来的而是堆出来的。最后你的项目质量也无法很好的保证。

3.项目管理与软件工程的结合才是完整的软件开发

4.在《精益与敏捷开发大型应用实践》一书中是这样描述软件设计和架构的：

（1）：“软件架构借鉴了建筑的架构，但结果证实这是个不太恰当的类比，而且给软件开发带来了有趣的副作用。建筑是硬的，因为在这个领域，设计只在施工前进行一次，然后该建筑或者设计就几乎是永久不变的了。注意建筑师和施工工人是不同的。但是软件不是一座建筑，软件是软的，而且编程也不是施工的过程，“软件架构”只不过是一大堆比喻列表中可以选择的一个不太完美类比而已”。

（2）：“......唯一确实看起来满足工程设计条件的软件文档是源代码“。

（3）："我意识到图表和文档并不是真正的设计，而源代码才是真正的设计。再次重申“......唯一确实看起来满足工程设计条件的软件文档是源代码“。

5.技术人员的业务理解（领域模型、设计模型、抽象建模）

技术人员的了解业务要有所侧重，你理解的业务和产品理解的业务是不一样的，技术人员需要将业务最终技术化才行。技术人员的最终的业务模型是有正确的模式可以参考的，就拿“创建订单”这个流程来说，等待技术人员需要去提取和抽象的东西是比较多的也是比较复杂的，需要结合很多的知识来进行设计活动。

比如订单，你需要结合“四色原型”模式来提取“订单”的模型，包括“订单的类型“、”订单的跟踪“，需要结合设计模式来抽象”创建订单的逻辑“，根据”不同的订单类型创建不同的最终订单“。还需要进行设计模型的抽象，比如创建订单，各个对象的交互是如何的，每个交互的输入和输出是什么。这些都需要技术人员理解了业务后应该具有的业务模型，如果需要将模型语言化就需要结合使用UML来建模。

6.技术债务其实是无法避免的，各种原因，时间进度、需求变更、市场迫切等，都迫使研发开始堆积技术债务，代码逐渐开始腐烂，难道我们作为技术人员就只有抱怨和推卸责任吗。这里我有一些个人看法，这些个人看法可能跟你的理解不一样，你可能会说我太理想主义了，但是我想说的是：“作为一个技术人员一定要有情怀，一定要有追求。”用我最尊敬好朋友冯老师的话说：“写代码一定要考究“。就算在时间比较紧的时候可以先写，但是要记住你的工作并没有完全完成。