开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《开发也要遵守基本法 hacker-laws-zh》
今日推荐英文原文：《Choosing the Right Platform for Your New App》
今日推荐开源项目：《开发也要遵守基本法 hacker-laws-zh》传送门：
GitHub链接
推荐理由：前几天 GitHub Trending 上开发人员定律项目的中文版。这个项目里介绍了很多听名字就不明觉厉的定律和原则，但你并不需要完全遵守它们。实际上有些定律已经被我们所熟知（除了它的名字），比如经常听到的那个——项目完成的时间永远比预期长。兴许读完这些定律和原则，你能在接下来的开发中减少一些无用功，多把精力集中在更重要的地方。
今日推荐英文原文：《Choosing the Right Platform for Your New App》作者：Allen Helton
原文链接：https://medium.com/better-programming/choosing-the-right-platform-for-your-new-app-7d7820191d3d
推荐理由：开源工场开发委提醒：平台多如毛，适合才最好；平台没选对，码农两行泪。
Choosing the Right Platform for Your New App
We live in a world overflowing with possibilities. We are inundated with potential options for everything we want to do. This includes development platforms when building a new application. It doesn’t matter if you’re building a mobile, desktop, or web application, you are provided with numerous different frameworks and technologies on which to write your code.
Perhaps one of the most important decisions you can make when developing your app is the platform you are going to build on. Once you choose it and begin development, you’re stuck with it. Sure, you can refactor the solution after you implement it, but it’s simply that: a refactor. Changing the platform would require a rebuild. Therefore, we need to take all of our options into account to make sure we choose the right platform the first time.
Have a Clear Vision
Software development is a process. Deciding on the platform has its place in the process, but you must first decide what it is you’re going to build. Make sure you understand the problem you are facing and have an idea of how you want to solve it.
A helpful technique I learned from some folks at AWS to coax out important details and design decisions is a product design meeting called a Working Backwards session. A Working Backwards session will make sure stakeholders from different parts of your organization are aligned with the vision and elicits feedback necessary to build a well-rounded product idea.
Your vision doesn’t have to be complete before you move on to the next step, but it does have to be accepted by the stakeholders. Don’t spend time getting ahead if you haven’t received approval on your idea. Making your intentions clear is the most important part of your product vision.
Decide on the Right Architecture
Now that you have a clear vision of the problem you are trying to solve and how you want to solve it, determining the high-level architecture is your next step. What patterns best fit the problem? At what scale do you need the app to perform? Do you want an on-prem installable app or an app in the cloud? Do you want to take advantage of managed services or write your own?
These are just a few of the many questions that drive the proposed architecture of a new product. Don’t get caught up trying to get too specific. Your goal is to decide on architectural patterns. The programming languages you are going to use don’t matter at this point. Remember, these are your steps to choose the platform you are going to build on.
Explore Your Options
With so many options out there for platforms, how do you decide which to build on? It is important to consider the estimated time to market and the size of the team building your app. Are you working on a tight deadline? Do you need something that is rock solid on day 1? Here are some options I’ve run across when building new applications from the ground up.
- Build it all yourself — There are times when building an installable desktop app fits the need the best. You start from a blank slate and piece together your application. This offers tremendous flexibility, but it can be time-consuming. Also, since everything is hand-written, you have the highest risk factor due to human error.
- Assemble vs Build — Thousands of companies exist today that specialize in one piece of an application, such as notifications, event busses, or document management. One platform ideation is to utilize as many of their services as possible so that you don’t have to write it all yourself. By assembling these services, you’ll end up with a quicker time to market and the responsibility of each service lies on the provider, meaning your team is not spending their time supporting, but rather innovating.
- Platform as a Service (PaaS) — Rather than assembling services from different vendors together to make your super app, you can take advantage of a PaaS company. These companies have already done the heavy lifting of orchestration, compliance, and hosting. You simply build your application on top of their platform and utilize their builders. Companies like Twilio offer a rich set of features that make it entirely possible to build your entire app from their dashboard, spending a fraction of the time it would take to build it all yourself.
- Low Code — A flavor of PaaS, low code platforms have also taken the complexity out of code writing and given you a fast track to application building. Low code tends to revolve around the idea of a visual designer to map out everything from your data entities to your user interface. When it’s time to compile, your visuals are generated into code behind the scenes and auto-deployed into a CI/CD pipeline. If you’re looking to get your application out as fast as possible, consider a vendor like Outsystems to get you started.
Prove It Out
Select a few of the options at your disposal and try to prove out your architecture with a Rapid Prototype. A Rapid Prototype is a high fidelity, functional proof of concept designed and developed in a single sprint. It is intended to provide a rich user experience and portray an idea to solicit feedback.
Building a Rapid Prototype in each potential platform will help you directly compare the platforms against each other. It will also give you a chance to learn about the architecture as you implement it multiple times. Each iteration should lead to a clearer understanding of how it works and the best practices around the patterns you chose.
To build a consistent Rapid Prototype, you need to decide on the proof of concept criteria that are most important to you and your stakeholders. Focus on your gamechanger. What can you build that will portray your idea the best? In the past, I have worked on teams who made light product specification documents and built the prototype as close to the spec as possible. This guaranteed the team was building the same product for each platform being assessed.
An important part to remember when proving out the platforms is to give each of them an equal chance. If you’re like many software engineers today, you might turn your nose up at a low code platform because it “isn’t coding.” Even if you don’t fully agree with the premise, give it a fair chance and you might be surprised with the results. Remember, your job is to build an application, not just to write code.
Get Objective with the Results
Seeing the software generated by each platform side by side is one thing, but coming up with a definitive winner can be a challenge. So many factors come into play when deciding on the platform, from cost to developer experience to supportability, the software you see in front of you is just the tip of the iceberg. Come up with a grading scheme to be objective and get a decisive answer.
When comparing platforms, I break my assessment into 8 categories:
- Developer Experience — How is it for the developers? Can they get up to speed quickly? Is it easy to build a new feature or read someone else’s code?
- Operations — How does the platform integrate with things like CI/CD, external services, or other managed services?
- Architecture — Does the platform allow me to build the architecture I want? If not, what is the alternative? Of my core pieces of functionality, what is easy to implement? What is hard to implement?
- Professional Services — Do I need a team of people to support the implementation of my software? What is necessary to onboard a new client? Do I even need professional services?
- Company Collaboration — Could other applications in my company use or integrate with this platform? Conversely, does this platform integrate with the other applications in my company?
- Business Operations — What is the cost of the platform? Does the platform vendor have long term viability?
- Support and Maintenance — Will I be able to support my product easily when it reaches production? How will I be able to maintain the code or fix defects?
- Security — Does the platform follow any compliance standards? Does it use proper authentication and authorization?
Assign a letter grade to each one of the categories and give the platform an overall rating based on the categories. Give each of the categories an appropriate weight based on your company’s needs.
Make the Call
You’ve seen what each of the platforms can do first hand. You have learned about the architecture you want to implement and have the first-hand experience with each platform on how to implement it. You have come up with an objective grading scheme to assign a letter grade to each one. It’s time to make the call.
Don’t argue with the results. If a platform you didn’t want to win has the best score, it’s the best option for the company. Nobody likes change and we don’t want to use something that we are unfamiliar with, but the good thing is that people are adaptable. They might fight you for a bit, but strong developers will come around and learn the benefits of the platform that allows them to be as performant as possible.
Be sure to run the decision by the senior leadership in your company. Show them the Rapid Prototypes you built in each platform and show them the report card for each. This is a company decision and you want everyone to be onboard.
You can use your Rapid Prototype as a starting point for your app! You don’t have to throw it away. You should have built a viable start to your application that you can extend into your production-ready application. Your work building the prototype has already put you ahead of schedule.
Conclusion
Take your time when choosing the platform for your new application. You’re going to be stuck with it for the life of your app. Get input from lots of different sources from around the organization. Any time you can bring in a new thought or opinion, you provide yourself an opportunity to make your application more well-rounded.
Remember to be objective when grading your Rapid Prototypes. You need to have a list of criteria to map out the most important principles to you. If you can be objective, you have proof to stand by when you make your decision on the platform. It’s hard to argue with numbers.
Learn as much as you can when running through your Rapid Prototypes. Learn about the platforms themselves, learn about how to implement your architecture, learn about how to be agile. Learning is the key to innovation. If you have an open mind and a willingness to learn, you will be amazed at the quality product you produce.
下载开源日报APP：
https://opensourcedaily.org/2579/
加入我们：
https://opensourcedaily.org/about/join/
关注我们：
https://opensourcedaily.org/about/love/
