Five rules for a successful cross-platform project
From the translator: I am now collecting bits and pieces of cross-platform software design literature. This small text is the most interesting thing I have found so far.
An encoder to implement a specific feature is enough Google, but there are special design requirements? Say, the #ifdef branching in methods is the only means of extracting the platform-specific parts of a project? (Is it a lot of pasta?) Are there higher level approaches, templates, “add-ins” over #ifdef ? I hope this post will serve as food for further discussion.
From the experience of cross-platform development, I learned a few simple principles, following which will help to avoid common pitfalls.
')
[1] This important point was missed on the team where I worked in 1999. The project was well built in MVC. The model is a DLL in C ++, the presentation is in Swing via JNI, everything is written in CodeWarrior for Mac OS and Windows. While it sounds good, right? And so, the Windows team made the project first and gave it to the Macintosh team. Then it turned out that the application was written in the Java 2 specification, which was then not supported on the Mac. Further - more: the source file names have exceeded the 31-character Finder limit, the project files did not compile because of the broken #enables ... The management decided to split the project into two branches, each of which left a bunch of unnecessary cross-platform code. These losses could have been avoided if we had Mac developers advising the team from the very beginning. ^
[2] I somehow led one project, and our management decided to fork the code to run the Mac version earlier. Although this decision saved several months, it took another year and a half to reconnect the two branches. ^
Tips banal, but no less valuable for people without such experience. Footnotes are particularly noteworthy. It seems that the branch of the project is the first thing to fear, because there can be a million motives for separation,and in general the Universe tends to chaos, but in any case the cause will be the wrong architectural decision, and the result will be a verdict from management.
We will rewrite the MFC application on Mac and Linux, with the GUI writing again in HTML5 / WebKit. For us, this is the first such project, I would like to avoid the maximum number of rakes ... Please share experiences! For my part, on the basis of otpishu on Habr.
An encoder to implement a specific feature is enough Google, but there are special design requirements? Say, the #ifdef branching in methods is the only means of extracting the platform-specific parts of a project? (Is it a lot of pasta?) Are there higher level approaches, templates, “add-ins” over #ifdef ? I hope this post will serve as food for further discussion.
From the experience of cross-platform development, I learned a few simple principles, following which will help to avoid common pitfalls.
')
- Develop your application in the concept of MVC. Perhaps this is the main key to the success of a cross-platform project.
- You should have two commands working from the start: for Windows and Mac. The experience of both groups is needed at the early stages of design and implementation, if you are seriously focused on cross-platform. one
- Use one code branch in VCS. Individual branches often go out of control and are no longer synchronized. 2 Use #ifdef for code for a specific platform.
- Write C / C ++ ANSI compliant code; use standard ANSI and STL libraries. Many cross-platform projects use multiple compilers, so it is important to minimize compiler errors and warnings. Make it a rule to turn on a high warning level and check that there are no warnings in the whole code.
- Put the Mac and PC on the table of each developer. From time to time there will be a situation when a developer for one platform wants to see how his code has influenced another platform. If a developer does not have easy access to another machine, it is more likely that his commit will break the application on another platform.
Notes
[1] This important point was missed on the team where I worked in 1999. The project was well built in MVC. The model is a DLL in C ++, the presentation is in Swing via JNI, everything is written in CodeWarrior for Mac OS and Windows. While it sounds good, right? And so, the Windows team made the project first and gave it to the Macintosh team. Then it turned out that the application was written in the Java 2 specification, which was then not supported on the Mac. Further - more: the source file names have exceeded the 31-character Finder limit, the project files did not compile because of the broken #enables ... The management decided to split the project into two branches, each of which left a bunch of unnecessary cross-platform code. These losses could have been avoided if we had Mac developers advising the team from the very beginning. ^
[2] I somehow led one project, and our management decided to fork the code to run the Mac version earlier. Although this decision saved several months, it took another year and a half to reconnect the two branches. ^
Conclusion (from translator)
Tips banal, but no less valuable for people without such experience. Footnotes are particularly noteworthy. It seems that the branch of the project is the first thing to fear, because there can be a million motives for separation,
We will rewrite the MFC application on Mac and Linux, with the GUI writing again in HTML5 / WebKit. For us, this is the first such project, I would like to avoid the maximum number of rakes ... Please share experiences! For my part, on the basis of otpishu on Habr.
Source: https://habr.com/ru/post/175801/
All Articles