Jim Bartek is the CEO of Growth Heroes. Control code quality is the topic. He has been a sales, marketing and communication consultant for over 10 years and has worked with dozens of startups as well as major corporations.
Main Points
Jim Bartek joins me to talk about his DX’19 presentation — Easy Clean Code.
I was at the DX’19 conference listening to Jim’s talk and immediately wanted to have him onto the show.
It is not an easy task to control code quality for teams. What tools to select, how to build Continous Integration (CI), how to integrate seamlessly the tools into the CI and make sure it works for each and every single team member. These questions are all answered by Jim!
In addition, I was aghast at Jim’s background. I thought he was just like you and me — yet another software engineer :). It turns out that sales, marketing, and communication are his strong suits while technical stuff is just a “bonus”. I have high regard for him!
Links
- Jim’s twitter handle
- Easy-Clean-Code github repo
- Visual Studio Code
- Illuminated Cloud IDE
- Prettier
- Prettier Plugin Apex
- PMD
- Codacy
Sponsor:
Codacy
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:17] Hi folks. Today's episode is sponsored by Codacy, one of the tools Jim Bartek, our guest, will elaborate in this session. Codacy is the online service that automatically identifies the issues through its static code analysis. It supports over 25 languages, including Apex, and it works seamlessly with the mainstream Git online services such as GitHub, GitLab, and Bitbucket. For instance, if I make an Apex code pull request against my GitHub repo, CodeCyc can analyze the code and push detect the issues as comments. If you want, it can even send the comments to your Slack channel. Think about how much manual work you can really save for your team in the code review process. And by the way, if your team is smaller than four users or your project is open sourced, CodeCay offers a forever free subscription. How cool is that? To get more information, please check Codacy's link in the show notes or visit SalesforceWay.com/Codacy. It's SalesforceWay.com/Codacy. With that said.
[01:26] Let's now dive into the show.
[01:46] Hey everybody! This is Xi Xiao. This is yet another episode of Salesforce Way podcast. Today I'm sitting with Jim Bartek, the CEO of Growth Heroes. Hello, Jim. How are you doing? Good. How are you? I'm good. I'm good. So I invited Jim to be in a show. Is that we actually met in the DX nineteen trip? And Jim, you did a really good presentation there to talk about how to automate, how to do the clean code qualities. That was immediately got me hooked. I wanted to invite you, so you know, talk more into details. What's that about, and share more with our listeners? Yeah, thank you very much. It was a cool little talk. Sure, yeah. Let's start with a little bit background and details. So, so what was the talk content? If you can brief us, and what kind of problems you try to tackle? Yeah. So the talk is called Easy Clean Code, and basically, we were just trying to tackle as a Salesforce consultancy as well as an ISV partner is just you know how do we handle growing our development team. And automating, making sure that we have consistent code quality, and that we're all doing things in in the same format, time and time again. And as we get a new code base for a new client, how do we go about cleaning up that code base in a way that benefits the client and makes it easier to maintain over time?
[03:17] Uh huh. So you wanted to use the tool as much as possible to automate the process, so that there is not much manual work involved in the whole process. Am I right? Yeah, so I mean, there's two challenges. One, you could have a developer or a you know team manager that was spending all their time cleaning the code and reviewing the quality, and doing these things. But there's a good amount of tools out there that help you do it more automatically. And so either the manager could run the tools or the developer could run the tools. But you kind of got inconsistencies, and as we would be under a time crunch, right? You might not do it as often as you should. So we kept looking more towards how let's just automate it, so that way we do it every time, so that we make sure that we're providing that that right code quality. And so it's part the automation with some of the tools that check the quality, and it's also part using templates and frameworks, and agreeing on a standard way to write the code in the first place. All right, and the the sample code is stored in GitHub, right? You have this easy clean code repository. Yeah, it's just GitHub.com/growthheroes/ECC. Okay, so I'll also put that into our show notes for our listener to check afterwards. Great. So, could we start them talking about what tools have you used? Do you think if this is a good topic to
[04:47] follow? Yeah, so I mean, some of the tools that are that are great to use are some of the ones that the new SF DX team is kind of promoting themselves, along with using tools like VS Code or Illuminated Cloud, you know, as an IDE. You can use tools like Prettier, ESLint, PMD. PMD is a really awesome tool for just making sure your Apex doesn't do anything too bad, and the other tools kind of help with linting and help with making sure your your code is formatted properly. Hmm. You mentioned Visual Studio Code. Uh, which IDE do you use personally? Yeah. So I use VS Code. Um. Okay. But the rest of the team uses Illuminated Cloud. So we always have some interesting conversations about you know which one's better and things you can do. Uh. And I I think they're both awesome. Okay. Okay. Yeah. We don't want to go into the IDE fight. Yeah. Um. Okay. So, in addition to the VS Code, you also mentioned some other tools. For example, the Prettier, right? I yeah understand that. That's is like a code formatting tool. Yeah, so there's a tool called Prettier, and you can run it. You know, from the command line, you can run it in your IDE. You can do all these nice things with it. And there's a community-driven add-on for Apex, so you can use Prettier for for Apex. You can use it for for Lightning Web Components, and so you can just download
[06:17] that, install that, and then the nice thing about it is you can you can have it automatically run every time you save a file. Or you can just run it manually inside your IDE with just a shortcut. You can also run it on a Git pre-commit hook, so that way every time you're trying to commit to Git, that it will just automatically run prettier for you. But then as well, you can run it in your CI automation, so that way you make sure it always gets done. Right, so it's really easy to install tool and it and it's really effective. I started to use Visual Studio Code like a year and a half ago. That actually was my first IDE in Salesforce ecosystem. So I have never used the the Force.com IDE, the Eclipse based. I don't know for the Illuminated Cloud or some other tools for formatting the Apex. Was it already there a long time ago? Because I understand the Visual Studio still today it's not all the formatting supported. Yeah, so so I mean, Illuminated Cloud and like Idea has its own code formatter, kind of built in that you can use, and you can configure the rules in it. the The problem that we had is that you can't really, or at least we couldn't find a way to then take those rule settings out of Illuminated Cloud and and use it everywhere. You can do some of the stuff from Idea and Illuminated Cloud on the command line.
[07:47] But still, we want to be able to run it in CI. We wanted our kind of requirement is everything we want to use. We want to be able to the dev needs to be able to do it, and we also need to be able to do it in continuous integration. So prettier just gives you that flexibility where you have a configuration. In your repo, and then everyone uses the same exact rules, versus me having my own formatting rules in Illuminated Cloud, and you having something different. You know, in VS Code. Uh huh. Um. So just to make sure I understand, the prettier is a formatting tool, and somebody in the ecosystem has created the prettier for Apex. It's kind of like a plug-in for the prettier that you can run the command line of prettier to format the Apex for us, right? Yeah. Yeah. You just install you npm install prettier, and then there's also a prettier plugin Apex, add-on. Yeah. Okay. And at the moment, VS Code does not have the feature that when we hit save, then automatically the preview is run. Yeah, I mean, there's some things you can do. You know, you can get further into it with VS Code, and you can change. You know, what happens when you save a file? There's even some other things you can do with SFDX to auto save and deploy a file. So you can control those things. We just kind of wanted to. Step back from the IDE, and focus more on the command line, and focus more on continuous integration.
[09:18] Yeah, makes sense. And also, if the command line is available, then it's a matter of, you know, add that feature into the Salesforce plugin in Visual Studio Code. Yeah, exactly. Yeah, yeah. Okay. And actually, that's a a long waiting feature for me. I've never used the like a code formatting in my Apex coding. I was like manual formatting, and I really hate the. Uh, when people work in the developer console, uh, it has its own way of formatting the code, and it will not use the Visual Studio Code. Especially, I have this editor config plugin, which allow me to define the format of the file. For example, what ender Uh, coded was do I put the extra empty line at the end of the file? Those definitions, then the dev console actually will screw up all these files if you touch it from, from the browser. I mean, I just really annoying that. I really hope everybody can start to use the prettier, which is officially recommended. Understand and then supports in all the. IDE as well as in the Dev Console. Yeah, well, I think everybody's going to get forced this way, right? Because Dev Console is not supporting Lightning Web Components, and yeah, they pretty much said that they they don't have any plans to ever support Lightning Web Components in Dev Console. So we're kind of already in a situation now where you you have to wean yourself
[10:48] off of Dev Console onto some of these bigger tools. So it's a good time to get into all these things and and learn how to do it. Uh huh. Have you worked with the Lightning Web Components so far? Yeah. So we um we switched over the beginning of twenty nineteen. We basically just said if we're going to do any net new pages, you know, or components for people, we're going to try to avoid Visual Force as much as possible, and just do everything in Lightning Web Components. Uh, so that's what we've been doing, and we haven't really. Had to break that rule. We've done everything in LWC so far this year, and there's more and more interest because of some of the, you know, deadlines coming up to move to Lightning, or at least they're going to become more aggressive about moving people to Lightning. So a lot of clients are interested in in having things be Lightning ready and or have their new features created in in Lightning Web Components. Yeah, definitely. And speaking of Lightning Web Components, we are talking about the JavaScript mainly, and of course the Lightning markup. But for the JavaScript, I understand there are much more sophisticated formatting tools, linting tools, right? Yeah, you can. So you can use ESLint and you can use even Jest now to do some testing with Jest for LWC. So you're getting a lot of these tools out of the box. And I just noticed actually, it was really cool earlier this week. I was messing around with the SFDX command line to
[12:19] spin up a new project. We're actually trying to get a client. Out of their org, so a new client we want to work on their code base and just trying to pull it straight into SFDX with the source retrieve instead of doing the metadata command line and you build a new project now with SFDX. If you have it build your project, it will include your in your LWC folder an ESLint configuration and help you get that going right off the bat. So that's really awesome. Yeah, I saw that. Yeah, it's part of like a templating of the new project. Yeah. Um, you also mentioned the PMD. Actually, uh, the PMD, how would I say, importer from the the official PMD to the Apex part. The Robert Sauterman was also in our podcast show before talking about the PMD and clean code. And you said it's a great tool. So how do you use the PMD in your work? Yeah, so we we all him a lot of thanks for the work he did getting to work with Apex and a lot of the kind of unit tests he has for different Apex failures, but and PMD is probably the most important thing actually that we use for our code quality, just because it's really good at tracking. The exact state of your code quality across your entire codebase, and just out of the out of the box rules from for Apex, the Apex rule set is is really handy, and you can take it as a starting
[13:49] point, and then you can break it down and only include the the rules or the rule types that you want in your file. So you get a you know a rule set for PMD that you put in your repo, and if you have that rule set in your in your repository. You can have your IDE like VS Code or Illuminated Cloud just go look for that configuration rule set and use it in the IDE as well. But since it's a rule set in your repository. Then you can also use that for continuous integration and elsewhere, and so you know there's a handful of different categories that you get out of the box for Apex, right? You get like, you know, are these error prone, right? Are these performance issues? Are these you know design issues? Best practices, right? I think there's security in there too, right? And so you can ignore some of them, right? So we might ignore the the design ones, right, at the beginning, or there's a code style, right? So we might ignore some of those when we get a new new customer base because you'll get too many. Errors and warnings. You get like three thousand, you know, errors and warnings, and you are like, well, how much of this are we actually going to clean up for a client? What do they really care about? You know, just because you don't agree with the style, right, doesn't mean you should spend time fixing it. So we'll tend to pare it down and maybe only focus on error prone like performance and security, and look at those issues and and look for certain things. Like it will tell you. How many times you have a SOQL statement inside of a for loop? It'll tell you how many times you have a DML statement
[15:19] inside of for loop. Right? Those are really bad design patterns to be doing database operations inside of a loop. So it'll throw you an error and say, "Hey, you have this problem with your code." So, what we found though is the problem with inheriting someone else's code base is that you could end up with a couple thousand PMD warnings right off the bat. Okay, and if you have a couple thousand warnings right off the bat, you just tend to ignore it. So we kind of go into this issue where it's kind of hard to use PMD because there is too many errors. So you can either cut your rule set down really small, so that you are only focusing on the rules that you care about, or what we started doing is we found with a tool called Codacy. We can actually have it do a diff of the code base and only show us with PMD if the code got better or worse. And so we kind of use that as a starting point to say, hey, we're not going to make your code any worse than it was when we inherited it, and then also we may focus on specific rules to try to eliminate any of those errors, like eliminate any SOQLs inside of loops, for example. So that's really been a cool tool to integrate with as well. Okay, I'll also put the CodeCee link, the homepage, to our show notes. So you you mentioned CodeCee could internally use PMD. For the code validation, is that what you say? Yeah. So
[16:49] Codacy is just a platform that focuses on code quality. And so again, if you have, say, you have your ESLint configuration in your Git repo, and you have your Prettier, and you have your PMD rule set, and you have all this stuff set up in your Git repository, then all you have to do is connect your Git repository to Codacy. And every time you have a commit or a pull request, it will it will run its code quality engine on your code, but it will use your existing configuration files. So that way, again, we have consistency. Where you know if we're doing it in the IDE, if we're doing the command line, if we're looking at code to see, we're using the same rules everywhere. And it will pick up those those files if you have them. The other cool thing about Coda C is that if you don't have them, you can just configure it in the UI in Coda C. But we've kind of stuck to making sure we have configuration files actually in our Git repository. But yeah, so that's a newer tool that we we've been using, and I think it's really helpful just to see. Did that specific commit make the code better or worse? Interesting. I'll definitely try that out as well. Yeah, there's a free version of it, so you can use it for free until you get to be too big of a team. Okay, I got it.
[18:20] Hi, just a quick note here. Don't forget to check the links shared in the show notes, where you can find the guests' contact information and the important complementary materials for each episode. In addition, I'd be so happy if you could share with me what you think about this podcast. You can reach me out by email, Twitter, LinkedIn, or website contact form. Your comments would definitely help me improve and deliver better content. So now let's get back to the show, shall we?
[18:59] And in the Easy Clean Code repository, there was a section talking about the code template and code framework. Could you elaborate on these two points? What does it mean? Yeah. So before we kind of even get into the continuous integration and trying to use tools like PMD for for code quality, you know the first step is just agreeing on what's good code, and also agreeing on. How we're going to continually reuse certain pieces of code. So from the templating side, we look at you know how do you write a trigger? How do you write a trigger handler? How do you write service classes? Right, and we came up with our own agreed upon naming conventions for all of our files. You know, how do we name a trigger? How do we name the handler? How do we do these things? We also came up with our own styles for what should every trigger look like. Right, we want a logicless trigger that doesn't really have any logic in it that basically just says, "Hey, unless I am being bypassed, you know, pass everything to the trigger handler." Right, and so we have a standardized trigger. We have a standardized trigger handler as well, that actually has a class that it that inherits some properties from, you know, a parent class. And then we use that trigger handler, and it already has everything templated out. Already has our comments in it. And so whenever we want to create a new trigger and trigger handler, we just copy and paste. These files, right, and then we we use them, and so that's just from a templating standpoint. Is, hey, let's let's
[20:29] agree upon how we should write this, and instead of writing it from scratch every time, so that's understand. Yeah, so that's a little more basic. Yeah, I guess there's no need to tell our listeners how important the trigger handler framework really is for us. Yeah, and there's there's a couple of cool different models out there. There's other different blog posts on what models people use and why. So there's a couple options you have as guides to pick from. Understand. How about the naming conventions you just mentioned for the variables and for the classes? Does PMD able to to pick that up as well? PMD will do a little bit around you know if you have things like cased properly, like if you have your your classes and your methods properly cased and things like that. But that's kind of about it. You know, it's more of making sure your your methods are named in a logical way that that makes sense and you're. Code is broken out into small enough pieces that you can describe what what that unit of work is is really doing. Yeah. So yeah, it doesn't help too much too much with that part. Yeah. Yeah. Maybe PMD is automating like ten percent of the clean code part, and then ninety percent still is up to the developers and the code review to discover the issues. Yeah, and hopefully, hopefully, you know, you don't need to rely on PMD. To know that you have these issues, but you know everyone is busy. We're doing a lot of work,
[21:59] and so it's just a good kind of stopgap to help the developers say, "Oh yeah, hey, I need to clean this up." Or especially help me, right? As we're going through like an ISV, you know, getting ready for code review, right? We're using PMD to to clean up our code and make sure that we haven't broken any security rules and do all that stuff before we get into like code scanning with Salesforce. So I think it helps for that. Understand, um, I understand in your repository you also talked about the Apex testing. Uh, do you, for example, use the scratch org for the Apex testing, or how do you handle that? Yeah. So for testing, it just depends, you know, on what setup we're in. If we're in an SFDX, you know, full-on scratch org, you know, base like for our app, then yeah, absolutely. You know, we'll we'll follow kind of the standard of when you're ready to test, you just automatically spin up a scratch org, push your code, run all the tests, get the results back, and then. You know, destroy the scratch org and kind of keep it clean slate. Where you're just you're pushing into that org just just to run the tests, verifying that it works, and and getting rid of that scratch org. If it's if it's a client where we're more not not scratch org based, then we'll try to do the same thing with with an extra sandbox, so that we'll push to an extra sandbox before we try to push to production. Understand? Have you tried run the Apex testing
[23:29] in multiple scratch org in parallel just to speed up the things? No, no, that's that sounds that sounds pretty cool though. I want I want to know more about that, but no, we haven't we haven't gotten that involved. I think our Um, our worst case, I think, for a while we had an org that took maybe eighteen minutes or twenty minutes to run all the tests, which isn't which isn't great, but isn't isn't horrible yet. And we were able to speed it up, um, and get that down to about half that time when we kind of realized it was taking that long. Uh, so now we haven't looked at that yet. Yeah, because I've um heard some talks from either our podcast guest or the um like DX or Dreamforce talk, is that some for some big customers they have the unit tests running for multiple hours, even days. So they were trying to use the parallel Apex testing to speed things up. Yeah, that'd be cool with like test suites as well. Maybe we could define like a a set of tests, or you know, get into an advanced package too. We can break up everything into different packages, and then yeah, you only have to test that one package. Yeah, the first step is always you have to split them into the separate packages before you are able to do that. But that prerequisite is already hard enough. Oh yeah. We talked a lot about these pieces, about the tools
[25:00] and how to use them. Can we just put them into one picture so that our listeners could understand from a high level? Maybe it makes sense for us to understand: if I'm a developer in my local setup, what should I do? And of course, on the server side, there's a continuous integration. So, what are the gateways on on the server as well? Could you help us on that? Yeah. So the easiest thing to do if you're just a developer and you and you're trying to sort through this is just with your IDE, you know, get get PMD working. You know, make sure using ESLint if you're if you're doing Lightning Web Components, and try out prettier with the prettier Apex plugin. If you have those things running for you consistently inside your IDE, then you're getting used to the results that it's giving you, and you're getting used to how it's formatting your code and the things that it's kind of complaining about that that you need to avoid in the future. And so that's a really easy place to start, and then it gets a lot harder when you want to actually try to automate it, right, and integrate it. Yeah. So there's a couple easy places to start with that, though. GitLab is just like GitHub if people haven't heard of it, but it has continuous integration built in. Now GitHub has the new actions and kind of workflows, so once that opens up to everybody, you might be able to do the same thing there as well. But. Looking at those two things,
[26:31] and just looking at the continuous integration that's already built into GitLab makes it a lot easier to get continuous integration up and running, because you don't have to authenticate into GitLab. Because it's already in GitLab, right? So it's in your same account. So that is absolutely the easiest way to get started with continuous integration. But you can also use other tools like Circle CI, Travis CI, and Salesforce has a really great tutorial on how to get Circle CI up and running. And I think they also have one on Travis CI as well, if you want to go those routes. But if you're just starting out, I really recommend GitLab with the built-in CI. And then really, what you do, as long as you have these tools like PMD and Prettier Apex and other tools already running on the command line. You just go write that all into a configuration file for your continuous integration, and in my repository there is a command line. You can see like a there's a you know circle CI folder, and you can see in there there's a config. Dot YAML file, so you can see that config for Circle CI, and you can see what we're doing there, and how you know you you define a job essentially, and you say the job is to. You test your code quality, right? And then inside that job, you might download the Salesforce DX command line, and then you'd install the Salesforce DX command line, right? And then you'd start running your different commands, right? So you might then, you know, push your code to an org, or
[28:01] you might install PMD and then run PMD from your. A rule set file that's already in your org. So once you get used to it, it's really easy to understand. But the beginning that configuration file for CI is tricky. So I would really recommend following a tutorial on that. Like I said, the Circle CI one from Salesforce is really good. If you're using GitLab, then they have their own. Configuration file. The one thing I'll note is that we're switching away from GitLab to GitHub in Circle CI, specifically because some of the code quality tools, like Codacy and others, there's like Code Climate. And others just don't work well with GitLab. Okay, and I'm not sure why, but they don't support it unless you're the enterprise tier. So, just know if you want to use some of those code quality automation grading tools, it might be easier to use GitHub. But it's going to be a bit, a little bit of a bigger lift to use GitHub plus Circle CI. Okay. So yeah, if you just stack those in order, right? Just get it all working locally on your computer. Get comfortable with it on your command line. Get comfortable with it in your IDE, and then take what you're doing on the command line, and then just put that all into a configuration file. For continuous integration, and then the last thing you really have to do with that is then just decide when do you want that continuous integration to run, right? Do you run it on every commit? Do you only run it when you have
[29:31] a pull request? Do you only run it on certain branches, right? Like before you push everything to master? Now, there's a lot of ways you can kind of decide what you want to do. Yeah, and. I guess not all our listeners is familiar with the continuous integration or the CI, and just introduce a little bit about that is that it's definitely not rocket science. It's thinking it's like multiple code quality gateways that you can plug into the pipeline before you commit the code to your remote. Repository or push your code into the Salesforce. So it's like a very flexible method. You can plug in whatever tools you want to plug in as long it's supporting the command line. Yeah, the best way I like to think about it is if you're already familiar with using Git and you're already familiar with pull requests, and you're already familiar with having a conversation on that pull request, right? Like your manager or someone else on the team might review your code, peer review it, and give give comments on. Why you added this? Why you got rid of this? You know what's going on with your code to to review it and make sure that that it's nice. Well, with continuous integration, you basically the goal is the same thing, except for automated, right? So when you have a pull request instead of. Me commenting on there, saying, "Hey, you know, you you missed this. You had a loop here inside of a
[31:01] you know SOQL inside of a loop. You know, you don't want to do that." Then PMD is just going to automatically do that, and there will automatically be a comment on your pull request saying, "Hey, you have a SOQL inside of a loop." As a comment on your pull request for you, so that gives you that feedback right before that pull request gets merged. It's basically getting automatically reviewed. That's where I see the most value of it there, but. Then it's still kind of late in the game, right? You know, you should have already fixed those issues before it got there. So it's more just like a catch at the end. You don't really want to rely on it. You want to not have those issues in the first place. So, so the one part is reviewing the code, right? Continuous integration makes it really easy to automate that. But the other part, like you're mentioning, is automating, running all your tests, getting those things to pass. And again, if you have those really large orgs, right? Like you're talking about days, oh my gosh, or or you know, tens of hours to run your tests, right? Yeah. You don't want to you don't want to forget to run them, and you don't want to have to try to manually run them on you know, ten different orgs. So with continuous integration, you could just say, "Hey, every time there's a pull request against you know our dev branch." Just go ahead and split it out across ten scratch orgs and run all the tests, and then return the results and automatically put it in there. And then as a dev, you know, hey, just just submit a pull request. And everything else would just happen, you know, auto magically,
[32:31] right for you. So it saves a lot of time as well when you get to those more complex orgs. Definitely. All right. Thanks, Jim. I think we can close the session almost now. Do you have something else to say before we let you go? Oh, just thanks so much for having me on the show. I think it's awesome. Really appreciate getting the chance to talk at TDX about this as well. I'm really passionate about it, so I just love talking with other people and seeing what people are doing that's better than what I've figured out so far. By no means is easy, clean code the end all be all, but it's a decent place to start. It's really good to have you on the show, Jim. Yeah, thanks so much. Bye, bye.
[33:20] Hey, this is the end of the show. If you enjoyed the content, please connect with me and let me know your thoughts. All my contact information is available on the website at SalesforceWay.com. Thanks for listening. See you next time.
