legacy code: how to approach

1.2.1. user classification

1.2.2. information gathering methods

1. informal
   

   Conversations with people in person or remotely.

2. formal
   

   Long, planned interviews in person or remotely, with the session recorded. I'm just helping to prepare a longer written statement for one of the application's users, for example, a user of a company's CRM. Requesting the user to demonstrate how they use the application and its functionalities, identify any issues, and suggest solutions.

   Recording audio-video conversations is invaluable for later reviewing and processing the entire conversation. After processing, I present him with the compiled ideas, opinions, and conclusions, requesting review, corrections, addition of any overlooked details, and consent for publication. After obtaining consent, I delete the video material, and include the interview in the documentation as an official user statement for the application. This serves as the basis for further actions in application design.

1.3.1. code whose execution generates data

1. how many rows are there in a given table?
   

   Depending on the age of the application, if it's new, there might be very few rows in each table. Therefore, the more critical question becomes:

2. when were the last rows added to a given table?
   

   Probably there is some information specifying the data creation date, such as column created_at (timestamp) or you can create such a column. Depending on the creation time of the data, we need to infer whether, if the most recently created data in the table is very old, it is worth examining this functionality and considering why it is not being used and if we can remove it.

   1. query example: SQL documentation
      

      Using a text file org you can write an SQL query in a text editor and execute it on the production database, placing the result directly in the documentation. Later, this can be exported to any format, such as HTML, which is exactly how this post was created in HTML format.

      When performing database analysis, I record my thought process: I save queries, data obtained, and conclusions. For clarity and documentation purposes, this constitutes documentation for others and myself.

      For a simple example, I am including the database queries below - the exact query I executed and its results.

      SELECT
          table_name,
          table_rows
      FROM
          information_schema.tables
      WHERE
          table_schema = 'fighterchamp'
        AND table_type = 'BASE TABLE'
      ORDER BY
          table_name;
      

      table_name	table_rows
      user	1000
      tournament	10
      info	0

      In summary, I would write something like this: Based on the query from [2024-06-03 Mon] executed on the production database, I conclude that the 'info' table does not contain any data. This serves as a basis for revising the code in this area and evaluating its usefulness for the user – dead code, probably nobody uses it.

1.3.2. code whose execution does not generate data

1. overall
   
   1. based on HTTP requests - logger
      

      Logging most of the HTTP requests. Depending on required information, this typically includes the path, controller and action names, user and role. You can store results in a file, database or to put it on the queue, it depends on the user load. I prefer to store results in database because it's easy to implement and results can be query by SQL.

   2. based on PHP
      

      There's a special PHP extension that provides a way to track if a piece of code is actually invoked - https://github.com/krakjoe/tombs.

2. selective
   

   When, due to performance considerations, it's inadvisable to enable all logging or when only a few suspicious areas exist, logging can be added in specific locations. This can verify if users visit a specific page or invoke a given action, such as a product purchase.

   This approach has earned its own term: 'tombstone'. A logger is responsible for logging the location it was called from and the time it was invoked. This information is logged to a special file. Dates are added to each log entry for convenience, such as 'Log::('2024-05-26')'. The resulting log entry would appear as '2024-05-26 UserController::showAction()'. A short (5-minute) presentation on this topic is available in David Schnepper's Ignite talk, "Isn't That Code Dead?".