How do I outsource software development

Developer corner


Other (Delphi) - Professional software development


Heiko - Tue 07/10/07 7:32 p.m.
Title: Professional software development


Hello,

I want to develop a bigger project for the summer parties now. That in itself is not the problem, but I would like to do it in such a way that it can be easily expanded later, etc. Hence the question: How do you develop software professionally?
So how big are parts of modules? E.g. current user (below PHP typical): rights and session in the user module directly in, or as submodules, even if they were only 100 lines?
How do the modules communicate with the GUI? Can you access it directly or just process it and the GUI then outputs the results itself?
With the latter I now have the case that I don't know how it would be cheapest (for this reason I also opened the thread here;)): I have a panel where you can change user data. But there are 2 different lists where you can select the user and where data would have to be adjusted. How would you best approach this?
The problem I have is that the units would cross each other, which Delphi does not allow (the module would need a public var, but at the same time the module wants to access the public form class).

And what does prof. Software development still to be considered? I have already built in a unit for constants (basically like a CSS file, only that was compiled in) and a unit for long files so that it is uniform (if 5 buttons have the same caption, I can do them the same way change in one fell swoop).

greetings
Heiko



Coder - Tue 10.07.07 8:07 p.m.


You should also use CVS or something similar
http://de.wikipedia.org/wiki/Concurrent_Versions_System



alzaimar - Tue 07/10/07 10:52 p.m.


Hi Heiko,

First of all: there is no such thing as 'professional' software development. Only good and bad. You definitely want to create good SW. I don't know if my SW is good.

So I would always develop the individual classes in such a way that no one can 'hack' them, i.e. make them crash. Of course you can smear any insantz if you want, but if you define exactly how your input and output parameters have to be structured ('Design by Contract'), then that’s something. Within these limits, your methods should work perfectly clean. Don't be afraid to throw an exception when something is wrong.

Furthermore, I would think about 'quality' in the broadest sense. Quality in the SW means: Your code / class must

-readable
-easy
-reusable
-robust (inevitably follows)

be. For each class, just think about whether you have to show it to forum members ('Code Review') and sell it. With this in mind, you automatically build proper classes. But you already know that.

You should clearly separate presentation (GUI) and functionality (objects). Ideally, a dialog represents a class and each button represents a specific method of the class or a refinement of the dialog (e.g. a button 'Edit details').

Class functionality has no place in dialog modules.

I would do without data-sensitive controls. They are suitable for small, simple Frickeltools or for RAD prototyping (this is what Delphi was originally developed for). I use it to maintain master data. In my projects there is always a 'Control Center' that provides the basic tables (lookup lists, language settings, etc.) for editing. Well, otherwise not.

Hmmm. Is there anything else? Sure, but you ask so many questions that my head is spinning.

Structure that a little (for old sacks like me)

But your resolution is real: agree:



Agawain - Tue 07/10/07 11:07 p.m.


Hm

@alzaimar, why no db sensitive controls?

I always quarrel with myself, on the one hand I see in practice that they are taking control of me ... although in this regard I have devexpress almost firmly under control: wink:

However, the form in which I then have to adjust some composites in order to get certain events is
again * yuck. As I said, I don't particularly like the event handling.

I only doubt that I would be much better off with a DevExpress StringGrid.

greeting

Aga



Sidorion - Wed 11.07.07 8:17 am


