Algorithm

680. Valid Palindrome II

Given a non-empty string s, you may delete at most one character. Judge whether you can make it a palindrome.

Example 1:
Input: "aba"
Output: True
Example 2:
Input: "abca"
Output: True
Explanation: You could delete the character 'c'.

Note:
The string will only contain lowercase characters a-z. The maximum length of the string is 50000.

思路:驗證迴文串使用雙指標，頭尾指標往裡縮，如果遇到不相等的字元，可以刪除左指標或者右指標的字元，再檢測剩下的串是否為迴文串，剩下的串中只要遇到不相等的字元
就判定不是迴文串（一開始的思路完全錯了，用了陣列翻轉的方法，但是這樣的話字串長了時間複雜度會非常高）

/**
 * @param {string} s
 * @return {boolean}
 */
var validPalindrome = function(s) {
    let left = 0;
    let right = s.length-1;
    while (left<right){
        if(s[left] !== s[right]){
            return valid(s,left+1,right) || valid(s,left,right-1)
        }
        left++;
        right--
    }
    return true
};

//這個輔助函式就可以將裡面的串都檢測是否為迴文串
function valid(str,l,r){
    while(l<r){
        if(str[l++] !== str[r--])
            return false
    }
    return true
}
 

Review

先貼地址 7 Skills of Highly “Effective” Programmers

上一篇選的過於簡單，這一篇又太難了，對照谷歌翻譯看得，但是感覺有的句子翻譯的也不好。

這篇文章講的是高效率程式設計師的7個技巧：

軟體工程師會通過練習leetcode題目以及完善簡歷來獲得面試技巧，一旦他們在一家初創公司，谷歌，亞馬遜或是另一家公司獲得了工作
他們用來獲得這份共偶的技能可能跟他們日常工作不匹配。我們團隊受到TechLead所創的高效率程式設計師的七個技巧的啟發，想對此主題提供自己的看法。

1. 學習如何閱讀別人的程式碼

除你之外每個人都在寫糟糕的程式碼。

這就是為什麼一項具有多項好處的偉大技能是能夠遵循別人的程式碼。

無論上一位工程師的程式碼有多麼混亂以及考慮不周，你都需要能夠去遍歷它，畢竟，這是你的工作。即使那位工程師是一年前的你。

這項技能有兩種好處，第一，能夠閱讀別人的程式碼是一個很好地瞭解不好設計的機會。當你瀏覽別人程式碼的時候你會了解哪些有效哪些無效。
更重要的是，你能瞭解到哪種型別的程式碼易於其他工程師遵循，哪種很難遵循。

你需要確保儘可能多的閱讀別人的程式碼。這樣，其他工程師會了解你是一位怎樣的高階工程師。

確保你能提出關於可維護程式碼以及良好註釋的重要性的觀點，這更進一步表明你在程式設計領域的領導地位。

你的設計應該井井有條，不需要任何文件。事實上，如果你是一位優秀的程式設計師你不需要編寫任何關於程式碼的文件。
這只是浪費時間，你需要話費時間程式設計以及參加會議進行討論。

能夠閱讀別人混亂的程式碼也會使得在有需要時更新變的容易。這同時意味著你缺乏更新程式碼的經驗。例如，我們曾經將指令碼從Powershell
轉換為Python再轉換為Perl。我們在Perl方面經驗有限，但是我們仍然有足夠的背景知識弄清楚發生了什麼並做出所需的更改。

這源於對所有程式碼的理解以及對Perl的瞭解。

閱讀別人的程式碼會使你更有價值，因為你可以遵循可能會絆倒別人的過度設計的系統。

2. 對不良專案的敏感度

有很多技能需要花費時間去了解，我們認為值得了解的技能之一是明白哪些專案不值得做，哪些專案顯然是步履維艱。

大公司的專案總是比可能完成的或者影響更大的專案多。有很多專案可能不會產生任何商業影響（至少不會對你），還有一些專案管理不善。
這並不是說當你不同意專案中的一些觀點時就要放棄你的想法。但是如果利益相關者不能合理的解釋最終結果會是什麼樣的，那這個專案大概是不值得做的。

同樣，有些專案可能聚焦於技術而不是解決方案，因此從一開始就很明顯不會產生太大影響。這項技巧需要你在明白不良專案到底是什麼樣之前
就做過很多不良專案。因此不要花費太多時間在辨別不良專案上。

在你職業生涯的某個時候，你會有良好的直覺。

3. 避免開會

無論你是軟體工程師還是資料科學家，開會都是必須的，因為你需要能夠與專案經理，終端使用者和客戶商議同一件事。但是
會議也有可能突然佔據你的整個行程。這就是為什麼學會如何避免不必要的會議是很重要的。或許更好的說法是管理而不是避免。
這裡的目標是確保你花費在會議上的時間能夠驅動決策並且幫助團隊前進。

最簡單的方法是每天安排一個兩小時的固定會議。通常情況下大多數會在他們覺得有益的時候召開一次定期會議。他們會利用這個時間
來趕上開發工作。

