学习笔记之三十年软件开发之路 - Things I Learnt The Hard Way (in 30 Years of Software Development)

三十年软件开发之路

• https://mp.weixin.qq.com/s/EgN-9bIHonRid1DM0csQDw
• https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/
• 【CSDN编者按】“千帆过尽仍少年”，对于程序员来讲，保留技术初心、不断提高实力是夯实本身的不二法则。而本文的做者，做为一名有着三十多年开发经验的“老”程序员，就在本文中详细总结了本身这些年踩过的坑和实践得出的真理，谈到了包括软件开发、团队工做、我的成长等方方面面。

---

• 软件开发
  • 先明确问题，再开始写代码
  • 将步骤写为注释
  • Gherkin是帮助你了解指望（expectation）的好帮手
  • 单元测试很好，集成测试更好
  • 测试可让API更好
  • 作你知道如何在命令行上运行的测试
  • 时刻准备好扔掉你的代码
  • 好的语言生来带有综合测试
  • 将来思路是垃圾思路
  • 文档是写给将来本身的情书
  • 功能文档是份合同
  • 若是一个函数的描述包含“和”，这就是不对的
  • 不要使用布尔型变量做为参数
  • 注意界面的变化
  • 好的语言自带集成的文档
  • 一门语言毫不仅仅是一门语言而已
  • 有时候，宁愿让应用程序崩溃也不要什么都不作
  • 若是你知道如何处理该问题，那么就处理它
  • 类型决定你的数据是个什么东西
  • 若是你的数据具备模式（schema），请使用结构（structure）来保留它
  • 理解并保持cargo cult的方式
  • 不要管所谓的“合适的生产力工具”，你只须要尽力去push进程
  • “正确的工具”比你想象的更明显
  • 不要跟你项目以外的事情纠缠
  • 数据流动比模式更重要
  • 设计模式是用来描述解决方案的，但它不能找到解决方案
  • 学习函数式编程的基础知识
  • 认知成本是可读性的杀手
  • Magical Number 7 ，正负二（7+-2的范围内）
  • 走捷径挺nice的，但只是在短时间内如此
  • 抵制“轻松”的诱惑
  • 老是在你的日期中使用时区
  • 老是使用UTF-8
  • 从笨办法开始
  • 日志用于事件，而不是用户界面
  • Debugger们被高估了
  • 始终使用版本控制系统
  • 每次提交一个更改
  • 当你过分交换时，“git add -p”是你的朋友
  • 按数据/类型组织项目，而不是功能
  • 建立库
  • 学会监控
  • config文件是个好东西
  • 命令行选项很奇怪，但颇有帮助
  • 不单单是功能组成，还有应用程序组成
  • 即便是作APP，也要从原始的东西开始
  • 优化是面向编译器的
  • 经过懒惰（评估）
• 在团队/工做上
  • code review并非为了彰显风格
  • 代码格式化工具还能够，但它们也不是无往不胜的
  • 代码风格：遵循它就是了
  • ...除非代码样式是Google Code样式
  • C / C ++只有一种编码风格：K＆R
  • Python只有一种编码风格：PEP8
  • 显式优于隐式
  • 公司想要专才，但全才在公司待的时间更长
  • 心中有用户
  • 处理用户数据的最佳安全方法是压根不捕获它
  • 记下来那些“让我花了一个多小时才解决的愚蠢失误”
  • 若是它没法在你的计算机上运行，那么你就有麻烦了
• 我的生活
  • 该停下来的时候，就停下来吧
  • CoC保护的是你，而不是别人
  • 学会说不
  • 你负责你代码的使用
  • 当还没完成时，不要说“已经完成了”
  • 你将从痛苦中了解你自身
  • 人们之因此会对代码/架构感到生气/烦恼，是出于关心
  • 从你的烦恼中学习
  • 注意人们对你的反应
  • 学会识别那些人格有毒的人，并远离他们
  • 谨防微观侵略
  • 不，我不认为这样的人是“会改正的”
  • 只有当你意识到本身是那类有毒的人/微侵略者时，才有可能本身改正
  • 英雄项目：总有一天你必须作的事情
  • 不要混淆“英雄项目”与“英雄综合症”
  • 知道什么时候该果断辞职
  • IT世界是一个很是小的“蛋”
  • 纸质笔记实际上颇有帮助
  • Trello很是酷，但Post-it更好
  • 在博客中记录你笨手笨脚的解决方案仍然比什么都不写要好
  • ...但请关闭评论
  • 把你的笨手笨脚的解决方案发布到网上
  • 列出“我不知道的事情”