typedef

Программисты

Давным-давно жили-были Программисты. Были они умные, знали дофига чего такого, что обычным людям ни в жисть не понять, и было их мало. Оттого спросом они пользовались необычайным, зарабатывали кучу денег и вообще считались уважаемыми людьми. Еще были Пользователи, которые тоже умели программировать. Даже больше того, в то время собственно пользование компьютером заключалось в написании для него программ. Каждому Пользователю приходилось учить Фортран или Бейсик, иначе компьютер превращался просто в бесполезный предмет интерьера. Конечно, до уровня Программистов Пользователям было как пешком до Луны, потому что для Пользователя программирование было лишь инструментом, подспорьем в проведении необходимых вычислений и анализа, тогда как Программист занимался написанием программ профессионально. Короче говоря, было такое счастливое время, и все были довольны. Но Программисты все же были круче.

Дальнейшая эволюция была стремительна и беспощадна. Суть революции хорошо выражается семантикой оператора shift  в некоторых скриптовых языках. Вместе с ростом числа компьютеров на душу населения росло и число пользователей, которые не умели программировать (если вообще хоть что-то умели). В то же время Программисты в связи с определенными геополитическими изменениями стали массово покидать родные края. Их нишу понемногу заняли Пользователи, умеющие программировать. В результате мы получили немоверную массу пользователей, которые не умеют ничего, некоторое количество Пользователей, которые умеют программировать, но не то чтобы очень сильны в этом, и тонкий-претонкий слой Программистов-мазохистов.

Да, вузы исправно каждый год выпускают тысячи молодых специалистов информационных специальностей. Но вот ведь какой парадокс: учили студента на Программиста, а получился Пользователь. Потому что воспитать Программиста может только другой Программист, а таких почти не осталось. Замкнутый круг.

Софт

Но это только одна сторона. Если посмотреть на рынок ПО, то несложно заметить, что ничего нового на нем фактически не появляется. Были эпохальные продукты вроде Windows, Office, 1C Что-То-Там и тому подобных монстров, которые закрыли собой гигантские ниши. Все! Нужно просто признать: эпоха разработки массового софта заканчивается. Все, что нужно среднестатистическому пользователю, уже написано. Зачем же тогда Microsoft год за годом печет новые Офисы и Винды? Что, старые чем-то плохи? Нет! Просто им хочется кушать. Поэтому они развешивают тонны маркетинговой лапши на нежные юзерские уши, лишь бы только кто-нибудь купил их новый Офис. Который от N предыдущих версий отличается только по-другому расположенными кнопками и приведенной в соответствие с веяниями моды цветовой гаммой. Без сомнения, за это стоит отдавать триста баксов!

Конечно, я преувеличиваю. В мире есть еще что разрабатывать.

• Веб-приложения. Сейчас «программист» уже в головах обывателей является синонимом «веб-программиста». Только вот беда — вердикт «уже написано» все чаще звучит и здесь. Народ уже не знает, что бы такое написать, поэтому пишет всякую ерунду, благо процесс ее создания упростился невероятно. Операционная система в браузере? Не смешите.
• Корпоративный софт. Опять-таки, загибающаяся область. Один универсальный инструмент (1С, SAP) и толпа низкоквалифицированных адептов (1С-«программист», хо-хо) легко заменяет большинство корпоративок. Остаются лишь только всякие банки, авиаперевозчики и т.п., которые поступили мудро, придумав настолько сложные бизнес-процессы, что хрен напишешь обобщенный инструмент. А если поднапрячься и все же написать, получится VisualStudio.
• Специфический софт. Драйверы, управляющий софт, firmware. Пожалуй, здесь пока еще все нормально. Появляются новые железки и комплексы — должен появиться и софт для них, никуда не денешься.

Итого

У вменяемого читателя должен на этом месте возникнуть в голове диссонанс. Как так — писать больше нечего, а программисты все работают (и неплохо зарабатывают). Ничего удивительного. Программисты работают по инерции.

