Aug. 20, 2024

Episode 335: In the Dynamics Corner Chair: Understanding Clean Code and The Importance of Code Reviews

Natalie and Stefan joined Kris and Brad in discussing Code Reviews and Clean Code. The conversation explored the topic of code reviews and clean code. Natalie and Stefan addressed the purpose of code reviews, what code reviewers should look for, and the importance of following coding conventions and style guides. They also discussed the concept of clean code, emphasizing readability, maintainability, and adherence to coding conventions.

Connect with Natalie on X (Twitter) https://twitter.com/KarolakNatalie

Connect with Stefan on X (Twitter) https://twitter.com/StefanMaron

Send us a text

#MSDyn365BC #BusinessCentral #BC #DynamicsCorner

Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/

00:00 - Code Reviews and Clean Code Discussion

11:03 - Utilizing Code Analyzers in Code Reviews

19:24 - Customizing Code Guidelines for Consistency

26:08 - Effective Code Review Best Practices

40:37 - Intent of Constructive Code Reviews

WEBVTT

00:00:00.300 --> 00:00:06.250
Welcome everyone to another episode of Dynamics Corner, the podcast where we dive deep into all things Microsoft Dynamics.

00:00:06.250 --> 00:00:16.753
Whether you're a seasoned expert or just starting your journey into the world of Dynamics 365, this is your place to gain insights, learn new tricks and reviewing the reviews of code.

00:00:16.753 --> 00:00:18.385
I'm your co-host, chris.

00:00:19.580 --> 00:00:20.263
And this is Brad.

00:00:20.263 --> 00:00:23.873
This episode is recorded on August 1st 2024.

00:00:23.873 --> 00:00:25.463
Chris, chris, chris.

00:00:25.463 --> 00:00:27.289
Reviewing of code.

00:00:27.289 --> 00:00:29.724
What is the reviewing of code?

00:00:29.724 --> 00:00:32.268
Do you know what the reviewing of code is?

00:00:32.268 --> 00:00:42.244
Well, today we had the opportunity to speak with two amazing guests to talk all about code reviews, clean code and several other points With us.

00:00:42.244 --> 00:00:45.412
Today we spoke with Natalie Karalik and Stephen Martin.

00:00:45.412 --> 00:01:01.680
Good afternoon.

00:01:01.801 --> 00:01:02.161
Hello, I'm fine.

00:01:02.161 --> 00:01:04.602
How are you Doing very well?

00:01:04.602 --> 00:01:06.885
Thank you, good afternoon Hello.

00:01:06.944 --> 00:01:07.885
I'm fine, how are you Doing?

00:01:07.885 --> 00:01:08.385
Very well, thank you.

00:01:08.406 --> 00:01:11.608
Good morning, good morning, good afternoon Stefan and Natalie.

00:01:11.608 --> 00:01:12.909
Great to see you.

00:01:12.909 --> 00:01:14.811
I've been looking forward to talking with you both.

00:01:14.811 --> 00:01:17.653
I have a lot of things I'd like to talk with you about.

00:01:17.653 --> 00:01:30.468
You know, I hear a lot about source control management, hear a lot about test automation, hear a lot about pipeline CICD, but one thing that comes in with the source code source control management.

00:01:30.468 --> 00:01:31.852
I hear people use different terms.

00:01:31.852 --> 00:01:37.091
Maybe we can get into that a little bit as well, but one of the things is code reviews.

00:01:37.091 --> 00:01:49.054
You know, everyone talks about let's do code reviews, let's talk about pull requests, let's talk about a number of different things, and I thought who else could we talk to about code reviews and clean code than the two of you?

00:01:49.054 --> 00:01:57.230
So, before we jump into that conversation, though, would you mind telling everyone who's listening a little bit about yourselves?

00:01:57.230 --> 00:01:58.712
We can start with Natalie.

00:02:00.614 --> 00:02:01.736
Yeah, hello everybody.

00:02:01.736 --> 00:02:03.602
So my name is Nathalie Karolak.

00:02:03.602 --> 00:02:14.010
I'm located in Germany, working for Cosmo Consult as a programmer for solutions published to the AppSource, so this is my main focus.

00:02:14.010 --> 00:02:18.033
I'm doing this since quite a long time already.

00:02:18.033 --> 00:02:25.225
I'm in the business since 2006 and I'm also a Microsoft MVP for business solutions, and I'm also a Microsoft MVP for.

00:02:25.246 --> 00:02:25.750
Business Solutions.

00:02:25.750 --> 00:02:27.019
That's right, congratulations.

00:02:27.019 --> 00:02:32.650
Fantastic Congrats you had received that recently, and also this is your second time speaking with us.

00:02:32.650 --> 00:02:43.930
We were fortunate and lucky enough to have you speak with us early on while we're still trying to figure all this out, so we appreciate your support and speaking with us then and also returning to speak with us again.

00:02:43.930 --> 00:02:46.242
Stefan sir, how are you doing?

00:02:47.967 --> 00:02:48.968
Yeah, thanks, I'm doing good.

00:02:48.968 --> 00:03:15.031
Hello everyone, I'm Stefan and I've been working with NAV since I started with NAV actually, so many folks as of today are not familiar with NAV anymore, so I want to point that out With NAV 2016, so not quite as long as Natalie, and I am originally from Germany.

00:03:15.031 --> 00:03:37.228
I'm now located in Poland for almost a year now and I'm working as a freelance developer, so mostly doing coding stuff, but then again all the as Brad already mentioned all the stuff that comes with us going through pipelines and code reviews and clean coding and stuff excellent, great.

00:03:37.247 --> 00:03:39.901
And you also have the BC coding stream which I like to watch.

00:03:39.901 --> 00:03:42.687
Unfortunately, I see that you had moved it over to YouTube.

00:03:42.687 --> 00:03:46.186
I have to try to figure out the timing on that, but that's.

00:03:46.186 --> 00:03:47.829
I appreciate seeing that.

00:03:47.829 --> 00:03:48.912
It's weird.

00:03:48.912 --> 00:03:52.991
Sometimes I just put it on and play it and just watch when I'm working or do whatever.

00:03:52.991 --> 00:03:55.087
So it's nice to have stuff like that.

00:03:55.087 --> 00:03:57.769
I kind of feel like I'm in the office with you or something.

00:03:59.501 --> 00:04:00.383
Well, that's the intention.

00:04:01.228 --> 00:04:03.526
Yes, well, the intention worked.

