我的服装DRP之开发感悟
先向各位拜个晚年。
今年过年期间都在想DRP的事，很多朋友也联系我，讨论技术问题的、谋求合作的、分析行业前景的、让我提供源码和数据库的都有。再次谢谢朋友们的关心。目前来说，在修改系统bug的同时，我打算重新找一份工作，毕竟在能力转换成财富之前，生活还是要继续。
Winform or WPF：
今天在QQ上和一位山东的朋友聊了会，其中聊到BS和CS的老生常谈，说道有些功能BS不好实现。我认为两个事物孰优孰劣需要放在特定场景中才能比较，关于这两者的区别谷歌一下即可，我就不分析了，徒惹板砖。其实同样是CS，具体的UI框架也包括很多，在.NET中主要就是winform和wpf，前几天就看到一篇文章关于开发WPF的一些感想，作者提出：为什么到现在都没有客户端的WPF系统？在如今WEB化和移动化大行其道的情况下，windows桌面程序开发的价值又有几何？说实话，我也心存同这位博主一样的疑虑。对于这两个问题，每个人都有自己的看法。我认为相似的几个技术有个先来后到的“优先级”，试想，假如wpf和winform的出现时间换一下，再扩展一下思路，假如当初C#和Java这两种语言同时出现在大伙面前，假如HTML遵循XAML的语法……世界会是什么样子？所谓的市场占有率通常并不能比较出技术间的优劣（没有贬低谁的意思），只能说声：抱歉，哥比你先到。
单纯对于行业软件而言，在winform和wpf中选择，我偏向于wpf。如果非得选择winform也可以，不过最好给我提供一个winform实现框架，这个框架需要包含以下三点功能：
- 支持源数据更改通知反馈；
- 支持路由的Command；
- 易用的界面设计功能；
架构设计：
工作多年，接触过许多编码界的朋友，其中一些高手对OO的理解可谓已入化境，没事就抽个接口玩玩，调试他们程序的时候永远只能看到黄色小箭头在浩瀚的代码海面上跳跃，要想一探究竟，对我这种菜鸟来说只有淹死的份。记得我刚参加工作那会，参与开发一个简单的会议管理软件，项目经理给我展示项目架构，说这是当时最流行的架构设计。我猛地一瞅，顿时有种膜拜的赶脚——那庞大的项目，那众多的类库，那抽象，那反射，那配置，一看就很高级哟，我估计没十年八年是理解不了的，差点还动了转行的念头。项目经理意味深长地拍着我的肩膀，说慢慢来，会明白的。可是我最终也没能明白。
我不明白的是为什么数据层要有个接口，他们跟我说为了支持多数据库，虽然现在只用到SqlServer，保不齐百年之后要切换到Oracle；我不明白的是为什么业务逻辑层也要接口，他们跟我说可能客户会经常改变需求，虽然需求改变常常导致改变接口本身，不过这是OO的原则，你纳闷说明你理解的还不够深；我不明白的是为什么要用工厂方法、抽象工厂方法，他们说这叫统一标准，虽然大部分接口都没有第二个实现类；我不明白的是为什么这看似高级的架构没有给开发者和用户带来良好的体验，他们说加班还不够；……
一年以后，我离开我的第一家公司。跟同事们告别的时候，我们都看到了各自心中的郁闷，这是长期作战的结果，而敌人是由我们自己制造出来的。
我还碰到过另一个极端，不是说三层么，做啥项目都只建三个类库，对应数据层、逻辑层、UI层，最多加个实体类库。你想要个通用类库，门都没有。
后来，我把QQ签名改成“设计，是一种美，就像盖大楼，如果每座房屋都是千篇一律，那么也就不存在架构师了。”，这是从某博文上复制下来的。虽然这句话并非那篇文章的重点，不过当时看到这句话的时候，我感觉到了共鸣，压抑已久的心灵终于得到解放，忍不住出门打了三斤白酒站在阳台就喝了起来。
开发效率：
原本我打算连着生产系统一块开发，后来想说先把分销稳定了再说。开发这套系统，至今经历了5个半月。想起当初我的4人团队一个半拉子系统都要搞几年，我惊异于自己的效率。本系统完全从0开始，所采用的框架也非我原本熟悉的，只不过在业务需求上借鉴了行业经验，但也增加了很多实用功能。若一个普通团队开发，我估计要在相同时间内完成几乎不可能（何谓普通？并不大的软件公司的项目团队）。也许你不会赞同我的观点，那是你没有经历过文档流于形式的“赶鸭子上架开发模式”。
这套系统首先大规模的系统重构就有4次，这对我来说，也就咬咬牙的事，但对一个团队意味着繁琐的沟通、重叠工作的分配、不满情绪的滋生、冒出的各种bug、疲劳的重复测试、责任问题、文档更新等等，以及上述负面效应的多次“迭代”。
对于分配给A的任务，你不能保证A完全按照你的想法来，即使功能实现了，你也得检查看看有么有影响运行效率的语句，特别是对能力不足的成员，尤其提心吊胆。在实现难点或功能点较多的模块，通常难以在一开始就明确知道采用何种方式，往往花四天时间构思，两天时间编码，在编码过程中会重构个好几次，这需要编码者有足够胜任该项任务的能力（而一个普通团队中很难有几个相当优秀的程序员，而技术主管又不能事事亲力亲为），有时候还得其它模块配合，这又牵扯出上述情况了。当某处需求实现了，尽管代码看上去并不十分完美，为了“顾全大局”，也就这样吧，甚至优良代码要向劣质代码让步。
若有原成员离开或新成员加入，稀奇古怪的编码风格会让相关成员抓狂，编码风格可以强制规范，但代码逻辑时不常地出现理解偏差。当系统终于成型，呈现出来的很可能是个臃肿的胖子，因为每个开发人员按自己的需求写的帮助类代码，很多都是重复的，更不用说隐藏在各处的私有可抽离代码。这无疑增加了后期维护的成本。
团队开发过程中，有规范的文档会好很多，此时文档就相当于整个团队的大脑负责信息存储的存储区，而成员间的沟通赋予了新的含义，那就是团队思想的源泉。不过我并不认为开发文档（如详设）在一开始就必须存在，而是在项目架构等基本上稳定了，再着手编写。说回来，现在有多少公司的文档作为其原本的意义而存在呢？
创业（？）：
老实说我这还谈不上创业二字，更多的是区别于正常上班的另一种工作方式。若以后能靠这赚点钱更好，否则就当提升下自己的开发能力。我并非做事目的性明确的人，所做的事只是我认为做了并无害处。大多数人都有个创业梦，特别是在IT界，真正去做的寥寥无几；创业并且小有成就的，寥寥无几；创业并且大展宏图的，寥寥无几。这些都不是我的目的，我的目的很简单，多赚点钱，然后做我真正喜欢做的事。
我一直以为我不是能坚持长久的人，特别是独自一人完成一个产品，特别是在一个结婚生子都显略晚的年纪。车子卖了，存款花了，即使通情达理的父母不会埋怨，即使有热心的兄弟帮着给我打气，却在无形中加重了我心中的负担。毕竟代码的世界里我能依靠的只有自己，每天对着显示器敲着一个个代码，偶尔想到迷雾重重的前景，我就想说：算了吧，安耽地找份工作也有不错的收入，何必逞强呢，一个人难道能比一个团队开发出更好的作品吗。孩提时代伟大的理想，此刻变成对社会几乎无用的“赚钱”二字，百年之后，谁又记得我呢？有时思想如同不小心打开的潘多拉魔盒，负面的情绪倾泻而出，让人极为沮丧。
令我欣慰的是，我完成了计划的第一步。没有半途而废并最终完成一个可用的产品，感觉挺好。
最后贴个系统截图以供观赏，截图中的数据为测试数据，图片摘自互联网，所示功能使用MVVM模式开发，若采用Winform，没有引入特殊扩展框架的话，估计至少三倍工作量还不一定能完成吧。
转载请注明本文出处：http://www.cnblogs.com/newton/archive/2013/01/20/2868272.html