程序员写的代码很糟糕，导致后面无法维护，这样的情况需要承担法律责任吗？

不需要，因为糟糕不糟糕糟糕成什么样子没发界定，很难量化，再者这种风险是企业经营者应该承担的法律，因为你独享了企业收益，那就得独自承担风险

不用，就像做饭一样有的人做的饭好吃有好看，有的好吃卖相一般，有的不好吃卖相还不好你下次不吃就好了难道要让他坐牢？

程序员写的代码是不是越少越好，为什么？

写代码和做产品一个意思，一开始做加法，然后开始做减法！

就我个人而言，能用一行代码搞定的事，休想骗我用十行！

但是在刚开始做开发的时候，由于对语言特性，思想，基本数据结构，API的不熟悉，我们可以写更多的代码来增加自己对编程语言的理解，但是此时的多不应该理解为代码量的多，而是实现方式的多，比如说map的遍历就有多种方式，ketSet，entrySet，迭代等多种方式，如果在一开始使用的时候就只会一种，那么在某些特定的场景里可能并不适用，所以做编程一开始应该学会做加法！

等到熟悉了基本的开发，怎么能用最简便，最清晰的方式做开发变为重点，应该使用最简单的方式实现业务代码。

举个栗子:一个对象list<Man>按照某个字段进行分组，需求很简单，怎么实现呢？

首先new一个map<string，list<Man>>，遍历list，new一个list1，将对象字段作为key，对象放入list1，然后作为value放入map，遍历第二个元素的时候，需要判断这个key是否存在，如果存在，取出存在的list1，将对象放入，如果不存在，new一个list2，将字段作为key，list2作为value放入map，代码实现大概有10行的样子(具体代码不想写)。

但使用JAVA8的流式处理，就一行代码如下:

是不是超级简单？

很多时候，我们代码的简化，得益于源语言的不断升级，所以在实际开发中我们需要不断的拥抱语言带来的新特性，和别人分享的开发技巧，来简化开发流程！

就JAVA语言而言，相对其他的go，scala等都略显笨重，比如使用设计模式进行开发，很多代码都是一开始看没有必要的，但是在后期扩展的时候，会发现十分容易，整个架构也很健壮，使用必要的更多的代码换取程序的健壮性，可扩展性是值得的！

综上，代码并不是越少越好，切勿偏离了代码设计最基本的原则(可扩展性，单一原则，健壮等)，更多的编程技巧，敬请关注。。。

讲真，一开始我也天真的以为代码越少越好，觉得代码少就表示学的东西更加的先进，更加的优质，不过表面上是如此，但是实际上并非如此。好的代码并不在于少，而是在于其健壮性、可拓展性、关键部分有注释、有逻辑性、方便调试、容易维护等等。