00:04:03.526 --> 00:04:10.268
I'm sure many others listen to it or watch it, and if they don't, um, I suggest they do so.

00:04:10.268 --> 00:04:31.086
When it comes to code reviews, um, and I deal with it, I get asked this often, even within you know, when I'm working, because we're talking, okay, well, we're going to write code, we're going to do a pull request, now someone's going to do a code review, and what is a code review, and what should someone do during a code review?

00:04:31.086 --> 00:04:34.225
Because that's what I get asked and there's some basic stuff I can say.

00:04:34.225 --> 00:04:36.846
Well, you know, I look at some of the simple things.

00:04:36.846 --> 00:04:38.725
So, what is a code review?

00:04:38.725 --> 00:04:42.312
What should a code reviewer do?

00:04:42.312 --> 00:04:51.620
What should a code reviewer do?

00:04:51.620 --> 00:04:52.523
What should a code reviewer look for?

00:04:52.543 --> 00:04:55.629
These are all the questions I have, so we'll hopefully get to them in the conversation.

00:04:55.629 --> 00:04:57.333
So what are your thoughts with that?

00:04:57.333 --> 00:05:02.682
Natalie, I know you work with code reviewers quite a bit, yeah, so if I should start, maybe I start with what it is not supposed to be.

00:05:02.682 --> 00:05:10.047
I simply get a formula called a pull request where I simply hit the approve button and that's it.

00:05:11.180 --> 00:05:22.189
My task as a reviewer is to look at the code, to check what is possible, at least within a short time, at least looking at it directly in the pull request itself.

00:05:22.189 --> 00:05:24.271
I could also download the old branch and check it all in the pull request itself.

00:05:24.271 --> 00:05:29.132
I could also download the old branch and check it all in my development environment, but this is something that I, for example, do not do.

00:05:29.132 --> 00:05:34.541
However, I want to check formal stuff.

00:05:34.541 --> 00:05:45.211
I want to see that code applies to certain conventions, to style guides, to style guides in order to help us to read the code easily.

00:05:45.951 --> 00:06:16.187
And the other task I have but it's not always possible is to also validate actually code, to look out for maybe errors or even just spelling mistakes, whatever it can be so simple things, but sometimes you're lucky and if you have a good reviewer, he or she can also point you to real logical bugs that even a test did not discover earlier.

00:06:16.187 --> 00:06:23.334
That's the ideal part, but at least you have the formal stuff, because this is the easiest thing to do and usually doesn't cost too much time.

00:06:23.334 --> 00:06:35.572
Yeah, but also it's always a question of how much you go into detail, but maybe this is something that Stefan first can talk about as well.

00:06:37.242 --> 00:06:37.644
Stefan Hoferlund.

00:06:37.644 --> 00:06:41.988
Yeah well, code reviews it's such a huge topic we could probably talk for hours straight about this.

00:06:41.988 --> 00:06:52.016
It really depends how you yeah what kind of change you're reviewing, I think, especially with how much you go into detail.

00:06:52.016 --> 00:07:08.827
If I'm just looking at a small change, which also should receive reviews, I think, in my opinion, then you can maybe go a little bit more into details, or maybe you don't need to go into details at all because you can look through it in a few minutes and there is nothing special going on.

00:07:08.827 --> 00:07:19.509
And I probably go into detail for certain parts of code changes, of a feature change or something, when I feel the need to it.

00:07:19.509 --> 00:07:33.129
And then I sometimes also download the code onto my machine to be able to really do code navigation and stuff, to really look through the code change, yeah, and then other changes really don't need much detail.

00:07:34.521 --> 00:07:35.363
I had another thought.

00:07:35.363 --> 00:07:52.862
What was it discovered was during code reviews that I saw a colleague, maybe not as familiar with Microsoft's code base, rewriting stuff or functionality that's already implemented in some of their helper code units.

00:07:52.862 --> 00:07:57.312
So it was really a possibility to point that out to them.

00:07:57.312 --> 00:08:04.687
So they learned code units, new code units from the base of the system app and reuse that and could get rid of some custom code.

00:08:04.687 --> 00:08:07.952
Yeah, so that's also a good thing.

00:08:08.673 --> 00:08:09.834
Very important point indeed.

00:08:12.279 --> 00:08:14.004
That is a big point and it goes with.

00:08:14.004 --> 00:08:23.610
You hit a couple points with the comments that you made and you touched upon maybe who should be doing the code review.

00:08:23.610 --> 00:08:38.711
Touched upon maybe who should be doing the code review because I also like to believe that code reviews can also be a learning experience or a teaching experience for someone, because I've had some individuals go through the code review experience that were new to AL development.

00:08:38.711 --> 00:08:48.769
Not necessarily to the code review purpose for, you know, validating the code, necessarily, but looking through it they were able to learn new things by looking at some code that others had created.

00:08:48.769 --> 00:08:52.433
So that's one aspect that I like about the code reviews.

00:08:52.433 --> 00:08:58.460
So they were doing it, not necessarily, like I said, for the approval process, but it was more of a training process.

00:09:01.347 --> 00:09:20.109
So your points, stefan, about learning the Microsoft-based code units or the base library, is important because so many things have been added, or so many new methods, so many new code units have been added, that a lot of developers do recreate that unintentionally, you know, unintentional duplication of what Microsoft already has.

00:09:20.109 --> 00:09:28.812
So being able to have multiple people look at it give some good insight and also provide the feedback with it.

00:09:28.812 --> 00:09:37.513
I like your approach Natalie too of what it is not, and it's one of those daunting tasks as well, because it does take time to do it.

00:09:37.513 --> 00:09:51.110
So the size of the code review matters as well, because I've seen pull requests with hundreds of files and I've looked at it and I just scratched my head and I'm like, do I just click approve or do I have to go through all of these changes Sometimes?

00:09:51.129 --> 00:09:51.551
you have to.

00:09:52.320 --> 00:09:57.706
Yeah, that's one thing to keep into consideration, I think, is the size of the code review.

00:09:57.706 --> 00:10:02.629
So, with that, what is your take on who should be doing the code review?

00:10:02.629 --> 00:10:12.044
Is it a senior developer, a developer functional consultant type, or or how do you if you fit the code review in the process?

00:10:13.467 --> 00:10:23.922
ideally everybody, but of course, this is not the way how we live it, due to organizational restrictions, maybe also permissions, whatever.

