1 2 Previous Next 19 Replies Latest reply on Jul 23, 2016 7:13 AM by wimdecorte

    Code review for developer teams ?  See changes ?

    binu.alexander

      When working wtih anohter developer in a team .. is there anyway to know what changees he/she has made to do code review ?

       

      I know there is no official version control .. but any workarounds ... advice  ??

        • 1. Re: Code review for developer teams ?  See changes ?
          Johan Hedman

          You always have the Database Design Report (DDR) that you can export and import into Base Elements and do the Comparison Report to see changes rom last DDR

          • 2. Re: Code review for developer teams ?  See changes ?
            jrenfrew

            Or do a DDR comparison with FMPerception for Geist Interactive

            1 of 1 people found this helpful
            • 3. Re: Code review for developer teams ?  See changes ?
              binu.alexander

              Thanks ... will see the demo version

              • 5. Re: Code review for developer teams ?  See changes ?
                CICT

                We tend to use internal procedures.

                 

                All scripts have a 'changelog' entry at the beginning, under which a dated note is entered for each amendment using an agreed format that gives date, who and brief description. Then any changes made also have a notes entry using the same date/who entries, which makes searching with 2EmpowerFM useful.

                 

                As we're on data separation model, we have a versioning layout where changes are recorded at an overview level and versioning/numbering.

                 

                We all have our own internal time sheets where more detailed notes are kept.

                 

                We also have an FM 'projects' database where objectives are recorded and marked off when completed, this is the main system we use for reviews.

                 

                Other than that, DDR and related tools are available as suggested earlier.

                 

                Regards

                Andy

                • 6. Re: Code review for developer teams ?  See changes ?
                  beverly

                  ... Compares FileMaker Pro Files And Lists Differences

                  beverly

                  2 of 2 people found this helpful
                  • 7. Re: Code review for developer teams ?  See changes ?
                    CICT

                    Hi Beverly

                     

                    To date we've not needed these type of products due to the way we develop as a team on the cloud. Do any offer a clue as to who made the changes listed, or is it just a list of changes between the compared files?

                     

                    Thanks

                    Andy

                    • 8. Re: Code review for developer teams ?  See changes ?
                      beverly

                      you are looking for a GitHub type of version control?

                      beverly

                      • 9. Re: Code review for developer teams ?  See changes ?
                        CICT

                        Not really, just curious. We have our own systems that work for us, but always keep an open mind to alternatives.

                         

                        binu.alexander was asking about reviewing code working with another developer and with all the recommendations above I was curious whether these actually allowed that, or whether each person has to volunteer that a particular change was their own.

                         

                        Kind regards

                         

                        Andy

                        • 10. Re: Code review for developer teams ?  See changes ?
                          coherentkris

                          IMHO the ROI for FM code reviews (scripting and custom functions are about all that makes sense inside a file)is minimal.

                          • 11. Re: Code review for developer teams ?  See changes ?
                            beverly

                            I don't know Andy, if FMdiff knows who-did-what. I just keep good notes on what I change! I add my name and the date to wherever I can (in the calcs and scripts). This helps me when I go back to something, as well. I also print DDR and/or scripts and field definitions before (and after) any major changes. Again for my own sanity. I also run BACKUPs (labeled appropriately) before any major changes.

                             

                            beverly

                            • 12. Re: Code review for developer teams ?  See changes ?
                              CICT

                              Sounds like we're at one there. 2EmpowerFM is very useful for finding changes by date if you're consistent with your date format and we always initial changes with a brief description, both at the start of a script and at the point of change.

                               

                              We're always developing on a separate version with the dev UI file a version ahead of the live one, upgrades take about 60 seconds and downgrade available if needed in the same timescale.

                               

                              We work on objectives rather than code normally and review with each other to ensure we haven't missed anything or a better way of doing something. I'm not sure lists of information could provide that level of quality assurance, although of course they have their place.

                               

                              Time to return to the mouseface

                              Andy

                              1 of 1 people found this helpful
                              • 13. Re: Code review for developer teams ?  See changes ?
                                binu.alexander

                                Thank you all for the useful insights .... let me shed some light on my case ..   I usually dont do team development and was managing myself for 2 years.. last 2-3 months i have got an additional developer to work on a larger project ... Since he is not onsite ... He is actually working on the development copy of the file on my server .. No issues there .

                                Just that sometimes he writes code which i need to approve or modify or completey reject ...  So I am looking for what changes he made since I reviewed last ..   I have regular backups ..

                                 

                                All the options suggested above all are paid so I need to make a call as to which one to purchase a single user license 

                                 

                                1) FM Diff  ($399)

                                2) FMPerception ($499)

                                3) BaseElements ($499)

                                 

                                Cost is a major issue for our team right now .. so maybe if someone could tell us advantages of any of the above specific tool over the other if would be  useful !

                                • 14. Re: Code review for developer teams ?  See changes ?
                                  philmodjunk

                                  My personal policies for managing script changes goes like this:

                                   

                                  Note the change in the Header block of comments at the start of the script. This shows name, date and a brief description.

                                  If the change is "small", I "encapsulate" the change in comments like this:

                                   

                                  #7/22/16 Phil Begin Change

                                  new steps here

                                  //disabled original steps here

                                  #7/22/16 Phil End Change

                                   

                                  That way, if a problem is discovered after the change is enabled, we have the ability to rapidly roll back the code by disabling the new steps and enabling the old.

                                   

                                  For larger changes, I dupe the entire script and modify the duped copy's name to include a "delete on date" usually one month in the future. In this case, we can revert code by deleting all steps from the working copy and then copy/pasting the entire script from the duped back up copy.

                                   

                                  My basic rule of thumb is that if any developer on the team that encounters the encapsulating comments and disabled code is free to delete the begin/end comments and disabled code if the change is at least a month old. (We can always restore from back ups, this is to just make it easy to spot, review and revert recent code changes.)

                                   

                                  The same goes for duped copies of a script that was more extensively changed. If the delete on date has passed, we then delete the dupes copy to minimize the "clutter".

                                  1 of 1 people found this helpful
                                  1 2 Previous Next