随笔分类 - 读书笔记
摘要：上一期已经成功生成了APK能成功安装到手机上了，图标和初始屏幕很难看，接下来着手修改图标和初始屏幕 一、修改图标 打开项目文件.csproj，找到以下代码 <!-- App Icon --> <MauiIcon Include="Resources\AppIcon\appicon.svg" Fore
阅读全文
摘要：上一期说到了如何生成APP应用，生成的文件是AAB格式的，这个格式安装不是很方便，如果能生成APK就好了 一、设置APP格式 打开项目文件.csproj，在PropertyGroup下添加属性 <AndroidPackageFormat>apk</AndroidPackageFormat> 二、设置
阅读全文
摘要：PS：开个新坑，内容都是全新接触的东西，包括MAUI，Blazor，MASA等等。整个项目都边学习边做的，有什么错的地方望大神指教。 学习开发安卓应用，我们的最终目标就是要生成一个APP应用，并能成功的在手机端打开。那么，我们首先要解决的就是怎么生成APP应用。 一、创建一个.NET MAUI Bl
阅读全文
摘要：官方的C#历史版本特性变更是按版本排序的，知识点有些乱，我就产生了一个想法，以一个数据库操作模块对这些知识做一个整合 注意事项： 1、不一定会整合所有的特性变更，但是努力整合 2、由于目的是在介绍历史版本特性，代码的实现不一定是最优方案 废话不多说，先上一段实体类代码 定义实体类 public cl
阅读全文
摘要：可用性定律 1、“别让我思考” 2、点击多少次都没关系，只要每次点击都是无须思考、明确无误的选择 3、去掉每个页面上一半的文字，然后把剩下的文字再去掉一半 关于网络使用情况的三个事实 1、不是阅读，而是扫描 2、不作最佳选择，而是满意即可 3、不是追根究底，而是勉强应付 广告牌设计101法则 - 为
阅读全文
摘要：失败的学位教育 符合要求的毕业生有个共同点，进入大学之前就已经自学编程，并且在大学里依然保持自学。 学校中所学的内容和在工作中发现的实际需要，这两者之间通常会有巨大的差异。 辅导 1、精心编写的帮忙手册 2、观察他人工作 3、非常规辅导 4、艰难的锤炼 学徒期 软件学徒期 1、大师 2、熟练工 3、
阅读全文
摘要：只是简单混合吗 有凝聚力的团队 形成团队是需要时间的。团队成员需要首先建立关系。 有凝聚力的团队通常有大约12名成员。7名程序员、2名测试人员、2名分析师和1名项目经理。 1）发酵期 成员克服个体差异性，默契配合，彼此信任，形成真正有凝聚力的团队，需要6个月到1年的时间。 一旦团队有了凝聚力，最好的
阅读全文
摘要：程序员与人 程序员与雇主 专业程序员的产要职责是满足雇主的需求。 专业程序员会花时间去理解业务。 程序员与程序员 程序员之间通常很难密切合作 1、代码个体所有 2、协作性的代码共有权 3、结对
阅读全文
摘要：避免压力 在压力下保持冷静的最好方式，便是规避会导致压力的处境。 承诺 避免对没有把握能够达成的最后期限做出承诺。 有时有人会代我们做出承诺。出于责任感我们必须主动找到方法来兑现承诺，但是一定不能接受承诺。 保持整洁 让系统、代码和设计尽可能整洁，就可以避免压力。 危机中的纪律 选择那些你在危机时刻
阅读全文
摘要：什么是预估 不同的人对预估有不同的看法。业务方觉得预估就是承诺。开发方认为预估就是猜测。 承诺 承诺是必须做到的。专业开发人员不随便承诺，除非他们确切知道可以完成。 如果被要求承诺做自己不确定的事情，那么就应当坚决拒绝。 预估 预估是一种猜测。它不包含任何承诺的色彩。 大多数软件开发人员都很不擅长预
阅读全文
摘要：会议 关于会议两条真理： 1、会议是必需的 2、会议浪费了大量的时间 拒绝 理智地使用时间，所以必须谨慎选择，应当参加哪些会议，礼貌拒绝哪些会议。 好的领导一定会主动维护你拒绝出席会议的决定，因为他和你一样关心你的时间。 离席 仔细管理自己的时间是你的责任。如果你发现参加某个会议是在浪费时间，就应当
阅读全文
摘要：QA应该找不到任何错误 QA也是团队的一部分 QA和开发人员应该紧密协作，携手保障系统的质量。 QA在团队中要扮演的便是需要规约定义者（specifier）和特性描述者（characterizer）。 需求规约定义者 QA的任务便是和业务人员一起创建自动化验收测试，作为系统真正的需求规约文档。 业务
阅读全文
摘要：需求的沟通 开发方与业务方之间最常见的沟通是关于需求的。业务方描述他们认为自己需要的东西，程序员按照自己理解的业务方表达的需求来开发。 在现实里，关于需求的沟通是极其困难的，其中会出现各种问题。 过早精细化 做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化。 1、不确定原则 每次向业务方展
阅读全文
摘要：编程柔道场 卡塔：编程卡塔是一整套敲击键盘和鼠标的动作，用来模拟编程问题的解决过程。 瓦萨：两个人的卡塔。一个人负责攻，另一个人负责守。 自由练习：很像由两个参与者解决问题的瓦萨，也可以有多人参与。 自身经验的拓展 职业程序通常会受到一种限制，即所解决问题的各类比较单一。老板通常只强调一种语言、一种
阅读全文
摘要：此事已有定论 TDD绝不仅仅是一种用于缩短编码周期的简单技巧。 每个开发人员都要适应和掌握TDD。 TDD的三项法则 1、在编好失败单元测试之前，不要编写任何产品代码。 2、只要有一个单凶测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况。 3、产品代码恰好能够让当前失败的单元测试成功通过
阅读全文
摘要：要精熟掌握每项技艺，关键都是要具备“信心”和“出错感知”能力。 做好准备 在编码时必须平衡互相牵制的多种因素 1、代码必须能够正常工作。 2、代码必须能够帮你解决客户提出的问题。 3、代码必须要能和现有系统结合得天衣无缝。 4、其他程序员必须能读懂你的代码。 凌晨3点写出的代码 疲劳的时候，千万不要
阅读全文
摘要：承诺用语 口头上说。心里认真。付诸行动。做出承诺，包含三个步骤 1、口头上说自己将会去做。 2、心里认真对待做出的承诺。 3、真正付诸运行。 识别“缺乏承诺”的征兆 在承诺做某事时，应当留意自己的用词，因为这些用词透露了我们对待承诺的认真程度。 真正的承诺听起来是怎样的 对自己将会做某件事做了清晰的
阅读全文
摘要：对抗角色 要做出艰难决定的时候，存在对抗角色间的冲突于此是最为有利的。 “为什么”远不如“事实”重要。事实是功能还需要两个星期才能完成。而为什么需要两个星期，则只是个细节。 高风险时刻 最要说“不”的是那些高风险的关键时刻。 要有团队神精神 有团队精神的人不会总是说“是”。 试试看 许诺“尝试”，意
阅读全文
摘要：担当责任 “专业主义”就意味着担当责任，不但象征着荣誉与骄傲，而且明确意味着责任与义务。 不行损害之事 1、不要破坏软件功能 1）让QA找不出任何问题，发布软件时，你应该确保QA找不出任何问题。 2）要确信代码正常运行，要求进行百分百测试覆盖，可以使用测试驱动开发（TDD）。 3）自动化QA，自动化
阅读全文
摘要：注释 C1：不恰当的信息 让注释传达本该更好地在源代码控制系统、问题追踪系统或任何其他记录系统中保存的信息，是不恰当的。注释只应该描述有关代码和设计的技术性信息。 C2：废弃的注释 过时、无关或不正确的注释就是废弃的注释。 C3：冗余注释 如果注释描述的是某种充分自我描述了的东西，那么注释就是多余的
阅读全文