00:10:23.922 --> 00:10:29.474
It's a question of how your pull requests are actually set up in your environment.

00:10:29.474 --> 00:10:39.899
For example, we are using DevOps and we have some policies attached, branches that define that we have to create pull requests for everything.

00:10:39.899 --> 00:11:03.331
All of them have to be reviewed by at least one external let's say second developer, and this is very, very useful in my opinion, and I also really see the progress and quality since we switched from CIL to AL and this whole request approach.

00:11:03.331 --> 00:11:04.312
With code reviewing.

00:11:04.312 --> 00:11:10.528
You can learn so much on both sides really and prevent many mistakes, so glad.

00:11:13.301 --> 00:11:24.743
Now you had mentioned CAL back in the old you know the older versions of NAV and how the objects were embedded within the application, within the object designer.

00:11:24.743 --> 00:11:25.513
So the objects were built within the application, within the object designer.

00:11:25.513 --> 00:11:28.216
So the objects were built as part of the application.

00:11:28.216 --> 00:11:36.451
So keeping track of changes and doing code reviews if anybody did code reviews back then were extremely difficult.

00:11:36.451 --> 00:11:40.191
I know I used to export the text files, just to track changes.

00:11:40.659 --> 00:11:51.955
I had PowerShell scripts set up just to export the text files and then each day load them into a repository, so we could see the difference of what it changed, because it was very difficult in that environment to do it.

00:11:51.955 --> 00:12:02.500
So I'm happy to see that with AL we moved forward to Visual Studio Code and having separate files to build these extensions Exactly.

00:12:02.542 --> 00:12:09.120
So I suppose none of us is missing these old times I'm not missing it for one moment at all.

00:12:09.240 --> 00:12:13.491
So, finally, even doing since the 2016, so you had the opportunity to experience that as well too.

00:12:13.491 --> 00:12:16.948
Um, and it was similar process back all the way.

00:12:16.948 --> 00:12:23.323
If you go way back to in the vision when it first started, it was the same concept, other than the rotator, all the way up through.

00:12:23.323 --> 00:12:24.928
So so we had some challenges.

00:12:24.928 --> 00:12:31.630
So it's refreshing, and it's also depending upon when someone started working with it.

00:12:31.630 --> 00:12:40.133
It is a learning experience, or someone needs to adapt to the changes of the way things used to be done in Cal versus where they are with AL.

00:12:40.133 --> 00:12:44.667
And you mentioned one thing spelling mistakes.

00:12:44.667 --> 00:12:54.620
I'm famous for making a couple of those, by the way.

00:12:54.620 --> 00:12:56.427
With those Spelling mistakes, how do you determine it's a spelling mistake?

00:12:56.427 --> 00:12:59.337
And I did see a topic recently that someone spoke about is which language someone should code in.

00:12:59.337 --> 00:13:10.052
So that would actually, I think, would attribute to what constitutes a spelling mistake, because if someone's doing a code review and they're determining if the word's spelled correctly, what is your thoughts on that?

00:13:14.105 --> 00:13:15.410
My take on that is really simple.

00:13:15.410 --> 00:13:32.802
I have a VS Code extension that checks it and if it yells at me, I review that and that would be the benefit of actually downloading the the branch to have uh, um yeah, helper tools locally to help with the code review and spelling mistakes, and that that extension would be one of them.

00:13:32.802 --> 00:13:35.951
And whenever it's it's blue, it's an info.

00:13:35.951 --> 00:13:52.379
Then I I look at it and I usually keep some of the warnings that it spits out in the, either in my user settings or in the workspace settings, as exceptions, because sometimes abbreviations are treated as a spelling mistake, although they are not.

00:13:52.379 --> 00:13:58.602
But it does a really good job also with camera casing and everything to pick the words up and check everything correctly.

00:13:59.004 --> 00:14:03.917
So that really helps a lot which extension is that that you use for that?

00:14:03.917 --> 00:14:05.100
That sounds helpful.

00:14:06.062 --> 00:14:06.904
I would need to check.

00:14:06.904 --> 00:14:10.837
From the top of my head I don't know, but yeah.

00:14:15.697 --> 00:14:16.480
Can you repeat that please?

00:14:18.368 --> 00:14:19.272
Sorry, the spell checker.

00:14:19.902 --> 00:14:20.623
Oh, the spell checker.

00:14:20.623 --> 00:14:23.971
Okay, so the spell checker extension?

00:14:23.971 --> 00:14:26.600
Does it work with any language, or just english?

00:14:28.043 --> 00:14:31.009
there are extensions like additional extensions per language.

00:14:31.211 --> 00:14:39.154
I think english is base and then not you, you can load multiple languages and create your own libraries.

00:14:39.154 --> 00:14:51.495
Um, I've activated for american english and british english because because I have to develop some elements really in British English for a very specific application and this really works.

00:14:51.495 --> 00:14:53.947
So it has different libraries.

00:14:55.320 --> 00:15:01.792
Well, that's one I know many people use it and I work with many that use it and I haven't.

00:15:01.792 --> 00:15:12.345
But I think I'm going to start as soon as we're done with this, just to see, I'm afraid, I think think sometimes to see what comes up with it, but we'll see you really didn't use it yet?

00:15:12.345 --> 00:15:15.631
No, no, no, no.

00:15:15.631 --> 00:15:18.860
Do you believe that all these years?

00:15:20.101 --> 00:15:22.025
how can you survive any day like that?

00:15:24.750 --> 00:15:25.293
I've made it.

00:15:25.293 --> 00:15:41.390
I've made it, but I have I know many use it because I end up sometimes seeing in the pull request the dictionaries where they add words, as you had mentioned to you know, as the info for the words that they want to accept with the spelling.

00:15:41.390 --> 00:15:42.846
So I know others use it, which is good.

00:15:42.846 --> 00:15:59.767
So, with the code review and the code review process you had mentioned what it's not and looking for structural changes and coded changes how do you base it?

00:15:59.767 --> 00:16:15.370
What do you base it on as far as when you look at these you had mentioned structural changes and content Is it based on just experience or are there certain standards that you follow as far as like a library or documented somewhere?

00:16:17.201 --> 00:16:26.971
In my personal opinion, I try to stick to the Microsoft standards of what they are using in their base apps the base app.

00:16:26.971 --> 00:16:45.315
Plus and this is very important in the newer repositories like BC apps for the system application and the business foundation app, because other apps who depend on us or Microsoft.

