Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm working on quite complicated project, in terms of business-logic quantity and quantity of components.
Each developer mostly works on "his own" component. I understand that this isn't very cross-functional, but it is impossible to know every components' details.
Team sostav changes from time to time. So we have situations when one person have to work on "other person's component". And this can be on periodic basement, so you can come back to the issue a month later - in that moments you can ask component business-logic's owner the same questions again and again, because you simply can forget some tiny but important details a month later.
This situation is annoying sometimes.
We have daily stand-up meetings, when person tells about what he has done and going to do.
We have project's wiki F.A.Q. page - we extract the most frequently asked questions.
What do you think about the problem?
And how would you recommend us to solve it?
given the component nature I'd go with:
1.) A framework document specifying the applications purpose, setup, requirements etc.
2.) Module documents for each component in a common format and indexed by name.
Look at the http://docs.python.org for a good example of general docs and http://docs.python.org/modindex.html for a good example of module/component docs
Oh, and daily meetings are generally bad, they take up a lot of time and answers get forgotten. Newcomers or sick people miss the meetings and have to be re-briefed. It's 100x better to write it all down and keep a paper/email trail unless discussion/feedback is required.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm a React Native Developer from the past 7 months. And this is my first technology I'm working on. So, I recently got to know that there are certain coding rules which I wasn't following and was unaware of. I have two general programming questions.
So I just got to know from an inteview that one should create wrapper functions in their code, by which I can just call a single function which points to a module or a API.
Like wrapper functions, what else is a good practice in programming?
Since I never worked on Android/iOS before and directly jumped to React Native. I often find myself doing trial and erros when it comes to do styling in my application.
Or what is the right way to style an element without giving too much margin/padding, which I assume is wrong. Or what is the right way to style where the styling works the same in all devices. Can someone recommend me a right article or video or something for this styling issue?
This may well be the broadest question(s) on StackOverflow :-). Just a few suggestions for the first question.
1. Read :
Many books have been written, some down-to-earth (Clean Code, The Pragmatic Programmer, Code Complete, Refactoring, ...), some more theoretical (Structure and Interpretation of Computer Programs, ...).
2. Collaborate :
You can sollicit code reviews from colleagues, have pair-programming sessions with them, attend coding dojos or hackathons. All of these are ways to share and transfer knowledge among peers, are very helpful, and almost always fun, too.
3. Play :
Sites like codewars.com are great to let you experiment with huge numbers of coding challenges, risk-free, and with the bonus benefit of seeing the solutions of others (once you're done :-)).
Maybe it's worth posting the second question separately, with the appropriate title. Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
So, I working on a problem at my workplace, that is a big company with a serious CNC shopfloor. Here I thought I could make the life much easier with a little software. I have the conception, I put a lot of work in it together with my helpful friends and here is the point, when I suppose to explain it to my leaders.
The problem is, I've never made anything like this before. So I don't know the way. I should use UML-diagrams and use cases, class diagrams etc? Or which is a preferred way?
Out of the management perspective you could explain why your programm is efficient and required to optimise the workflow. Creating a presentation could help you make the idea of the application clear and bring it in a form which is understandable.
If I were you I will go in priorities for activities diagram. You create an activity diagram of the old flow and another with the new flow. You show both to your manager and you compare them. Normally your program will minimise steps inside the new flow. Then you can say that with less steps to manage there will be more money to earn for your manager and you at the end :)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So, I just started a new job a few weeks back. It is my first job doing software, and I have been tasked with learning how a giant project works. Now, the guy before me left NO (zilch) documentation or comments anywhere in the source code. In addition, he applied basically EVERY design pattern in the famous design patterns book by Gamma, etc...
My question is, how do I start? I have tried setting break points for certain calls that I want to learn (learn bit by bit), but because of the 5 million design patterns employed, every call goes up about 7 levels just to finish, and by then, it's hard to keep track of the 20 some objects being created and used.
Has anyone had a similar experience? A few pointers on different methods to try?
Specs: language - VB.net
IDE - Visual Studio 2010
Using - Windows Forms
Brain - Melting
Inheriting a large project without documentation is always a huge pain in the ass. I hope you have already accustomed your manager to the inconvenient truth that it will take several weeks or even months until you can maintain that project efficiently.
I would start with creating some UML class diagrams. That could tell you a lot about how the system works and which design patterns are used where.
While doing so, I would also add comments to the code with everything I learned about it. When I am not sure if I understood what the code does correctly, I would add a common string like "NOT_SURE" to the comment. Later, when I have a better understanding of the system, I could use a text search to find and revise these comments.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I'm currently developing the front end of a new CMS for a digital streaming company, the main problem the project has is keeping track of the technical language that has sprung up around it.
It currently involves around 60 staff in four countries, aside from a wiki (which has thus far failed to be kept up-to-date), anyone have any good tools or tips for building and maintaining a glossary for a project like this?
aside from a wiki (which has thus far failed to be kept up-to-date)
This comment makes me pretty nervous about suggesting other solutions. Wiki's can come with their own problems, but keeping it up to date is not a problem inherent in the platform. It's a cultural or organizational problem. A wiki provides a very easy way to track and update data. If, today, you cannot keep it up to date, ask yourself how you will solve this problem if you change the tool?
Changing to another platform could solve things like: The wiki isn't scalable for that amount of data; we want to make controlled edits; we need to release in multiple languages; we need to release in other formats.
For the updating problem, try something simple to start, like assigning a dedicated team member to glossary maintenance. They don't have to be the only contributor, but if you have someone who is dedicated to paying some attention to this area you will have a much better chance of keeping things up to date.
In an untended garden, it's not the fault of the soil that you have no flowers.
DITA has a glossary specialization. You can maintain a central company glossary in it. In individual company documents, you create a mini glossary topic then use a content reference to pull any terms you need into your document.
It does sound more like a version control issue though.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am going to be taking over from a developer here at work soon. Hence, I'll be supporting all the applications that he has written over the last few years.
My question is, when supporting an application that you probably don't know much about, what kind of documentation is most helpful to get a handle on how to fix problems, extend functionality, modify functionality, etc? I'm thinking it would need to give you an overview of what the software does, what interfaces it has to other software, what databases it uses, usernames, passwords, and so on.
Is there such a thing as a software support document? Referrals to any templates would be most helpful.
BTW, unfortunately, there are no requirements documents, specs, etc! So, really my question is, if my colleague had a day to write a single document for each application so that I could (more easily) support it, what would that document be and/or what would it look like?
I would ask for primarily some sort of flow chart/schema of the way the app functions.
I would want to be able to know how each file interacts with other files (and the database). So this way, you'd know where to start to fix a bug or add a new feature, etc.
So to do a quick, text mockup of it:
Index.php -> Login.php -> Dashboard.php
Index.php:
Has login box. Submits login into to login.php
Login.php:
Verifies data with database entries, shows error on fail or sends to Dashboard.php
Dashboard.php:
Once logged in this acts as a main menu
Something along these lines? For basic documentation I'd think this is the way to go.
Hope this helps. Good luck!