Опять я про инструментарий программиста и задачи. Как определить, что надо выбрать для конкретного проекта и где заканчивается возможность управлять сложностью задачи ?
Если рассуждать , то очевидно - выбор надо делать так, чтобы инструмент подходил для решения задачи. Но когда речь идет о сверлении дырок в бетоне, то в общем выбор достаточно прозаичный - перфоратор определенной мощности с учетом того, сколько времени мы собираемся сверлить. Решение может быть найдено достаточно быстро. Потому что задача простая.
Но когда только формулировка требований является весьма сложной задачей, да и сам инструмент тоже требует на изучение иногда несколько недель или месяцев - тогда как выбирать ?
Возьмем для примера Spring Framework и реализацию Java EE в части Dependency Injection. Как можно определить - подходит или не подходит ? В какой-то момент инструмент становится важнее задачи. А на самом деле на чем надо фокусироваться ? Само собой, на задаче. Но иногда процесс понимания инструмента становится отдельной задачей. Как говорит мой коллега: "Была у программиста проблема. Собрался он ее решить с помощью регулярных выражений. И теперь у программиста две проблемы".
Ведь по сути нам не надо заниматься решением проблем для использования того же сервера приложений - нам надо решать свою задачу. Но мы берем какой-нибудь сервер приложений (потому что он много чего может - и это правда) и начинаем придумывать решение нашей задачи уже с учетом сложностей сервера приложений. Дальше - больше. Мы используем системы high availability и понимаем, что поддержка этих систем требует глубокого знания самого инструмента. Но нам-то на самом деле надо,чтобы именно НАША система была доступна 24x7. Нам в общем-то не нужен сервер приложений (во всяком случае его глубокое понимание).
Системы BPM (Business Process Management) - их появление служит важным задачам. Но их использование требует больших усилий.
Есть ощущение, что мы идем к ситуации, когда нам нужен отдельный специалист по каждому инструменту - потому, что читать предложения о работе, в которых перечисляются десятка два технологий, каждая из которых требует месяцы, а то и годы практики, становится уже забавным. В моей голове несколько десятков сокращений, за каждым из которых несколько недель или месяцев изучения - если вы хотите в этом разобраться не поверхностно, а "с чувством, с толком, с расстановкой".
Да, есть уже настолько отлаженные инструменты, что мы не занимаем себе голову. Наподобие вышеупомянутого перфоратора. Работает четко, надежно (пока не сломается). Здесь вся суть в словечке "отлаженный". Т.е. доведенный до безукоризненной работы.
Но такое возможно, когда инструмент простой. Как только сложность пересекает некоторую черту - мы получаем проблемы.
Сложность растет, надежность падает. Хотя может надо рассматривать процесс с "пирамидальной песочной позиции".
Насыпаем пирамиду, песок на самом верху удерживается плохо - скатывается. Не надежная конструкция наверху. Но внизу песчинки уже сложились в устойчивую структуру. Чем шире основание, тем выше пирамида. Потом придумываются системы удержания песка, его экономии, более производительного насыпания, кран для высоты, потом может появится еще что-нибудь.
В принципе, у нас похожая ситуация. Железо становится надежнее, базовый софт тоже - может все не так страшно ? Но ведь все имеет какие-то пределы. Как скорость света. Хотя закон Мура пока выполняется. Истина как всегда где-то есть, но вот подойдет ли она нам ?
Удачи.
Если рассуждать , то очевидно - выбор надо делать так, чтобы инструмент подходил для решения задачи. Но когда речь идет о сверлении дырок в бетоне, то в общем выбор достаточно прозаичный - перфоратор определенной мощности с учетом того, сколько времени мы собираемся сверлить. Решение может быть найдено достаточно быстро. Потому что задача простая.
Но когда только формулировка требований является весьма сложной задачей, да и сам инструмент тоже требует на изучение иногда несколько недель или месяцев - тогда как выбирать ?
Возьмем для примера Spring Framework и реализацию Java EE в части Dependency Injection. Как можно определить - подходит или не подходит ? В какой-то момент инструмент становится важнее задачи. А на самом деле на чем надо фокусироваться ? Само собой, на задаче. Но иногда процесс понимания инструмента становится отдельной задачей. Как говорит мой коллега: "Была у программиста проблема. Собрался он ее решить с помощью регулярных выражений. И теперь у программиста две проблемы".
Ведь по сути нам не надо заниматься решением проблем для использования того же сервера приложений - нам надо решать свою задачу. Но мы берем какой-нибудь сервер приложений (потому что он много чего может - и это правда) и начинаем придумывать решение нашей задачи уже с учетом сложностей сервера приложений. Дальше - больше. Мы используем системы high availability и понимаем, что поддержка этих систем требует глубокого знания самого инструмента. Но нам-то на самом деле надо,чтобы именно НАША система была доступна 24x7. Нам в общем-то не нужен сервер приложений (во всяком случае его глубокое понимание).
Системы BPM (Business Process Management) - их появление служит важным задачам. Но их использование требует больших усилий.
Есть ощущение, что мы идем к ситуации, когда нам нужен отдельный специалист по каждому инструменту - потому, что читать предложения о работе, в которых перечисляются десятка два технологий, каждая из которых требует месяцы, а то и годы практики, становится уже забавным. В моей голове несколько десятков сокращений, за каждым из которых несколько недель или месяцев изучения - если вы хотите в этом разобраться не поверхностно, а "с чувством, с толком, с расстановкой".
Да, есть уже настолько отлаженные инструменты, что мы не занимаем себе голову. Наподобие вышеупомянутого перфоратора. Работает четко, надежно (пока не сломается). Здесь вся суть в словечке "отлаженный". Т.е. доведенный до безукоризненной работы.
Но такое возможно, когда инструмент простой. Как только сложность пересекает некоторую черту - мы получаем проблемы.
Сложность растет, надежность падает. Хотя может надо рассматривать процесс с "пирамидальной песочной позиции".
Насыпаем пирамиду, песок на самом верху удерживается плохо - скатывается. Не надежная конструкция наверху. Но внизу песчинки уже сложились в устойчивую структуру. Чем шире основание, тем выше пирамида. Потом придумываются системы удержания песка, его экономии, более производительного насыпания, кран для высоты, потом может появится еще что-нибудь.
В принципе, у нас похожая ситуация. Железо становится надежнее, базовый софт тоже - может все не так страшно ? Но ведь все имеет какие-то пределы. Как скорость света. Хотя закон Мура пока выполняется. Истина как всегда где-то есть, но вот подойдет ли она нам ?
Удачи.
Комментариев нет:
Отправить комментарий