00:16:45.315 --> 00:16:47.899
They should not switch between language styles.

00:16:47.899 --> 00:16:55.206
They should find the same style of code to attach to to read it easily.

00:16:55.206 --> 00:17:02.013
But I'm not telling that I'm applying everything blindly.

00:17:02.013 --> 00:17:04.146
There is always some criticism in it.

00:17:04.146 --> 00:17:17.413
I would not really stick to everything, but at least to everything that really makes sense and makes things easier to read.

00:17:17.413 --> 00:17:18.605
That's very important to me.

00:17:18.605 --> 00:17:40.826
What I have found helpful which is not followed, for example, by Microsoft is that properties within an object or whatever are sorted alphabetically, because only that way you can easily compare what's different between two versions of a file, between two different files actually.

00:17:40.826 --> 00:17:42.791
Yeah.

00:17:43.520 --> 00:17:44.124
That I do use.

00:17:45.101 --> 00:17:48.951
Some database structure that I I do use.

00:17:49.191 --> 00:18:06.826
By the way, I use azl tools and I set up the code cleanup to go through and clean up all of the sorting because I found, like you, it's easier to do a compare of what had changed if things are sorted in a certain manner because that way they're aligned, even if you use it to sort the procedures.

00:18:06.859 --> 00:18:14.891
I know there's some topic individuals have about how do you sort the procedures with the locals and the globals or do you group them together, sort them by name?

00:18:14.891 --> 00:18:25.673
But I have found in the code review process it's helpful to have it sorted and that's a valid reason for having them sorted, in my opinion as well to make it easier to do the review.

00:18:25.673 --> 00:18:31.811
So we talked about the use of a spell checker.

00:18:31.811 --> 00:18:35.069
Stefan, you mentioned downloading the source so you could have the spell checker.

00:18:35.069 --> 00:18:37.440
What about some of the other source code analyzers?

00:18:37.440 --> 00:18:48.547
Do you think that should be part of the process, because we know, with the source code as the app source cop, for example, and there's other tools available.

00:18:48.547 --> 00:18:50.817
Do you use those as part of the code view?

00:18:50.817 --> 00:18:52.584
Do you think they're helpful as part of the code review?

00:18:53.748 --> 00:18:55.513
absolutely yes, and that's actually.

00:18:55.513 --> 00:19:01.928
I did a live stream recently about where I reviewed one of the pull requests from microsoft and that's exactly what I did.

00:19:01.928 --> 00:19:17.188
I just ran this through all the analyzers, also the the linter cop, to get all the different warnings and everything right right away in VS code and then I could just write comments where where I, where I thought it was useful.

00:19:17.188 --> 00:19:24.252
I don't need to find those things myself if there is like helper tools that can do the work for you.

00:19:24.252 --> 00:19:30.049
And I just wanted to pick up on Natalie's comment on the guidelines introduced by Microsoft.

00:19:30.049 --> 00:19:38.549
I really agree with the approach to follow them where it makes sense, and I just wanted to give an example where I actively decided to not follow their guidelines.

00:19:38.980 --> 00:19:46.586
I think there is one rule for the variable naming that it should be exactly like the type you're using, for example, for table name.

00:19:46.586 --> 00:20:00.526
That rule is disabled in all my repositories, for example, because it makes sense to a certain degree, but there's just too many false positives where I wouldn't agree to this rule, so it doesn't make sense for me.

00:20:00.526 --> 00:20:14.143
And the object naming I decided a while ago already that I just cannot afford to have spaces in my object names, since we are limited to 30 characters, so it's a pascal case for me now through like everything.

00:20:14.143 --> 00:20:15.626
Same goes for field names.

00:20:15.626 --> 00:20:31.903
Um, so I know there was a this unwritten rule since forever that it should always be with spaces and everything, and then you end up abbreviating, then you add dots and then it's all just abbreviations, so no one knows what it actually has to mean if they don't look at the caption.

00:20:31.903 --> 00:20:34.352
So that doesn't make sense for me at all.

00:20:35.296 --> 00:20:50.450
I have to chuckle because I I feel what you're saying with the naming, with the 30 characters, because even if you try to do a customer card ext, if you're doing a customer card extension right, and then you have to put in a fix on it, yeah you end up.

00:20:50.450 --> 00:20:52.727
People start I see crazy abbreviations.

00:20:52.727 --> 00:20:57.326
Wherever you get some of the longer pages you know, like the sales credit memo, they start dropping off words.

00:20:57.446 --> 00:21:11.988
Or, you know, journal gets abbreviated a number of different ways and then you add up and then like, if you're doing app source or even for PDEs, you're recommended to use a suffix, an ethics, at least a prefix or a suffix of three characters.

00:21:11.988 --> 00:21:15.630
Now I like to add two extra characters per app.

00:21:15.630 --> 00:21:16.281
I'm doing so.

00:21:16.281 --> 00:21:18.525
It's five characters already for the ethics.

00:21:18.525 --> 00:21:23.468
I'm left with 25 characters, and that's just not enough if you have spaces and all this stuff.

00:21:27.480 --> 00:21:29.343
So it's just not enough if you have spaces and all this stuff.

00:21:29.343 --> 00:21:31.183
So it's a best-case case for me for a few years already.

00:21:31.183 --> 00:21:34.186
Although your approach makes a lot of sense, I totally agree.

00:21:34.186 --> 00:21:34.567
I don't do it.

00:21:34.567 --> 00:21:43.635
I only try still, because it's just the rest of being an OG, I think it's just I'm just being used to that.

00:21:43.635 --> 00:21:45.665
Oh my God, yeah, business Central Life and OG.

00:21:45.665 --> 00:21:46.404
I think I was being used to that all my business central life.

00:21:46.404 --> 00:21:57.528
I try to create it in the old way as possible, and if the space doesn't fit there then I simply squeeze it into a Pascal case or just remove one space and then the next.

00:21:59.061 --> 00:22:11.413
I think in the end it's all about consistency, and when I work for companies which have existing code and they want me to add code into their app or just help them develop and they decide to have the spaces, I of course adjust.

00:22:11.413 --> 00:22:12.865
So this is the second part.

00:22:12.865 --> 00:22:32.701
While Microsoft sets somewhat of the base of guidelines, I think if a company agrees for themselves, like we want to do certain things differently, this should also be, um, like always used, sorry, um, so like a company-wide rule.

00:22:32.701 --> 00:22:37.770
Set of of guidelines is the next part, the next layer, in my opinion.