另一種避免會議以便完成工作的方式是在其他人之前出現。就個人研二，我們喜歡早點來，因為通常來說，辦公室是安靜的。
大多數像你一樣早來的人只是希望在沒人煩你的時候完成工作。

這對個人貢獻者而言是很重要的，因為我們的工作需要時間專注並且不跟其他人說話。是的，有時候你可能會想和其他人一起解決問題。
但是一旦你克服了阻塞問題，你只需要編碼。它是關於一個區域，在這個區域裡你會對你正在做的工作在你的頭腦中產生源源不斷的複雜的想法。
如果你停止了，你就很難再從你停止的地方撿起來。

4. GitHub...等不了嗎？

很多計算機專業的學生在他們成為學生起就使用Git，他們瞭解每一個命令，引數，並能在專業人士周圍打轉（我覺得是離專業人士很近了）。
其他人在他們一開始工作的時候才開始接觸Git，對他們而言，Git是地獄般的風景，由於他們混亂的命令和程序。
他們不會100%確定他們在做什麼（這也是備忘錄受歡迎的原因）。

無論你們公司使用的是什麼倉庫系統，如果能正確使用，系統就是有幫助的，不能合理使用系統就會成為阻礙。一個簡單的push或commit不需要太多時間就能
讓你花費數小時來解開由多個分支和分支組成的大雜燴。另外，如果你忘記拉取倉庫的最新版本，你將需要解決合併從未有過的衝突。

如果你需要記錄git命令到備忘錄上，那就去做，這會使你的生活變得簡單。

5. 編寫簡答可維護的程式碼

年輕工程師可能會有的一個傾向就是他們會想要在一種解決方案中實現他們所知道的一切事情。你需要了解面向物件程式設計，資料結構，設計模式和新技術，
並在你編寫的每一段程式碼中用到它。你創造了一種不必要的複雜性，因為你過度依賴於你過去使用的解決方案或者設計模式。

在複雜的設計層面和簡單的程式碼之間應該有一種平衡，設計模式和麵向物件的程式設計旨在簡化計劃中的程式碼。然而，越多的程式被抽象，封裝，黑盒，越難以除錯。

6. 學會說不併分清輕重緩急

這確實是對所有角色有用，無論你是金融分析師還是軟體工程師。但是特別的，技術角色似乎讓每個人都需要一些東西。
如果你是一位資料工程師，你可能會被要求做的不僅僅是開發工作。一些團隊需要資料提取，其他團隊需要儀表盤，還有一些團隊需要為他們的資料科學家提供
新的管道。

現在，分清主次和說不可能確實是兩項不同的技能，但是他們是緊密交織的。分清主次意味著你僅需要花費時間在公司有重大影響的事情上。而說不僅以為這避免需要由
不同團隊解決的工作。對於所有角色來說他們通常是同時發生的。

這可能是很難掌握的一項技能，因為它很容易接受你提出的每一項請求。尤其是你剛從大學畢業。你不想讓任何人失望，你總會有很多事要做。

在大公司裡總會有無盡的工作量，關鍵是隻做能做的事。

有很多技能沒有在面試中測試過甚至大學裡沒有教過。通常，這是由於環境的限制，而不是缺乏將學生暴露於實際開發中已存在的問題的願景。

7. 操作設計思維

一項很難再面試中測試並且在大學課程中很難複製的技能是思考終端使用者會如何不正確的使用你的軟體。我們通常將其稱為思考操作場景。

然而這只是一種對於你偽造證據程式碼的禮貌的說法。

例如，由於大部分程式設計都是維護性的，因此通常意味著更改與其他程式碼高度糾結的程式碼。
即使是一個簡單的更改也需要跟蹤物件、方法和/或API的所有可能引用。
否則很容易意外的破壞你沒有意識到是連線的模組。即使你只是在修改資料庫的資料型別。

也包括在開發之前考慮邊界情況以及完整的頂層設計。

在開發新的模組或者微服務時的一些更復雜的情況，花費時間去思考你正在構建的操作場景是很重要的。思考將來使用者會如何需要你的新模組，他們會如何不正確的使用它，
哪些引數是需要的，將來程式設計師是否有不同的方式使用你的程式碼。

簡化程式碼與程式只是問題的一部分。創造出在你的機器上執行良好的軟體是很容易的。但是有很多部署程式碼的方式可以產生錯誤。一旦投入生產，很難說哪些程式碼會被使用以及哪些會與你的原始程式碼關聯。
從現在之後的五年，未來的程式設計師可能會因為你程式碼的侷限性而感到沮喪。

這篇文章讀的我很累了，不過確實很有用，有一點我覺得說的很對，在我們對基礎掌握不牢或者運用不熟練的時候我們總想把我們知道的所有的東西用在一個解決方案裡，這可能會使得程式碼變的複雜而不可維護

Tips

剛剛學到的，GitHub上fork的用法，可以將他人倉庫的專案複製到自己的倉庫，這樣push的時候就只是提交到自己的倉庫中而不必擔心會修改原作者的專案。

Share

想分享一個前端面試題庫的小程式，叫高階前端面試。