CSC321.01 2016F, Class 22: Course Wrapup ======================================== _Overview_ * Preliminaries. * Admin. * Upcoming Work. * Questions. * The subject matter(s) of the course. * Listing Topics. * EOCE. * Debriefing. * Student comments. Preliminaries ------------- ### Admin * Pre-break PSA. ### Upcoming Work * Essays! ### Good Things to Do * Get enough rest. ### Questions The Subject Matter(s) of the Course ----------------------------------- * Conceptual: Getting you to think about the design of software. * Concrete: A variety of tools. * Compromise: Particular partterns and practices and .... Important Points: Sam's View ---------------------------- * Core to software development is *communication*: With clients, with fellow developers, etc. * Agile methodologies have shown great success by relying on a few key principles and practices: * Short iterations with regular communication with the client * User stories as a focus. * Test-driven development * Regular check-ins with the team * Refactoring * Focus on working code that you will then extend/adapt. * .... * The various agile principles and practices work to build a greater whole. * Studying the designs of experienced designers can help you design better. These designs are now encapsulated in patterns. * MVC * Factory * ... * Software development also incorporates a variety of small and large practices, such as having development and release servers and using tools to propagate from one to the other. * Software development benefits from a wide variety of tools, tools that you should (eventually) know well. * It takes time and practice to become a good developer. * It is helpful to understand data modeling. * You have a responsibility to think about the ethics of your work. Debriefing ---------- See the form at . *What topics should we add before you fill out the form?* Fill out the form! Glance at the results Course Evaluation ----------------- You know the drill. * I'll leave the room while you fill out the evaluation form. * Grab me when you are done. * If you have extra time, read the student comments (eboard or outline) or look at the data from the class. * Someone needs to bring it to the Science Division Office after class. Debrief ------- *What do we see in the statistics on the form?* * Some people want more class time to do things / less discussion * Most people want more homework (or more spread out homework)! * Concern that there's just not enough time to learn the things that we are learning. (The joy of two-credit, half-semester courses.) * Sam should give more practice on Ruby stuff. * Sam should make students close computers. * Frankencourse - Pulls together lots of things. But helpful to know that there's a huge world of things that we should know. * Consensus is overrated. * More time on ethics ; more debate * Maybe use the first few weeks of 322 learning Rails. * Maybe the time of familiarizing yourself with the project simultaneously is good. * Returning students could be mentors or could have side projects or just refresh .... Important Points: Student Views ------------------------------- * Relational database management systems. * Behavior driven design (and TDD) * Forming tests based on what the client wants and developing your program to suit their minimum needs first makes sure that you and the client are on the same page as much as possible. * I hadn't thought of TDD as a design method before and it helped me write code in smaller chunks to get one function working at a time instead of getting bogged down in big-picture hypotheticals. * Automated testing is both important, and convenient for anyone who might be using your code in the future. Understanding how to write good tests is essential to being a good developer. * Even if you don't implement TDD, make sure you know how to test your code and plan your code around behaviors it should exhibit. * Code smells * These are some very simple identifiers that will help your code be more correct and look more elegant at the same time. * Refactor! * Keep your code DRY. * Pay attention to the ethics of Computer Science. * I didn’t realize there were a set of “rules” until this class. Even if you choose to abide by them or not, be aware of what people will expect of you. * Agile programming * especially iteration goals, point systems, pair programming, quick daily check-ins, and the idea of developing in small chunks (user stories) so that you always have a working, adaptable code base * Design Patterns * Even though it is important to learn how to solve problems on your own, because many problems you will face in your career have been solved by previous programmers, it is not only okay to look at their solutions, but it is actually good practice to learn from them and use them in your own code as long as you cite where you got your material. * Model-View Controller * User Stories * Effective to handle client expectations * Software Life Cycle * Legacy Code * I think most of us will end up working with legacy code at some point and knowing a good procedure for wading through it and figuring it out will be very helpful. I would have liked to get some more practice doing so in a more guided and structured environment, or watching someone experienced figure out legacy code. * Ethics * I think we just need to be hit over the head with ethics sometimes. Perhaps multiple times. If there have been ethics portions of the required courses before, either I wasn't mature enough as a person or as a computer scientist to appreciate them. Now seemed like an effective time to me to introduce them. * Ruby * Ruby's meta-programming abilities are super interesting. Understanding how to use these may make programming in Ruby easier. * General design points * One of the most useful things in writing a program is organization. Like writing an essay, it is much easier to write a program if you start with a strong outline. * Software development isn't as simple as just writing code and testing it. Depending on who you are developing for and your objectives, designing the code may be more complicated than just laying out a couple quick sketches. * When I was younger, I thought the key to being a good programmer was simply being able to learn new languages and systems quickly. However as I get older, I'm starting to realise that simply being able to learn what's there isn't as important as being able to evaluate the tools and overall concepts at hand, and then applying them to the problem. This is related to the pattern and antipattern concepts discussed recently. * Write code conscientiously! If you're writing code in industry, it would be potentially / definitely used by people/updated. Write clean, DRY, efficient code that can be updated and make sure it's readable and understandable. Cannot stress the importance of this enough. Don't make your code legacy code. * Make your code neat and comment everything, not just for others, but for yourself. Legacy coding is important, don’t be a pain to your successor or future you. * Usually if you are having a problem with figuring out how to approach a problem, someone else has had a similar problem and another person has most likely come up with a common solution that can help you solve the issue. * One important aspect of working in a group, especially with coding, is that although you should split up the tasks so that each member is not working on the same code at the same time, it is also important to constantly be checking in with other members to ensure that you know what they have changed, why they have changed it, and to confirm that they have not made any errors with their fixes.