00:22:38.311 --> 00:22:53.645
So, yeah, when, when a company agrees to do like the old way, then of course, so that that is a good point where you can start that the rules and the guidelines and to use can be company specific, whatever fits the, the company that's managing the code or the code that's theirs.

00:22:53.645 --> 00:23:03.326
And as long as I agree with you, as long as you're consistent with what you're doing, it makes it easier for whoever's working with it or anybody who is going to come in to do the code rework with the code after.

00:23:04.569 --> 00:23:16.035
I think one good example for this is this keyword I think, natalie, you posted the point where Microsoft agreed on or said that they are going to do it everywhere.

00:23:16.035 --> 00:23:21.872
So they are going to prefix variables System app, system app Okay.

00:23:21.872 --> 00:23:23.221
System app yeah, I mean.

00:23:23.221 --> 00:23:24.567
Base app is another story.

00:23:24.567 --> 00:23:27.480
System app okay.

00:23:27.480 --> 00:23:28.142
System app yeah, I mean.

00:23:28.142 --> 00:23:28.983
Base app is another story.

00:23:29.003 --> 00:23:41.201
So they're they're going to prefix globals and functions that are in a code unit scope with this, although it's not mandatory by the language, um, and I know, or I read a lot of comments on twitter, that many people do not agree with this.

00:23:41.201 --> 00:23:53.670
So then again, if I would do a review at a company where it was agreed that they're not going to use it, then you should never use it that way, because I feel like, in my opinion, consistency is key.

00:23:53.670 --> 00:24:03.476
So if you want to use it, then use it and always, if you do not want to use it, then only use it in those specific cases where it's necessary to use it and otherwise not.

00:24:03.476 --> 00:24:10.405
In those specific cases where it's necessary to use it and otherwise not, but not switching around from code unit to code unit, because this ends up being annoying, in my opinion.

00:24:11.950 --> 00:24:15.380
It does, which brings me to another.

00:24:15.380 --> 00:24:37.390
I have so many questions about this with code, code reviews and code processes, because you hit on a key point with this being added to the language as the language evolves and functionality evolves within the language and maybe even standards evolve with the language.

00:24:37.390 --> 00:24:42.435
Some code is created in earlier versions.

00:24:42.435 --> 00:24:52.761
Some code gets created all the way back from Cal and it's a functionality that needed to be migrated or moved or upgraded to work with AL or even in earlier versions of ALs.

00:24:52.761 --> 00:24:54.001
Maybe you can pick a version.

00:24:54.001 --> 00:25:06.461
What about bringing in and using some of that new functionality where there wasn't a standard before and there is a standard now or there's new addition now?

00:25:06.461 --> 00:25:09.013
Is that something where you fix it as you go?

00:25:09.013 --> 00:25:14.371
Should someone review and update the code base to use some of these new functionality for the standards?

00:25:17.275 --> 00:26:07.777
there's the challenge with that as far as adoption of new techniques and practices with code that hasn't been around for the inception of those changes that's a delicate topic, if I understood it correctly, because there are different approaches and when it comes to such new standards as introducing this Microsoft, for example, they have decided that they want to make it the new standard and the base app, but they also decided that for pull requests that are now already created for any new lines of code they already want to edit, or at least allow it to edit now from then on, want to edit or at least allow it to edit now from then on, what they do not do is to choose one point at a time and convert everything in a separate pull request.

00:26:08.345 --> 00:26:13.755
And this is what I would actually do with my apps, which are smaller than the base app or any other standard app, obviously.

00:26:13.755 --> 00:26:23.689
But when I want to switch to another coding standard, for me this is a topic for a separate pull request which is doing only that.

00:26:23.689 --> 00:26:39.452
And I don't want to have pull requests that have one main task to change some functionality, some funky stuff but then they also format this one, some totally unrelated code line, in that object changing to this and that I don't know.

00:26:39.452 --> 00:26:41.657
This is at least in my head.

00:26:41.657 --> 00:26:45.753
This is just one big mess and I don't see the the benefit of that.

00:26:45.753 --> 00:26:47.377
How do you think about that?

00:26:49.968 --> 00:26:54.615
I think, um, it's, yeah, it's somewhat agree with you.

00:26:55.355 --> 00:27:10.848
Um, I think my take on this is really as you said it has to be a separate code pull request and it's also like, if you change it through, like adjust something throughout the whole extension, this can introduce bugs, since you change everything, you touch the code.

00:27:10.888 --> 00:27:18.355
Basically, if you change it, something can break, and so this has to be where outside of the group of developers.

00:27:18.415 --> 00:27:32.130
In my opinion, if you're working on a pretend extension, the customer needs to know they need to test again and they probably need to test everything, so it should sit somewhere in in a testing environment for some time so they have time to review whether everything still works.

00:27:32.130 --> 00:27:40.511
If you're working for a product, then well, whoever like the testers, needs to know that they potentially need to retest everything because you really touched everything.

00:27:40.511 --> 00:28:02.395
The other approach is, if you do not want to do like a major change like this, I feel like when you're working on one code unit given that you don't have like code units with thousands and thousands of lines, if you have them separately, separately created and like smaller code units, I would probably convert them one by one as I work on them.

00:28:02.395 --> 00:28:15.451
If I'm working on one topic, then I can convert that topic because I know it will be tested anyways, because I'm doing changes to that topic so that I can adjust language and bring in those new language features as we go.

00:28:18.609 --> 00:28:19.874
It's a mixed approach.

00:28:19.874 --> 00:28:21.229
I think it sounds situational.

00:28:21.229 --> 00:28:22.532
Now you mentioned a point.

00:28:22.532 --> 00:28:29.448
If you're uh doing it for a small app, maybe it's easier to to do it all at once to find you brought up some points of.

00:28:29.448 --> 00:28:31.776
You know, maybe as you work through and you go through it.

00:28:31.776 --> 00:28:44.673
Uh, you also, natalie, you mentioned uh something I I think for the the two of the topic of and we started talking, I guess, around it is what's in a pull request for a code review.

00:28:44.855 --> 00:28:58.355
You had mentioned that upgrading functionality within the language, language functionality or language standards should be its own separate pull request, where feature or fixes should be their own separate pull request.

00:28:58.355 --> 00:29:01.842
What do you both think of?

00:29:01.842 --> 00:29:11.156
What should be in a pull request and what should be included with a pull request, and what I mean by that is is it one issue per pull request?

