4 ms·
You might have learned the wrong lesson. A broken code should not be able to make it to production, there should be several steps to prevent that, including: P
by runarberg 4y ago
You might have learned the wrong lesson.
A broken code should not be able to make it to production, there should be several steps to prevent that, including: Peer review, CI, QA, a staging environment, manual testing, etc.
Always assume that developers can screw up in trivial ways, and build your delivery system such that trivial screw ups will be caught early, rather then dictate how your devs setup their work stations.
Also don’t code review the code it self, review the diff.
- nullgeo 4y agoYeah exactly, if I `require important.rb` in this file, and `important.rb` wasn't committed how did that project even build and get deployed. Any sane build system will instantly fail for this situations. Looks like an issue with dev ops/engineering culture rather than .gitignore
- someweirdperson 4y ago>Also don’t code review the code it self, review the diff. A significant percentage of the most critical problems I detect during reviews is in the parts that have not been changed, invisible in the diff. A good diff is necessary, but not sufficient.