Have a look at the two software development stuts here [http://wiki.delphigl.com/index.php/Tutorial] (pretty far down on the page).



Decipaitor- Wed 11.07.07 11:49 am

alzaimar wrote the following:


First of all: there is no such thing as 'professional' software development. Only good and bad.


What nonsense.
1. Professional software development is initially only software development with which money is to be earned - therefore professional, what comes from profession = profession
2. It would be really wonderful if there was only good and all bad software development. Because then you could say exactly: that is good and that is bad. That way you would have quickly sorted out the bad species and the world would be ideal.
So no, of course there are also gray areas. After all, there is no such thing as a panacea. Some processes and procedural models are almost ideal for some tasks, although there are also tasks that make them look very bad.

Now to software development:
First of all, software development is not just about pure programming. No, that only makes up a relatively small part. Before that comes the analysis, specification document, design document. Only then does the implementation take place. After that and in between, the systematic tests are included. Then comes the integration and acceptance (+ tests).


Heiko- Fri 10.08.07 17:19

So, I now had enough time to read through the Tuts from Sidorion (I've already read a lot of Tuts from there, but not all of them (and some seem to have forgotten too;))).


I will probably not use SVN for the project yet, as my experience so far is that you normally don't go backwards. I only use SVN if it is a project where several people are working on it or if it is a php project, where I only upload the files that have really changed and thus I do not overlook any files (I use the phpBB AbiForum from me like that;))


alzaimar wrote the following:
First of all: there is no such thing as 'professional' software development. Only good and bad. You definitely want to create good SW. I don't know if my SW is good.


Dezipaitor wrote the following:
alzaimar wrote the following:
First of all: there is no such thing as 'professional' software development. Only good and bad.


What nonsense.
1. Professional software development is initially only software development with which money is to be earned - therefore professional, what comes from profession = profession
2. It would be really wonderful if there was only good and all bad software development. Because then you could say exactly: that is good and that is bad. That way you would have quickly sorted out the bad species and the world would be ideal.
So no, of course there are also gray areas. After all, there is no such thing as a panacea. Some processes and procedural models are almost ideal for some tasks, although there are also tasks that make them look very bad.


I see it as a mixture of both;).
Professional software development is software development in which even large projects (a few thousand lines and classes) you can still keep track of the code and understand it easily. This is mostly inevitable with professionals, and also with some freeware developers, but unfortunately not much. So I agree with both of them here;).

Dezipaitor wrote the following:
Now to software development:
First of all, software development is not just about pure programming. No, that only makes up a relatively small part. Before that comes the analysis, specification document, design document. Only then does the implementation take place. After that and in between, the systematic tests are included. Then comes the integration and acceptance (+ tests).

Yes, I am familiar with this process (we have had it often enough in the InfoLK). An Excel table was used as an analysis and specification document for me, where I have so far practiced what I would like to do next with the software (only much more user-friendly and more functional (more statistics, etc.)).

alzaimar wrote the following:
So I would always develop the individual classes in such a way that no one can 'hack' them, i.e. make them crash. Of course you can smear any insantz if you want, but if you define exactly how your input and output parameters have to be structured ('Design by Contract'), then that’s something. Within these limits, your methods should work perfectly clean. Don't be afraid to throw an exception when something is wrong.

I don't think much of exceptions directly. I prefer to prevent the error right from the start or output it via normal messages. So that messages are not thrown from the core, but from the GUI (I hate try blocks: twisted:)

alzaimar wrote the following:
Furthermore, I would think about 'quality' in the broadest sense. Quality in the SW means: Your code / class must

-readable
-easy
-reusable
-robust (inevitably follows)

be. For each class, just think about whether you have to show it to forum members ('Code Review') and sell it. With this in mind, you automatically build proper classes. But you already know that.

That is the main goal for me. The most difficult thing to read is that it is legible (I always take too few comments). We once did a little CodeReiew during our internship. The only problem was that the others didn't speak the language that well and therefore didn't always understand what I was doing (a lot with pointers).


alzaimar wrote the following:
You should clearly separate presentation (GUI) and functionality (objects). Ideally, a dialog represents a class and each button represents a specific method of the class or a refinement of the dialog (e.g. a button 'Edit details').

That is the main concern of this thread - how to do this in the cheapest way.

Class functionality has no place in dialog modules.

alzaimar wrote the following:
I would do without data-sensitive controls. They are suitable for small, simple Frickeltools or for RAD prototyping (that's what Delphi was originally developed for). I use it to maintain master data. In my projects there is always a 'Control Center' that provides the basic tables (lookup lists, language settings, etc.) for editing. Well, otherwise not.

I generally think that most of it lies with the GUI objects, because VirtualStringTree literally tempts you to do it. However, I want to try to make it so that there is a core that can cope without it. I hope that works with my project;).

