【讀書心得】(gitbook)程序員的自我修養

突然注意到，近期閱讀另一本推薦的書，沒有轉來這裡。就丟個連結上去看拉XD。
這裡閱讀我的心得筆記：【心得筆記】「松本行弘的程序世界」讀書筆記

剛把另一本也看了一下，雖然書名是「程序員的自我修養」，不過更像一位程序員的經驗筆記而已，跟另一本經典的書–程序員的自我修養：鏈接、裝載與庫差多了(這本很硬)。

推薦指數：★★☆☆☆

前言

這本書在寫這篇觀後感的前五個月還在更新，可以前往GitBook閱讀。不過我自己儲存的紀錄，應該是2016年9月的版本，我不清楚之後加了或修改了多少內容，至少在我看的版本中，有許多非常簡陋的地方。

雖然不太推薦，因為就感覺僅僅是一本快速紀錄的筆記，但仍有一些佳句值得紀錄，故有了這篇心得。

佳句

无论是否是技术人员，我觉得都应该坚持写作。写作带给你的是思维的总结，因为有些事情你只是去想，貌似是很简单。当你去深入思考，其实又是另一个境界。

記得之前就受過這句話影響，最近參加11屆iT鐵人賽頒獎典禮，雖然只是去拿個參賽獎，但回頭看這句話，更有感覺。
喔！對了，最近我GitHub開了新Repo，還在私人狀態，但多少和這有關。

想要成为一个合格的程序员，扎实的基础是必不可少的。
想要成为一个优秀的程序员，对计算机的发展需要有深入浅出的了解。

That why I learn more and more things.
這當然跟為什麼我很少直接用套件有關。除了node.js的11行程式碼刪除事件外，近期發表的一個js建議學習框架，幾個前幾年還有名的掉了下來，多少也強化我這想法。(當然，不是凡是都要自己造輪子，但是懂的造，和只會用是兩個境界)

另外有一個，check list可以參考(我自己目前沒有，或許會拿來用、拿來改)：

常规项

• 代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。
• 所有的代码是否简单易懂？
• 代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
• 是否存在多余的或是重复的代码？
• 代码是否尽可能的模块化了？
• 是否有可以被替换的全局变量？
• 是否有被注释掉的代码？
• 循环是否设置了长度和正确的终止条件？
• 是否有可以被库函数替代的代码？
• 是否有可以删除的日志或调试代码？

安全

• 所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？
• 在哪里使用了第三方工具，返回的错误是否被捕获？
• 输出的值是否进行了检查并且编码？
• 无效的参数值是否能够处理？

文档

• 是否有注释，并且描述了代码的意图？
• 所有的函数都有注释吗？
• 对非常规行为和边界情况处理是否有描述？
• 第三方库的使用和函数是否有文档？
• 数据结构和计量单位是否进行了解释？
• 是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如‘TODO’？

测试

• 代码是否可以测试？比如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。
• 是否存在测试，它们是否可以被理解？比如，至少达到你满意的代码覆盖(code coverage)。
• 单元测试是否真正的测试了代码是否可以完成预期的功能？
• 是否检查了数组的“越界“错误？
• 是否有可以被已经存在的API所替代的测试代码？

最後，最近在求職。

搞技术的，不缺千里马，却的是伯乐。
我们要强大自己的团队，就需要招聘到对的人：技术和思想都一致的人。
STAR原则
所谓STAR原则，即Situation（情景）、Task（任务）、Action（行动）和Result（结果）四个英文单词的首字母组合。STAR原则是结构化面试当中非常重要的一个理论。