管理系统开发提高生产力
Humans are complex creatures with a wide variety of motivations for getting work done. Our motivation as developers is not purely extrinsic or financial — sometimes it’s for the joy of delivering code.
人类是复杂的生物，具有完成工作的多种动机。 我们作为开发人员的动机并非纯粹是外在的或财务上的—有时是出于交付代码的乐趣。
You might be a shipper, someone who enjoys shipping code quickly for the sense of achievement and being able to spend time with your family. This is the developer who calls Yagni to deliver something of value.
您可能是一个托运人，为了获得成就感并能够与家人共度时光而乐于享受送货代码的人。 这是叫Yagni提供有价值的东西的开发人员。
However, your colleague working from home two towns away might be a planner, someone who values the intrinsic reward of creating the right abstractions and nailing that design.
但是，您的同事在两个镇上的家中工作可能是一个计划者，他非常重视创建正确的抽象并钉上设计的内在奖励。
The two of you might have a different how, but you both want the same outcome — productivity. Several of my former managers might disagree, but I believe that most people want to be productive regardless of motivation. So, whether you are a shipper or a planner, here are six techniques that can help you maximize your productivity and speed up your delivery.
你们两个可能有不同的怎么样，但是你都希望得到相同的结果-生产力。 我的几位前任经理可能会不同意，但我相信大多数人都希望不管生产力如何都可以提高工作效率。 因此，无论您是托运人还是计划员，以下六种技术都可以帮助您最大限度地提高生产率并加快交货速度。
1.在工作中使用正确的语言 (1. Use the Right Language for the Job)
I once had a roommate who used my pliers as a hammer. He was able to successfully hang his pictures, but my pliers were damaged. A tack hammer would have done a faster job. Similarly, using the right coding language for your team’s application can make a huge difference in getting the job done quickly and efficiently.
我曾经有一个室友，他用钳子作锤子。 他能够成功地挂起他的照片，但是我的钳子被损坏了。 大头钉锤会做得更快。 同样，为团队的应用程序使用正确的编码语言可以对快速高效地完成工作产生巨大的影响。
For example, Python has roots in scientific computing and is excellent for data science. Developers who value stability and consistent ways of approaching problems will love Python. In contrast, Ruby is excellent for expressive code for websites, and the Ruby community tolerates a plurality of approaches to the same problem.
例如， Python扎根于科学计算，并且对数据科学非常有用。 重视稳定性和解决问题的一致方法的开发人员会喜欢Python。 相反， Ruby非常适合用于网站的表达性代码，并且Ruby社区容忍了多种解决同一问题的方法。
PHP is an excellent option for fast server-side applications and can be deployed just about anywhere. There are legions of PHP developers available to work on your project, and the language and ecosystem have come a long way. Node.js allows web developers to use the same language on the server-side as the client-side at the cost of some complexity. If you’re looking for a highly interactive client-side experience, you might choose to optimize for Node.js.
PHP是快速服务器端应用程序的绝佳选择，几乎可以在任何地方部署。 有大量PHP开发人员可用于您的项目，并且语言和生态系统已经走了很长一段路。 Node.js允许Web开发人员在服务器端使用与客户端相同的语言，但会付出一定的复杂性。 如果您正在寻找高度互动的客户端体验，则可以选择针对Node.js进行优化。
Regardless, try not to let the latest fashions influence your language choice. Use the language and approach that works best for your unique project. A decade ago, we started rendering pages on the server-side with some JavaScript decoration. Around the middle of the decade, we then started rendering on the client-side with REST or GraphQL APIs for data. At the beginning of 2020, we have a backlash toward simpler applications that render the server-side with some TypeScript decoration.
无论如何，请尽量不要让最新时尚影响您的语言选择。 使用最适合您的独特项目的语言和方法。 十年前，我们开始使用一些JavaScript装饰在服务器端呈现页面。 大约在本世纪中叶，我们开始使用REST或GraphQL API进行客户端数据渲染。 在2020年初，我们对一些较简单的应用程序产生了强烈反对，这些应用程序使用一些TypeScript装饰来呈现服务器端。
2.不要进行身份验证 (2. Don’t Roll Your Authentication)
I’ve worked on several projects where the team implemented custom-built authentication in the application, including saving salted password hashes to the database. We didn’t need to. At the time, we had the infrastructure to delegate authentication to Active Directory so the users could enjoy the same password as their Windows login. However, Conway’s Law and egos saw that possibility off. The development manager didn’t like the infrastructure manager, and development happened where there was no access to the company network.
我参与了多个项目，其中团队在应用程序中实现了自定义身份验证，包括将盐腌的密码哈希保存到数据库中。 我们不需要。 当时，我们拥有将身份验证委派给Active Directory的基础结构，因此用户可以享受与Windows登录名相同的密码。 然而，康威定律和自负却使这种可能性消失了。 开发经理不喜欢基础架构经理，并且开发发生在无法访问公司网络的地方。
Now that Auth0 and similar products exist, do you want to go through the trouble and risks of implementing authentication? It’s arguably a better engineering trade-off to delegate authentication to Auth0 so you can get an MVP out the door and then consider retrofitting for cost reasons as you scale. You’ll also get many additional features and a better security footprint for your applications.
现在已经有了Auth0和类似的产品，您是否想解决实施身份验证的麻烦和风险？ 将身份验证委托给Auth0可能是一个更好的工程折衷方案，因此您可以获取MVP，然后在进行扩展时出于成本原因考虑进行改造。 您还将获得许多其他功能，并为您的应用程序提供更好的安全性。
Lots of people build boats, but few build their outboard motors. Why get stuck at sea when you can buy a Yamaha and get home?
许多人建造船只，但很少有人建造舷外发动机。 当您可以购买雅马哈并回家时，为什么会陷在海上？
3.首先编写单元测试 (3. Write the Unit Tests First)
We get it. Writing unit tests can be like brushing your teeth. Brushing teeth is better than tooth decay, though. Sometimes you just want to jump into implementing code and tests get in the way. It’s OK to feel that way.
我们懂了。 编写单元测试就像刷牙一样。 不过，刷牙胜于蛀牙。 有时，您只是想跳入实现代码的过程，而测试会妨碍您的工作。 那样感觉就可以了。
Jumping straight into implementation without allowing tests to drive your design can feel productive. However, you may end up with code that smells — long methods and long parameter lists are just the start. In the end, your code will be harder to test and maintain. Sure, sometimes you need to explore an idea and smash out that code. Just be sure to do a ‘git reset’ and implement it again with unit tests. You’ll end up with a better design.
在没有允许测试驱动您的设计的情况下直接进入实现过程可能会产生高产。 但是，您可能最终会得到嗅到的代码-长的方法和长的参数列表只是开始。 最后，您的代码将更加难以测试和维护。 当然，有时您需要探索一个想法并粉碎该代码。 只需确保执行“ git reset”并通过单元测试再次实现即可。 您最终将获得更好的设计。
Bolted on, after-the-fact unit tests are very easy to spot. They are usually very coarse as they need to instantiate large classes and assert that they work. Such an approach doesn’t give you the true value of unit tests. A well-written unit test will assist you in teasing out the concerns and stubbing or mocking out dependencies that make things happen in the real world. Testing code that has real-world concerns can be difficult. It’s much easier when you’ve done the work to separate the concerns.
扎实的事后单元测试非常容易发现。 它们通常非常粗糙，因为它们需要实例化大型类并断言它们可以工作。 这样的方法并没有给您单元测试的真正价值。 编写良好的单元测试将帮助您消除疑虑，消除或嘲笑使事情在现实世界中发生的依赖性。 测试具有实际问题的代码可能很困难。 完成工作以分离关注点时，这要容易得多。
If that’s not enough to convince you, asking for more time so you can add tests after you’ve made the untested code work (and getting it past QA) is going to make your project manager angry. Don’t even mention the word “refactoring.”
如果这还不足以说服您，请拨出更多时间，以便在使未经测试的代码正常工作(并使其超过QA)之后添加测试，这将使您的项目经理感到愤怒。 甚至不提“重构”一词。
To be successful with unit tests, break the feature down into tiny cycles of “Red, Green, Refactor.”
为了成功进行单元测试，请将功能分解为“红色，绿色，重构”的微小循环。
- Red — Start by writing a unit test that fails. Stub out the real-world activities so you can run unit tests any time you like. 红色-从编写失败的单元测试开始。 排除现实世界中的活动，以便您可以随时运行单元测试。
- Green — Write the code that makes that unit test pass. 绿色-编写使该单元测试通过的代码。
- Refactor — If you need to clean up your code, now is the time to refactor and run that unit test again. 重构—如果您需要清理代码，现在是时候重构并再次运行该单元测试了。
And repeat.
重复一遍。
Using this pattern, you’ll gain more confidence in your code, and you can smile at the project manager as you tick the feature off as done.
使用此模式，您将对代码有更大的信心，并且在完成功能的勾勾时可以对项目经理微笑。
4.利用SaaS，IaaS和PaaS (4. Take Advantage of SaaS, IaaS, and PaaS)
When systems administrators wore army boots, frowned a lot, and put servers in racks, it was clear that their jobs were different than a developer’s. Roles aren’t as clear-cut today. Teams aren’t staffed the way they used to be; we’re expected to have more skills than ever and jump in wherever and whenever needed. Developers often spend too much time doing non-code tasks, such as infrastructure, DevOps, integrations, and so on. Yes, these tasks are important, but they don’t make working software.
当系统管理员穿着军靴，皱着眉头并且将服务器放在机架中时，很明显他们的工作与开发人员的工作不同。 如今，角色还不那么明确。 团队的人员配备不再像以前一样。 我们有望拥有比以往更多的技能，并随时随地跳入。 开发人员经常将大量时间用于执行非代码任务，例如基础架构，DevOps，集成等。 是的，这些任务很重要，但它们不能使软件正常工作。
Infrastructure as a Service (IaaS) providers like AWS takes the sheer effort of running infrastructure and make it disappear. You can deploy a new revision of your application with a simple git push. No need to perform subnet calculations or design network architectures, or argue with the DBA; the IaaS vendor takes care of that for you.
像AWS这样的基础架构即服务(IaaS)提供商需要花费大量精力来运行基础架构并使之消失。 您可以通过简单的git push部署应用程序的新修订版。 无需执行子网计算或设计网络架构，也无需与DBA争论； IaaS供应商会为您解决这一问题。
It gets better. There are hundreds of suppliers that take something that was once a project chore and offer their software as a service (SaaS).
它变得更好了。 有成百上千的供应商接受了曾经是项目琐事的事情，并提供他们的软件即服务(SaaS)。
For example, you don’t need to configure Logstash and ElasticSearch replication. There are at least half a dozen companies that will ingest all the logs from your application, allow you to search them, and delete them after 90 days so you don’t pick up a GDPR fine in the future. Many companies will also deliver email and SMS with nothing more than a credit card on file and an API client. Twenty years ago, those grumpy systems administrators would have been configuring Sendmail, reading logs, drinking coffee, and cursing — all at the same time.
例如，您不需要配置Logstash和ElasticSearch复制。 至少有六家公司将从您的应用程序中提取所有日志，允许您搜索它们，并在90天后将其删除，这样您以后就不会再受到GDPR罚款了。 许多公司还将提供电子邮件和SMS，而这些电子邮件和SMS只是文件上的信用卡和API客户端。 二十年前，那些脾气暴躁的系统管理员本来可以同时配置Sendmail，阅读日志，喝咖啡和诅咒。
Of course, there’s no silver bullet. You need to have a way to find the more reliable and scrupulous providers of all these services. The bazaar can be noisy. Also, paying for all those vendors carries its irritations. Ideally, you wouldn’t put your manager’s credit card in each app and have them do the monthly dance to get invoices for reimbursement.
当然，没有银弹。 您需要一种方法来找到所有这些服务的更可靠，更严格的提供商。 集市可能很吵。 而且，为所有这些供应商付款会带来烦恼。 理想情况下，您不必将经理的信用卡放在每个应用程序中，而让他们每月进行一次舞蹈以获得报销的发票。
And finally, Platform as a Service (PaaS) providers like Heroku have spent the last decade working out how to outsource not only application hosting but also the add-on marketplace. They take care of the infrastructure and the platform with pre-configured installations of a wide variety of technology stacks. You can kick the tires on third party suppliers, get ideas to market in just hours, and easily pay for their services through one bill.
最后，像Heroku这样的平台即服务(PaaS)提供商在过去的十年中一直在研究如何不仅外包应用程序托管，而且外包外包市场。 他们通过各种技术堆栈的预配置安装来维护基础架构和平台。 您可以不满第三方供应商，在几个小时内将创意推向市场，并轻松地通过一张账单支付他们的服务费用。
5.听你的IDE (5. Listen to Your IDE)
In Greek Mythology, Cassandra was a priestess of Apollo. Cassandra was cursed to have prophecies that were never to be believed. Your IDE is like Cassandra making prophecies — your cyclomatic complexity is too high, or that case block doesn’t have a final default clause. If you don’t listen to your IDE, you may spend a lot of time debugging.
在希腊神话中，卡桑德拉是阿波罗的女祭司。 卡桑德拉(Cassandra)被诅咒拥有无法相信的预言。 您的IDE就像卡桑德拉(Cassandra)做的预言一样-您的循环复杂度太高，或者该case块没有最终的default子句。 如果您不收听IDE，则可能会花费大量时间进行调试。
In addition to the built-in features of your IDE or editor, there’s a huge ecosystem of linters out there. SonarLint deserves a special mention as it supports the most popular IDEs (Eclipse, IntelliJ, Visual Studio, VS Code) and provides top-notch recommendations for security issues, signs of subtle bugs, and code smells. That’s a superpower if your team uses SonarQube for measuring code quality. Fixing the recommendations in your IDE means you’ll be seen to commit secure and maintainable code.
除了您的IDE或编辑器的内置功能之外，还有一个庞大的linter生态系统。 SonarLint特别值得一提，因为它支持最流行的IDE(Eclipse，IntelliJ，Visual Studio，VS Code)，并提供有关安全问题，细微错误和代码气味的一流建议。 如果您的团队使用SonarQube来衡量代码质量，那将是一个超级大国。 在IDE中修正建议意味着您将被视为提交安全且可维护的代码。
Let your IDE be a believable prophet, like Athenais. The recommendations reduce risk and complexity in your code.
让您的IDE像Athenais一样成为可信的先知。 这些建议降低了代码的风险和复杂性。
6.进行构建，并使其快速 (6. Make a Build Process, and Make It Fast)
A good build tool is an invisible train that your code rides to production. As a solo developer, you might choose to run your tests and deployment on a local dev environment from your IDE. That’s great as you will probably have a fast feedback loop. This allows you to experiment all day long with code.
良好的构建工具是您的代码可用于生产的无形训练。 作为独立开发人员，您可以选择从IDE在本地开发环境中运行测试和部署。 很好，因为您可能会有一个快速的反馈循环。 这使您可以整天尝试代码。
However, as you begin to collaborate with others, you’ll want the code to run in CI/CD pipelines, which historically don’t tend to play well with desktop dev tools. A Makefile, build.gradle, or another build tool that fits your language and runtime environment will slot in nicely and prove that your code and tests run clean outside your computer. Furthermore, you’ll also gain a place to automate some deployment concerns, such as database migrations, packaging, distribution, and so on.
但是，当您开始与他人合作时，您希望代码在CI / CD管道中运行，从历史上看，它们在台式机开发工具中往往无法很好地发挥作用。 一个Makefile ， build.gradle或其他适合您的语言和运行时环境的构建工具将很好地插入并证明您的代码和测试可以在计算机外部干净地运行。 此外，您还将获得一个使一些部署问题自动化的地方，例如数据库迁移，打包，分发等。
Furthermore, a well-designed build tool and implementation will reduce the time spent on tasks that have already been done. You might want to run unit tests all the time, but is there any point in recompiling or linting code when none of the dependencies have changed?
此外，设计良好的构建工具和实施将减少花在已完成任务上的时间。 您可能想一直运行单元测试，但是当所有依赖项都没有改变时，重新编译或整理代码有什么意义吗？
I find a pain point in any new project where I’ve done some fundamental exploration in code and need to start down the path to production. Then, I switch my focus from writing code to exploring its interaction with the outside world. This is the time to implement your build process, then configure your IDE to run it.
在任何新的项目中，我都对代码进行了一些基础性的探索，并且需要重新开始生产，这是一个痛点。 然后，我将重点从编写代码转向探索与外界的交互。 现在是实施构建过程，然后配置IDE使其运行的时候。
更加轻松快捷的交付 (Easier and Faster Delivery)
Delivering functional software to users who appreciate it is very fulfilling. Many factors may be compromising your productivity and delivery time. However, regardless of whether you like to ship fast or slow, there are tangible steps you can take to make it easier and faster to deliver. I hope that one of the six productivity techniques that I have included in this article makes your job — and your life — a little easier. God speed.
向欣赏它的用户提供功能性软件非常令人满意。 许多因素可能会影响您的生产率和交货时间。 但是，不管您是想快还是慢地发货，您都可以采取切实的步骤来使它更容易，更快地交付。 我希望本文所包含的六种生产力技术中的一种能够使您的工作以及您的生活更轻松一些。 神速。
管理系统开发提高生产力
7347
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
