![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
О программистическом выборе
Jun. 27th, 2009 09:06 amОдна из самых распространённых ошибок программирования - сделанный выбор.
Принятие решение для программистов является одним из самых сложных вопросов. Особенно на начальном этапе занятия этим ремеслом. С годами до некоторых доходит, а до некоторых не доходит никогда. Это я исходя из наблюдаемого мной по опыту общения делаю вывод.
Так уж получается что человек образованный и занятый трудом интеллектуёвым занимается принятием решений. Да и вообще мораль общественная в отношении принятия решений назидает что?
Правильно! Она назидает что решения надо принимать правильные.
А какое решение самое правильное в программировании знаете?
В ПРОГРАММИРОВАНИИ САМОЕ ВЕРНОЕ РЕШЕНИЕ - ОТЛОЖЕННОЕ
Что это значит на практике?
Это значит что для ХОРОШЕГО программиста правильный цвет это не красный и не синий. Правильный это тот который выбран пользователем. И это в общем касается решительно всего и распространяется на всю глубину тайнописи кода.
Когда перед программистом встаёт какой-то выбор, то в идеале он должен найти способ не принимать решения прямо сейчас. Задача его в подавляющем большинстве случаев сводится к тому чтобы оставлять выбор на потом.
Например выражение : for (int i=0; i<100; i++) содержит сделанный выбор о количестве повторений. Это и есть сделанный выбор. Общеизвестная уже практика подсказывает что куда лучше придать этому выражению вид : for (int i=0; i<MY_LIMIT; i++) и задать вот этот самый MY_LIMIT где-то в заголовке где его потом проще отыскать.
Это пример того как на практике происходит отсрочка принятия решения в программировании. Ещё лучше пойти дальше и вынести значение этого самого MY_LIMIT вообще за пределы кода, куда-то во внешний файл конфигурации. И это будет примером ещё более хорошего тона в программировании.
Там в файле конфигурации это значение сможет менять коллега-гик-администратор который выколупает смысл этого значения из своего многолетнего опыта.
Ещё более хорошим тоном было бы вынести это значение в область доступную конечному пользователю где коллега-гик-администратор уже не требуется.
Вы думаете это я лекции читаю о том что не надо хардкодить константы в программе?
Нет же. Это я лишь пример привожу куда более широкого и общего правила, выделенного жирным там выше.
К сожалению большинство наблюдаемых мной коллег программистов не в состоянии экстраполировать это правило дальше чем "не надо хардкодить константы" в то время как на этом это правило далеко не заканчивается.
Оно относится вообще ко всему. К структурам данных и связности элементов интерфейса пользователя, к организации файловых структур и вечным вопросам о том каким цветом выделять выбранный элемент в списке.
Армия программистов думая что помогает людям принимает ЗА них решения которые на самом деле должны быть отложены и предоставлены пользователю в виде выбора. Помните пожалуйста об этом, дорогие коллеги.
Наша задача не решать за людей, а обеспечивать людям саму возможность этого решения.
Принятие решение для программистов является одним из самых сложных вопросов. Особенно на начальном этапе занятия этим ремеслом. С годами до некоторых доходит, а до некоторых не доходит никогда. Это я исходя из наблюдаемого мной по опыту общения делаю вывод.
Так уж получается что человек образованный и занятый трудом интеллектуёвым занимается принятием решений. Да и вообще мораль общественная в отношении принятия решений назидает что?
Правильно! Она назидает что решения надо принимать правильные.
А какое решение самое правильное в программировании знаете?
В ПРОГРАММИРОВАНИИ САМОЕ ВЕРНОЕ РЕШЕНИЕ - ОТЛОЖЕННОЕ
Что это значит на практике?
Это значит что для ХОРОШЕГО программиста правильный цвет это не красный и не синий. Правильный это тот который выбран пользователем. И это в общем касается решительно всего и распространяется на всю глубину тайнописи кода.
Когда перед программистом встаёт какой-то выбор, то в идеале он должен найти способ не принимать решения прямо сейчас. Задача его в подавляющем большинстве случаев сводится к тому чтобы оставлять выбор на потом.
Например выражение : for (int i=0; i<100; i++) содержит сделанный выбор о количестве повторений. Это и есть сделанный выбор. Общеизвестная уже практика подсказывает что куда лучше придать этому выражению вид : for (int i=0; i<MY_LIMIT; i++) и задать вот этот самый MY_LIMIT где-то в заголовке где его потом проще отыскать.
Это пример того как на практике происходит отсрочка принятия решения в программировании. Ещё лучше пойти дальше и вынести значение этого самого MY_LIMIT вообще за пределы кода, куда-то во внешний файл конфигурации. И это будет примером ещё более хорошего тона в программировании.
Там в файле конфигурации это значение сможет менять коллега-гик-администратор который выколупает смысл этого значения из своего многолетнего опыта.
Ещё более хорошим тоном было бы вынести это значение в область доступную конечному пользователю где коллега-гик-администратор уже не требуется.
Вы думаете это я лекции читаю о том что не надо хардкодить константы в программе?
Нет же. Это я лишь пример привожу куда более широкого и общего правила, выделенного жирным там выше.
К сожалению большинство наблюдаемых мной коллег программистов не в состоянии экстраполировать это правило дальше чем "не надо хардкодить константы" в то время как на этом это правило далеко не заканчивается.
Оно относится вообще ко всему. К структурам данных и связности элементов интерфейса пользователя, к организации файловых структур и вечным вопросам о том каким цветом выделять выбранный элемент в списке.
Армия программистов думая что помогает людям принимает ЗА них решения которые на самом деле должны быть отложены и предоставлены пользователю в виде выбора. Помните пожалуйста об этом, дорогие коллеги.
Наша задача не решать за людей, а обеспечивать людям саму возможность этого решения.