00:29:11.156 --> 00:29:15.016
Is it one major feature per pull request?

00:29:15.016 --> 00:29:17.750
And within the pull request?

00:29:17.750 --> 00:29:21.096
You know, if you use GitHub, you use DevOps.

00:29:21.096 --> 00:29:22.338
Those are the two popular tools.

00:29:22.338 --> 00:29:25.134
I know there are many other tools available that can be used.

00:29:25.134 --> 00:29:31.817
What documentation should be included with the pull request for the reviewer?

00:29:31.817 --> 00:29:37.472
Either one of you can jump on this one.

00:29:37.472 --> 00:29:39.231
I'm interested in hearing both of your opinions.

00:29:39.231 --> 00:29:47.838
You both have great opinions on all of this in points of view, so I'm eager to hear Stefan first.

00:29:49.526 --> 00:29:50.288
Okay, we'll alternate.

00:29:50.288 --> 00:29:51.112
Stefan, you go first.

00:29:51.112 --> 00:29:53.112
This time We'll alternate.

00:29:54.965 --> 00:30:03.138
Yeah, I mean again hours of potential talking First what should be an issue.

00:30:03.138 --> 00:30:04.611
I mean again hours of potential talking First what should be an issue.

00:30:04.611 --> 00:30:17.530
I mean if you and there is probably a line between what should be an issue or a feature request, possibly, and what should be an epic, with lots and lots of issues or features, depending on the platform you're using.

00:30:17.530 --> 00:30:20.733
So that shouldn't be too big either.

00:30:20.733 --> 00:30:25.652
And then, if you need to have a bigger issue, how many pull requests should you do?

00:30:25.652 --> 00:30:35.810
And I think this is also important if you want to control the or if you want to improve the quality of the code review itself.

00:30:35.810 --> 00:30:47.688
Because, as you said, if you have thousands of objects touched in a single pull request, you're not going to expect that anyone takes the time, sits down eight hours straight and just reviews everything you did there for the last three months.

00:30:48.189 --> 00:30:55.813
So, not to mention the, the merging conflicts that arise with this, with those kind of huge changes.

00:30:55.813 --> 00:31:00.865
So I'm really in favor of small pull requests.

00:31:00.865 --> 00:31:07.991
I can imagine lots of pull requests for a single issue, as long as you have something that can be merged.

00:31:07.991 --> 00:31:22.268
It's really hard to come up with an example here, but if you're working on a feature and you can encapsulate a few things out of this feature, like first I'm going to introduce this change and then I need to introduce five change and then I'm I need to introduce five more changes.

00:31:22.268 --> 00:31:22.628
I can.

00:31:22.628 --> 00:31:27.611
I can separate those and merge them without breaking anything in the target branch I'm merging to.

00:31:28.113 --> 00:32:03.921
I can totally imagining splitting it up just to make it easier to merge, to review and to test possibly um, I have problems with the 100% agile paradigm, like making hundreds of tiny pull requests one by one, then fixing some previous pull requests and this and that, and you have a long, long commit list of tiny changes or mostly bug fixes, that nobody can really understand.

00:32:03.921 --> 00:32:35.236
And why I'm mentioning that is I'm developing, as I said, apps for AppSource and they are also to be used on on-premise environments, and we have teams that create also on-premise extensions, maybe from our AppSource extensions and for them although no one has approached me yet to do that, but in my opinion the ideal way is that I provide such pull requests that any other extension developer can use as a pick list.

00:32:35.236 --> 00:32:44.233
They want a feature A and then this and that, and they don't want to pick 100 pull requests, but only a few with the functionality they need.

00:32:44.233 --> 00:32:49.251
They don't need to search for a bundle of pull requests for actually one big feature.

00:32:49.251 --> 00:33:14.773
So usually I try to really keep pull requests clean so they cover a specific feature topic or bug fix for something, however very encapsulated, and sometimes I do hit the situation that my pull request becomes too big in terms of the number of objects to look at.

00:33:15.464 --> 00:33:35.019
However, even when I do that, I still take care of my commits inside that pull request that they are separated nicely so you can click through the commits and check them individually, like, for example, when I just did a code cleanup using the AZAL tools.

00:33:35.019 --> 00:33:43.852
Then per single conversion step I do a single commit so you can check them one by one.

00:33:43.852 --> 00:33:45.912
This is helpful for the reviewer.

00:33:45.912 --> 00:33:53.298
But overall I still follow the line or the paradigm.

00:33:53.298 --> 00:33:59.057
You have to keep them small enough because it's a hazard to look at two and two-thirds.

00:33:59.057 --> 00:34:00.780
But again.

00:34:01.082 --> 00:34:10.931
I found it important to keep the commit history readable even to human beings, anybody else handing it that way.

00:34:12.905 --> 00:34:21.862
Yes, I prefer, as you had mentioned, I prefer the smaller pull requests for the individual changes, and I too too do.

00:34:21.862 --> 00:34:26.356
Commits are tough because it depends on what you're working on.

00:34:26.356 --> 00:34:30.510
I do go back and if I'm doing a code review I will look through the commit history.

00:34:30.510 --> 00:34:43.585
But, depending upon the scope or the size of what the developer has with working on, some of their commits may be just a sense of saving and getting the code into the repository in the branch for that.

00:34:43.585 --> 00:34:50.326
Whatever they're working on Some of that I know we promote committing it to get it stored in there.

00:34:50.326 --> 00:35:01.393
In the event that you have a problem with the system that you're working on, or if somebody needs to take leave because of illness or from other emergencies, somebody else can go pick back right up where they have and see the changes that they've made.

00:35:01.393 --> 00:35:07.889
So some of that with me is also with the commits depends upon the duration of the modification that you're working on.

00:35:07.889 --> 00:35:15.193
But those large pull requests I think are very difficult to go through.

00:35:15.193 --> 00:35:20.510
And also a pull request per I don't know if you want to call it issue.

00:35:20.510 --> 00:35:21.969
I mean, again, it depends what you're working on.

00:35:21.969 --> 00:35:23.773
But one small topic.

00:35:23.773 --> 00:35:32.675
I'll leave the word as a topic so that somebody's reviewing is they're not trying to look at multiple things, they're looking at one specific topic at a time so that they can put.

00:35:32.675 --> 00:35:37.768
You know, I like to put my mind into that one topic and not try and say, okay, well, this goes with this, this goes with that.

