31–40 of 47 posts
Ironically the page layout is broken on my iPhone using safari. One can debug this with desktop safari by going into responsive design mode (forget what it’s called)
Yep, same on Android. Weird, being a mobile design.
For content, I agree, but houses also have plumbing, an electricity network, heating, etc
A house where all the wire was bundled up in a single room would be weird.
Regardless if the method changed is in the same file or another directory my IDE will find it for me right away.
This is an age old discussion but I think it has been made somewhat moot by the speed and power of our IDE's. Essentially there have been two approaches...
1 ) Put things that are the same together. Tools go in the tool-shed, food in the kitchen.
2) Put things that you need to use at the same time together. Some tools can go in the kitchen because you need a few tools there. Maybe a small fridge in the tool-shed is not a bad idea.
A new third approach opens up as our IDE's got more powerful. Put the files anywhere. This is akin to having a robot in your house that regardless of where you are, it will make a tool or food appear for you on request. This is similar to how I no longer spend time organizing old emails because I just rely on the email system's powerful searching features to find what I need.
For example, my IDE (Netbeans) has CNTRL-O, which lets me go to any class file directly without going to any directories. It also has usage search and implementation search. If you digging around directories, then you doing it wrong. I am still not sold on putting your files in random places, but I just feel where you put them matters less for most purposes.
This layout is similar to how I organize a fairly large real world project in my Flask course[0].
For example, here's some folders that house various functionality:
admin/
bet/
billing/
contact/
page/
user/
Each one has templates, views (route definitions), background tasks and models that are associated to that specific thing.
Sharing code is super simple between the 2. If you find yourself creating a general function that could be used in both, then you drop it in a lib/ folder that lives outside of those folders.
Overall this makes it very easy to skim a code base and see what it does. I've scaled this same pattern to having about 15 of those folders for distinct app functionality and hundreds of models, etc..
> But since the file is not located near the change, you need to search through the entire code base to see where the changed function is called in order to update the calls. Regardless if the method changed is in the same file or another directory my IDE will find it for me right away. This is an age old discussion but I think it has been made somewhat moot by the speed and power of our IDE's. Essentially there have…
How we store our documents; how we structure our work: This is a constant background channel of communication to the entire team, working tirelessly every moment of every day. It strongly influences how we think about our work, and is one of the best ways we have of influencing the engineering culture of our organisation. Melvin Conway: "Organizations which design systems ... are constrained to produce designs which…
Nowhere is this clearer than when the structure is hierarchical. Divisions close to the root of the tree implicitly carry a greater weight of importance than those close to the leaves.
This property means that it is difficult to find compromise within a single hierarchy; a driving force behind the prevalence of flat 'tagging' mechanisms.
In spite these drawbacks, the very rigidity of hierarchies offers us an unparalleled communications opportunity: The distinctions that we make at the root of the tree are highly visible and send a clear message about the divisions and items that we consider important.
Is it important that tests be kept separate from product logic? Is it important that projects be kept distinct from one another? Is it important that each component or service be kept isolated? How about maturity? Is it important that research code be kept distinct from production code?
We have the opportunity to form a strong opinion, to make a lasting choice, and to shape the culture and the attitudes of those who follow.
That said, when a project gets big enough I tend to end up relying on memory and search (e.g. IntelliJ's find class) to find files anyway - at that point file name conventions are more important than anything else.
This is pretty similar to how I like to structure my code - basically by feature rather than by type. I find there's a lot less mental overhead to working this way, but it can bite you if you end up with a lot of code that is shared between features. Plus what a 'feature' is can be more subjective than what a type of class is and some teams might struggle because of strong, contrasting opinions on this. That said, wh…
> But since the file is not located near the change, you need to search through the entire code base to see where the changed function is called in order to update the calls. Regardless if the method changed is in the same file or another directory my IDE will find it for me right away. This is an age old discussion but I think it has been made somewhat moot by the speed and power of our IDE's. Essentially there have…
What you're describing are the facilities that modern IDEs and editors provide to support searching. Those are great, and like you, I use those search facilities to jump directly to a specific point of interest a lot of the time when I'm developing.
However, searching is useful only if you already know what you want to search for. If you're trying to explore the overall structure of a large program, having the files (and the contents within those files) organised systematically still makes browsing easier.