准备换一家公司，放弃物流行业，不知是对是错
我因为身体和学历问题，工作机会很少，且年至而立，倍觉前路暗淡。去年经朋友介绍，从北方小镇来到中部某二线城市，进了一个专做立体仓库的公司的软件部。来之前很高兴，终于可以结束私单生涯，贴近一个行业，安安稳稳的做点东西了。于是带了一点小幻想，坐了一天一夜火车，来到这里。

然而当他们打开 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吧