alzaimar wrote the following:
But your resolution is real: agree:

If you want to study info at some point, you should get used to something like that as soon as possible;).



So now to the open question. Small (unasked) questions were answered by the Tuts. What is left is:
  • How many classes do you put in a unit (so what, in your experience, is the optimum in terms of scope)
  • How can you get Delphi to have 2 classes that cannot communicate with each other in different units?


For the last point the following example would be:


Delphi source code

1:
2:
3:
4:
5:
6:
7:
8:
interface
...
TForm1 = ...
public
SubClass: TSubClass;
end;
...
implementation



Delphi source code

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
interface
...
TSubClass = ...
public

end;
...
implementation

TSubClass. ...
begin
Form1. ...: = ...;
end;


Or does everything inevitably have to go to the main class?

greetings
Heiko


alias5000- Fri 10.08.07 7:30 p.m.

Heiko wrote the following:
[*] How many classes do you put in a unit (so what, in your experience, is the optimum in terms of scope)

I would structure this in such a way that it makes sense. So basically a module, i.e. a thematic unit in a unit, as long as it makes sense and is readable. If the unit gets too big, the module can be distributed over several units

greeting
alias5000


Luckie - Fri 10.08.07 7:57 pm


So I would start with something small as an exercise to get a feel for OOP thinking. Then you notice pretty quickly that the main work happens in your head, with the development and interaction of the classes. Programming the Ds is then just pure hard work on the keyboard.

Just yesterday we had a similar case in the Delphipraxis: http://www.delphipraxis.net/topic116000_oop+funktion+einer+oberklasse+von+einer+unterklasse+aus.html my solution for the problem arose from this: http: //www.delphipraxis.net/topic116050_memory+spiel.html
Above all, read my own quote from the second link. Then you will see that the rest will almost take care of itself.



Heiko - Fri 10.08.07 21:21


I plan to do the same as you do there - for the core. My problem has to do with my general programming style.
In fact, I usually store the code from the forum lar in extra classes so that it is clearer. Because with the composites you still get a lot of parameters that I don't need. That's why I've got used to outsourcing and only handing over the important things. Without this peculiarity I don't see a problem, but I just don't like the finished parameters from Borland;).



alias5000 - Fri 10.08.07 21:45


Maybe not the most common programming style;)
But if you pack these classes into the GUI, then a core / GUI separation should be possible (but what functions do these classes have?: Gruebel :)

greeting
alias5000



Heiko - Sat 08/11/07 5:50 p.m.


* grumble * I'm slowly despairing of Delphi (maybe it's also because you don't know the problem with PHP;)). I have a GUIManager in one unit and the UserManager in another unit. But because of this s ** t crossover it doesn't work. And I don't want to pack everything into one unit, because otherwise it would have a few thousand lines ... Isn't there a nice variant?

@ Luckie: As you did it with your Proggi, unfortunately I can't do it. Because the GUI should not be generated at runtime;).



Christian S.- Sat 08/11/07 5:52 p.m.

Heiko wrote the following:
I have a GUIManager in one unit and the UserManager in another unit. But because of this s ** t crossover it doesn't work. And I don't want to pack everything into one unit, because otherwise it would have a few thousand lines ... Isn't there a nice variant?
New question -> new thread


Heiko - Sat 08/11/07 5:54 p.m.


@Christian: That's part of the question (see first post);)



Christian S. - Sat 08/11/07 6:00 PM


Your initial posting will likely have ten questions. As long as none of them should be discussed in detail, but only serves to clarify what you are about - okay. But doing the detailed discussions in one thread is not useful or desirable.




Developer-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2021 by Christian Stelzmann All rights reserved.
All contributions come from third parties and may not violate applicable law.
The developer corner and the associated websites expressly distance themselves from third-party content of any kind!