Reddit reviews Software Engineering: A Practitioner's Approach
We found 3 Reddit comments about Software Engineering: A Practitioner's Approach. Here are the top ones, ranked by their Reddit score.
We found 3 Reddit comments about Software Engineering: A Practitioner's Approach. Here are the top ones, ranked by their Reddit score.
I've posted this before but I'll repost it here:
Now in terms of the question that you ask in the title - this is what I recommend:
Job Interview Prep
Junior Software Engineer Reading List
Read This First
Fundementals
Understanding Professional Software Environments
Mentality
History
Mid Level Software Engineer Reading List
Read This First
Fundementals
Software Design
Software Engineering Skill Sets
Databases
User Experience
Mentality
History
Specialist Skills
In spite of the fact that many of these won't apply to your specific job I still recommend reading them for the insight, they'll give you into programming language and technology design.
Although, I am not a professional (currently, I graduated high school this year, and I am taking a year off before university to recover my health), from what I learned and applied, your planning should be first dependent upon how much time you have to deliver the project and the extent of communication you have with the risk holders.
Ideally, if you have a great amount of time and extent of communication, you might want to adopt a unified process model in a waterfall manner such that you do all your planning in the beginning. First, scope the project to understand what the risk holders' general objectives are for the project. Second, adapt the scope to determine the user classes for the required Android application. Third, by defining your user classes, write user cases for them. The user cases help generate required system features and processes. These processes help you generate story boards regarding how the user should execute a user case which ultimately helps you design your views. Fourth, research the software and hardware constraints in regards to implementing the system features. This step allows you to prioritize what features you will implement first and how you might test them. (Don't forget to research operating system quirks between various Android versions and the interfaces the risk holders require.) Fifth, verify with the risk holders the priority of the required system features. Sixth, begin your high-level design. The extent of this step is dependent upon the quality of the prior steps. If you have a great grasps of the requirements for the project and they are invariable to change, design your architecture and then components. UML diagrams should be used again if you have a great understanding of the project. All of the above steps regard the aspect of modelling in a software development process. I ignored any planning for quality management.
Unfortunately, you may lack time or great communication with risk holders (i.e. unresponsive feedback and continually changing requests). If so, I wouldn't follow all the steps above since it takes a while and you don't want your time to be wasted. Follow a rapid prototyping process or the agile process. I don't have much to say about them. They are nice.
Importantly, like everyone said, high-level design is very important. For my first Android application, my application's architecture and components were so poorly designed that my core logic was too coupled with my views and my components did not achieve a level of abstraction required for ease in refactoring. Thus, when it came time to implement new features or fix old features, it would take too much time.
If you have to work with databases, schema migrations can be hellish (I felt like crying in the inside when I learned about schema migrations). From the words of almighty Jake Wharton: "I hate it all. Schema migrations, content providers, content values, uri matchers, cursors, column interfaces, sql builders." Thus, do special planning if required with databases.
Some blog post I found (It seems very interesting. I haven't tried it yet): http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/
Finally, a really nice read if you ever have the time, Software Engineering: A Practitioner's Approach: http://www.amazon.ca/Software-Engineering-A-Practitioners-Approach/dp/0073375977
Please take what I typed with a grain of salt, I just started programming for Android in October, so I too am trying to find out the best practices.
These are what I had. Different professors might use different books, obviously.
I didn't actually use or even buy the books for SoftEng and did fine. The other two classes relied heavily on problems from the book for homeworks.