Hi Kevin,

Hope you are doing well

In our project we do it manually maintaining in excel spreadsheet , like for x feature team mate A made changes in xyz screen action and added abc client action. and the lead reviews the updated code and provides feedback on code.

Regards,

Swapnil

Hi Kevin,

I've always seen code reviews as a people problem - the architecture dashboard and a list of best practices are great tools, but people problems are best solved with communication. Depending on how large a feature you're reviewing is, sometimes it's as simple as sitting down and having a chat with a peer in order to understand what was developed, and more importantly, why.

The flow I used in my last project was simple enough. When features were selected for development, they couldn't reach user testing until they were reviewed (in order to prevent users from accepting something that could potentially be refactored). Once a feature was ready for reviewing, at least one team member would be available to walk through what was developed, and we'd go over the extent of the feature.

I've tried to do it in the past like you mention - adding notes to problematic sections of modules, but I feel that this leads to a sense of "not my problem, someone else will fix it", especially in large teams and if your modules have multiple developers. By sitting down and talking with specific authors, you're adding a sense of accountability and responsibility to each developed feature. You can of course keep your own notes and double check the refactor results afterwards, but I feel that leaving TODO notes in modules is very easy to ignore. You can combine this with whatever tracking tools you use in order to get a feel of the current status (JIRA, for example), but in my experience, personally delivering feedback and letting specific authors take charge of refactors leads to better results.

Hi Kevin,

Please try Architecture Dashboard where you can view all the issues related to code. Please see below link to get more details about Architecture Dashboard. I am sure this feature will help you. 

https://success.outsystems.com/Documentation/Architecture_Dashboard/Introduction_to_Architecture_Dashboard

Thanks & Regards,

Sachin

I have tried different approaches, but on my latest project, we used the following:

Have on the Stories a field labeled "Solution" to record what the developer did and where she/he did it.

After finishing the development the person would write down her/his report without forgetting to state the full path(s) to the change(s) (eSpace > Screen/Action > ScreenAction > ...)

When the report was complete, the story would move to "Waiting for review" and another developer would pick up the "Do review" sub-task and move the story to "In Review".

If "issues" were found, the reviewer would create sub-tasks on the story and assigned those to the developer. Again, it was necessary to state where the "issue(s)" was/were found and, maybe, put some screenshots. If needed, the developer and the reviewer would do a meeting to clarify things and share ideas.

The advantages of this approach were: 

• There is always, at least, two team members knowing why and how something was done.
• There is more sharing of Outsystems knowledge between team members.
• We could search in Jira for all stories that changed a screen/action.

It's important to state that having the solution in Jira wouldn't mean the code wouldn't have comments; in fact, part of the reviewer's task was to be sure the more complicated logic had the necessary comments.

I hope this helps!

Regards,

Ricardo

hi Kevin,

We add the changes done to the code in a Jira subtask like what espace, which action and what changes were done are maintained there and also we add comments in the code where changes are done and then the peer manually reviews the code following Outsystems best practices and also refers to the Jira subtask for the changes and has discussion with the person who made the changes if required.

Regards,

Shilpa Uppund

As of now only manual process with the help of some tools like above shared by team members

Waking up an very debated topic... 

Architecture dashboard gives you a good indication of your factory quality, although if you are looking to prevent technical debt, enable and engage in peer-reviews and promote sharing & collaboration of best practices

The "low code review" might just be what you are looking for.

Low code review - Outsystems Forge

Hi Wenchester,

On my projects, I normally ask the developers to check each other work and I do sanity checks once in a while, this enables the responsibilization of the team and they will learn to do the code correctly.

Hope it helps,

Ricardo Pisco.

Hi Wenchester,

Did you get the chance to try the "low code review" ?

Would be great to hear your feedback about it !

Thanks !

Pedro Abreu

what have people found to help Pre Code Review?

My thought is -if there is good clean code, would reviews be quicker/easier, or even necessary?

any experience with BDD or TDD?  Are they successful proactive approaches?

we are a small team, with each developer dedicated to 1 application.  While they are willing to help out if someone gets stuck, they are hesitant to deep dive and review someone's code.  

We implemented a development freeze to concentrate on AI, and clean up and stabilize code for applications already in production, and hopefully come up with some lessons learned for future applications.  

communication is an essential factor, however, I don't want to bog them down with too much admin work (Jira, meetings, etc).

I will check out the low code review, haven't yet but definitely will.

Hi Linda,

In my experience, particularly in (half) remote teams, code reviews are fundamental for 2 reasons.

1. They will enable technical growth, knowledge sharing, broader exposure & experience to your developers.

As your team is not in the office all the time, those points may compensate the continuous growth of your developers as if they were constantly together. It may also help bring "everyone on the same page" on various technical subjects.

2. Improve code quality and prevent technical debt, since you will no longer have developers doing the wrong thing for a long period of time.

While code reviews are not intended to focus on functional details, review cycles will generally improve the technical practice and mindset of developers and deliveries.

That's for reviews, I'll let someone else shed some light on BDD and TDD.

A great new year !

Pedro Abreu

@Amir Prince Code review