工作心得
<h2>业务优先，代码之后。可以理解为：业务凌驾于代码之上。</h2>
<h2>做技术上的匠人，保持工匠精神。</h2>
<h2>面对工作任务思考方向</h2>
<ul>
<li>
<h4>1-业务是什么？</h4>
<ul>
<li>业务逻辑是否清晰？</li>
<li>与原系统存在的逻辑是什么？</li>
<li>与原系统逻辑存在的关联性、差异性是什么？</li>
<li>业务上是否涉及到其他系统？</li>
</ul>
</li>
<li>
<h4>2-业务流程是什么？</h4>
<ul>
<li>与原系统流程上如何衔接？</li>
<li>流程上是否涉及其他系统？</li>
</ul>
</li>
<li>
<h4>3-哪些问题已经确定？哪些问题需要确认沟通？</h4>
<ul>
<li>哪些问题不确定、存在问题？</li>
<li>存在问题要如何解决，需要和谁沟通？</li>
</ul>
</li>
<li>
<h4>4-确定要做的工作有哪些？</h4>
<ul>
<li>要做的工作内容，细路为：从整体到细节，从大到小。</li>
<li>排好优先级，尽量想的很详细很清晰。</li>
<li>根据任务完成时间，按照排好优先级进行开发任务。</li>
</ul>
</li>
<li>
<h4>5-回顾整体业务逻辑，整体流程。</h4>
<ul>
<li>明确每个人的角色及分工。负责人，项目经理，产品经理，前端，后端，测试，运维。</li>
<li>清楚自己在项目中充当几个角色，做到思考问题时，角色转换。</li>
<li>在小公司，遇到问题时，在确认需要求时，自己可能是产品经理，项目经理，后端等几个角色。</li>
</ul>
</li>
<li>
<h4>6-在整个任务周期，遇到特别难解决的问题思考方向：</h4>
<ul>
<li>从业务、流程，到每个人的角色，从整体到细节去思考。</li>
<li>在开发过程中，遇到开发问题难解决，要再次想一下业务逻辑和流程是否理解正确，是否存在不清晰的地方。</li>
<li><strong>要反推需求是否有合理、正确，是否要反馈给需求方进行需求确认、讨论、调整。</strong></li>
</ul>
</li>
<li>
<h4>7-确认正式环境，预上线环境，测试环境，开发环境，是否发生变化？</h4>
</li>
<li>
<h4>8-上线流程是什么？上线时间节点是什么？不清楚要主动去问去沟通</h4>
</li>
<li>
<h4>9-业务上无疑问，明确接口有哪些，涉及哪些数据表</h4>
<ul>
<li>代码写完后，反复确认。
<ul>
<li>对于代码和业务尽量做到，在头脑中能背出自己写代码的思路，甚至部分重要代码，比任何人对整体都要清晰。</li>
</ul></li>
<li><strong>明确各个服务器情况及环境</strong>
<ul>
<li>服务器环境，Web服务器，缓存服务器，数据库服务器，PHP服务器，前端技术对接</li>
</ul></li>
<li><strong>写代码注意时间复杂度(运行时间)，空间复杂度(占用空间)</strong>
<ul>
<li>代码的抽象性、可读性，做好兼顾取舍。</li>
</ul></li>
<li><strong>复杂SQL语句，请使用原生SQL，尤其是在数据分析报表时</strong></li>
</ul>
</li>
<li>
<h4>10-上线后，复盘、总结</h4>
<ul>
<li>涉及新技术，及时学习提升</li>
</ul>
</li>
<li>
<h4>11-清楚自己工作中的优势</h4>
<ul>
<li>自己在技术上实现更好，产品经理在需求分析更精准。</li>
<li>自己沟通能力、理解能力很好。</li>
</ul>
</li>
</ul>
<hr />
<h2>工作中代码的好习惯</h2>
<p><strong>1-每天来了，在代码版本中，一行一行的看一下前一天的代码，目的是查检并避免代码有bug。</strong></p>
<ul>
<li>看的过程中，要想一下代码和业务逻辑。在头脑中要有一些变量的数据结构。</li>
</ul>
<p><strong>2-修改复杂逻辑代码时，务必测试涉及到的相关功能，正常流程和非正常流程(有时间，务必测试一下)。</strong></p>
<ul>
<li>自己测试完成后，需要向涉及功能人员说明，并让他们帮忙测试一下。</li>
</ul>
<p><strong>3-在修改变量时，一定要双击选择，并搜索该变量。</strong></p>
<ul>
<li>
<p>看看有多少个地方使用，避免凭着记忆，导致变量少改、漏改，致使程序出现Bug。</p>
</li>
<li>尤其是使用isset()和empty()方法时，漏改的变量也不会报错。</li>
</ul>
<p><strong>4-开发相关功能时，评估相关功能操作对数据表的交叉性。</strong></p>
<ul>
<li>多个功能操作，涉及相同几个数据表时，要把相关功能涉及的数据表都统计出来，再去写代码。</li>
<li>如果需求不明确，需要主动去反问有哪些功能，尽量做到使用统一的数据、方法，防止后期功能频繁改动，导致代码改来改去，总也出问题，这块改好，另一块又出现新的问题。</li>
</ul>
<p><strong>5-涉及复杂业务逻辑代码，修改一些变量和方法时，一定要考虑到对其他功能、代码产生的影响。</strong></p>
<ul>
<li>修改完成后，一定要使用phpstorm的Xdebug调试，节省时间，数据结构一目了解。</li>
</ul>
<p><strong>6-涉及多处使用的数据结构，一定要使用同一个方法，方法里数据结构一定要单一，避免出现过多无用的数据。</strong></p>
<p><strong>7-用别人的方法，涉及数据结构的，一定要清楚是什么数据结构</strong></p>
<ul>
<li>目的是用人别人代码不至于出错</li>
</ul>
<h2>工作方式</h2>
<ul>
<li>1-写代码前，了解业务逻辑，沟通清楚，理清业务逻辑中的关联性，和原有系统如何整合，了解业务逻辑和数据存在关系。</li>
<li>2-接到一个项目或者一个功能模块，基本做三个过程沟通，最开始，过程中，结束。
<ul>
<li>每个过程，基本沟通一到三次，大致沟通三到九次。</li>
<li>目的是，把自己做的想的，尽量和其他人统一到一致。</li>
</ul></li>
<li>3-沟通分为主动和被动，我选择主动，双向沟通。</li>
</ul>
<h2>使用工具，写代码方面心得</h2>
<ul>
<li>1-查看代码，经常使用代码折叠快捷键，或者行号定位，很少使用鼠标滑轮来回滑动方式查找定位代码。</li>
<li>2-经常使用代码活动模板，尽量少写代码，争取更多时间去思考如何解决问题，怎么做更完善、更合适。</li>
<li>3-我写代码原则是，第一是可读性，第二是复用性，第三扩展性。</li>
<li>4-每个方法控制在100行至300行之间，最好是一屏到两屏范围，超出这个范围，折分成几个方法。</li>
<li>5-类的继承、方法调用，垂直深度尽量不要超过三层；如果超出，尝试更换为水平方式。
循环，判断嵌套，我也遵循这个原则。</li>
<li>6-工作中，各种软件尽可能多使用快捷键。</li>
<li>7-鼠标选择，尽可能双击选择，不能满足再使用拖动选择。</li>
<li>8-尽量避免代码实现业务逻辑中的藕合度过高。</li>
</ul>
<h2>日本人布置工作至少说5遍</h2>
<h3>第一遍，</h3>
<p>麻烦你做个什么事。</p>
<h3>第二遍，</h3>
<p>麻烦你重复一下我让你做什么事。</p>
<h3>第三遍，</h3>
<p>你知道我让你做这个事的目的是什么。</p>
<h3>第四遍，</h3>
<p>这个事会不会出现什么意外，你怎么应对？</p>
<h3>第五遍，</h3>
<p>你自己做这个事，有什么想法和建议。</p>
<h2>建议程序人员必看书藉</h2>
<ul>
<li>1-关于代码书写艺术方面书藉。</li>
<li>2-产品方面书藉，如人人都是产品经理。</li>
</ul>