Продолжение "I'm not standard". Тов.Чистяков, утверждает, что я читаю Ruby-скрипты средством повышения производительности программиста.
Это полная ерунда. Ruby не может быть средством повышения производительности программиста в общем случае. Бывают задачи, которые проще и быстрее решать на Ruby, чем на C++. В таких случаях я пытаюсь использовать Ruby. Иногда это получается.
Что же влияет на производительность программиста? Очень много факторов. Технические и организационные, например, поскольку о них я более-менее обосновано могу говорить. В отличие от, скажем, психологических факторов.
Технические факторы, к которым относится использование того или иного языка программирования, достаточно очевидны и неинтересны. Язык программирования далеко не самый важный из них. Точнее, даже не сам язык, а его приспособленность для решения конкретной задачи. Не много найдется написанных на C++ web-приложений, поскольку это не ниша C++. Более важным техническим фактором я считаю инструментарий, в который входят редакторы, IDE, компиляторы, отладчики, профайлеры и пр. Качественный профайлер способен сэкономить программисту дни, если не недели. Ну и самым важным техническим фактором я бы назвал наличие готовых библиотек, которыми располагает программист. Поскольку их использование способно сократить трудозатраты на разработку буквально в разы.
Но технические факторы вряд ли заслуживают отдельного пристального внимания, поскольку они и так на виду. К тому же зачастую программист способен воздействовать на технические факторы. Если не на уровне выбора языка, то хотя бы на уровне выбора библиотек и IDE. Гораздо более важными являются организационные факторы. Тем более, что далеко не всегда программист может на них повлиять и изменить.
Вот, к примеру, такой очень важный фактор, как атмосфера в рабочем коллективе.
Атмосфера должна быть комфортной и располагающей к спокойной, продуктивной работе. Очень сложно сосредоточится на коде, когда вокруг звонят телефоны, ведутся совещания, обсуждаются посторонние темы, включается или выключается кондиционер, открываются или закрываются окна, хлопают входные двери, работает радио и пр. Именно из-за этих не очень существенных, но многочисленных, мелочей лично я предпочитаю работать дома, а в офисе появляться только по необходимости.
Атмосфера должна быть творческой и располагающей к сотрудничеству. Очень здорово, когда есть возможность обсудить какую-то идею или проблему с несколькими другими людьми. И сделать это "не отходя от кассы" - прямо за своим рабочим местом. Чтобы не было никаких препятствий к спонтанным совещаниям/обсуждениям/спорам/"пора бежать в магазин", поскольку зачастую случайно вовлеченный в такое мероприятие человек способен высказать неординарную идею или подсказать решение, которое ты сам по каким-то причинам не замечаешь.
На мой взгляд, созданию такой творческой атмосферы во многом способствует возможность безнаказанно тратить время на решение шуточных и бесполезных задачек, достойных шнобелевской премии. Вроде задачи о "нелинейном коэффициенте". Хотя это все индивидуально... Может для кого-то катализатором креативной атмосферы могут стать и официальные корпоративы... :)
Очевидно, что "комфортная и спокойная" является противоположностью "свободной и творческой", если речь идет о большом числе людей в одном помещении. Решение этого противоречия уже давно найдено и озвучено, например, в книге ДеМарко и Листера "Человеческий фактор". В идеале, каждый разработчик должен иметь отдельный кабинет, обязательно с плотно закрывающейся дверью. Но это в идеале. На практике же не редкость, когда в одной комнате работают четыре-пять, а то и больше программистов :(
А еще рабочая атмосфера должна быть открытой (по крайней мере, внутри трудящейся над одним проектом команды). Очень плохо, когда программисты намеренно скрывают друг от друга знания или отказываются помогать друг другу. Еще хуже, когда участники проекта по каким-то соображениям искажают относящуюся к проекту информацию.
Со мной в EPAm-е произошел показательный случай. Когда мне было поручено определить, насколько хорошо закомментирован исходный код проекта, я выяснил, что Javadoc-комментариев очень мало. На вопрос о причинах такого положения вещей я ответил, дословно: "Потому что программисты ленятся или не успевают". За что был несколько раз отчитан начальством разного уровня о том, что нельзя "выносить сор из избы". Этот эпизод стал одним из первых звоночков о том, что EPAm не та контора, в которой мне хотелось бы работать. Поскольку мне быстро дали понять, что целью является не сам проект, а соблюдение неких корпоративных приличий. Если уж эти приличия настолько важны, то пусть их соблюдает какой-нибудь менеджер, который находится между разработчиками и заказчиками. Но внутри команды, которая занимается проектом, не должно быть недомолвок или намеренного искажения реальной ситуации.
Еще одним организационным фактором, который серьезно сказывается на производительности программиста, является заинтересованность разработчика в том, чем он занимается. Если поставленная передо мной задача интересна мне, захватывает меня, если я берусь за нее с энтузиазмом, то она будет решена мной гораздо, гораздо быстрее и качественнее, чем не зацепившая меня. Можно попробовать приплести сюда профессионализм. Мол, профессионалу должно быть все равно, что делать. Может быть и должно, но в моем случае это точно не так. Хотя большую часть времени как раз приходится заниматься тем, что "нужно" и "должно", а не тем, чем хотелось бы. Так что фокус в том, чтобы, суметь найти хоть какой-нибудь интерес в том, что нужно запрограммировать сейчас. Если фокус удается, то производительность заметно возрастает. Ну а если нет... :(
А в завершение, пожалуй, самый важный организационный фактор. Я думаю, что наилучших результатов программист достигает только тогда, когда он четко знает что он делает (цель) и как он это будет делать (путь).
Не всегда цель определяется самим разработчиком. Ее, по идее, должен определять заказчик, а затем уточнять менеджер. Но это, как правило, стратегические цели. А вот пути их достижения -- это уже вотчина разработчика.
Например, заказчик озвучил мне проблему: "При таких-то стечениях обстоятельств в таком-то компоненте начинает накапливаться очень большая очередь ожидающих обработки транзакций". И поставил задачу: "Устранить эту проблему. Очередь транзакций не должна накапливаться". Это задача. Но для меня, как для программиста, еще нет цели. Целью должно стать некоторое решение этой задачи. Естественно, у любой проблемы есть несколько решений. Далеко не всегда первое найденное решение будет удовлетворять заказчика или требовать минимальных усилий разработчика. Поэтому очень желательно рассмотреть (как говорят, обсосать) решение со всех сторон, чтобы убедиться, что именно оно подлежит реализации. Иногда, еще до начала реализации, при тщательном изучении решения с разных точек зрения становится очевидно, что оно ошибочно и лучше выбрать какое-то другое. И фокус в том, чтобы перед началом программирования точно знать, какое же именно решение будет запрограммировано (это и есть цель).
Но это еще не весь фокус. Как правило, подлежащие реализации решение бывает описано на достаточно высоком уровне и, поэтому, допускает несколько возможных алгоритмов реализации (и даже воплощений каждого из этих алгоритмов в коде). Так вот, прежде чем приступать к написанию кода, разработчик должен точно знать, какой алгоритм и в каком виде он хочет запрограммировать (это и есть путь). Чем более подробно программист будет себе представлять детали будущей программы, тем меньше времени у него займет и кодирование, и тестирование, и отладка, и документирование. А самое четкое представление о том, что предстоит написать, дает уже записанная в каком-то подробном виде программа. Например, в виде черновиков кода на бумаге. И это еще одна причина, по которой я стараюсь писать наиболее важные и сложные куски кода сначала на бумаге. Это сильно экономит мое время на отладке и документировании кода.
Вот такое вот плавное замыкание моего порочного круга и возврат к первой теме -- программированию на бумаге :)
Комментариев нет:
Отправить комментарий