00:35:37.768 --> 00:35:42.271
I can see the changes all for this one thing and see where it touches and be able to work with it.

00:35:42.271 --> 00:35:47.634
And then, as far as some of the comments, you know.

00:35:47.653 --> 00:35:56.960
To go back to the code review as well, I know sometimes I go with you know I saw TNA's code review session at Directions, north America.

00:35:56.960 --> 00:36:10.126
I know he did it in Europe as well and you know I follow it and I it's one of the things that really got me thinking about this topic is even like putting in, like the nitpicking, because it you know how deep do you go with the comments that you're making?

00:36:10.126 --> 00:36:13.644
I mean, there's some things that are fundamentally wrong, but then there's other things.

00:36:13.644 --> 00:36:15.208
Sometimes I have to go.

00:36:15.208 --> 00:36:18.393
Eh, it's okay, but do we let it go?

00:36:18.393 --> 00:36:19.295
Do we not let it go?

00:36:19.295 --> 00:36:21.840
Maybe you may want to change it or think about doing it this way.

00:36:21.840 --> 00:36:25.233
So I'm with Stefan.

00:36:25.233 --> 00:36:30.034
We could talk about this for days, I think, and not cover all the code review processes.

00:36:31.309 --> 00:36:32.713
I want to comment on that real quick.

00:36:32.713 --> 00:36:36.414
When I was reviewing the Microsoft code I had exactly that thought.

00:36:36.414 --> 00:36:47.335
Do I really complain about all the different typing mismatches and everything that the lindelkop warns about, because I really don't like those um?

00:36:47.335 --> 00:36:49.327
Or do I just let it go and just?

00:36:49.327 --> 00:36:49.967
I mean it?

00:36:49.967 --> 00:36:52.094
Functionality wise it doesn't change anything.

00:36:52.094 --> 00:36:58.577
But what I know is in microsoft's code base it's really hard to have them change anything once it's in there.

00:36:58.577 --> 00:37:09.168
So I decided to to comment on everything, because now there is the opportunity to fix those and I don't need to look at this for the next like 20 years, um.

00:37:09.168 --> 00:37:18.067
So yeah, because I'm like in in partner code, I think it's way easier to fix those kind of things afterwards.

00:37:18.067 --> 00:37:25.456
If you come across those kind of um, yeah, I wouldn't, wouldn't call it issues for the lack of a better word.

00:37:25.456 --> 00:37:27.545
But yeah, you can, you can fix those afterwards.

00:37:27.545 --> 00:37:29.289
But for microsoft's code it's a different story.

00:37:29.289 --> 00:37:31.313
Another reason.

00:37:31.474 --> 00:37:45.061
A good argument to handle it that way, as you said, is um, I don't know how you handle it, but in my career, it was always very helpful for me to look at Microsoft code, to learn from it, to copy some patterns or whatever.

00:37:45.061 --> 00:37:56.865
And if we let now bad Microsoft code into the code base, this will multiply by everyone who will see it and work with it, and this is something that I cannot live with.

00:37:56.865 --> 00:38:28.451
This is something that I cannot live with, and so my pull requests, my code reviews sorry, always very nitty if such an adjective exists, and it can be very annoying in that, and I am also fearing that people get really irritated by that, and I hope nobody takes it personally, because even if you do that, the writer of this pull request, the author, still is king.

00:38:28.851 --> 00:38:41.159
He or she can always decline anything or accept it or at least talk about it, and we never know what's on their mind, like how they want it to be.

00:38:41.159 --> 00:38:51.458
And I've made the experience that at Microsoft they are open to even those little nit things of code reviews.

00:38:51.458 --> 00:38:57.371
Most of them are really considered and sometimes you get a thank you oh, I didn't see that, or whatever.

00:38:57.371 --> 00:39:06.213
So if you have the time and if you have the nerve to really do that, just go for it and see what happens.

00:39:07.505 --> 00:39:09.554
What I also did in the code review.

00:39:09.554 --> 00:39:12.034
I ended up actually doing those changes for them.

00:39:12.034 --> 00:39:27.114
I created a pull request onto the pull request branch because I said, well, I've downloaded the branch, I'm working on it and while I'm looking at it I can right away fix those little like here is a semicolon too much or here's like a casing mid-mesh.

00:39:27.114 --> 00:39:33.634
And I said, oh, here would I just add some spaces like empty lines, to just make it more readable.

00:39:33.634 --> 00:39:54.052
Just those kind of things I usually do right away in pull requests because I'm looking at it anyways, and then the reviewer still needs to review my review pull request and accept all the changes to their branch and then that way they know about what I changed but they don't need to do the work again, which I already did before.

00:39:55.440 --> 00:39:56.045
That's a good point.

00:39:56.045 --> 00:39:56.144
Which?

00:39:56.164 --> 00:40:01.137
wouldn't be necessary if Microsoft used all those tools available in their own repository.

00:40:05.726 --> 00:40:17.898
It is true, because if you run through even their base OS code analyzers, some of their base code will not pass any of those as well.

00:40:17.898 --> 00:40:36.032
So it's good your point is valid, natalie, as well is if they cleaned up some of those inconsistencies and if we're using that as a model to go by, we could eliminate the multiplication of potential other bad habits, bad design or other issues with the code as well too.

00:40:36.032 --> 00:40:47.391
But sometimes I think we've all been in the case as well as oh, I'm just going to add this, I'll add this, I'll add this, and then you go back and look and say, ha, had I known this from the beginning, I would have redone this whole thing and done it this way.

00:40:47.391 --> 00:40:52.697
Uh, so there's sometimes I it goes back to your word I like likes your new word, nitty.

00:40:52.697 --> 00:41:12.045
Uh, you know when you're nitpicking at some of this stuff and just trying to, you know, get an understanding of what the I guess I have a new nickname nitty natalie.

00:41:12.065 --> 00:41:12.989
I like that that right there.

00:41:12.989 --> 00:41:13.411
See, we can coin.

00:41:13.411 --> 00:41:14.074
That is nitty natalie.

00:41:14.074 --> 00:41:16.081
Well, you have the librarian, but so it's nitty natalie, the bc docs library.

00:41:16.101 --> 00:41:22.210
Maybe I will need the other one, or maybe it's already my internal name in Microsoft, but nobody called me that way.

00:41:24.166 --> 00:41:26.510
I'll have to make sure we Niddy, natalie.