С одной стороны, компании все еще думают, что стоит только нанять программиста, как все проблемы исчезнут. Видимо, сказываются смутные воспоминания о золотом веке софтостроения в 90-х годах. А поскольку у нас в стране бизнес основан на связях и откатах, а не на грамотном управлении, то никто и не позаботился посчитать, действительно ли найм программистов за большие деньги приносит прибыль. Конечно, к софтверным компаниям (которые в данном случае выступают в роли этаких метапрограммистов) это не относится.

С другой стороны, программисты все еще считают себя самыми востребованными специалистами на свете и всячески это мнение поддерживают. Вместе с тем их профессионализм стремительно падает (см. выше), а самооценка столь же стремительно растет. «Российских Программистов» это касается в первую очередь. Г-н Медведев вон считает, что «наши программисты — самые программистые». А на деле выходит, что они (мы) сливаем по всем статьям западным коллегам, а денег хотим много.

Так что готовьтесь. Пройдет еще несколько лет (думаю, от 5 до 15), и запас инерции кончится. Собственно, зарплаты программистов уже падают (и в рублях, и в долларах), как и количество вакансий. А скоро мы получим:

• в разы меньшее количество рабочих мест;
• гораздо более высокие требования к квалификации;
• жесточайшую конкуренцию.

Приходите через пять лет, проверим.

(7 голосов, средний: 4.00 из 5)

 Loading ...

Название: Ремесло программиста: практика написания хорошего кода
Автор: Питер Гудлиф
Год выхода: 2009
Издательство: Символ-Плюс
Тираж: 1500
Объем: 704 стр.
Обложка: мягкая
Где покупал: books.ru
Цена: 690 р

Концентрированный программистский здравый смысл. Разбавлять водой по вкусу и употреблять ежедневно.

Жаль, что человеческий мозг устроен так, что не может сразу принять прочитанное на веру и закрепить на уровне рефлексов. Для подавляющего большинства начинающих программистов знания, изложенные в книге, являются абсолютно необходимыми. Это тот минимум, после которого человек имеет право называть себя программистом. Когда я учился программировать, таких книжек не было, поэтому все «золотые правила» приходилось открывать самостоятельно. Трудно сказать, какой путь лучше. В книге все разложено по полочками и проверено электроникой. С другой стороны, ничто так не способствует выработке правильных навыков, как хождение по граблям.

«Ремесло программиста» освещает почти все практические аспекты профессиональной разработки, и в этом здорово похожа на «Совершенный код» Макконнела. Но если последний претендует на некоторую всеобъемлющность (во словечко!), то Гудлиф пишет о более приземленных вещах, и делает это как-то более живенько. Читать интересно, местами даже забавно.

Минусы:

• картинки с обезьянами — дурацкие;
• опытным программистам будет скучновато читать (хотя, пожалуй, так и должно быть).

Плюсы:

• изложение систематическое, но при этом очень живенькое;
• хороший перевод;
• для лучшего запоминания в конце каждого раздела есть вопросы по прочитанному и вопросы для размышления; а в конце книги на вопросы еще и даются развернутые и обоснованные ответы;
• для ленивых в тексте разбросаны «золотые правила», подводящие итог рассказанному на одной-двух предшествующих страницах.

(Еще не оценили)

 Loading ...

Меня всегда удивляет, когда люди тратят на что-то массу усилий и средств, но забывают подумать об одном небольшом, но очень важном аспекте, который может обесценить все затраты. Ну или значительную часть.

Ярчайший пример такого подхода (сначала потратить кучу денег, потом подумать) я каждый день наблюдаю по пути на работу. На станциях электричек и метро стоят турникеты. Казалось бы, простая задача с единственным условием: не пропускать человека, у которого нет билета.

