「这是我参与2022首次更文挑战的第8天，活动详情查看：2022首次更文挑战」。
一听这个问题，还真觉得可能会是这样的情况。新人可能存在实践经验不足，老项目不会给尝试新架构的机会，又没有新项目的情况，确实是不太好实践。而且前篇也确实讲的太粗，今日份十分钟就交流一个足够细小的工程实践吧。
函数，是我们编程的基石，网上先找个函数的说明图贴过来：
定义函数呢，大的原则，自己总结了四个字就是：短小精悍 。
- 短：每行代码不宜过长，超出一屏能看到的范围都属于过长。
- 小：函数体不宜太大。50行内为宜，绝不能超过100行。
- 精：一个函数只做一件事。尽可能避免一个函数有多逻辑分支或多目标。
- 悍：健壮，测试完备，避免漏洞。
如何做到这四个字，说实话不少的有丰富工程经验的研发都难做到很好。仅“小”这件事，需要大量的工程经验和编码者优秀的工程设计能力，并不是简单的把单函数拆多函数了事的。如果没有设计的拆小函数，也可能带来糟糕的后果，如：函数设计混乱、函数重用性差甚至带来重复代码等等。
方法体拆小细节部分大致想一下会有点多，今日份十分钟先不展开说方法体部分了，就细说一下方法头部分。
-
修饰符：按需使用，跟业务场景和架构设计强相关，这里不过多漫谈了。
-
返回值：按需使用，尽量避免多值返回，比如 Tuple2 之类的定义返回。
-
方法名：清晰的描述清楚这个函数的作用，尽量使用动词定义，任何人看到都会立刻明白这个函数的执行动作和目标是什么最好，别害怕名字定义太长，IDE是我们的好帮手，最好的注释就是定义清楚名称。另外还有一个考量就是如何方便IDE搜索，方便到项目外的人也知道大概如何搜索最宜。
-
参数：
-
同方法名一样，清晰准确的命名，清晰到不需要写注释最好，当然该写的时候还是要写注释的。
-
0个参数最好，1个其次，2个还可以容忍，3个要看场景容忍，超过3个的参数真的就不太能忍受了，长串的参数列表的函数定义看起来就非常丑陋让人不愿意细看下去。
- 参数里原则上是不要有Boolean类型的参数的，因为涉及这样的参数，理论上我们都应该把函数拆小的。
- 一个参数时，这个参数一般是函数动作的主体，比如fileHandle:write(String message)。
- 两个参数时，这两个参数一般是大家有共识的，比如笛卡尔坐标系下的点：drawPoint(int x,int y)，或者项目内其他共识性参数。
- 三个参数及以上，就参数排序、作用、因果条件的因素加倍的增加，要非常小心使用，尽力避免。可以尝试抽象封装成值对象，注意一定要有设计，无序的参数封装依然是灾难的开始，像上边说的无序拆分“小”函数一样。
- 谨慎的把参数作为返回结果，很容易让使用者搞不清楚参数顺序，如 append(s1,s2)远不如 s1.append(s2)好。
-
了解到过多实践原则，对初级工程师而言，有时候做事会束手束脚，甚至有了代码洁癖，尽量避免从一个极端走向另一个极端。工程师还是以实践为主，理论指导实践，需要会灵活变通。定义函数时大胆的去定义，实现需求为先，然后根据原则或以往个人经验，去打磨完善，最终形成一段漂亮的有美感的代码，有经验的工程师只是会更容易写出漂亮的代码。
#今日份十分钟#，打磨时间太短，难免有些粗糙和疏漏，依然是抛砖引玉，希望大家留言交流，甚至完善出更好的函数实践的工程原则或方法论。
