Full stack developer @Engie Romania. I develop applications in PHP, HTML and Javascript. I love OOP and DDD and I have an interest in functional programming, at this point, only to be used in web development. Mainly in Javascript. But one day, I hope I will have the time to learn Haskell. My linkedin profile is: https://www.linkedin.com/in/ovidiu-b%C4%83di%C8%9B%C4%83-11139578
Nothing here yet.
No blogs yet.
That is not actually true. The second code will take just about as much as the first. Count the execution steps. There are n more instructions extra for n products. This is nothing. Even if you have a large dataset, you will feel no impact, not to mention that I expect some of this to be optimized by compiler. If you do not believe me, make a script and benchmark. You will be surprised to see that there is almost no difference.
You want to separate things because you can have a method process($products) and another one doSomething($products) and most likely there will also be doSomethingElse($products). Also, it helps to be able to have code between doSomething($products) and doSomethingElse($products). And when you call the doSomethingElse($products), most of the times you get to save the process iteration, and if you have multiple conditional processing, you end up with a cleaner code and easier to maintain. You can also extract all those types of things in some sort of config for different classes of items and you can change the order of things a lot easier. Especially if those doSomething calls are long calls, for generating files, sending notifications, computing complex things. Imagine you need to create some pdf files and send emails for some of the products, but not for all. It may not be the same type of email or PDF. Having this type of extraction, all you need to do is call the right method on processed data and it all works just fine. The extra "n" steps of iteration are nothing compared to the number of steps in making a file or sending an email or publishing things to rabbit, calling some api or whatever. Not to mention the fact that exception handling becomes a lot easier if you have the type of processing separated.
The only thing that is an extra operation, is the iteration index. So you will have extra n increments for an array of size n. If you compare the number of operations in a loop, n is small compared to what happens in the other functions. If all you do is increment that index, then it is important. Note that the complexity remains the same. In my opinion, even if it may not feel that way, in reality it will almost not register in a benchmark as a difference unless is it is a sample size of epic proportions. And it would increase the time with very little. The advantage of this approach is that it may be helpful to add other such conditional processors, and each can be its own function with a descriptive name, and the cost of this is really small.
I am aware of the fact that the industry already has AI today. My point is that it will be more and more used and it will become easier to interact with for non technical people. It will be possible for someone to formulate a problem in natural language, and the AI figure out what information it needs to understand what the person wants, it will ask relevant questions to clarify the problem, and then provide the answers in natural language. We have that already today. The problem is that at this point is for very few people, and is not as strong as it could be. And the real progress will start when the AI will start asking its own questions and providing its own answers. Because we are not smart enough to know what to ask. But in a decade, I expect the AI to be that smart. And the real progress will start the day AI starts asking itself questions.
A.I. I expect that the AI will become mainstream in next few years. Not necessarily strong AI. But it is already at an impressive level and it will grow fast. We have the tendency to underestimate the power of the exponential function. But I think, once is out there, we will see progress at first, then more progress a lot faster, then the progress will be so fast we won't be able to notice it anymore.
I see no reason to form a policy about this. Your code needs to be SOLID. If it is, it will be easy to decide where a feature should be. Also, code needs to be simple. If you put those calls on back-end, you increase the complexity of your project, because your server becomes a glorified router. Your frontend should not care about your server. And it should be able to call any resource it needs using the right endpoint. As long as the API provides all the data as you need it, and it needs not further validation and you trust the API you call, is okay to just use that API. On the other hand, if performance is not a problem, and you already have a service that abstracts away API calls and validation on the server, for consistency I would use that. Consistency is good and it makes things easier to understand for new people joining the project. But I do not think it is a must, in this case.
It is all about what your need is at the moment. If you access a public API, and you do not need to keep any records about user interaction with that API, you can just dump it on the client side and save up on server load. For example, if you want to put some Twitter feed in your UI, I see no reason to route this on your server, unless you want to filter that feed in some way. If the API you call requires tinkering with the response or a special kind of request, then it belongs on the server.
The best way to understand a large app... is not try to understand it. You will have tasks. See where the entry point is and go from there. Try to understand as much as you need to get your job done. Refactor small things where is needed. If you are to spend a lot of time on that app, you will end up learning it. If not, any time spent on learning it, is wasted effort. Is more important to have a high level understanding of the business it solves. Have a look at the database and see what is in there, without wasting too much time on understanding all relationships. Is impossible to understand it all fast, and if you are in a large team, what you understand today, tomorrow may change. Don't try to rush your understanding. It will just come. You can do your job just fine if you take one step at a time and build the knowledge in time. Make sure you spend more time learning to clean the code and write clean code. Is a lot more value in that, and that will put value in any project. I bet a good programmer, with no understanding of a project, when going in it, it can make some good changes that help without any understanding of what the app is for.