标签：思考 遇到 实践 持续交付 精通 管理 设计模式 阴影 信息化
不求甚解亦或是固步自封，都是从事IT行业所不可取的。如果只会写一手好代码，却不会思考，那只能称作码农，而不是Coder。写了这么多年的代码，做了那么多年的开发项目，你是否曾经有过这样的迷茫和困惑——技术发展日新月异，奋力追赶的我们，究竟在缔造着什么？
程序员的宿命？
程序员的职业生涯中难免遇到烂项目，有些项目是你加入时已经烂了，有些是自己从头开始亲手做成了烂项目，有些是从里到外的烂，有些是表面光鲜等你深入进去发现是个“焦油坑”，有些是此时还没烂但是已经出现问题征兆走在了腐烂的路上。
国内基本上是这样，从英文社区和技术媒体上老外同行的抱怨程度看，国外应该是差不多的，虽然整体素质可能更高，但是也因更久的信息化而积累了更多问题。毕竟“焦油坑”这些舶来的术语不是无缘无故被发明出来的。
Any way，很多人认为这大概就是这个行业的宿命——要么改行，要么就是与烂项目烂代码长相伴。面对这宿命的阴影，有些人认命了麻木了，逐渐对这个行业失去热情。
那些不认命的选择与之抗争，也基本是一股脑的乱撞，去做出种种判断和尝试。
精通那么多技术为何还是做不好一个项目？
其实，软件开发人员的工作职责远远超过单纯的计算机编程。
在参与软件开发的整个生命周期中需要开发人员担当多个角色，努力通过研究和替代技术等解决问题的方法来实现产品研发目标，从而改进整个产品。
程序员的迷茫和困惑不仅仅是面对技术繁杂的无力感，更重要的是因为长期埋没于软件世界的浩大的分工体系中，无法看清从业务到软件架构的价值链条，无法清楚定位自己在分工体系的位置，处理不好自身与技术、业务的关系所致。
组件臃肿：Service 组件的个数跟领域实体对象个数基本相当，必然造成个别Service 组件变得非常臃肿——API 非常多，代码行数达到几千行；
职责模糊：业务逻辑往往跨多个领域实体，无论放在哪个 Service 都不合适，同样的，要找一个功能的实现逻辑也无法确定在哪个 Service 中；
代码重复 or 逻辑纠缠的两难选择：当遇到一个业务逻辑，其中的某个环节在另一个业务逻辑 API 中已经实现，这时如果不想忍受重复实现和代码，就只能去调用那个 API。但这样就造成了业务逻辑组件之间的耦合与依赖，这种耦合与依赖很快会扩散——新的 API 又会被其它业务逻辑依赖，最终形成蜘蛛网一样的复杂依赖甚至循环依赖；
接下来，让我们从项目管理聚焦到项目代码这个相对小的领域来深入剖析。
开启程序员职场破冰之旅——云开发平台大有可为
要想成为软件开发的专家，需要完整了解软件开发的流程，并在关键部分掌握丰富经验。需要了解设计模式同时遵循软件开发的最佳实践，包括创造性和思考力。
传统上实现这一目标需要掌握代码管理、服务器端开发、客户端开发、运维、云计算、网页设计、分布式系统、数据库、编程规约、基础设施管理、可扩展性、安全性待方面的能力。
而作为新潮开发工具的云开发平台将底层技术和公用应用封装成参数模块，开发人员无需再经过繁琐的编程代码去实现功能需求，只需使用可视化、配置式配置元数据即可开发系统。
软件开发作为一种商业活动，判断其成败的依据应该是：能否以可接受的成本、可预期的时间节奏、稳定的质量水平、持续交付满足业务需要的功能市场需要的产品。其实就是项目管理四要素——成本、进度、范围、质量，传统项目管理理论认为这四要素彼此制约难以兼得，项目管理的艺术在于四要素的平衡取舍。
而云开发平台的综合性及简便性，在保持一个质量水平的前提下，成本、进度、范围三要素确确实实得到了改善，更不必牺牲某一方面比如牺牲成本（加班加点）来加快进度交付急需的功能。让技术开发者可以更专注于软件项目的设计及管理，从而提高软件开发效率及项目质量，轻松成为全栈软件开发工程师！
标签：思考 遇到 实践 持续交付 精通 管理 设计模式 阴影 信息化
原文地址：https://blog.51cto.com/14865310/2520555
