对程序员来说最难的是写代码吗？

谢谢邀请！

对于不同阶段的程序员有不同阶段的任务，所面临的难点也并不相同，但是对于程序员来说，代码本身的难度只在学习的初期有所体现，随着编程经验的增加，代码本身的难度会逐渐下降，因为编程语言本身就是工具，只要多使用必然会越来越熟练。

通常情况下，编写代码的难度体现在以下几个方面：

第一：算法设计和实现。编程的核心问题是算法问题，编程问题说到底就是个数学问题，这就是为什么很多人认为编程难的原因，难在算法上而不是在编程语言本身上。算法实现还涉及到数据结构的应用，所以编程也被认为是算法设计加数据结构。算法设计和数据结构涉及到程序的执行效率，这对于大型系统来说尤为重要。对于研发级程序员来说，通常需要具备扎实的数学基础。

第二：架构的选择。架构设计、模块化、数据交换、资源规划、分布式处理、并发处理等问题是程序员面临的又一个难点，相对于算法来说，这部分难点需要大量的经验积累和对技术本身的深刻认知，所以往往架构师都需要有丰富的实践经验。如果说算法解决的是核心问题，那么架构解决的就是整体协调性问题。如果把算法设计看成是优秀的球员，那么架构设计就相当于教练员，只有有效的配合才能取得好的成绩。

第三：技术验证和调试。研发人员重要的任务是验证，验证技术是一个漫长且复杂的过程，要模拟出实际的应用场景，然后通过不同的方案设计来验证执行效率，这通常也是一个比较难的工作。技术验证和调试需要一个团队的配合，一个技术的验证过程往往有众多经验丰富的技术专家来进行，所以这是技术含量比较高的工作之一。

程序设计工作是一个门槛相对较高的职业，通常情况下，程序员在整个职业生涯的过程中也需要不断的学习。

作者简介：中国科学院大学计算机专业研究生导师，从事IT行业多年，研究方向包括动态软件体系结构、大数据、人工智能相关领域，有多年的一线研发经验。欢迎关注作者，欢迎咨询计算机相关问题。

不会写代码，怎么做数据挖掘？

如果熟悉编程,小批量数据可以使用R,Python等,大批量数据可以使用Spark,Flink等.

Python 有一些库如下:

如果不会写代码,也有很多工具可以选择.

收费的:

SAS

SPSS

JMP

Knime

rapidminer

免费的

WEKA

Orange

当然 Excel也可以

如何判断一个程序员写代码好与不好？

程序员写的代码质量好坏可以从两个角度入手

1.好的代码一般通俗易懂

高手总会化繁为简，写的代码首先是能让人看懂，谷歌苹果的工程师代码提交之前都会找上周围的同时给看一遍，如果对方觉得没有什么问题可以直接提交，并且在提交注释里面写上reviewer名字，这样同时也把责任给担起来了，看似一个很简单的模式，却被绝大部分技术公司沿用。

所以代码不能只有自己能看懂，让别人能看懂你的思路，你的设计意图。

2.好的代码，遵守整个系统编码规范，不出格，最重要的一点好的代码能够经得起实践的考验，在实际运转过程中，没有很重大的系统崩溃出现才能称得上好代码

所以代码不能只是看着好，在性能上也需要有不俗的体现，对于程序员来讲代码就是脸面，特别是在团队配合之中，如果一个人写的代码质量高就会给人形成一种靠谱的感觉，在配合过程中也比较容易形成默契的感觉，一看谁写的代码如果平时代码质量高，大家在调用该模块的时候会觉得很舒心，很放心。代码直接关系着程序员的品质问题了，有很多老程序员对于代码质量非常关注，不允许自己犯一些很低级的错误，导致自己的名誉受损。

程序员真的觉得写代码比女朋友重要吗？

这个观点毫无疑问是正确的。

我是一个程序员，代码确实比女朋友重要：

1、代码听你的，女朋天要你听她的

2、代码可以常常更新，女朋友随时可以把你换了

3、代码不会哭，女朋友动不动就哭

4、代码不用你花钱给它买礼物，女朋友各种节日生日都要记得买礼物

5、写代码的乐趣可以持久，多大年龄了都可以写，女朋友的热情度最多保持3个月

6、代码可以不断调优，女朋友怎么打扮也是那个样子

7、代码几乎可以干任何你想让它完成的任务，女朋友给你一堆任务

8、代码可以多种风格，女朋友只有一个性格

9、你生气了可以对代码大喊大叫，女朋友生气了对你大喊大叫

10、你不用对代码说一次你爱它，它也会乖乖地在那里，你要有一天不跟女朋友说爱她，她就能跟你翻脸

11、太多了，我都写不下去了……

写不出代码应该怎么办？

个人认为应做到以下几点基础：

1.其实写代码就和写作文类似，没有一个好的思路是没办法才思泉涌的，所以首先要思路清晰，平时工作当中不要只当一个代码的搬运工，不然这个和搬砖工人有什么区别？（并非歧视）；

2.一定要多思考，思维要灵活谨慎细致，考虑要周全，把每一种情况、状态、条件都要想到；

3.一定要多和相关技术人员、大牛多交流，有利于思路的开拓。

※最重要的一点一定要记住：上层建筑决定意识形态，没有一个好idea是不会有好的代码的！※

做到以上几点再经过勤加练习，假以时日，一定会成功的！加油！

程序员会忘记自己写的代码逻辑么？

谢邀，作为十多年的老码农，遇到过好几次这样的经历：“这是谁写的代码，写的真烂....咦？好像是我之前写的”。

