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
Me and my friend started working together as partners , we have decided to make Kick-as* website after website.
We have the ideas written down like 100's of them (yes we are choosing best and easy among them first).
My friend does the layout design and arranging things , and my part is coding and server management.
The little problem i am facing is lack of experience in planing a project. What i do is, I just start the code straight away and along with code I make DB, like when i need a table i make it.
I know this is very bad approach for a medium sized project.
Here at stackoverflow i saw lots of experienced coders. Need to learn a lot from you guys :) .
So can you plese help me on how to plan a project and what coding standard/structure/frameworks to be used (I do PHP code).
Thanks in advance.
Start by defining the scope. Write a paragraph to a page and try to describe your website. A top-down approach would be to start thinking of functionality you'd like to implement and refining it by adding more detail.
A top-down approach (is also known as step-wise design) is essentially the breaking down of a system to gain insight into its compositional sub-systems. In a top-down approach an overview of the system is first formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements. A top-down model is often specified with the assistance of "black boxes", these make it easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms or be detailed enough to realistically validate the model.
http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design.
There are many other approaches, however.
http://en.wikipedia.org/wiki/Software_project_management#Software_development_process
Again, the most important step is to be able to put your idea in words; before you can adequately do that, I wouldn't even consider starting to write one line of code.
Regarding coding standard/structure/frameworks I recommend zend framework coding standard, MVC structure, and Zend Framework.
A brief guide for a MVC architecture. The idea is tho help you remember ideas (while your brain is steaming code) and have documents for future programmers.
Design the database. Make an ER diagram. Put it in a document.
Briefly describe reasons behind the design for the important issues (why you choose a polymorphic relation, why use this view, what selects you expect that are more trickey etc.). This will change as you code (and there is nothing you can do). Document the changes. To cope with the changes, use a versioning system for the database like rails migrations.
Design the structure of your website (sections, pages, links, page-flows etc.). Document it. (like: "the site 2 sections, this section is made of ..." etc.)
Based on this make a document describing your controllers and views. ( "a controller for articles, with a list view, and article view, also edit and create views but just for admins" etc).
Describe how you are going to enforce authentication and authorization (on controller and view level). Who is allowed where.
Describe how you protect against the main web-attacks (xss, csrf) where required. (example: "i escape all my view variables using htmlentities for xss protection and ...")
Design your models and side functionality (sending emails, background jobs etc.). These will be the bulk of code. Document each and describe the main issues (for example how timezones are to be handled, how this certain model is to connect to the currency service, how that model is to parse and manipulate some crone file, what algoritm you shall use to decide top 5 articles, depending on your app.) Describe what libraries you use, how, and for what purposes (example: "we are to use curl to scrap SO and make rss feed")
Describe how you protect against the main web-attacks where required (sql-injection, xss).
As you code, things change. Your knowledge about the discrete works of your system evolves and you start to improve the design based on the new found enlightenment. Document your changes.
A few thoughts from someone who loves abstractions.
Figure out what your websites will have in common. Once you have identified the main commonalities, look for frameworks or libraries that deal with as many of them as possible (besides filling your other criteria), such as the boilerplate DB code.
For the common features that you can't find any ready-to-use code (they always exist in customized websites) you'll have a chance to write a common library to be used across your websites yourself. This could be a template for your markup, a JavaScript library or a reusable server-side component, or all together.
Based on your description it sounds like you are enjoying great freedom in the creative process (versus getting a requirements spec handed to you and asked to implement it). I'd say don't over plan either, "just starting to code right away" is a lot of fun and not all bad. Experience will be your best friend, and by the time you reach website #100, you'll have lots of it. When building your second website, your experiences with the first one will help you avoid making some of the mistakes you made, and you'll discover new similarities that you did not anticipate in the planning phase. Just make sure to take the time, move the common code to a single library, and go back and edit your first website to use it. Do this a few times over and you will have learned lessons that are worth a lot.
Related
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 11 years ago.
Improve this question
For the past weeks I can't stop thinking about the architecture of a CMS I have to develop shortly. First of all I want to answer to the possible first questions that you could ask me.
Q: Have you read the similar questions on StackOverflow?
A: Yes, I have. Unfortunately none applies to what I have to ask.
Q: Why would you want to code another CMS???
A: Well, this is a bit of a long answer. Long story short: it has to be closed-source and it has to meet the requirements I need (it won't be 100% a CMS, it's a much more delicate subject - any project developed with it will be somewhere between 60-70% CMS and the rest will be custom code for that project's specific needs)
Tools of the trade:
PHP
Zend Framework (my personal choice; I'm very familiar with it and I won't change it for this task whatsoever)
What I need this "CMS" to be
Developer oriented
Since it won't be a pure 100% CMS it has to be developer oriented - easy to maintain, easy to develop against (more like the feeling when developing on an enterprise level framework)
User/Editor oriented
While working on a project like this one, any programmer might find himself going in a wrong way and not thinking the person who'll work as an editor using this CMS is not in fact a very technical person. This is the part where conflicts happen - if it's not simple to use, yet powerful enough, you will have a lot of problems to deal with.
i18n & l10
I'm almost certain it will be kind of a difficult task to code something both developer and user oriented and if I won't achieve this, I would like to give more importance to the developer instead of the editor. I am aware it's not a good deal to ignore the actual user of the software, but this CMS has to be fast to develop against.
Possible architecture patterns
1. General object
The first architectural design that got me thinking was the following:
I define a general object. The user/admin goes in the administration area and defines the data object he needs. Easy one.
The object page (for example) has a title field, a body field and a slug. It was just defined by the user and now he can create content based on this "data structure". Seems pretty neat, but I still didn't solve some of this architecture's problems.
How will those dynamic objects will be stored in the database? Should I use a dataTypes table, an objects table and link them many to many via objectProperties table?
Or maybe should I serialize them and store everything in the objects table?
Should I give the user the possibility to create new dataType properties and add them to its objects?
How will I i18n all of this?
Isn't too complicated to force the user to define its own data structures?
Will it be too messy if it will have a lot of data structures defined, multiple languages? Would it be still manageable?
2. Extreme developer oriented - scaffold data structures
Today I found myself thinking about this possibility. It would be pretty neat to define the data structure of an object in a yaml or ini file and then scaffold it's database table, model and CRUD. Also mention it's relations to other "data structure" objects to get the right CRUD implementation (think about page data structure and category data structure, for example).
Unfortunately this made me also think about several possible problems.
Will I be able to code such a scaffolding tool on top of Zend Framework? (which is known to be lacking scaffolding if we except the 2 or 3 suggestions made by the community, like this one)
Is too stupid to create 2 tables for each object so I can internationalize it?
Would it be too strict on the user if he can't define new data structures without the programmer?
Conclusion
I'm still very confused on how to approach this subject and what architecture to choose. At this very moment both are pretty challenging in terms of development.
My questions are pretty straight-forward.
If you would have to choose one of this approaches, which would it be and why?
Can you maybe suggest a more interesting pattern to follow, considering my needs?
Just some general advice, if you are really trying to manage free-form content then I would stay away from relational databases for storing your data and go with an XML solution. A relational database has too much structure for something that is purely content oriented. Think of a home page... You have info displayed like: welcome notice, about us, who we are. That doesn't really map well to a table / collection of tables especially when you start adding / removing some of those items. Something with a defined structure, like stack overflow, does map well to a relation datbase however.
Take a look at Day CMS, Apache Sling, Java Content Repository for some ideas.
http://www.day.com/day/en.html
http://sling.apache.org/site/index.html
http://en.wikipedia.org/wiki/Content_repository_API_for_Java
From my point of view more options are always a problem. Users are mostly ignorant, when it comes to complex systems. Therefore I'd stick with the developer-oriented solution. Developer will decide what kind of content can be displayed. Optionally I would allow some kind of "open" content - for power users, allowing complex CSS/HTML/JS. Complex content like photo galleries, user profiles, etc. should not be designed by BFUs.
So to sum up - main feature - creating pages that can be dropped anywhere in the structure (that should be very flexible). If they want user profiles, you can create a new type of page. But at the end of the day, BFUs can do anything with enough time. It depends on the price/time scale. If they can pay for it and need it fast, they will make you create a new user profile page type, taht will be easy to fill. If they are kinda poor, they'll choose to setup all by themselves using normal page and WYSIWYG :D
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 6 years ago.
Improve this question
I'm rewriting a big website, that needs very solid architecture, here are my few questions, and pardon me for mixing apples and oranges and probably kiwi too:) I did a lot of research and ended up totally confused.
Main question: Which approach would you take in building a big website expected to grow in every way?
Single entry point, pages data in the database, pulled by associating GET variable with database entry (?pageid=whatever)
Single entry point, pages data in separate files, included based on GET variable (?pageid=whatever would include whatever.php)
MVC (Alright guys, I'm all for it, but can't grasp the concept besides checking all tutorials and frameworks out there, do they store "view" in database? Seems to me from examples that if you have 1000 pages of same kind they can be shaped by 1 model, but I'll still need to have 1000 "views" files?)
PAC - this sounds even more logical to me, but didn't find much resources - if this is a good way to go, can you recommend any books or links?
DAL/DAO/DDD - i learned about these terms by diligently reading through stack overflow before posting question. Not sure if it belongs to this list
Sit down and create my own architecture (likely to do if nobody enlightens me here:)
Something not mentioned...
Thanks.
Scalability/availability (iow. high-traffic) for websites is best addressed by none of the items you mention. Especially points 1 and 2; storing the page definitions in a database is an absolute no-no. MVC and other similar patterns are more for code clarity and maintenance, not for scalability.
An important piece of missing information is what kind of concurrent hits/sec are you expecting? Sometimes, people who haven't built high-traffic websites are surprised at the hit rates that actually constitute a "scalability nightmare".
There are books on how to design scalable architectures, so an SO post will not be able to the topic justice, but some very top-level concepts, in no particular order, are:
Scalability is best handled first by looking at hardware-based solutions. A beefy server with an array of SSD disks can go a long way.
Make static anything that can be static. Serve as much as you can from the web server, not the DB. For example, a lot of pages on websites dynamically generate data lists out of databases from data stores that very rarely or never really change.
Cache output that changes infrequently, and tune the cache refresh.
Build dynamic pages to be stateless or asynchronous. Look into CQRS and Event Sourcing for patterns that favor/facilitate scaling.
Tune your queries. The DB is usually the big bottleneck since it is a shared resource. Lots of web app builders use ORMs that create poor queries.
Tune your database engine. Backups, replication, sweeping, logging, all of these require just a little bit of resource from your engine. Tuning it can lead to a faster DB that buys you time from a scale-out.
Reduce the number of HTTP requests from clients. Each HTTP connect has overhead. Check your pages and see if you can increase the payload in each request so as to reduce the overall number of individual requests.
At this point, you've optimized the behavior on one server, and you have to "scale out". Now, things get very complicated very fast. Load-balancing scenarios of various types (sharding, DNS-driven, dumb balancing, etc), separating read data from write data on different DBs, going to a virtualization solution like Google Apps, offload static content to a big CDN service, use a language like Erlang or Scala and parallelize your app, etc...
Single entry point, pages data in the
database, pulled by associating GET
variable with database entry
(?pageid=whatever)
Potential nightmare for maintenance. And also for development if you have team of more than 2-3 people. You would need to create a set of strict rules for everyone to adhere to - effort that would be much better spent if using MVC. Same goes for 2.
MVC (Alright guys, I'm all for it, but
can't grasp the concept besides
checking all tutorials and frameworks
out there, do they store "view" in
database? Seems to me from examples
that if you have 1000 pages of same
kind they can be shaped by 1 model,
but I'll still need to have 1000
"views" files?)
It depends how many page layouts are there. Most MVC frameworks allow you to work with structured views (i.e. main page views, sub-views). Think of a view as HTML template for the web page. How many templates and sub-templates inside you need is exactly how many view's you'll have. I believe most websites can get away with up to 50 main views and up to 100 subviews - but those are very large sites. Looking at some sites I run, it's more like 50 views in total.
DAL/DAO/DDD - i learned about these
terms by diligently reading through
stack overflow before posting
question. Not sure if it belongs to
this list
It does. DDD is great if you need meta-views or meta-models. Say, if all your models are quite similar in structure, but differ only in database tables used and your views almost map 1:1 to models. In that case, it is a good time for DDD. A good example is some ERP software where you don't need a separate design for all the database tables, you can use some uniform way to do all the CRUD operations. In this case you could probably get away with one model and a couple of views - all generated dynamically at run-time using meta-model that maps database columns, types and rules to logic of programming language. But, please note that it does take some time and effort to build a quality DDD engine so that your application doesn't look like hacked-up MS Access program.
Sit down and create my own
architecture (likely to do if nobody
enlightens me here:)
If you're building a public-facing website, you're most likely going to do it well with MVC. A very good starting point is to look at CodeIgniter video tutorials. It helped me understand what MVC really is and how to use it way better than any HOWTO or manual I read. And they only take 29minutes altogether:
http://codeigniter.com/tutorials/
Enjoy.
I'm a fan of MVC because I've found it easier to scale your team when everything has a place and is nice and compartmentalized. It takes some getting used to, but the easiest way to get a handle on it is to dive in.
That said definitely check your local library to see if they have the O'Reilley book on scaling: http://oreilly.com/catalog/9780596102357 which is a good place to start.
If you're creating a "big" website and don't fully grasp MVC or a web framework then a CMS might be a better route since you can expand it with plugins as you see fit. With this route you can worry more about the content and page structure rather than the platform. As long as you pick the appropriate CMS.
I would suggest to create a mock app with some of the web mvc frameworks in the wild and pick one, with which your development was smooth enough. Establishing your code on a solid basis is fundamental, if you want to grasp concepts of mvc and be ready to add new functionality to your web easily.
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
Been doing a lot of Php & MySQL programming over the past 3 or 4 years. I really enjoy it, and all its related back-end technology.
I'm mostly doing freelance work here and there, but I am not a design guy, and really don't enjoy tinkering with CSS trying to make it work :)
My question is, is it ok to just be good at the server-side end of things, and outsource / team up with a good CSS person? How about in the context of things like Wordpress, Drupal, Cake, etc? Do people expect they're you to setup all their Wordpress functionality, and implement their Photoshop files into designs as well?
I really speaking from a freelance point of view, and not so much working in a major company with tons of programmers / designers.
The very best designers aren't usually the very best developers, or vice-versa. It seems like you would benefit from finding a good partner who excels in design to complement your focus on back-end programming. No need to hide that from those who hire you.
However, even if you're not great with making things look pretty, you should probably be familiar with the code the designers use to make things look pretty. It comes in handy, and you'll at least be able to construct basic designs for prototyping, and eventually reasonably clean, solid designs for final products. And, if a basic change in an existing layout is needed, you won't be afraid to make it yourself. It's a skill set worth building.
The key for me has been finding a frontend or backend person who has a general enough understanding of the other side works so that you can coordinate enough for him to say
"Ok if we want this element to look like this I need your php function to generate a with a unique id etc. My most successful projects have been with developers who specialize in a certain thing but still maintain general knowledge of all the different aspects that go into a project.
From my experience, doing "freelance website work" means you end up doing all of the work on your own, but don't get me wrong, building a website these days is extremely easy in most cases and I would suggest you learn CSS if that is what you want to continue doing. Web applications are a different story.
From a freelance perspective, it depends on how much you're willing to to spend outsourcing to your css/design person. A client is only going to be willing to spend X on the project, it doesn't matter to them how it gets done (or shouldn't). So as long as you don't mind slicing off a percentage of X to pay the designer, that should be fine. Especially if it's not going to be a client you maintain sites for.
Having said that, though, if it's a customer you're going to have to maintain and make changes over time, you're going to really want a background in the design aspect. At least enough to make minimal changes. A complete redesign will probably require outsourcing again.
This is approximately the model I've set up. I'm absolutely horrible with photoshop/graphic creation, but the html + css aspect is not hard.
I had an internship that I mainly did back-end work and the little front-end work was the minutae of moving elements pixel by pixel. That gave me a strong distaste for front-end work. But I am in a similar situation as I've primarily been a back-end person and am now transitioning to more front-end work.
My advice would be to get comfortable enough with CSS and the blog/cms frameworks so that you can tweak them and make small modifications. If a client comes to you and starts saying how they want the front-end to look and you have a blank look on your face or are unable to give a reasonable estimation of how much time it will take to implement the updates (or if it's even possible) that will be a big dissuading factor in their eyes.
Don't be afraid of getting deeper into front-end design as well, it improves your marketability not having to rely on others for a portion of the project.
From my personal experience, heightening you experience in the basics of front-end develop will benefit you for more than one reason. Sometimes the best way to deliver a usable front-end requires specialty programming on the back-end. If you can except what will be happening on the front-end, or even developing the barebones of it yourself, that will help greatly.
You might be asking yourself, "Okay, that doesn't really answer my question?" but in fact it does. It's Web 2.0+ out there... clients expect beautiful, dynamic, and easy-to-use websites. This often requires the use of JavaScript and how it interacts with your server scripts and the CSS, layout, and design of the page.
So, in short, if you're wanting to do freelance stuff, in my opinion, it would be worth your while to expand your horizons. I honestly think the gap between "Web Developer" and "Web Designer" has been slowly closes over the years.
Personally, I work for the computer support department of a state University and all the websites we do are both written and designed by myself without any "outsourcing" of my work. I can do what I need, I can make changes on the fly without waiting for another person to do, and I can test immediately. All three are huge advantages in our environment.
One aspect I wanted to direct your attention to is the choice of your development framework. If your framework supports MVC (model-view-controller) separation, then it's very natural for a developer to work on the M and the C, while the designer (CSS/HTML professional) works on the V component. This creates a great workflow and a good separation of responsibilities - and you can work on two separate files at the same time! They're on HTML peppered with some tags, you're on the logic.
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
We have a "web application" which has been developed over the past 7 months. The problem is, it was not really documented. The requirements consisted of a small bulleted list from the initial meeting 7 months ago (it's more of a "goals" statement than software requirements). It has collected a number of features which stemmed from small verbal or chat discussions.
The developer is leaving very soon. He wrote the entire thing himself and he knows all of the quirks and underlying rules to each page, but nobody else really knows much more than the user interface side of it; which of course is the easy part, as it's made to be intuitive to the user. But if someone needs to repair or add a feature to it, the entire thing is a black box. The code has some minimal comments, and of course the good thing about web applications is that the address bar points you in the right direction towards fixing a problem or upgrading a page.
But how should the developer go about documenting this web application? He is a bit lost as far as where to begin. As developers, how do you completely document your web applications for other developers, maintainers, and administrative-level users? What approach do you use, where do you start, what software do you use, do you have a template?
An idea of magnitude: it uses PHP, MySQL and jQuery. It has about 20-30 main (frontend) files, along with about 15 included files and a couple folders of some assets -- so overall it's a pretty small application. It interfaces with 7 MySQL tables, each one well-named, so I think the database end is pretty self-explanatory. There is a config.inc.php file with definitions of consts like the MySQL user details, some from/to emails, and URLs which PHP uses to insert into emails and pages (relative and absolute paths, basiecally). There is some AJAX via jQuery.
Please comment if there is any other information that would help you help me and I will be glad to edit it in.
The developer leaves on Friday. However he can dedicate most of his 24 remaining hours to this documentation task. So, yeah, things are bleak but 24 hours is quite a bit... right? :-\
I would start by listing the main features that the application currently implements (update the initial bullet points).
Then, for each bullet point, write down the main requirements associated with that bullet point.
For each requirement, write down:
Anything quirky about that particular requirement
Where in the code that requirement is implemented (which php, inc files, tables)
This will give you something of a traceability hierarchy
Feature => Requirement => Implementation
It will also provide a good framework to jostle memories and write down gotcha's.
Then, comment each php and inc page.
Start with a header that outlines the purpose and which requirement(s) from the previous list are satisfied (reverse traceability from code to requirement).
Go through each php/inc file and comment the major actions/decisions/loops indicating what they are trying to accomplish and any design considerations that are assumed (e.g. "input is assumed to have been validated in the previous step").
When commenting the source code, you may want to use a tool such as PHPDoc so that you can generate documentation out of the comments.
One approach could be to arrange a series of hand over meetings. In these the developer would have to explain the code for each section.
He could write some notes in preparation for these, but having the other developers take minutes as well might help them understand the code. Also these meetings would be an opportunity to ask questions about aspects that aren't clear.
Don't try to do the whole site in one go. Break it down into smaller chunks grouped somehow - by function or by area. This means that your other developers aren't bombarded with too much information in one go, the original developer can concentrate on one area at time and you have a chance to follow up after the meeting.
Even if nothing "sticks" straight away there will be some documentation and some familiarity with the site when you revisit it later.
Another approach could be for the developer to give a series of short presentations on the site and how it was built. This might prompt him to remember why he took the approaches he did. This is invaluable when looking at code. If you know what problem it was trying to solve it's a lot easier to understand.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
I have a problem about structures of the complex applications. Because my knowledge background does not come from education, I have always had a problem understanding an application's layers, design patterns, and programing structures. First of all, I can do whatever I want with PHP, because I know common functions and I have experience with it, but I want to create bigger and more complicated applications than I did before, so I always ask questions myself while I am writing code: Is this best place to do this? Is this the best way to do this? Do people use this way to do the same thing?
To answer these questions correctly, I created my own small MVC PHP framework which really looks like Zend Framework. I did this because I want to clarify all parts of the application. I know that there are lots of design crimes in my framework and all my applications, and I think that the main problem is the border between Controller and Model.
I asked lots of questions about this on SO, but still it is not clear for me. Therefore, I will explain what I know and what I do, and please show my mistakes, and correct them, or just explain some information about design patterns, or just explain what my problem is.
What I know
I know active record pattern. For example, we have user class, we use same class to save data to database, and we use same class as a object. So object is active we can create one then if we change it we can save it with same class ( $user = new user('Oguz'); $user->save();)
I know factory pattern . We have to classes for one object (User_Factory and User). We use user_factory class to access database for example get user or delete user. And user class is the object it self.
My problem starts when there is a connection between objects (not like many-to-many or belongs-to). For example, we have a video website which has a favorite system. The process of adding favorite consists of these steps (1-check the video with this id, check the user with this id. validating steps). While we are just adding or updating just one object we user other objects too (User factory and video factory). Generally I can do all this things in controller. But I fell that this is not the best place to do this. Because I call these steps as a process (adding favorite process). So this process should not go in controller because we may want to use same process as an API in another controller-action. So I feel like there should be another place which includes this processes for example process library. I do not even know which programing problem I am talking about.
The connection between object does not just exist in validation step.For example think about search process. when user search a string first we have to create new search row (for latest searches stuff), then we have to search YouTube, if we can not find we have to search other video sites et cetera. So this action is a process search process, I think putting the all logic in controller is a correct way to to this. we use lots of classes and objects so I can not put this process in search objects class.
I think one of the best things you can do is dig in and understand, really understand how things work. In the arena of web development, we are typically isolated from the details of TCP, packets, transports, protocols, etc... But sometimes, it is so isolated, that we forget to learn how it works, and as a result, stick ourselves in a little box.
I've been programming PHP professionally for nearly 10 years. I've never used an MVC framework. I've always separated user interface from application logic from database access.
We don't need a bunch of "patterns". We need true understanding of the problem, and the vision to create an elegant solution, re-using other work as much as possible.
So I guess I am suggesting that you switch your focus from trying to make your application fit into a pattern, and re-consider the logic needed to successfully complete your application. Many times, it is very simple, but we tend to over-complicate it.
Throw off the handcuffs of MVC and patterns... (and then watch me get downvoted for ranting against the status quo).
Good luck with everything. And by the way, you will learn far more about programming in 4 years of doing it, than 4 years of college. Not to say you should or should not go to college, but just be aware that in many cases, you already know more than your professors will about real-world programming.
MVC is a fashion blooming 20 years late. If you feel it pushes you into "wrong" code, it's because that's just what it does. Do things from the first principles. And... The community is not a shrine of divine wisdom. We're just a bunch of loud code monkeys. Use your own brain. And... MVC is a fashion blooming 20 years late. If you feel it pushes you into "wrong" code, it's because that's just what it does. Do things from the first principles. And...
Good luck, and enjoy your endeavors!