kelatebaru

ircmaxell: Framework Fixation - An Anti Pattern , short summary: delegation of architecture decisions to frameworks may not be optimal or even wrong only use frameworks when doing prototypes or projects you don't need to maintain frameworks don't save time/money in the long term frameworks don't make it easier to hire good programmers using a framework prevents developers from understanding backgrounds not all framework developers are super heroes (look at the bug trackers ...) favor libraries over frameworks Quotes: Most of the monolithic frameworks are red herrings...solving problems of yesterday The typical mantra of "just let a framework do it for you" helps nothing except creating brainless code monkeys. ( source ) My opinion: frameworks are not so bad, but you need to evaluate them very carefully before using evaluation means checking code quality, features AND performance matching the specific problems of your business choosing the wrong framework throws...

A professor once told me: Remember, a string goes into the server, a string goes out. Not more, not less. So let's ask the following questions: do you need a seven tier architecture? do you need to write a servlet container in PHP? do you need to derive a class more than twice? where do you need OOP? do you need design patterns? how to choose the right technology? And here are the development principles: keep it simple and stupid! (kiss principle) don't write your architecture on more than one slide write less code, you must maintain it! test your code, you're responsible for it! don't import much code from libraries, you might need to fix or upgrade it don't trust user input, don't trust foreign code, trust your own code don't use design patterns you don't understand no backup, no future don't use technologies you haven't evaluated for the current task if you're not sure how to decide, make more tests don't follow general recommendation...