Как у программиста, благодаря стремительному падению цен на память и увеличению скорости вычислений вдвое каждые два года, у вас есть выбор. Вы можете провести шесть месяцев, переписывая циклы в Ассемблере, или провести шесть месяцев, играя на ударных в рок-группе, и в каждом из этих случаев ваша программа будут работать быстрее. У программистов на Ассемблере нет поклонниц.
Joel Spolsky
Всегда задавался вопросом — почему Basic настолько непопулярен в среде отечественных программистов, в то время, как на Западе он имеет значительное распространение. Закрадывалось подозрение, что у нас, на просторах бывшего СССР, все программисты — челябинцы, и пишут прямо на машинном коде, так что писать на таком высокоуровневом языке как Бейсик, у них не получается в силу отсутствия иных клавиш, кроме 1 и 0.
Вдохновлен этим постом.
Так сложилось, что первым языком программирования (ЯП), при помощи которого я пытался решать прикладные задачи, оказался Visual Basic (версия IDE 6) — так как с другими ЯП квалификации было явно недостаточно, кроме того, моя институтская специальность не относилась к ИТ-наукам. У моего отца была (и есть) автостанция, и ему на тот момент необходимо было вести каким-то образом учет клиентов — соответственно нужно было создать что-то для решения простой логики учета клиент — машины — заказы — работы — запчасти и отчетов по всему этому. Опенсорсного софта на тот момент не существовало, 1С стоил много. В итоге, написанную программу удалось продать еще двум СТО, что я считаю, как для первого опыта, неплохим результатом.
Примерно в это же время многие мои сверстники, тоже еще студенты, уже изучали Delphi, C++ и Java. Мой багаж знаний по ЯП особо не рос (небольшой опыт был с php4), идеология ООП у меня была не востребована. Лично я не понимал, какая практическая польза мне от понимания организации памяти в Си или той же инкапсуляции, если я нигде на практике это не использую. Сейчас я так же смотрю на всякие agile'ы и канбаны.
И вот, спустя годы, меня посетила вот такая мысль: ЯП есть методика решения определенной задачи, не больше и не меньше. Мотивация при написании программы — решение задачи, а не сам факт написания программы; эффективность решения задачи состоит не в качестве созданного инструмента, а в соответствии требуемого качества качеству реализованному. Вроде бы все банально. Visual Basic, как ЯП, действительно достаточно прост, чтобы с ним мог работать начинающий. Visual Basic же достаточно сложен, чтобы реализовать почти все, что могут реализовать иные, более сложные ЯП. Он универсален, он — как Windows в мире компьютеров, с точки зрения универсальности, разумеется. Более того, спустя полтора десятка лет, он практически не изменился и живет в своей классической реализации в VBA!
Теперь, уже работая ИТ-менеджером в представительстве крупной западной компании, пришлось искать пути решения иных, намного более сложных прикладных задач. Около трех лет я выделял на решение одного проекта достаточно ограниченное время. На данный момент, этот мой проект включает сервер БД и сервер приложений, надстройки для Outlook и Excel. Но у меня растет дочь, которую я хотел видеть не только мирно спящей в своей кроватке, но и еще по вечерам иметь возможность играть с ней, учить ее и учиться самому.
Несомненно, если бы я изначально нашел подрядчика на этот проект, просидел бы с их аналитиком уйму времени — возможно, даже больше, чем я потратил на собственную реализацию — и, в конечном счете, получил на выходе кошерную систему с базой данных и app сервером, то в одной отдельно взятой компании наступило бы счастье, да? Но вот как-то не да. Ибо требования бизнеса в динамичном окружении меняются с космической скоростью, а работа с внешним поставщиком занимает значительную часть времени, много его расходуется на различные согласования, бюджетирование и пр.
Конечно, аксакалы могли бы посоветовать завести внутри компании свой штат разработчиков, который бы занимался разработкой и поддержкой. Да вот незадача — сейчас глобальная тенденция практически любого бизнеса, наоборот, вынести непрофильные (те, которые не связаны с выпускаемым продуктом) ресурсы наружу компании. Сегодня, модель поддержки моей системы собственными силами является наиболее экономически выгодной, разработка различных плюшек происходит «по накатанным рельсам» и занимает минимум времени. Собственно, для этого-то прикладные ЯП и нужны.
Решение прикладных задач, осуществляемое в сжатые сроки и с ограниченным человеческим ресурсом, не оставляет другого выхода, как взять самый удобный и простой в освоении инструмент, ибо изучению нюансов организации памяти уже нет места. Нужно взять и сделать что-то, что заработает сейчас, и, возможно, завтра. Теперь мой проект превратился в эдакого Колосса, но, в отличие от глиняного аналога, ему не нужно будет стоять века, ему нужно лишь произвести впечатление / выполнить действие здесь и сейчас, даже без среднесрочной перспективы.
Все мои размышления на эту тему привели меня к довольно-таки логичному выводу. Мы, русские, не умеем делать вещи оптимально. Мы можем сделать что-то великолепно — например, запустить человека в космос, построить самый вместительный в мире самолет — но потратить на это уйму сил, времени и, немаловажно, денег. Мы можем сделать что-то из рук вон плохо — вспомним советскую легкую промышленность. Мы не умеем делать вещи на приемлемом уровне, а если пойти дальше — не умеем определить, какой уровень таки приемлем, практически во всем. И даже если умеем, то очень часто забываем этим воспользоваться.
Запад же умеет это делать куда лучше нас, к примеру, там около века очень успешно используют принцип 80/20, он же «Закон Парето». Apple, создавая новые наушники, изучила структуру ушей тысяч человек, и сделала свое изобретение таким, чтобы оно подходило 80% ушей. Я слушал музыку в этих наушниках, звучат они действительно здорово, я отношусь к 80%, и я однозначно куплю их себе.
Давайте учиться делать вещи с оглядкой на оптимальность затраченных ресурсов — сил, времени, денег. В этом мне видится путь к процветанию. Поощряйте тех, кто только встает на путь изучения программирования, и не заставляйте их садиться сразу за «плюсы».
Справедливости ради, стоит отметить, что Колосс уже прошел рефакторинг, с расчетом на более длительный период эксплуатации (согласно проекту — 2 года) с главной целью — повысить стабильность. Цель достигнута, аптайм — уже 204 дня. Я уверен, что дальнейшие итерации рефакторинга моего Колосса — если таковые потребуются — будут проводиться сторонними разработчиками, ибо дальнейшее усложнение логики повлечет лавинообразное снижение устойчивости системы. Но это уже совсем другая история.
