py_project_inventory

NAMESPACE: me.hegland-lance.dev.apps.py_project_inventory

PURPOSE: Python script to catalog Python project directory, summarizing directories, modules, classes, functions, lines, and characters. Lines and characters could be an estimate of development output. Modules, functions, directories, and classes could be an estimate of organization and modularity.

.

Table of Contents

• Features
• Background
• Known Issues
• Requirements
• Installation
• Configuration
• Usage
• Contributors
• Roadmap
• License

.

Features

TODO: Outline key features.

• End-User Features
  • Creates summary of Python development project assets that can be used to better understand the following:
    • development effort (e.g. lines and characters);
    • development modularity, organization, and sophistication (e.g. functions, modules, directories, classes);
    • developed capabilities; and,
    • opportunities and roadmaps for future development (e.g. simplification, modularization, organization, extension).
• Development, Maintenance, and Use
  • Clear, Readable, and Consistent: Designs and code are easy to read and understand; use meaningful variable and function names, adhere to consistent styles and conventions, plus include comments and documentation to explain complex logic or algorithms. This helps all development team members to be more familiar with how things are structured and named, making it quicker and easier for the team to work on various parts of the application when troubleshooting, debugging, maintaining, or expanding.
  • Simple: Designs and code is regularly reviewed and intentionally simplified to avoid unnecessary complexity and over-engineering, making them easier to test, debug, and maintain. This also reduces the likelihood of introducing bugs.
  • Robust and Error-Handling: Designs and code are robust in the face of unexpected inputs or conditions. Both handle errors gracefully and provide meaningful error messages or logging to aid in debugging.
  • Modular: each code module is self-contained; can be easily understood and maintained as a standalone unit. Each module has a clear purpose and well-defined interface with other modules, as needed. This promotes code reusability and makes it easier to replace or upgrade individual components.
  • Documented: Clear and up-to-date documentation exists, including inline comments, function/method documentation, and high-level architectural documentation. This makes it easier for all team members to understand and use the designs, code, and overall application.
  • Testable: Dependencies on external systems and services are intentionally minimized. Hooks and mocks are intentionally created for testing purposes. As a result, code modules can be quickly and easily tested in isolation with unit tests, integration tests, and other testing methodologies.
  • Efficient: Algorithms are optimized, unnecessary computations are minimized, and performance bottlenecks are avoided. This ensures that each module and overall application performs its intended purpose in a timely manner, without excessive resource consumption (e.g. CPU, memory, disk space, etc.).
  • Maintainable: Designs and code are clear, simple, and modular, therefore, developers can easily make changes or enhancements with minimal risk of introducing new issues.
  • Scalable: Designs and code are intentionally reviewed for load balancing, caching, and distributed architectures to ensure they perform well given changes and larger workloads.
  • Flexible and Extensible: Design patterns, abstractions, and interfaces are used to improve flexibility and extensibility. This makes future changes easier because they don't require significant modifications to existing designs or code.

.

Background

Development motivated by desire for the following:

• summary of a development project, an inventory and map of development assets (e.g. functions, modules, directories, classes);
• estimate of development metrics, such as the following:
  • effort (e.g. lines and characters); plus,
  • modularity, organization, and sophistication (e.g. functions, modules, directories, classes); plus,
• compareable development snapshot to better understand a project's evolution;

.

Known Issues

TODO: Identify known issues.

• Primary Known Issue
  • Secondary Known Issue
  • Secondary Known Issue
  • …
  • Secondary Known Issue
• Primary Known Issue
  • Secondary Known Issue
  • Secondary Known Issue
  • …
  • Secondary Known Issue
• …
• Primary Known Issue
  • Secondary Known Issue
  • Secondary Known Issue
  • …
  • Secondary Known Issue

.

Requirements

TODO: Identify requirements.

• Primary Requirement
  • Secondary Requirement
  • Secondary Requirement
  • …
  • Secondary Requirement
• Primary Requirement
  • Secondary Requirement
  • Secondary Requirement
  • …
  • Secondary Requirement
• …
• Primary Requirement
  • Secondary Requirement
  • Secondary Requirement
  • …
  • Secondary Requirement

.

Installation

TODO: Identify installation steps.

1. Review README.md.
2. Satisfy minimum requirements.
3. Installation Primary Step
   1. Installation Secondary Step
   2. Installation Secondary Step
   3. …
   4. Installation Secondary Step
4. Installation Primary Step
   1. Installation Secondary Step
   2. Installation Secondary Step
   3. …
   4. Installation Secondary Step
5. …
6. Installation Primary Step
   1. Installation Secondary Step
   2. Installation Secondary Step
   3. …
   4. Installation Secondary Step
7. Complete configuration.

.

Configuration

TODO: Identify configuration steps.

1. Complete installation.
2. Configuration Primary Step
   1. Configuration Secondary Step
   2. Configuration Secondary Step
   3. …
   4. Configuration Secondary Step
3. Configuration Primary Step
   1. Configuration Secondary Step
   2. Configuration Secondary Step
   3. …
   4. Configuration Secondary Step
4. …
5. Configuration Primary Step
   1. Configuration Secondary Step
   2. Configuration Secondary Step
   3. …
   4. Configuration Secondary Step
6. Review usage instructions.

.

Usage

TODO: Identify usage steps.

1. Review README.md.
2. Complete installation and configuration.
3. Complete usage steps for specific use case below:
   • Use Case 1
   • Use Case 2
   • …
   • Use Case N

Use Case 1

TODO: Describe use case.

1. Use Case Primary Step
   1. Use Case Secondary Step
   2. Use Case Secondary Step
   3. …
   4. Use Case Secondary Step
2. Use Case Primary Step
   1. Use Case Secondary Step
   2. Use Case Secondary Step
   3. …
   4. Use Case Secondary Step
3. …
4. Use Case Primary Step
   1. Use Case Secondary Step
   2. Use Case Secondary Step
   3. …
   4. Use Case Secondary Step

Use Case 2

TODO: Describe use case.

1. Use Case Primary Step
   1. Use Case Secondary Step
   2. Use Case Secondary Step
   3. …
   4. Use Case Secondary Step
2. Use Case Primary Step
   1. Use Case Secondary Step
   2. Use Case Secondary Step
   3. …
   4. Use Case Secondary Step
3. …
4. Use Case Primary Step
   1. Use Case Secondary Step
   2. Use Case Secondary Step
   3. …
   4. Use Case Secondary Step

Use Case N

TODO: Describe use case.

1. Use Case Primary Step
   1. Use Case Secondary Step
   2. Use Case Secondary Step
   3. …
   4. Use Case Secondary Step
2. Use Case Primary Step
   1. Use Case Secondary Step
   2. Use Case Secondary Step
   3. …
   4. Use Case Secondary Step
3. …
4. Use Case Primary Step
   1. Use Case Secondary Step
   2. Use Case Secondary Step
   3. …
   4. Use Case Secondary Step

.

Contributors

• Lance Hegland, (lance.hegland@gmail.com)

.

Roadmap

TODO: Outline roadmap.

1. Improvement Primary Step
   1. Improvement Secondary Step
   2. Improvement Secondary Step
   3. …
   4. Improvement Secondary Step
2. Improvement Primary Step
   1. Improvement Secondary Step
   2. Improvement Secondary Step
   3. …
   4. Improvement Secondary Step
3. …
4. Improvement Primary Step
   1. Improvement Secondary Step
   2. Improvement Secondary Step
   3. …
   4. Improvement Secondary Step

.

License

TODO