ARTS第0周

ARTS是左耳朵耗子专栏《左耳听风》用户自发每周完成一个ARTS：

1.Algorithm：每周至少做一个 leetcode 的算法题

2.Review：阅读并点评至少一篇英文技术文章

3.Tip：学习至少一个技术技巧

4.Share：分享一篇有观点和思考的技术文章

看到这个消息的时候，觉得是一次很好的机会，因为这4点是目前很想做的事，但奈何人本性懒，一直未开始。

1.Algorithm:之前几乎没怎么好好学过算法。所以就去leetcode做了最简单的一道：

给定一个整数数组 nums和一个目标值 target，请你在该数组中找出和为目标值的那两个整数，并返回他们的数组下标。

你可以假设每种输入只会对应一个答案。但是，你不能重复利用这个数组中同样的元素。

示例:

给定 nums = [2, 7, 11, 15], target = 9因为 nums[0] + nums[1] = 2 + 7 = 9所以返回 [0, 1]

答案：

class Solution {

    public int[] twoSum(int[] nums, int target) {

        for(int i=0;i

            int j = i + 1;

            int total = 0;

            while( j < nums.length){

              total =  nums[i] + nums[j];

                if(total == target){

                    return  new int[]{i,j};

                }

                j++;

            }

        }

      return null;

    }

}

写的最简单的解决方式，但因为没用ide，一直因为小细节出现问题。而且也顺便了解到不仅仅只是为了写出来正常运行，更为重要的是算法的性能：时间复杂度和空间复杂度。以后都会注意这个问题。

2.Review

https://mubu.com/doc/udAENYn4ud

因为没找到其他合适的英文文章。但我觉得这篇开始也是很有意义的。

我的定位是自己处在拐点上，所以要做的是踏踏实实把基础打牢。

3.Tips

最近在做ip相关业务，因为第一次做没任何经验，但是发现所有的ip转成long，存储或查询都会省很多事，还会增加性能。

4.Share

文章直接写吧

                                               编程必要条件--解决问题

    我是一个转行来学的半路出家的非专业人员。犹记得当初也是因为对于电影中的程序员无笔崇敬，另外，也是大学导师告诉我，多学编程挺好——他自己就写了个小工具让我们用。我就觉得这是多么棒的事情！后来，也确实做了这一行。

   我碰到的很多转行的或者一些本行的刚工作的程序员，很多其实没有太多想法

1.只是知道别人告诉我要这样做，或者带我的师父要我这样做（问题一：不思考）。

2.工作也只是按照自己理解的做，没太多交流（问题二：不敢或不习惯和别人沟通，问题三：并没有想过主动了解自己的工作任务）

3.业务实现不了后，只是一味的网上找答案（问题四：没对自己的代码完全掌控）

其实上述的四个问题其实都在解决问题这个大板块上。

问题一：这个就完全是个搬运工，别人说什么就是什么。任何事都这样，这是最糟糕的。

后果：你永远无法进步。

问题二：这个问题其实尤其突出，大部分的人都会这样。

后果：很多业务问题不提前沟通，就会增加很多后期本不需更改的代码。甚至整个方向全改。

问题三：这个好像也挺多，具体就是，你说什么我就按照自己理解的直接写。这个后果和问题二是重合的。

问题四：后果：一但出现bug,无能力解决

其实很多人也许想到这些内容，但就是做不到。

问题一：我觉得是态度问题，编程本来就是脑力劳动，如果连这最根本的你都否认，但也许你并不适合。

问题二：所有的误会都发生在没有及时沟通的时候。其实，真的去沟通后，就会发现真正要做好工作的人是绝不会因为沟通过多而烦你，反而是你，没及时沟通会更令人烦恼。所以，大胆沟通吧。

问题三：这个其实也属于沟通。你要及时反馈让别人明白你要怎么做，这样才能确认任务传达是有效的。

问题四：出现问题，善用搜索是对的，但是必须是你完全理解这样做的原因及效果。这样技术才会越来越好，下一次才会能解决相同的问题。

上面说的都是解决问题相关项。其实还有很多，以后有机会再详细展开吧。