oa考勤管理系统解决方案,考勤系统操作流程
903
2022-05-29
入了程序员的行,势必就要做好终身学习的准备,而且要根据新技术的发展不断更新迭代自己的知识体系。自我迭代,是推进小白走向大白的必经之路。学习新知识新技术的同时,我们也需要重视经典的方法论,比如算法、数据结构、软件工程、设计模式等以及程序员修炼之道。
下面是在读这本书时的一些笔记:
1. 人生是你的
你有权选择: 人生是自己的,把握住人生,让它如你所愿。
2. 我的源码被猫吃了
提供选择,别找借口:提供选择而不是去找理由,不要只说做不到,解释一下都能做些什么。
3. 软件的熵
不要放任破窗:只要看到不好的设计、错误的决策、糟糕的代码就赶紧去纠正。
4. 石头做的汤和煮熟的青蛙
做推动变革的催化剂: 你无法强迫人们去改变但可以展示美好未来,并帮助他们参与创造。
牢记全景:不要过度沉漫于细枝末节,以免察觉不到周围正在发生的事情。
5. 够好即可的软件
将质量要求视为需求问题:让用户参与对项目真实质量需求的确定。
6. 知识组合
对知识组合做定期投资:养成学习的习惯
批判性地分析你读到和听到的东西:不要受供应商、媒体炒作或教条的影响,根据自身和项目的实际情况来分析信息。
7. 交流!
英语就是另一门编程语言:将英语视作一门编程语言。写文档和编程一样要遵循DRY原则、ETC、自动化等。
说什么和怎么说同样重要:如果无法有效交流,任何伟大的想法都是没有意义的。
把文档嵌进去,而不要栓在表面:与代码隔离的文档很难保持正确并及时更新。
8. 优秀设计的精髓
优秀的设计比糟糕的设计更容易变更:适合使用者的事物,都已经过良好设计。对代码来说这意味着必须适应变化。
9. DRY邪恶的重复
DRY不要重复你自己:系统中的每一条知识都必须有单一且无歧义的权威陈述。
让复用变得更容易:只要复用方便,人们就会去做。创建一个支持复用的环境。
10. 正交性
消除不相关事物之间的影响:设计的组件,需要自成一体、独立自主,有单一的清晰定义的意图。
11. 可逆性
不设最终决定:不要把决定刻在石头上,而要将其视为写在沙滩上的东西,时刻准备应变。
要有替代方案、放弃追逐时尚:尼尔福特说过: “昨日之最佳实践即明日之反模式。” 要基于基本原则去选择架构,而不盲从于流行。
12. 曳光弹
使用曳光弹找到目标:通过不断尝试并看清着弹点,曳光弹可确保你最终击中目标。
13. 原型与便签
用原型学习:制作原型旨在学习经验其价值不在于过程中产生的代码,而在于得到的教训。
14. 领域语
靠近问题域编程:用问题领域的语言来做设计和编程。
15. 估算
通过估算来避免意外:开始之前做估算,能提前发现潜在问题
16. 纯文本的威力
将知识用纯文本保存:纯文本不会过时,它能够让你的工作事半功倍,并能简化调试和测试工作。
17.Shell 游戏
发挥 Shell 的威力:当图形化界面无法胜任时
18.加强编辑能力
游刃有余地使用编辑器:既然编辑器是至关重要的工具,不妨了解一下如何用它更快更准确地实现需求。
19.版本控制
永远使用版本控制:版本控制为你的工作创造了一个时间机器,可以用它重返过去。
20.调试
去解决问题,而不是责备: Bug 到底来自你的失误还是别人的失误真的不重要,它终究是你的问题,需要你来修复。
不要恐慌
修改代码前先让代码在测试中失效
读一下那些该死的出错信息
“select”没出问题
不要假设,要证明
21.文本处理
学习一门文本处理语言:既然每天都要花大量的时间与文本打交道,何不让计算机帮你分担一二?
22 .工程日记
你无法写出完美的软件:软件不可能是完美的,对于在所难免的错误,要保护代码和用户免受其影响。
23.契约式设计
通过契约进行设计:代码是否不多不少刚好完成它宣称要做的事情,可以使用契约加以校验和文档化。
24.死掉的程序不会说谎
尽早崩溃:彻底死掉的程序通常比有缺陷的程序造成的损害要小。
25.断言式编程
使用断言去预防不可能的事情:如果一件事情不可能发生,那么就用断言来确保其的确不会发生。断言在校验你的假设,要使用断言在不确定的世界中将你的代码保护起来。
26.如何保持资源的平衡
有始有终: 只要有可能,对资源进行分配的函数或对象就有责任去释放该资源
27.不要冲出前灯范围
小步前进由始至终: 永远小步前进,不断检查反馈,并且在推进前先做调整。
28.解耦
解耦代码让改变更容易:耦合使事物紧紧绑定在一起,以至于很难只改变其中之一
29.在现实世界中抛球杂要
30.变换式编程
编程讲的是代码,而程序谈的是数据,所有的程序都在变换数据
31.继承税
不要付继承税:考虑一下能更好满足需求的替代方案,比如接口、委托或 mixin
32.配置
使用外部配置参数化应用程序:如果代码对一些在应用程序发布后还有可能改变的值有所依赖,那么就在应用外部维护这些值。
33.打破时域耦合
通过分析工作流来提高并发性
34.共字状态是不正确的状态
共享状态会带来无穷的麻烦,而且往往只有重启才能解决
35.角色与进程
使用角色来管理并发状态,可以避免显式的同步
36.黑板
使用黑板来协调工作流:使用黑板来协调不相关的事实和代理人,能同时保持参与者之间的独立性和孤立性。
37.听从蜥赐脑
听你内心的蜥蜴:当编程举步维艰时,其实是潜意识在告诉你有什么地方不对。
38.巧合式编程
不要依赖巧合编程:只能依赖可靠的事物。注意偶然事件的复杂性,不要混淆快乐的巧合与有目的的计划。
39.算法速度
评估算法的级别:在开始编程前,对这件事情大概会花多长时间要有概念
对估算做测试
40.重构
尽早重构,经常重构:像除草和翻整花园那样,只要有需要就对代码进行重新编写、修订和架构,以便找到问题的根源并加以修复。
41.为编码测试
测试与找Bug无关
测试是代码的第一个用户
42.基于特性测试
使用基于特性的测试来校验假设
43.出门在外注意安全
保持代码简洁,让攻击面最小:复杂的代码给Bug以滋生之沃土,给攻击者以可趁之机。
44.事物命名
好好取名,需要时更名:用名字向读者表达你的意图,并且在意图改变时及时更名。
45.需求之坑
无人确切知道自己想要什么:软件开发更像是一种由用户和程序员协同创造的行为。
46.处理无法解决的难题
不要跳出框框思考找到框框:在面对无法解决的难题时,识别出真正的约束。可以问自己∶"必须这样做才能搞定吗? 必须搞定它吗?"
47.携手共建
不要一个人埋头钻进代码中:编程往往困难又费力,找个朋友和你一起干。
敏捷不是一个名称
敏捷有关你如何做事
48.敏捷的本质
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
49.务实的团队
维持小而稳定、全功能的团队:团队应保持稳定、小巧,团队中的每个人都应相互信任、互相依赖。
49.椰子派不上用场
做能起作用的事,在用户需要时交付:不要卡着流程要求,刻意等到几周甚至几个月后才交付。
50.务实的入门套件
使用版本控制来驱动构建、测试和发布
尽早测试,经常测试,自动测试
直到所有的测试都已运行,编码才算完成
使用破坏者检测你的测试
测试状态覆盖率,而非代码覆盖率
每个Bug只找一次
不要使用手动程序
51.取悦用户
取悦用户,而不要只是交付代码:为用户开发能够带来商业价值的解决方案,并让他们每天都感到愉快。
52.傲慢与偏见
在作品上签名:过去的工匠在为他们的作品签名时非常自豪,你也应该这样。
开发者
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。