Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Article idea] About the "no-go" areas in PrestaShop codebase #731

Open
matks opened this issue Jun 21, 2020 · 1 comment
Open

[Article idea] About the "no-go" areas in PrestaShop codebase #731

matks opened this issue Jun 21, 2020 · 1 comment

Comments

@matks
Copy link
Contributor

matks commented Jun 21, 2020

Following #704 and #705 I think about another topic that might need a dedicated article: the "no-go" zones in PS codebase.

With this marketing name that sounds like a movie title 馃槃 I am referring to the part of the code we are afraid of modifying to deep because of unknown side-effects.

In this article I would explain:

  • PS has grown huge in all of these years with hundred of features being implemented without a reliable set of tests and documentation
  • PS architecture was not fit for this kind of evolution (see Pablo's series of article about that https://build.prestashop.com/news/prestashop-in-2019-and-beyond-part-1-current-architecture/)
  • the result is that today there are some zones of the PrestaShop code we are kind of afraid of modifying deeply because they are very hard to modify without breaking something (I would call these zones "fragiles") and there is no available set of tests or documentation to help finding possible unwanted side-effects : I am talking for example about the Cart Rules computation engine or the Webservice
  • however a software which cannot evolve is cursed to die as competitors continue to evolve and fit better with the market needs ; so we NEED to evolve
  • and I would explain our strategy to advance in spite of these "no-go" zones
    • migrate to Symfony and "re-conquer" zones thanks to this (while fixing a lot of legacy bugs)
    • cover current implementation with huge test net (E2E tests and Behat tests)
    • and because we need to, we continue modifying (= enter the "no-go" zone) the code in those area, so we have a long stabilization periods (beta and RC) to find all unwanted side-effects
    • and we are very careful about any changes we do in these area, be it internal changes done by the team or external changes done by contributors

This article would help us explaining to people why we refuse to merge some PRs (because they relate to these "no-go" zones) and what is our long-term strategy about it.

wdyt @eternoendless @PrestaShop/prestashop-core-developers @PrestaShop/prestashop-product-team @PrestaShop/prestashop-qa

@LouiseBonnard
Copy link
Contributor

I think it'd be much appreciated! A lot of those no-go zones are crucial for business (cart rules, exactly, for instance) and really need to be addressed. Some contributors do not understand why we barely address them. So explaining our strategy to slowly move forward on those topics will help partners, contributors, etc. to understand and go with this strategy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants