软件开发过程中的一些碎语

点击上方蓝字关注我，知识会给你力量好久没有碎碎念了，在家闭关两礼拜了，终于有点时间来思考思考了。最近的计划最近正在着手做一些Flutter相关的工作，顺便整理了一套「Flutter兵法」，看完保证让你在产品面前横着走。做这些东西的目的，实际上是自己在学习的过程中，对技术方案和架构的思考，同时，学习现有的方案，从而归纳出一套最佳实践，不仅对我是一个提高，也对他人在实践过程中...

有些想法是以前没有表达清楚的， 在这个帖子里唠叨两句。1. 关系模型和对象之间的矛盾， 其实很多时候找出真正的重点甚至本质的钥匙在于， 不同的阶段之间如何连接， 和比如性能之类的看似比较外围的点。 现在有一种比较不好的说法， 比如机器越来越快， 性能不重要了， 等等。 如果真是如此， 其实很多矛盾就根本不存在。 比如， 即使我们采用的是面向对象数据库，或者某个超级强大的ORM框架；也许在某些特别合...

在以前学软件的时候，我也不知道我最终会走这条路。 在认识一个事物之前，总是觉得这个事物简单，我可以拿下，但是当真正去做的时候，事实并非当初想的那样。 就拿以前的做广告来说，在没做之前，觉得广告不就是设计设计，画画图什么的，自己应该能搞定，但是真要到去做的时候，发现广告并非我想象的那样，各种设计，各种格式。各种打印等，到至今我还是觉得做一个广告写真，是那样的繁琐。 在学习软件之前，也没想到是如

邮件写作要力求明确 跟我们在学校上学不一样，表达观点之前用一些铺垫。工作邮件是要尽快尽简洁地表明观点 -- 简洁明了。 邮件标题要明确(state key point) 一封邮件只讲一件事，多个事情分多个邮件表述 (one mail one topic)不要用大段文字，多用图表、列表 ，适当分段并加小标题 (readable) 不清楚的地方要明确主动确认 (No Guess) 介绍清

这方面的论述很多，我就摘一些失败的教训。避免使用错误的方法制造正确的产品在软件开发中会很强调测试。的确、测试是质量的保证。按照lean的精神，写不能测试的代码都是浪费精力（要有daily测试或定期测试）。但是， 测试只保证有质量的代码，却不保证有质量的设计。

老大QH的要求是：        1)    Task要细化：细化到足够小，足够明确；每个task的时间跨度要小点        2)   Output要明确：每一个task的output要清晰明确.   从resource的角度，Plan 应该细化到每一个人每一天的ta

完成功能其实非常初级 功能的稳定性　可扩展性　如何规模化　性能优化　这些是后端程序员要考虑的 对UI工程师而言，考虑的不应该是2 pixel 而是用户流程和体验 不过哥就是考虑的太多　　不爱立刻完成．．．． 虽说有些事情不是普通程序人员做的，更像是架构使或者technical leader做的事情；但是，你有了这样的思维，从长远/整体的角度看问题(系统性思维)，对个人成长是

码农们一般不用关心如何确定需求，确认自己理解需求就行了；剩下的主要是需求的实现以及功能的单元测试。说到功能，码农的工作基本上是围绕增删改查来展开的。欢迎讨论。

很多人都是因为技术出色，才被提拔到leader(猪头小队长)的位置的。但是一上来就很不自在，可能会觉得没有以前舒服了。 以前是individual contributor，做好自己的就行了，每天也过得很充实。一到做leader，每天慢慢碌碌，到下班了觉得好像没做什么正事：代码没有coding几行。于是很迷茫，leader的价值到底在哪里？ 最近看了点东西，对自己启发很大。 indiv

The purpose of maintaining the issue log is as following: 1.    Keep track of the issues that need help from manager team or architecture t

软件工程的核心问题之一就是管理复杂度(对人，时间，风险这三者的管理)