观谈影视
写代码和做产品一个意思，一开始做加法，然后开始做减法！
就我个人而言，能用一行代码搞定的事，休想骗我用十行！
但是在刚开始做开发的时候，由于对语言特性，思想，基本数据结构，API的不熟悉，我们可以写更多的代码来增加自己对编程语言的理解，但是此时的多不应该理解为代码量的多，而是实现方式的多，比如说map的遍历就有多种方式，ketSet，entrySet，迭代等多种方式，如果在一开始使用的时候就只会一种，那么在某些特定的场景里可能并不适用，所以做编程一开始应该学会做加法！
等到熟悉了基本的开发，怎么能用最简便，最清晰的方式做开发变为重点，应该使用最简单的方式实现业务代码。
举个栗子:一个对象list
首先new一个map<string>>，遍历list，new一个list1，将对象字段作为key，对象放入list1，然后作为value放入map，遍历第二个元素的时候，需要判断这个key是否存在，如果存在，取出存在的list1，将对象放入，如果不存在，new一个list2，将字段作为key，list2作为value放入map，代码实现大概有10行的样子(具体代码不想写)。/<string>
但使用JAVA8的流式处理，就一行代码如下:是不是超级简单？
很多时候，我们代码的简化，得益于源语言的不断升级，所以在实际开发中我们需要不断的拥抱语言带来的新特性，和别人分享的开发技巧，来简化开发流程！
就JAVA语言而言，相对其他的go，scala等都略显笨重，比如使用设计模式进行开发，很多代码都是一开始看没有必要的，但是在后期扩展的时候，会发现十分容易，整个架构也很健壮，使用必要的更多的代码换取程序的健壮性，可扩展性是值得的！
综上，代码并不是越少越好，切勿偏离了代码设计最基本的原则(可扩展性，单一原则，健壮等)，更多的编程技巧，敬请关注。。。
此生唯一
作为一名程序员，我来谈谈我的看法。
其实这种说法是不对的。
程序员写代码，其实讲究的首先是如何去实现产品的这个功能，然后才是如何使用最优解来实现。记住，最优解不是说代码越少就是最优方案。这是个大误区。
好的代码其实不是说量越少越好，而是说时间复杂度越低越好。比如举个简单的例子，你用一行代码写了一个功能，但是这个功能十分消耗性能和时间，而你用十行代码写了一个一样的功能并且这个功能不怎么消耗时间，你觉得哪一个代码算的上好？
其次，好的代码他自己会说话。我们在写代码的时候对于产量名称，或者方法名称都十分有讲究，这个不能乱写，要让别人接手的人能够看得懂才行。并且好的代码的逻辑和条理是非常清晰的，一目了然。而不像有些代码东一点西一点，乱七八糟，看的人头晕目眩的，这种代码越少越看不懂，越少越垃圾。
总而言之，好的代码必须满足两点，一点是时间复杂度没那么高，不消耗大量的性能。第二点，逻辑清晰，能够让人一看就能够明白。这才是好代码。
晨雨细曲
个人经验，代码，就是对现实世界的虚拟，什么对象，函数，类，接口，等很多概念。用现实世界的一件事来表述，做汽车，a厂做钣金，b厂做发动机，c厂做轮胎。程序员把各厂生产的部件弄起来，那些厂有的已经有了，如果没有，那就先成立一个。就这么简单，
明天101434451
兵无常势水无常形，代码多还是少，要看需要，比如在某些极度追求性能的C程序核心算法点，做20个元素整型数组每个元素的逐个处理，也许一个循环一个函数三十行代码就完事，为了效率可能会换成在一个代码片段内逐个写每个元素的处理代码，虽然单调重复，但也比编译器自动优化要高出零点几个到近一个百分点的性能。必要的时候还可能把那个重复的代码段换成汇编语句内嵌以期再提升一个百分点的性能，如此一来代码量更大了。
这个例子也要分两面来看：如果认为为了提升性能产生的代码是必要的，则我们提到的“代码量更大”这个判断不成立——干这活本来就需要这么多的代码，还能在性能保障的前提下有代码的精简末？如果有，Do it。这么看的话，又是代码越少越好了。
当然多数时候，代码的简洁、维护性好是优先级更高的事情。程序员往往会有个习惯，对自己写的代码隔一段时间重构一次——因为对业务更熟悉、算法的构思更精炼了，有了更好的结构、更便于维护、风险更小，重构的念头就会产生。
米爸来啦
代码的长度决定不了程序员的水平。比如有的任务一开始需要写20行，封装后用一行代码就可以完成。但是有的任务需要更高的精度和执行速度，你就必须对底层操作，比如指针，汇编，封装反而影响了执行速度，你需要写更多的代码。
代码长度取决于任务需求。
并且在团队里，为了代码的可读性，不能太长，因为记不住。也不能太短，因为看不懂。
小汐vivi
通常，一个正常项目不是所有的代码都是自己写的。会引用很多框架frame work。这些框架是其他程序员写的，但它们迭代了多个版本，负责这些框架的程序员可能本身水平就高……最终，这些框架通常会比现写的代码更稳定，更容易维护。
对于平均水平及以下的程序员，或者项目周期短，应该尽量使用框架，尽量减少自己写的新代码。这样可以在可接受的时间内，获得一个平均水平的软件。
对于有更高要求的项目来说，通用框架很难达到要求（安全，速度，可维护性等）。而且，能召集更多高水平程序员的情况下，要发挥这些程序员的价值，以获得一个竞争能力更强的软件，就必须重新构架了。当然，更少代码，通常会有更快的运行速度，更少bug。对于高级程序员来说，简洁，明快，有欣赏性的代码，也是骨子里的追求（否则不可能到高级）。
我低端就改我名
是有那么回事，否则不会有面向对象的光辉，和组件化、服务化等设计思想了。它们是为了代码重用，解藕而生。试想一下，相同代码无数次重复出现，这样的代码量绝对够多，但是无法维护。只不过，你调用不是你写的代码的话，就是依赖，过分的依赖也不好维护，升级困难，冲突多。看你怎么权衡吧。
自以为神人的鸟人
本人大数据开发一枚
这个，不敢苟同，写代码，很多时候不是写hello word 就完事了，更多的时候要考虑代码的其他方面，比如，数据一致性，线上数据有问题，代码怎么办，代码的分布式锁，请求过多打爆了数据库怎么办等等等等，所以，代码越少，意味着，你考虑的越少，遇到情况就会出问题维护，这样，问题一多，维护成本就会很高，所以，代码并不是越少越好
爱动漫的小迷弟
猴子哟吐槽
是的 代码量越少越好 ！因为代码量可以看出一个人的技术 也方便 后期软件修改也有好的帮助