Проблема в том, что современные турникеты не выполняют основную свою функцию. Экономный народ массово преодолевает такие смешные для русского человека препятствия, не обращая даже внимания на дежурную тетеньку (смысл ее работы остается для меня загадкой). Без билета типичные турникеты с дверками можно преодолеть аж двумя способами.

1. Пройти следом за пассажиром с билетом, прижавшись к нему якобы в порыве человеколюбия. Особенно этой уязвимости подвержены турникеты с двумя парами дверок: они не закрываются, пока не сработает сенсор «человек прошел». Ограничения на продолжительность открытия турникета, похоже, нет. Наверное, разработчики посчитали, что люди бывают разные, с большими животами и сумками. Или вдруг человек посреди турникета остановится и захочет постоять. Возникает же иногда такое желание — постоять в турникете. Правда ведь?
   В результате, зафиксированный мной рекорд — четыре человека прошли по одному билету гуськом.
2. Перепрыгнуть. Тут все ясно, хотя в случае четырехдверчатых экземпляров не каждому это под силу. Видел всего несколько раз.

Когда первый способ прохода стал очевидным для железнодорожников, появились турникеты-триподы, с тремя трубами на одной оси (как в московских автобусах).

О да, они не позволяют пройти гуськом (разве что двоим очень тощим). Зато с перепрыгиванием дело стало обстоять гораздо проще: преодолеть нужно всего лишь одну горизонтальную трубу. Но и это еще не все! Под таким турникетом легко подлезть! Какой удар для конструктора!

Потратили, стало быть, кучу денег, а толку? Не беда — денег еще много! И у турникетов появились крепкие ребята в камуфляже. Народ насторожился. Не каждый теперь рискнет проскочить зайцем — шанс получить по почкам от правоохранителей перевешивал стоимость билета. Но хитрость скоро раскрылась. Крепкие ребята в камуфляже оказались просто крепкими ребятами в камуфляже. При попытке безбилетно преодолеть турникет они лишь устало бубнят: «По одному проходим, по одному». Все вернулось на круги своя. Средства потрачены, безработица среди крепких парней, тетенек и конструкторов турникетов стремительно упала, народ продолжает экономить. Все довольны.

А ведь достаточно было подумать пару минут, чтобы устранить перечисленные выше «сравнительно законные способы» прохождения без билета. Например, при двух парах дверок не давать передней паре открываться, пока не закроется задняя (тут остается возможность перепрыгивания). Или вообще сделать как в Нью-Йоркском метро, «вертушку» высотой в человеческий рост. Конечно, у нас в стране порой задача «сделать правильно» как таковая не ставится, главное чтобы за эту работу можно было освоить деньги. Но это уже совсем другая история.

Вопрос, как устранить возможность генерации фальшивых билетов на электричку, оставляется читателям в качестве несложной разминки для ума.

Надеюсь, вы не подумали, что этот пост про электрички и турникеты.

(2 голосов, средний: 4.50 из 5)
 Loading ...

Интернет-блоггинг дает каждому свободу самовыражения, возможность высказать свое мнение и быть услышанным. Так иногда говорят. На деле оказывается, что существует некоторое (небольшое) число популярных людей, которые создают первоначальную информацию. Остальные блоггеры моментально подхватывают знамя, и по сети, как круги на воде, распространяется волна вторичных и пятидясетиричных производных. Инициирующий пост может быть совершенно бессодержательным, глупым и никому не нужным, но порождаемый им поток обсуждений иногда может привести к чему-то новому и полезному.

В программерской блогосфере таких «первичных» людей немало, особенно если принимать во внимание англоязычные блоги. Но самый знаменитый, как ни крути, Джоэль Спольски. Знаменит он в основном тем, что увлекательно пишет о банальных вещах, издает по мотивам блога книги, и тем, что его блог предопределил успех его софтверной компании Fog Creek. Он не обязательно пишет все правильно и обстоятельно, но зато читать его интересно, и это вдохновляет никому неизвестного блоггера написать «вот Джоэль вчера написал то-то, а я по этому поводу думаю вот это», после чего следует шикарнейший узкоспециальный пост.

