ARTS打开第九周

Algorithm：Leetcode 234. 回文链表
https://leetcode-cn.com/problems/palindrome-linked-list/submissions/
请判断一个链表是否为回文链表。

示例 1:

输入: 1->2
输出: false
示例 2:

输入: 1->2->2->1
输出: true
进阶：
你能否用 O(n) 时间复杂度和 O(1) 空间复杂度解决此题？

解法一：先遍历一遍，将原链表全部反转得到一个新链表；再遍历一遍，将新旧两个链表逐个比较。时间复杂度和空间复杂度都是O(n)。
解法二：先遍历一遍求出链表长度，计算出链表中间节点的位置。然后遍历前半段，将其反转。继续遍历后半段，将其与反转后的前半段链表逐个比较。时间复杂度是O(n)，空间复杂度是O(1)。
解法二优化：用快慢指针寻找中间节点，反转后半段而不是前半段，因为反转前半段还得关心链表长度是奇数还是偶数。

/**
 * Definition for singly-linked list.
 * public class ListNode {
 *     int val;
 *     ListNode next;
 *     ListNode(int x) { val = x; }
 * }
 */
class Solution {
    
    // 解法二优化：用快慢指针寻找中间节点，反转后半段而不是前半段，因为反转前半段还得关心链表长度是奇数还是偶数。
    public boolean isPalindrome(ListNode head) {
        ListNode fast = head;// 快指针每次移动两步
        ListNode slow = head;// 慢指针每次移动一步
        for(; fast != null && fast.next != null; fast = fast.next.next, slow = slow.next);
        //慢指针指向后半段的起始节点，后半段有可能比前半段多一个节点
        ListNode leftStart = head;
        ListNode rightStart = reverseOriginalList(slow);
        
        while(leftStart != slow && leftStart.val == rightStart.val) {
            leftStart = leftStart.next;
            rightStart = rightStart.next;
        }
        return leftStart == slow;
    }
    
    private ListNode reverseOriginalList(ListNode head) {
        ListNode p = null;
        ListNode q = head;
        ListNode r = head == null ? null : head.next;
        while(q != null) {
            q.next = p;
            p = q;
            q = r;
            r = r == null ? null : r.next;
        }
        return p;
    }
    
    // 解法二：先遍历一遍求出链表长度，计算出链表中间节点的位置。然后遍历前半段，将其反转。继续遍历后半段，将其与反转后的前半段链表逐个比较。
    private boolean isPalindromeSolution_2(ListNode head) {
        // count O(n)
        int size = 0;
        ListNode p = head;
        while(p != null) {
            p = p.next;
            size++;
        }
        
        // reverse the left half O(n/2)
        int half = size / 2;
        int i = 0;
        p = null;
        ListNode q = head;
        ListNode r = head == null ? null : head.next;
        while(i++ < half) {
            q.next = p;
            p = q;
            q = r;
            r = r == null ? null : r.next;
        }
        
        // compare O(n/2)
        ListNode leftStart = p;
        ListNode rightStart = size % 2 == 0 ? q : r;
        while(leftStart != null && leftStart.val == rightStart.val) {
            leftStart = leftStart.next;
            rightStart = rightStart.next;
        }
        return leftStart == null;
        // total O(n) 空间复杂度O(1)
    }
    
    // 解法一：将输入反转得到一个新的链表，逐个比较。时间和空间复杂度都是O(n)
    private boolean isPalindromeSolution_1(ListNode head) {
        ListNode reverseHead = reverseNewList(head);
        while(head != null && head.val == reverseHead.val) {
            head = head.next;
            reverseHead = reverseHead.next;

        }
        return head == null;
    }
    

    private ListNode reverseNewList(ListNode head) {
        ListNode p = null;
        while(head != null) {
            ListNode node = new ListNode(head.val);
            node.next = p;
            p = node;
            head = head.next;
        }
        return p;
        
    }
    
    private void print(ListNode head) {
        StringBuilder sb = new StringBuilder();
        while(head != null) {
            sb.append(head.val);
            head = head.next;
        }
        System.out.println(sb.toString());
    }
}

Review: API design practices for Java

https://developer.ibm.com/articles/api-design-practices-for-java/
文章列出了在做api设计时需要考虑的一些问题：

