Reddit 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.

Computers & Technology
Books
Computer Programming
Software Design, Testing & Engineering
Software Development
Software Engineering: A Practitioner's Approach
Check price on Amazon

3 Reddit comments about Software Engineering: A Practitioner's Approach:

u/CSMastermind · 4 pointsr/learnprogramming

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


  1. Cracking the Coding Interview: 189 Programming Questions and Solutions
  2. Programming Interviews Exposed: Coding Your Way Through the Interview
  3. Introduction to Algorithms
  4. The Algorithm Design Manual
  5. Effective Java
  6. Concurrent Programming in Java™: Design Principles and Pattern
  7. Modern Operating Systems
  8. Programming Pearls
  9. Discrete Mathematics for Computer Scientists

    Junior Software Engineer Reading List


    Read This First


  10. Pragmatic Thinking and Learning: Refactor Your Wetware

    Fundementals


  11. Code Complete: A Practical Handbook of Software Construction
  12. Software Estimation: Demystifying the Black Art
  13. Software Engineering: A Practitioner's Approach
  14. Refactoring: Improving the Design of Existing Code
  15. Coder to Developer: Tools and Strategies for Delivering Your Software
  16. Perfect Software: And Other Illusions about Testing
  17. Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application

    Understanding Professional Software Environments


  18. Agile Software Development: The Cooperative Game
  19. Software Project Survival Guide
  20. The Best Software Writing I: Selected and Introduced by Joel Spolsky
  21. Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
  22. Rapid Development: Taming Wild Software Schedules
  23. Peopleware: Productive Projects and Teams

    Mentality


  24. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
  25. Against Method
  26. The Passionate Programmer: Creating a Remarkable Career in Software Development

    History


  27. The Mythical Man-Month: Essays on Software Engineering
  28. Computing Calamities: Lessons Learned from Products, Projects, and Companies That Failed
  29. The Deadline: A Novel About Project Management

    Mid Level Software Engineer Reading List


    Read This First


  30. Personal Development for Smart People: The Conscious Pursuit of Personal Growth

    Fundementals


  31. The Clean Coder: A Code of Conduct for Professional Programmers
  32. Clean Code: A Handbook of Agile Software Craftsmanship
  33. Solid Code
  34. Code Craft: The Practice of Writing Excellent Code
  35. Software Craftsmanship: The New Imperative
  36. Writing Solid Code

    Software Design


  37. Head First Design Patterns: A Brain-Friendly Guide
  38. Design Patterns: Elements of Reusable Object-Oriented Software
  39. Domain-Driven Design: Tackling Complexity in the Heart of Software
  40. Domain-Driven Design Distilled
  41. Design Patterns Explained: A New Perspective on Object-Oriented Design
  42. Design Patterns in C# - Even though this is specific to C# the pattern can be used in any OO language.
  43. Refactoring to Patterns

    Software Engineering Skill Sets


  44. Building Microservices: Designing Fine-Grained Systems
  45. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools
  46. NoEstimates: How To Measure Project Progress Without Estimating
  47. Object-Oriented Software Construction
  48. The Art of Software Testing
  49. Release It!: Design and Deploy Production-Ready Software
  50. Working Effectively with Legacy Code
  51. Test Driven Development: By Example

    Databases


  52. Database System Concepts
  53. Database Management Systems
  54. Foundation for Object / Relational Databases: The Third Manifesto
  55. Refactoring Databases: Evolutionary Database Design
  56. Data Access Patterns: Database Interactions in Object-Oriented Applications

    User Experience


  57. Don't Make Me Think: A Common Sense Approach to Web Usability
  58. The Design of Everyday Things
  59. Programming Collective Intelligence: Building Smart Web 2.0 Applications
  60. User Interface Design for Programmers
  61. GUI Bloopers 2.0: Common User Interface Design Don'ts and Dos

    Mentality


  62. The Productive Programmer
  63. Extreme Programming Explained: Embrace Change
  64. Coders at Work: Reflections on the Craft of Programming
  65. Facts and Fallacies of Software Engineering

    History


  66. Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
  67. New Turning Omnibus: 66 Excursions in Computer Science
  68. Hacker's Delight
  69. The Alchemist
  70. Masterminds of Programming: Conversations with the Creators of Major Programming Languages
  71. The Information: A History, A Theory, A Flood

    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.

  72. Peter Norton's Assembly Language Book for the IBM PC
  73. Expert C Programming: Deep C Secrets
  74. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming
  75. The C++ Programming Language
  76. Effective C++: 55 Specific Ways to Improve Your Programs and Designs
  77. More Effective C++: 35 New Ways to Improve Your Programs and Designs
  78. More Effective C#: 50 Specific Ways to Improve Your C#
  79. CLR via C#
  80. Mr. Bunny's Big Cup o' Java
  81. Thinking in Java
  82. JUnit in Action
  83. Functional Programming in Scala
  84. The Art of Prolog: Advanced Programming Techniques
  85. The Craft of Prolog
  86. Programming Perl: Unmatched Power for Text Processing and Scripting
  87. Dive into Python 3
  88. why's (poignant) guide to Ruby
u/jj2parkie · 2 pointsr/androiddev

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.

u/zweischeisse · 1 pointr/jhu

These are what I had. Different professors might use different books, obviously.