Я не склонен к паразитированию на популярных трендах, но мимо этой мощной волны я просто не мог пройти мимо, поскольку был искренне возмущен.

Началось все с подкаста номер 38 на StackOverflow, в котором Джоэль и Джефф Этвуд диалогируют на разнообразные IT-темы. В частности, они затрагивают вопрос юнит-тестов и методологии TDD; это вызвало такую бурную дискуссию, что Джоэль аж написал целый пост, приведя там стенограмму оного фрагмента подкаста. Вкратце, ключевые мысли примерно такие:

1. TDD — бесполезная штука, потому что 100% покрытие кода тестами очень тяжело достичь, да и не нужно.
2. Модульные тесты не нужны, потому что на них тратится слишком много времени. Кроме того, если что-то нужно будет менять в коде, возможно придется изменить кучу тестов.
3. Писать тесты для унаследованного кода тяжело и ненужно (и поэтому модульные тесты вообще не нужны).

Я, конечно, несколько преувеличил. Но не одному мне это показалось ересью. Разгромный отзыв написал Uncle Bob (автор agile-подхода и принципов SOLID, по которым Джоэль тоже проехался), пожурив авторов с этакой отцовской грустью («Джоэль, ты неправ») и усомнившись в целесообразности использования разрабатываемых ими продуктов. Маленькую обиженную заметку «Джоэль неправ насчет моей работы» опубликовал Кент Бек (соавтор TDD и XP). Ну и понеслось. Нашлись как противники TDD и вообще тестов, так и сторонники (в том числе индийские). bishop3000 высказался против использования TDD и тестов для legacy code (справедливо, см. ниже).  Появилось даже интереснейшее обсуждение на Hacker News.

Любопытно, что большинство противников тестирования приводит аргументы из разряда «мне Петрович напел, не понравилось» или вообще делают чисто умозрительные заключения. Никто из них не смог сказать «Вот мы в нашем проекте фанатично поддерживали полное покрытие кода тестами, но так умаялись, что решили отказаться от тестов вообще. После этого мы выпустили продукт на месяц раньше срока, и теперь тратим половину рабочего дня на чтение благодарственных писем от пользователей». То есть, натурально, против TDD и тестов выступают люди, которые ни того, ни другого не пробовали — максимум прочитали пару статей, на основе которых и сформировали свое мнение. Джоэль, выходит, тоже пусть лучше пишет блог, чем код. Но Этвуд? Может, они его там в StackOverflow на наркотиках держат?

Мое мнение — и TDD, и навыками написания модульных тестов должен в полной мере овладеть каждый уважающий себя программист. Существуют случаи, когда ни то, ни другое применять нет смысла (например, при создании прототипов). Кроме того, 100% покрытия тестами (распространенное заблуждение насчет TDD, что «все должно быть покрыто тестами») — штука действительно сродни мифической, и мало где практикуемая. Хотя бы потому, что это никому не нужно. Зачем, в самом деле, тестировать геттеры/сеттеры? Или настолько тривиальный код, что вы готовы головой за него поручиться?

Модульный тест — это проверка публичного интерфейса. Это фундаментальный принцип, из непонимания которого проистекает множество бед. Например, некоторые думают, что если наш класс использует стороннюю библиотеку, то нужно сначала написать для этой библиотеки тесты. Неверно! Тесты писать нужно для нашего класса, и если поведение класса будет нарушено из-за ошибок библиотеки, тесты на это отреагируют. Та же логика применима и к пресловутому вопросу «как тестировать закрытые методы». Их не нужно тестировать! Если открытые методы протестированы и работают правильно, то закрытые никого не интересуют.

Ну, и наконец, заявление Спольски, что, мол, если понадобится что-то поменять, то придется править много тестов, очевидно вопиюще неверное. Модульные тесты на то и модульные, что… сможете сами догадаться? Вот-вот. И если в вашем коде изменение в одном месте обрушает все остальное — грош вам цена как программисту.

