我因为身体和学历问题,工作机会很少,且年至而立,倍觉前路暗淡。去年经朋友介绍,从北方小镇来到中部某二线城市,进了一个专做立体仓库的公司的软件部。来之前很高兴,终于可以结束私单生涯,贴近一个行业,安安稳稳的做点东西了。于是带了一点小幻想,坐了一天一夜火车,来到这里。
然而当他们打开 visual studio,给我介绍代码的时候,我吃了一惊。
程序名义上是 CS 结构,但实际上没有服务端。扮演服务端角色的是一些 dll,winform 做的可执行程序通过 remoting 使用这些 dll。但是他们使用 remoting 的方式很特别,所有的调用通过一个方法实现,方法的签名是这样的:
public static void Call(string dll, string cls, string method, Info info)
这个方法做的全部事情就是根据前三个参数找到一个业务方法,用反射来调用。结果就是,这些 dll 必须和主程序放在一个目录中,否则程序不能运行。这是 remoting 吗?对此,他们的解释是,我们将来打算把这些 dll 放在真正的服务端里。
再看一下第四个参数,Info 类,这是传递给业务方法的参数,这个类非常狗血,大致是这样的:
- C# code
public class Info{ // 几个 DataTable 字段 public DataTable TableA; public DataTable TableB; public DataTable TableC; public DataTable TableD; public DataTable TableE; // 几个 string 字段 public string StrA; public string StrB; public string StrC; public string StrD; ...}
所有的业务数据通过 Info 类的实例来传递,方法返回时,返回值也从 info 中读取。至于 TableA, TableB, StrA, StrB 这些东西在调用方法前后是什么意思,由写代码的人自己解释。Info 类的另一个问题是,所有的业务数据在编译时都没有类型信息,全部是 object 或 string。强类型语言编译器带来的诸多好处,像烂菜叶一样给丢到了垃圾桶里。
业务逻辑的实现也是一塌糊涂。说这些是业务逻辑不够准确,这些代码并没有定义体现业务含义的接口,而完全是数据访问风格。套路是这样的:如果有一个名为 Group 的表,那么就写一个 Group 类,类中的标准方法有:Init,Select, Insert, Update, Delete。相应的,UI 上会有一个叫做 frmGroup 的窗体,Group 类就是给这个窗体使用的。我曾经添加了一个稍微表意一点的方法,然后被告知,这个方法不符合规范,你应该使用 Update 完成操作。而 sql 语句的编写也有很坑爹的要求,随便复制一句:
- C# code
String sql = string.Format(@"select {3}, {6}, {7}, {8}, {0}, {9}, {4}, {10}, {11}, {1}, {2}from {5}where ({3} = {12})"...);
这个写法将来能维护么?
刚来的时候我提了几个建议:使用强类型,使用表意的标识符,添加单元测试,写能体现业务的代码,不要滥用缩写(到处是匪夷所思的缩写)。被一一驳回。于是自觉无趣,不再说什么。
一直听大牛们说,写代码要贴近一个行业,才不至于被一波又一波的技术浪潮拍死在沙滩上。物流是个很有发展的行业,这家公司可能是我接近这个行业的唯一机会。只是我实在忍受不了那些编码方式了,混了半年,终于决定走人。是对是错,心中没底。
------解决方案--------------------
对这个设计实在是无语,做做玩具还行,遇到复杂的业务怎么维护......
------解决方案--------------------
看完了。其实每个公司的开发部门都有一套他们的开发框架,生搬硬套,没有创新,只图完成项目,收钱了事。
------解决方案--------------------
开发方式有很多种。早期vs2003开发的转过来的。基本上都是这个写法。
楼主说要进行某一行业。行业就和技术没有太多关系,只要能实现就可以。你所说的三层,实体类固然好。但也只是其中一种写法。
三层的东西你如果关联十几个表。同时更新七八个表的数据。那就比较难弄了。
可是你用这种方式。处理非常复杂的逻辑关系。却是非常自由。
------解决方案--------------------
------解决方案--------------------
不管什么技术只要用户已经能够稳定的使用,那就说明这技术已经完成了量变到质变。
所以LZ不该只看到这套框架的缺点
------解决方案--------------------
很霸气的公司······无论能否赚到钱,只要LZ跟着这么写代码···你的习惯就会很烂了···
------解决方案--------------------
楼主我支持你闪人。
------解决方案--------------------
- C# code
如果温饱没问题就san吧