Ты уже пишешь. Пишешь пока еще несложные программы, и довольно медленно. Но ты рвешься в бой. Как резко увеличить скорость? Вот что тебя волнует. Скажу сразу — резко не получится. Быстрого ничего не бывает. Но постепенно и методично… В общем, слушай.
Прежде всего, научись выделять куски программ с одинаковыми операторами в модули. Да, в каждом конкретном случае такое выделение замедлит работу. А тебе нужно побыстрей ее сделать!
«В следующий раз обязательно выделю!» — подумаешь ты. Вот тут ты и не прав. В следующий раз будет то же самое. Зато, если потратить время на подпрограмму, часто используемую, получишь выигрыш и, возможно, немалый, но не сегодня. Так что — подумай. Научись видеть те куски, которые можно написать отдельно, делай из них библиотеки, используй их не только сам, но и предлагай сотрудникам. А они с тобой поделятся своими личными наработками. И ты дополнительно выиграешь. Когда подпрограмм у тебя наберется много — ты почувствуешь увеличение скорости, почувствуешь явно вместе с ощущением легкости в работе.
Второй момент. Что часто нас замедляет: большие проблемы? Нет. Над ними мы постоянно думаем, даже не замечая этого. Думаем дома, в транспорте, во сне. В результате мы готовы их решить, и довольно оперативно.
Замедляют нас мелочи! Предположим, ты приступил к созданию программы. Ты многое продумал. Но нет в наличии файла с исходными данными. Решая главную проблему, ты не удосужился им обзавестись. Не подошел к нужному специалисту — а он сейчас в отпуске, не выяснил для себя структуру данных. Что же делать? Есть напарник специалиста, но он сейчас занят и только через два дня обещает разобраться. И ты вынужден ждать.
В самом начале создания программы, а лучше даже перед ее началом, надо позаботиться об отладочной среде. Тогда первые же написанные команды сразу будут тестироваться. Отладку лучше производить по ходу написания — сделал кусок, отладил. Современные объектно-ориентированные языки буквально предназначены для этого.
Может здорово замедлить скорость зависимость от кого-то. Тебе должны давать информацию по работе или поставлять исходные данные для отладки. Но делается это медленно, хотя и делается. Представь себе: ты идешь по тропинке, а впереди человек, которого нельзя обогнать. Он не так уж тихо идет, но шаг его на полступни меньше твоего. Ты особо не замедлился, но на большом расстоянии ушел бы далеко вперед, если б вы шли рядом. Так что старайся свести эту зависимость на нет. Бери информацию заранее, научись добывать сам — в общем, делай, что хочешь, лишь бы не зависеть от кого-то! Помню такую практику в начале своего пути. Работа была разделена на постановку задачи (делал постановщик) и на ее формализацию (задача программиста). Путь был очень длинный. Какое я облегчение испытывал впоследствии, когда получал задание непосредственно от заказчика. Это было рациональнее и быстрее.
Третий момент. Обязательно делай копии своих недописанных программ. Потеря исходных текстов в результате аварии сведет все твои старания к нулю. И еще одно — при возникновении нового вопроса не всегда полезно долго искать ответ в документации. Максимально используй живую среду. Кто-то уже прошел через это и ответит, а у кого-то на этот счет уже есть подпрограмма. Я не говорю о том, чтобы вообще в инструкции не заглядывать. Потом ты успеешь еще туда посмотреть. Но на данный момент ты выигрываешь в быстром освоении задачи. Оперативный обмен своими проблемами резко увеличивает скорость их разрешения.
С чем-то не согласен? У вас так не принято? Тогда отодвинься в сторонку. Я тебя поучил. А теперь займусь твоим начальником. Сударь, хотите, чтобы скорость работы Вашего коллектива была ошеломительно большой? Понятно. Кто же не хочет! Тогда сделайте так, чтобы внутри отдела господствовала открытая информационная среда. Чтобы люди старались делиться как своими удачами, так и своими ошибками. Добейтесь, чтобы вновь поступивший сотрудник ответ на любой вопрос получал из живых уст, а не из скучных книг.
Как у нас часто бывает? Приходит человек на новое место, задает вопрос, а его отсылают к документации. Кому-то некогда, а кто-то просто не хочет, чтобы быстро доросли до его уровня. Причем, аргументы отсылающих звучат настолько убедительно, что даже можно поверить. Вы тоже верите? И не верите мне? А Вы представьте такую картину. Попадаете Вы в город, где говорят на иностранном языке. Вам нужно жить в этой среде. Вам нужно узнать о ней много. Вы пытаетесь задавать вопросы. И вместо того, чтобы подсказать Вам, куда можно пойти поесть, Вас отсылают к словарю. Подумайте, когда Вы в таких условиях научитесь говорить? А поесть, интересно, Вам удастся? Так что подумайте, сударь! Если Вы не создадите такой среды в коллективе, программист все равно добьется своих высот, но позже, а возможно, и гораздо позже. К тому же, он может стать информационно замкнутым. А зачем делиться? Ведь он всего добивался своим трудом, так почему он должен кому-то помогать?
Что касается меня, то я имел в самом начале работы очень доброжелательный источник информации. Он оперативно реагировал на любые мои, да и не только мои вопросы. Для него это было своеобразным видом спорта. Повзрослев как специалист, я также с удовольствием стал делиться своими знаниями. И что я при этом обнаружил? Это очень выгодно. Объясняя возникший вопрос, ты вдруг сам начинаешь его лучше понимать. Убыстряется реакция на поиск собственных ошибок. К тому же, помогая, часто обзаводишься дефицитной компьютерной информацией, за которой давно гонялся. (Это могут быть и программы, и драйвера, и системы.) А здесь тебе ее предлагают сами. Так что оперативная помощь ближнему взаимовыгодна!
Поняли, сударь? Ухватил суть, программист? Вот и отлично. Попробуйте!