К сожалению, под «программистами» сейчас понимаются все те, кто пишет программы. Но в действительности среди них можно выделить два класса: те, кто подходит к делу систематически и «по-инженерному», и те, кто просто пишет много кода, надеясь на свой опыт. Представьте, например, строителя, который кладет кирпичи «на глазок», руководствуется в работе карандашным эскизом, а перпендикулярность определяет, прищуривши глаз и наклонив голову. Я видел результаты работы таких строителей.

(Еще не оценили)

 Loading ...

Все без исключения мужики, которые умеют водить машину, убеждены до глубины души — гены, отвечающие за пол и цвет волос, непосредственным образом связаны со способностью адекватно вести себя на дороге. Говоря проще, блондинки просто физиологически не способны научиться нормально водить (хотя к некоторым немкам это, видимо, не относится). Не могу ничего определенного сказать по этому поводу, поскольку мастерство единственной знакомой блондинки-водителя еще не успел оценить. Зато с удивлением недавно понял, что природная склонность совершенно необходима для занятия программированием!

Не стоит сразу меня обвинять в мракобесии и развешивать ярлыки. Как ни удивительно, проблема склонности к программированию существует, и люди даже пишут по этому поводу серьезные статьи. В статье заявляется с известной долей недоумения, что, оказывается, существует способ сказать до начала обучения, сумеет ли человек осилить программирование или лучше сразу на рудники. Нехило так, а? Приходит студент поступать на программерскую кафедру, а его просят ответить на три простых вопроса, после чего (голосом магистра Йоды): «Тебя обучать не будем мы! Силы в тебе увидеть не можем!..»

Я бы, наверное, принял все это за шутку, если бы сам не столкнулся с живым подтверждением. Однажды я попробовал в порядке развлечения научить азам программирования двух людей. Один из них не смог понять, как работает присваивание значений переменным. То есть, натурально, пришлось минут 20 объяснять, что означает запись a = 1. Другой человек воспринял концепцию присваивания легко и непринужденно, хотя никогда до этого не программировал, да и желания такого не имел. Каково же было мое удивление, когда я наткнулся на пост Джеффа Этвуда, откуда и узнал про существование исследования в этой области. И вопрос на понимание присваивания у них первый в списке!

В общем, как ни крути, существует разница между людьми. Одни могут в уме строить и выполнять модели дискретных структур, а другие — не могут. Одни люди потенциально могут стать программистами, а другие — нет. Конечно, есть масса людей, зарабатывающих деньги программированием, но неспособные понять рекурсию, косвенную адресацию или функциональную парадигму. Но это другое — такие люди не строят ментальные модели программ, они просто действуют по аналогии или используют упрощенные способы формализации (строительство SQL-запросов мышкой в Access), и хакеров из них не получится ни при каком раскладе.

Ну и самое главное — список понятий, которые настоящий программист должен понимать. Причем не умом, а подсознанием, интуитивно — словами ведь всякий может рассказать, что такое рекурсия, если ему достаточно долго это повторять. Итак, необходимо понимать:

• присваивание;
• последовательное выполнение;
• циклы;
• рекурсию;
• косвенную адресацию (указатели);
• мультипрограммирование (многопоточность);
• «чувство правильной вещи».

Я несколько расширил список, приведенный в вышеупомянутом исследовании, добавив косвенность и «чувство правильной вещи«. Под последним подразумевается нечто вроде программистского здравого смысла, способность выбрать из нескольких способов реализации одного и того же самый «правильный» и «красивый» вариант. Причем не формулируя критерии, по которым сделан выбор.

Попробуйте испытать своих некомпьютерных знакомых и убедитесь, что ген программизма таки существует. Ну а не убедитесь — бросайте в меня камень, чего уж там.

(2 голосов, средний: 5.00 из 5)

 Loading ...