• Java package必须是一个内聚、稳定的单元。一个package应当围绕一个意图，避免使用像 java.util 这样的package，因为如果一个package里包含好几个主题的内容，势必会产生很多不必要的依赖。同时，package应当以兼容的方式向前演进。
• 最小化包之间的连接。package之间的互相依赖越少越好，这样可以简化模块化系统对依赖的解析。
• 接口优于类，并且api中使用的类型和异常尽量是不变的，不能继承的。
• 避免使用静态成员和静态工厂。API中使用静态成员会导致不易测试。
• 尽量使用依赖注入的方式提供单例而不是使用getInstance的方式。
• 不要对classloader做任何假设。api consumer 和 api provider之间避免传递类名，否则根据类名加载类时可能会遇到可见性问题（因为classloader不同）。应传递Class对象或者该类的某个实例。
• 不要对永久性做任何假设。不要假设对象只被创造而不被回收。也就是说要定义好资源回收的方法，例如实现closeable接口。
• 用文档清楚地说明哪些类型是需要api提供者实现的，哪些是需要api消费者提供的。api提供者对提供者需要实现的接口和消费者实现的接口都敏感，任何一个有改动，api提供者都需要同步改动；api消费者只对消费者需要实现的接口敏感，除非它想使用api中的新的功能，否则它不用关心api提供者接口的改动。

Tip: 使用SSH远程执行命令时单引号和双引号的区别

举个例子，想在本地写一个脚本，执行一下就可以删除远程服务器上的所有tag等于的docker 镜像：

#!/bin/bash
set -e

ssh_ip=xx.xx.xx.xx
ssh_port=yy

ssh root@${ssh_ip} -p ${ssh_port} ' docker rmi $(docker images -f "dangling=true" -q) '

在这个脚本里，我们使用单引号括起了一个command，作为ssh远程执行的命令。这个command里使用$()开启一个新的shell执行一个子命令，将执行完的结果传给 docker rmi 命令。

如果我们用单引号括起command，command里的变量不会被解析，只会作为普通字符串传递到远程机器上，然后在远程机器上被解析，也就是这里的docker images命令和docker rmi命令都是在远程机器上执行的；

如果我们用双引号括起command，command里的变量会先在本地被解析，然后将解析后的结果作为command的一部分传到远程机器上，也就是docker images命令会在本地执行，而docker rmi命令在远程执行。

不注意上述区别的话，我们的脚本就会不work。

另外，如果想要在双引号括起来的command里的变量不在本地解析，也可以在变量前加转义符 \ ，就像这样：

ssh root@${ssh_ip} -p ${ssh_port} “ docker rmi \$(docker images -f ’dangling=true‘ -q) ”

注意，如果引号里面又有引号，需要单双引号嵌套使用。

参考资料：
https://stackoverflow.com/questions/32523398/execute-bash-command-with-calling-subshell-via-ssh-with-here-document
https://blog.51cto.com/hjh524/1566553

Share:阿里高级技术专家方法论：如何写复杂业务代码？

阅读原文

文章以举例子的形式阐述了写复杂代码的方法论，其中提到一些观点，记录如下：

1. 分治，不要将复杂逻辑写在一个类里
2. 最好是什么工具都不要用，次之是用一个极简的Pipeline模式，最差是使用像流程引擎这样的重方法
3. 在做过程分解的时候，我建议工程师不要把太多精力放在工具上，放在设计模式带来的灵活性上。而是应该多花时间在对问题分析，结构化分解，最后通过合理的抽象，形成合适的阶段（Phase）和步骤（Step）上
4. 通过对象的多态可以消除我们代码中的大部分的if-else
5. 有过程分解要好于没有分解，过程分解+对象模型要好于仅仅是过程分解
6. 自上而下的结构化分解+自下而上的面向对象分析。
7. 能力下沉：所谓的能力下沉，是指我们不强求一次就能设计出Domain的能力，也不需要强制要求把所有的业务功能都放到Domain层，而是采用实用主义的态度，即只对那些需要在多个场景中需要被复用的能力进行抽象下沉，而不需要复用的，就暂时放在App层的Use Case里就好了
8. 指导下沉有两个关键指标：复用性、内聚性
   复用性是告诉我们When（什么时候该下沉了），即有重复代码的时候。内聚性是告诉我们How（要下沉到哪里），功能有没有内聚到恰当的实体上，有没有放到合适的层次上（因为Domain层的能力也是有两个层次的，一个是Domain Service这是相对比较粗的粒度，另一个是Domain的Model这个是最细粒度的复用）。
9. 不管是业务技术还是底层技术人员，有一些思维和能力都是共通的。比如，分解问题的能力，抽象思维，结构化思维等等。
10. “做不好业务开发的，也做不好技术底层开发，反之亦然。业务开发一点都不简单，只是我们很多人把它做“简单”了