ARTS開啟第九周

algorithm：leetcode 234. 回文鍊錶

請判斷乙個鍊錶是否為回文鍊錶。

示例 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 
* }*/class solution 
return leftstart == slow;
}private listnode reverseoriginallist(listnode head) 
return p;
}// 解法二：先遍歷一遍求出鍊錶長度，計算出鍊錶中間節點的位置。然後遍歷前半段，將其反轉。繼續遍歷後半段，將其與反轉後的前半段鍊錶逐個比較。
private boolean ispalindromesolution_2(listnode head) 
// 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) 
// compare o(n/2)
listnode leftstart = p;
listnode rightstart = size % 2 == 0 ? q : r;
while(leftstart != null && leftstart.val == rightstart.val) 
return leftstart == null;
// total o(n) 空間複雜度o(1)
}// 解法一：將輸入反轉得到乙個新的鍊錶，逐個比較。時間和空間複雜度都是o(n)
private boolean ispalindromesolution_1(listnode head) 
return head == null;
}private listnode reversenewlist(listnode head) 
return p;
}private void print(listnode head) 
system.out.println(sb.tostring());
}}

舉個例子，想在本地寫乙個指令碼，執行一下就可以刪除遠端伺服器上的所有tag等於的docker 映象：

#!/bin/bash
set -e
ssh_ip=xx.xx.xx.xx
ssh_port=yy
ssh root@$ -p $ ' 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@$ -p $ 「 docker rmi \$(docker images -f 』dangling=true『 -q) 」

注意，如果引號裡面又有引號，需要單雙引號巢狀使用。

參考資料：

閱讀原文

分治，不要將複雜邏輯寫在乙個類裡

最好是什麼工具都不要用，次之是用乙個極簡的pipeline模式，最差是使用像流程引擎這樣的重方法

在做過程分解的時候，我建議工程師不要把太多精力放在工具上，放在設計模式帶來的靈活性上。而是應該多花時間在對問題分析，結構化分解，最後通過合理的抽象，形成合適的階段（phase）和步驟（step）上

通過物件的多型可以消除我們**中的大部分的if-else

有過程分解要好於沒有分解，過程分解+物件模型要好於僅僅是過程分解

自上而下的結構化分解+自下而上的物件導向分析。

指導下沉有兩個關鍵指標：復用性、內聚性

復用性是告訴我們when（什麼時候該下沉了），即有重複**的時候。內聚性是告訴我們how（要下沉到**），功能有沒有內聚到恰當的實體上，有沒有放到合適的層次上（因為domain層的能力也是有兩個層次的，乙個是domain service這是相對比較粗的粒度，另乙個是domain的model這個是最細粒度的復用）。

不管是業務技術還是底層技術人員，有一些思維和能力都是共通的。比如，分解問題的能力，抽象思維，結構化思維等等。

「做不好業務開發的，也做不好技術底層開發，反之亦然。業務開發一點都不簡單，只是我們很多人把它做「簡單」了

ARTS開啟第九周

第九周工資

第九周總結

第九周作業

ARTS開啟第九周

第九周 工資

第九周總結

第九周作業

相關推薦

第九周工資