Вот вам мой тред по осознанному потреблению для программистов. Тред ↓
Старайтесь не заводить объектов, отвечающих только за одну функцию. Каждый объект должен выполнять хотя бы две-три функции, в идеале пять-шесть. Это поможет вам сократить количество необходимых объектов.
Вместо обновления библиотек на новые версии попробуйте обходиться теми, что у вас уже есть. Например, поставьте себе задачу не обновлять и не добавлять новых библиотек в проект в течение года.
Не коммитьте каждую задачу отдельно. Вместо этого соберите все задачи за день и закоммитьте их за один раз перед уходом с работы. А еще лучьше коммитить один раз в конце недели. Это поможет сократить объем бумажной работы, которая требуется серверам на каждый коммит.
Закрывайте InputStream-ы, которыми не пользуетесь. Каждый лишняя секунда открытого InputStream-а приводит к перерасходу ресурсов.
Не выбрасывайте отработанные объекты в garbage collector. Заведите общую кучу, откуда отработанные объекты смогут доставать и переиспользовать другие части программы.
Попробуйте продолжать использовать объекты некоторое время после истечения их годности. Например, во многих случаях кэш после инвалидации можно использовать еще какое-то время, и результаты будут не сильно хуже.
Отдавайте предпочтение классам с «органическими» названиями. Так, «TreeMap» сделан из натуральных материалов, тогда как «HashMap» явно какая-то химия, произведенная на заводе. Watchdog лучше Timer. Stream лучше Channel. Thread (нить) – зависит от материала. Исключение – Exception
Не пишите {} для блоков из одного выражения. Блоки без скобочек работают не хуже, но занимают меньше места на диске.
Не закрывайте html-теги! Браузер сам поймет, где логически заканчивается ваш div.
Комментарии... Ну вы поняли. Программа прекрасно работает и без них.
Гуглите документацию? Не открвайте новые табы, если есть открытые старые. Вбивайте новый адрес прямо в них!
Сокращайте имена переменных. Чем короче – тем лучше. В идеале должна остаться одна буква. Это может сократить размер файлов на 5-10%. А это дисковое пространство. А это экология!
Табы вместо пробелов. Один таб занимает на диске всего лишь четверть места, которое нужно пробелу. А ведь ваша программа состоит из пробелов минимум на 50%!
Не обнуляйте только что выделенную память. Вместо этого проверьте, нет ли там данных, которые можно было бы использовать повторно (только для C/C++ программистов).
Сортируйте отработанные объекты по способу переработки. Заведите несколько garbage collector-ов и правильно распределяйте объекты между ними.
Откажитесь от Option! Это вредная обертка, которая загрязняет нашу среду. Вместо этого отдайте предпочтение nullable-типам.
Не выделяйте объекты маленькими порциями, это создает очень много накладных расходов на каждый. Выделяйте объекты сразу сотнями или тысячами и доставайте оттуда по мере необходимости.
Носите с собой собственные пустые List и Map, чтобы не пользоваться одноразовыми.
Не выделяйте списки и словари «с запасом», «на вырост». Выделяйте ровно столько, сколько элементов планируется в них положить.
Выключайте программу, если пользователь долго ей не пользуется. Скажем, автозакрытие после пяти минут неактивности может сэкономить потенциально часы бессмысленного существования. Программы.
Программа собирается долго? Сходите погуляйте. Не нужно бежать покупать компьютер по-быстрее, корпорации только этого и хотят.
Спасибо за внимание и помните: об экологии может заботиться каждый! Даже если вы живете в интернете
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Very interesting case study in 5 parts when a man tries to implement a sudoku puzzle but got overwhelmed by TDD and OOP and haven’t got any tangible result except “board representation” ravimohan.blogspot.ru/2007/04/learni… (first five links)
I was ready to bet he’s just a junior getting familiar with Ruby but turned out he’s Ron Jeffries, one of the founders of eXtreme Programming. Here’s what he thinks of himself
What’s the takeout? Don’t get stuck in the design too much I guess. Whatever works, get to the meat as quick as you can, improve later if needed. Also: methodologies, TDD and OOP won’t replace thinking about the problem at hand