虽然是半开玩笑，不过确实很忘记自己写的代码逻辑，也会觉得自己之前写的代码很烂。

为什么会忘记自己写的代码逻辑

我能想到的大概有这么几种原因：

• 有的时候，代码不一定是自己写的代码，挺多的时候，面对一个自己不熟悉的功能，程序员都是使用搜索引擎找个Demo，拿过来简单调试一下就直接使用，而不去仔细看里面的实现是怎么样的。
  

• 大部分程序员写完代码之后，很少会定期“复盘”自己的代码，甚至写完之后，就不再看第二遍，所以对待自己写过的代码，未必会有深刻的印象。

• 随着工作时间的积累，代码风格也是不断地变化的，很有可能两三年之后，代码风格完全不同。

• 就算没有以上的种种，但随着时间的增长，除了少量印象深刻的代码，相信大部分都会慢慢地遗忘掉。（忘记了，读一读代码，还是能找会自己的）

为什么会觉得自己写的代码很烂

正常情况下，我在看自己三四年前的代码，都会觉得很烂。

我觉得是一件好事儿，因为我在不断的成长，我的代码在不断的进化。

如何防止忘记代码逻辑

很容易，多写注释：

• 方法上的注释，写明这个方法的主要作用是什么，入参出参分别是什么含义。
  

• 变量的注释（首先变量起名就要注意），变量是什么含义，什么情况会赋值成什么。

• 复杂代码块的注释，虽然不用每一行代码都需要写注释，但是复杂的代码块，最好还是写一下当时的思路。

希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、职业发展等方面的见解，希望能得到你的关注；另外，关注我后私信【资料】两个字，可获取架构、大数据、面试等相关资料。

学习写代码怎么样，好找工作吗？

学写代码，但不要只学代码。要有运营的思维。光写代码很简单，能把代码运营好才有用。

如何看待不会写代码的架构师？

入行十几年和很多架构师打过交到，绝大部分的架构师在具备超强的架构能力的同时，同时还兼具强大的编码能力，而且会的编程语言还挺多，从程序员的角度认知，架构师还是需要懂一些代码实现的原理对于架构整体架构还是非常有好处的。毕竟程序代码架构和代码的实现性能息息相关，所以架构不能脱离开代码的实现而单独存在，当然也见过专注于框架，不去在意具体代码的实现，可能是见识浅薄的原因，相对来讲还是非常少。

当今软件的发展分工是越来越精细，对于架构师来讲安心做好框架方面的东西，不关心底层的实现在一定程度上反而有助于提升整体软件体系结构，框架主要体现以下几个方面

1.可扩展性，兼容性

一个好的框架在后续加入新的功能之后，可以有机的结合在一起，新的功能的增加还能和之前的旧的功能有兼容性，两者之间不会因为新的功能的增加而引起冲突，后续再次添加新的功能不需要大范围的改变框架，在国内很多软件公司由于前期工期赶得比较紧迫，后面再次添加新的功能需要改动的东西非常多，导致框架的兼容性不够，成为大家都不敢动的马蜂窝。

2.健壮性

好的框架支持多个功能的同时不能因为功能多，导致性能的下降，这都是需要在设计之初需要考虑的事情，不能因为功能太多，导致整体系统的性能下降太多，里面在设计的时候就需要引入共享池的概念，大家一起共用，同时采用预加载的方式提升效率问题

3.有生命力

好的框架用上几年也不会显得过时，有前瞻性东西，用了几年还能不落伍继续使用，设计之初必须考虑未来几年负载承受能力，这样在大规模的功能上线之后的几年内框架还能支撑住，未来新的未知功能还能继续支撑，这算是架构的最高境界。

满足上述三条至于是不是有编码能力其实已经不是很重要的事情了，相对来讲懂得写代码在架构的时候显得更加接近地气，但容易思维受到限制，关键还是看结果。

希望能帮到你。

2018年，你的最后一行代码打算写什么？

Choose to be here,Not have to be here.

写JAVA后端代码时逻辑混乱怎么办？

后端代码复杂度通过分拆、分而治之来解决。首先通常通过拆分工程、多个工程间可以存在依赖关系，但一定要单向依赖，不能成环，如果有环就得考虑把环形依赖部分拆分出来成为单独的工程，来解决环形依赖。

对于工程里的代码可通过横向拆分、纵向分拆来降低复杂度。横向分层按controler、service、dao、sqlmap，纵向分模块system、biz1、biz2……bizN，但在数通畅联内部，横、纵向拆分相结合模式，如下图：

首先通过横向分拆出controller、cxmodule、module等层次，module作为业务层根据业务功能的不同进行纵向分拆，分成analysis、dwmodel、metadata、schedule等功能模块，在各个功能模块中，横向分拆出exteral、handler、service、sqlmap，其中exteral负责数据接口，提供可调用的服务和接口；handler作为控制层，通过调度代码负责业务的调度，以及一些参数封装、结果集处理等操作；service则是负责具体业务的业务处理层，除了增删改查外，一些贴近业务的功能也会在service中完成；sqlmap用于定义操作数据库的SQL语句。

通过这种分层的方式，实现代码层次的分隔，做到各守各层、结构清晰，对于一些跨模块调用的接口，如在不同模块中需要对同一张数据表进行操作时，可以将接口提升到上层cxmodule中作为公共接口，实现类和方法的复用；对于一些可复用的、相对独立的功能，可以通过在cxmodule中定义一个干净的接口，在module的功能模块中通过实现接口实现业务逻辑，而不使用spring的事务管理机制，降低代码的复杂度。