Проблемы к которым приводят глобальные переменные

К примеру у вас есть такой модуль в файле toolbar.js:

var toolbarModule = {
    toolbar: undefined,
    initToolbar: function (cell) {
        toolbarModule.toolbar = createToolbar();
    }
};

Используете вы этот модуль просто подключением файла toolbar.js.

toolbarModule.initToolbar(c);

Главный минус этого кода в том, что если вам понадобится еще один тулбар (например, для другого таба), то оба они будут делить переменную toolbarModule.toolbar и произойдет коллизия.

Чтобы решить эту проблему, нужно использовать либо классы, экземпляры, которых инкапсулируют в себе свои переменные. Либо нужно сделать так, чтобы всё нужное для функции передавалось через ее аргументы, и чтобы всё нужное от функции возвращалось в качестве результата.

Вариант с классами это по сути те же самые глобальные переменные только в рамках класса. Если использовать функции, то оверхедом будет увеличение количества параметров функции. 

Мне больше нравится функциональный подход, когда "весь мир" передается в функцию. Классы как структуры больше подходят для хранения данных. Хотя с другой стороны, если функция использует другие функции, то проще их объединить в класс.

Интеграция изменений

Помню в начале моей трудовой деятельности в местном сегменте разработки ПО еще не слишком сильно было развито использование систем контроля версий. Я видел пару разработчиков, которые просто обменивались изменениями в коде на флешке. В принципе в этом есть какой-то смысл, потому что когда встраиваешь изменения другого человека в свой код, то ты как бы знакомишься с тем, что он сделал и сохраняешь свое представление о проекте. Такой насильственный code review получается. А при использовании системы контроля версий, ты часто понятия не имеешь как изменился проект. Можно конечно это всё смотреть по коммитам, но это лень делать. Если что-то можно не сделать, то скорее всего это не будет сделано.

Протаскивание аргументов через цепочку функций

Один из нюансов функционального программирования в том, что всю информацию о внешнем мире функция получает через свои аргументы. Чего нет в аргументах, того нет вообще. Такой подход уменьшает число ошибок связанных с глобальными переменными. Такие функции легче тестировать, потому что все их зависимости передаются в функцию через аргументы и не нужно создавать какую-то внешнюю среду для функции.

При написании функций, часто бывает такая ситуация, что приходится протаскивать какой-то аргумент через несколько функций верхнего уровня до конечной функции.

foo2(arg);

function foo2(param) {
    foo3(param);
}

function foo3(param) {
    foo4(param);
}

Мне кажется, что это ошибка проектирования и связана она с тем, что не происходит возврата значения наверх из глубинных функций. Если функция foo4 располагает какими-то данными, сложив которые с аргументом arg надо произвести над всем этим какую-то операцию, то тащить в функцию foo4 аргумент arg неправильно. Нужно наоборот через return обеспечить всплытие данных foo4 наверх, и там наверху сложив их с arg сделать нужную операцию.

foo2_res = foo2();
doSomething(arg, foo2_res.foo3_res.foo4_res)

function foo2() {
    return { foo3_res: foo3() };
}

function foo3() {
    return { foo4_res: foo4() };
}

Протаскивая через функцию косвенные аргументы, вы размываете фокус и специализацию этой функции. Т.е. она размывается и теряет свое узкое назначение.

Что должен знать простой кодер?

Я более пяти лет работал кодером и за все эти годы мне приходилось решать разные задачи, но тем не менее все они являются типовыми и поддаются классификации и обобщению. В этом посте я расскажу какие задачи приходится решать обычным кодерам. Я буду их приводить в порядке воспоминаний, так что порядок не важен.

[прогноз] Веб-интерфейсы победят настольные интерфейсы

Если походить по гитхабу и посмотреть на всю ту красоту, которую можно создать с помощью HTML5 + CSS + JS, то это становится очевидно.

Desktop-интерфейсы например, Cocoa для OS X, кроссплатформенные Qt и Swing, WPF и Windows Forms для Windows постепенно уступят место веб-интерфейсам. Они слишком неподвижные, им не хватает гибкости.

Поэтому если вы всё ещё занимаетесь этими направлениями, то стоит задуматься о том есть ли у desktop-интерфейсов будущее. Например, стоит попробовать реализовать desktop-приложение на веб-стеке. Можно даже подумать о гибридном варианте, в котором UI вынести в браузерный компонент. Вот недавно видел пример drag&drop взаимодействия HTML5-страницы и настольного Objective-C приложения. Возможно в будущем появится облегченная версия WebView чисто для визуализации компонентов. Такой LiteWebView будет как обычный NSView только будет базироваться на веб-технологиях.

Или вот еще пример, мне нужен dashboard на Objective-C. Идем на GitHub и что мы видим...

Ни одного dashboard-проекта на Objective-C.

UPD 28.07.2015: Да, я угадал. А кто-то не только угадал, но и технологию успел замутить:

• Создатель GUI для AV - про skillsets, separation of conсerns и митболы - «Хакер»
• http://www.terrainformatica.com/sciter/