00:41:26.510 --> 00:41:32.373
No, my thoughts to you is with that Niddy, with anybody who makes the comments, I always look at the intent.

00:41:32.373 --> 00:41:39.891
I mean, there's nothing wrong with constructive criticism because, as you both had mentioned, sometimes someone may not be aware of something, or they can.

00:41:39.891 --> 00:41:48.007
Always, you know, I know myself, I always want to learn to do, you know, do things better if possible, or even learn different ways to do things.

00:41:48.007 --> 00:41:56.427
It doesn't necessarily, you know, different doesn't always mean better, but sometimes difference there, and I think it's all in the intent of who's doing the review and the comments they make.

00:41:56.427 --> 00:42:09.679
If it's meant to be helpful or constructive, then people should be receptive to it and they make a decision on it and not think of them as being, you know, nitty-nattly how does that?

00:42:10.126 --> 00:42:10.766
how does that work?

00:42:10.766 --> 00:42:16.666
If you're on your own, like if you're an independent developer, like, how do you code review?

00:42:16.666 --> 00:42:21.155
Do you find peers to help you review your code?

00:42:21.155 --> 00:42:22.438
How does that work?

00:42:24.311 --> 00:42:42.871
sometimes there are in companies I work with, there are other developers who can do the review, but sometimes there's just no one, so I, uh, mostly review myself after a time you sleep on it first yeah, but I mean you always go back to your own code and wonder what you did there and why you did that.

00:42:43.485 --> 00:42:57.315
So yeah, but again, mostly using tools to get as much like warnings and infos and errors up front to do as less mistakes as I possibly can.

00:42:57.315 --> 00:42:58.550
But yeah, you're absolutely right.

00:42:58.550 --> 00:43:00.764
I mean, if there is no one to review, there is no one to review, there is no one to review.

00:43:00.764 --> 00:43:04.612
And sometimes it would be better if someone would have reviewed my code.

00:43:07.065 --> 00:43:16.994
Would you still go through the same process as if you're reviewing someone else's code or because you're on your own, do you just speed through it?

00:43:19.206 --> 00:43:27.751
Well, to be honest with you, I mean mostly it's, uh, going through the code, getting it in, getting it tested, and if it works, it works.

00:43:27.751 --> 00:43:36.146
But, um, yeah, sometimes for for more crucial stuff, I really go back to it after a few days and review myself, as I would normally review others.

00:43:36.146 --> 00:43:49.291
Um, but most of the code I just end up being working on and reviewing and reading what again and over again, and then if I notice something, I obviously, um, yeah, correct it that's good.

00:43:49.351 --> 00:44:04.505
It's a good habit to have because you know, I I know there's plenty of independent developers out there that they'll probably skip through some of that, unfortunately so just to kind of, we're talking about code views.

00:44:04.585 --> 00:44:08.134
I do want to talk about clean code and what clean code is.

00:44:08.134 --> 00:44:15.503
In a minute I think there's something else that we wanted to discuss, but now I'm thinking of this from the process point of view.

00:44:15.503 --> 00:44:17.447
Stefan, you're talking about testing.

00:44:17.447 --> 00:44:18.989
Natalie, you mentioned it as well.

00:44:20.512 --> 00:44:30.152
So you have within a repository, you'll have a main branch, and the main branch, I'm assuming, should be whatever is loaded in production, whatever is in someone's production environment.

00:44:30.152 --> 00:44:34.215
But there also is a point where there is a test environment.

00:44:34.215 --> 00:44:42.838
So someone will make a branch, that will make a modification for a branch and they'll make a pull request.

00:44:42.838 --> 00:45:06.425
What are your thoughts on having a branch for whatever's in Sandbox, the Sandbox environment, so that we know what's in testing or what somebody's working on a pull request into a test branch to have that code be tested and then, once that passes, have a pull request from the test branch into the main branch for the features that they'd want to bring forward?

00:45:06.425 --> 00:45:15.791
Or would you load code into the test branch from a developer branch and then, once it's completed, do a pull request to bring it into the main branch?

00:45:16.974 --> 00:45:47.192
I still don't get what a test branch is, because I'm developing a development branch, a feature branch, so to speak, and when I'm finished and I'm creating the pull request, the pull request policies attached to Azure DevOps, they just run pipelines based on the newly created code, temporarily merged into the target branch, and this is then tested by running automated tests.

00:45:47.192 --> 00:45:49.456
So what is a test branch?

00:45:50.585 --> 00:45:53.237
Well, I was thinking more of when you had user-based testing.

00:45:53.237 --> 00:45:58.713
Stefan mentioned having the users test some functionality and test some changes Automated testing.

00:45:58.713 --> 00:46:00.577
I'm a huge advocate for automated testing.

00:46:00.577 --> 00:46:01.067
That's a whole.

00:46:01.067 --> 00:46:02.733
We could talk days about that too.

00:46:02.733 --> 00:46:10.112
So, yes, when you create a pull request to get brought into, we'll call the main branch production.

00:46:10.112 --> 00:46:10.809
You could run those.

00:46:11.130 --> 00:46:16.576
All those automated tests should be executed to ensure that they pass as function.

00:46:16.576 --> 00:46:28.018
But all of those automated tests or in some cases, when working for customers or if you're working for an end user, you still have to pass user acceptance testing in some cases.

00:46:28.018 --> 00:46:35.492
So at that point you will have a sandbox environment with changes that are loaded for the users to test afterwards at a point.

00:46:35.492 --> 00:46:43.097
I mean you can't have some automated tests for those, but in this type of environment you still would want to have user acceptance before moving it to production.

00:46:43.097 --> 00:46:48.356
So maybe it's good that you don't have to deal with that.

00:46:48.356 --> 00:46:50.932
Stefan, what are your thoughts on that?

00:46:50.932 --> 00:46:54.416
Do you have to do the same type of process or have you worked with that same type of process?

00:46:56.186 --> 00:46:57.242
Yes, and it's challenging.

00:46:57.242 --> 00:47:00.427
Yes, and it's challenging.

00:47:00.427 --> 00:47:10.612
Through the conversation I tried to think about how that used to be before we were using extensions in the CL days, but I can't really remember anymore.

00:47:10.612 --> 00:47:15.155
So the challenge is really that you have one code base.

00:47:15.155 --> 00:47:24.099
So if you have one testing environment and one test branch and you have multiple features, what are you doing if one feature gets approved but three are still waiting for testing?

00:47:24.099 --> 00:47:24.920