Term Analysis on PHP project

[francescobianco]

Hey there, fellow developers and tech enthusiasts! 👋

Let's dive into a topic that's often overlooked but holds immense importance in the world of PHP development: Term Analysis. 📊

In the ever-evolving landscape of software engineering, our codebases are like living organisms, growing and evolving over time. But have you ever paused to consider how critical it is to analyze the keywords and terms used within our projects? 🕵️‍♂️

Why Term Analysis Matters

Think about it: as we code away, we use words and phrases that have specific meanings within the context of our business logic. These terms are the building blocks of our applications, representing the core functionalities and processes that drive our projects. But what if these terms start straying off course? 🤔

Imagine a scenario where developers use generic or out-of-scope terms that sound familiar but aren't aligned with the business logic. This can lead to misunderstandings, confusion, and even misguided decisions during refactoring, updates, and future development phases. 😱

The Power of Alignment

By conducting term analysis, we gain a powerful tool to ensure that our codebase's language aligns with our business domain. We can distinguish between crucial domain-specific terms and more generic terms that might seep in. This alignment minimizes the risk of misinterpretation, errors, and potential pitfalls down the line. 🚀

Unleashing the Potential

Term analysis doesn't just prevent confusion – it can also foster collaboration. Developers can speak the same language, comprehend each other's intentions, and make informed decisions based on a shared understanding of key terms. This synergy between code and concept paves the way for innovation and seamless project evolution. 💡

So, let's open up the discussion: How do you view term analysis in your PHP projects? Do you think it's a vital practice to ensure code and business logic are in harmony, or do you have a different perspective? Share your thoughts, experiences, and insights below! Let's unravel the impact of term analysis together. 💬🔗

Here's to coding smarter and speaking the language of our applications! 🌐👩‍💻👨‍💻

#TermAnalysis #CodeIntelligence #PHPProjects #BusinessLogic #TechTalk

Looking forward to your valuable opinions and insights!

Cheers,
Francesco Bianco

[RayPooley]

francescobianco
No developer has time for this.
Certainly no client is ever going to have time for it and a developer's time is the client's money.
"Smart"ness doesn't only apply to programming.
It applies to the design of the system as a whole.
Decisions about scalability, flexibility, reusability make the difference between well vs badly structured systems.
The program layer is just one part of the system.
But let's focus on that since that's the main topic here.
Specifically on reusability.
Well written structured code is modular code.
It's based on a few simple principles.
First of all is maintenance. If you need to alter the logic you should only have to do it in one place,
Second is lean coding. If a line of code doesn't add value to the program simply don't add it.
Third is clean coding. Coding that's easy to read, maintain, understand and change through structure and consistency yet remains robust and secure to withstand performance demands.
If a coded process is required more than once in an application then it should be defined as a function.
A function that can be called more than once whenever it is needed.
A function that converts date formats or calculates lapsed time would be a good example.
But if a function performs a task that is specific to one program then it can be defined within that program and called as many times as required.
If a function performs a task that is required across multiple programs then it can be defined in a seperate module file and the module can be imported by each program that requires it making the code available to the program.
This is particularly the case in object orientated programming where many global functions/methods might typically be incorporated within a single class that can be referenced and instantiated in programs and passed around at run time from one program to another.
My point is this.
Simply counting the absolute number of times a word or term appears in the raw code, particularly when it comes to functions and modules, tells you nothing about the number of times whatever that term refers to is referenced at run time because that depends on the logical structure of the system.
Term analysis doesn't matter.
Structural analysis is what matters.

[Weedpacket]

Making sure that everyone agrees on what the words they use mean is important, but that's a requirement for the business as a whole, not software development, and it's only the responsibility of IT in the same very broad sense that includes paperclips under "information technology".

[RayPooley]

Weedpacket
In 1994 a book was published by "The Gang of Four". "Design Patterns: Elements of Reusable Object orientated Software".

It essentially tried to establish some design standards with regards to the structure of OOD systems and OOP.

It is described a "influential" and I suppose it was in a sense. But when you look at the recommendations in detail to be fair they are basically common sense. They recommend designs that any logically minded person would come up with on their own. Indeed I think the team's strategy was to scour thousands of programs looking for what they considered good coding and bad coding (structured vs unstructured) and gathering together what they considered to be examples of the good. So it wasn't anything they had invented, so to speak, since the good stuff was essentially other peoples' code. They simply offered an opinion. The opinion that this good approach should be adopted as a standard.

But the thing is the emphasis was on structure not wordage. It would be absurd to expect all programmers to use the same terms for similar elements in their program code. What matters is that they use meaningful terms so that the term conveys what that element represents in the program.

You could ask a thousand people to draw a picture of a tree and you would get a thousand different pictures. Some good and some not so good. But from a structure perspective they should all have the same features and in the correct layout. Roots at teh bottom that look like roots, a trunk in teh middle that looks like a trunk, branches and leaves on the top that look like branches and leaves. If the leaves are on the roots then that's a problem.

I would point out, however, that nobody (client or employer) in the last 30 years has ever quizzed me on design patterns at interview. They have always looked at my code and logged on to my systems and made their mind up on the basis of those.
Proof of the pudding as it were.

[Weedpacket]

RayPooley In 1994 a book was published by "The Gang of Four". "Design Patterns: Elements of Reusable Object orientated Software".

Yes, I am familiar with it; it was an adaptation of the pattern language from architecture.

When I was writing clinical software, the entities in the "business logic" and what to call them were very well specified indeed; if they weren't, people would die. But it wasn't for us to specify them, since they came from the application domain. We just had to use them (correctly). I think that's the terminology that was intended in the emoji-ridden generic OP that reads more like something from a linkfarm (it's not very well-written; for example, it doesn't actually say what "term analysis" is — believe me, the irony is not lost on me). Whether you care about the difference between a Visitor or Strategy pattern or not is neither here nor there.

[RayPooley]

Weedpacket
There are times when a "term" search is necessary of course.

But there are pretty much standard ways of doing that already.

I don't know if you were around for the Y2K issue in the run up to the turn of the century 1999 - 2000.
The concern was that elapsed time calculations in legacy programs would suddenly break systems
because they only used the year component of the calender year to calculate the number of years.

I worked in a corporate bank at the time and there were 3710 legacy COBOL programs in their
banking systems. CICS and batch. It was my task to make sure that they would survive the turn of the century.

Any date calculation on any platform, you would think, would involve some function / method / property of a native DATE object. So it was just a matter of trawling the source code for references to those functions / methods / properties to find where they were.

There 823 programs where the date calculation code was embebbed in the program, I was surprised at how unstructured the system was. They had been around for while.

Anyway, I just wrote a module that contained all the date functions required, modified each program to include the module and changed the apporopriate embedded code to use the fucntions in the new module.

Took 4 months.

Y2K came and went without incident I'm glad to say.

But it goes to what I said earlier. Structure matters.

Modularity is the most important consideration when designing maintainable and flexible systems.

[Weedpacket]

Yes; I am familiar with the Y2K problem. I was there.