Кто написал код

Рецензия на книгу Чарльза Петцольда «Код. Тайный язык информатики», или Зачем программисту знать, как устроен фонарик

Рецензия на книгу Чарльза Петцольда «Код. Тайный язык информатики», или Зачем. главное изображение

Первые страницы книги Чарльза Петцольда «Код. Тайный язык информатики» меня сильно озадачили. Фонарик, азбука Морзе, шрифт Брайля. Окей, а зачем это мне? И когда будет про компьютеры и код? Примерно с третьей или четвёртой главы картинка начала складываться. А седьмая и восьмая главы заставили меня потратить полночи на арифметические операции в восьмеричной и двоичной системах счисления. После этого я не смог оторваться от книги до последней главы. Но обо всём по порядку.

О книге Петцольда «Код»

Книга Чарльза Петцольда «Код. Тайный язык информатики» вышла на английском языке в 1999 году. А идея написать книгу родилась у автора ещё в конце 80-х годов прошлого века, когда он писал серию статей для PC Magazine.

В предисловии Петцольд написал, что «Код» должен помочь читателям понять, как работает компьютер. Более того, благодаря книге это понимание должно быть «таким же глубоким, как у инженеров-электронщиков и программистов».

Позднее в интервью для Amazon Петцольд конкретизировал, для кого написал «Код»: «Это книга для программистов, она представляет собой уникальное путешествие по цифровым технологиям, благодаря которым работают наши компьютеры».

В 2007 году программист и блогер Джеф Антвуд назвал книгу Чарльза Петцольда признанием в любви к компьютеру.

Книгу можно купить в бумажном и электронном формате. Я приобрел её в «Литресе», здесь она продаётся в формате pdf, mobi, epub и fb2. Также электронная и бумажная версии есть в продаже на сайте издательства «Манн, Иванов и Фербер».

Код, да не тот: о чём книга Петцольда

Первые главы книги могут удивить читателя. Автор начинает путешествие внутрь компьютера с рассказа об обмене сообщениями с помощью фонарика, об азбуке Морзе и шрифте Брайля. Потом читатель знакомится с устройством реле и телеграфа. К этому моменту становится понятен замысел Петцольда: он показывает и объясняет технологии, благодаря которым компьютеры стали возможны в принципе.

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

В книге автор детально рассматривает восьмеричную, двоичную и шестнадцатеричную систему. К последней он переходит после объяснения логических вентилей и схемы построения двоичного сумматора — устройства, которое умеет складывать числа. Это устройство можно построить с помощью реле, которые образуют логические вентили.

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

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

Простая в принципе, сложная в деталях: что мне понравилось, а что не очень

«Что это такое, какой фонарик, зачем здесь написано про электросхемы?» — такие мысли мешали сосредоточиться в первые полчаса чтения. Удивление ушло, когда пришло понимание замысла автора. Вместе с этим пониманием появился азарт. Захотелось разобраться в системах, устройствах и технологиях, благодаря которым работают компьютеры.

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

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

Самая сложная часть книги начинается, когда Петцольд рассказывает, как собирать логические вентили с помощью реле, и как с помощью реле можно построить простое вычислительное устройство. Уже к этому моменту я понимал, что принцип работы сумматора не отличается от принципа работы современного компьютера. Это, наверное, самая удивительная вещь, которую я узнал из книги.

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

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

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

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

Вместо заключения: читать или нет?

Однозначно читать. В первую очередь книга будет полезна новичкам, особенно студентам без технической подготовки. «Код» написан понятно и интересно, но при этом автор избежал поверхностности. Возможно, для человека с техническим образованием в работе Петцольда будет не очень много нового, но книга однозначно освежит в памяти важную информацию.

Что такое хороший код, или как стать востребованным разработчиком

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

Начну, пожалуй, с философии, а именно, со слов Сократа: «Вот вам мой совет — никогда не слушайте ничьих советов».

Пара оговорок:

• Информация в данной статье носит рекомендательный характер, и ни в коем случае не следует её расценивать как призыв «делать нужно только так, а все остальное —неправильно».
• Определения буду давать своим языком, просто потому что с некоторыми общепринятыми я не согласен.
• Так как последние годы я специализируюсь в стеке .NET технологий на языке C#, то, соответственно, все примеры в следующих статьях будут именно на этом языке.

Уверен, что вопрос «Что такое хороший код?», возник с самого начала появления такой отрасли как программирование. И в процессе становления этой индустрии критерии оценки довольно серьезно менялись. Вот некоторые из них:

Я занялся программированием более 20 лет назад и честно пытался придерживаться правил написания хорошего кода, которые были актуальны на тот период времени. Только вот в чем фишка: как бы я ни старался, меня не покидало ощущение, что я написал нехорошо и можно сделать лучше. И я старался снова, осваивал новые технологии, некоторые канули в лету, некоторые развились настолько, что стали иметь мало общего с первоначальным прототипом, и все равно я так и не получил 100% уверенности, что да — этот код написан хорошо. И как оказалось, причина этому довольно проста. Хорошего кода в классическом понимании не существует, потому что невозможно угодить всем и вся. Но в процессе поиска ответа на вопрос, как научиться писать хороший код, я получил ответы на множество других вопросов и, что самое важное для программиста — это профессиональный опыт и знания. И я готов поделиться своим опытом в своих статьях.

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

Любой продукт имеет заказчика априори. Заказчиком может выступать ваш непосредственный работодатель, какой-либо сторонний заказчик, либо вы сами. Так может быть, если программный продукт, который полностью реализует требования заказчика — это и есть эталон, который можно обозвать хорошим кодом? Это первое заблуждение новичка. На самом деле сделать продукт согласно требованиям заказчика может любой разработчик. В срок — опытный разработчик, а вот сделать продукт в срок и правильно может только профессионал. Таким образом, правильно написанный код — это тот, который легко поддерживать и сопровождать.

Легко масштабируемый продукт — это продукт, на внесение изменений в который уходит минимум средств (под средствами понимаются любые трудозатраты: будь то труд/ часы разработчика или тестировщика, время, затрачиваемое на управление проектами и даже время на коммуникацию!)

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

Совет второй — ваша задача как разработчика, это понять, что нужно заказчику. Чем точнее вы это поймете, тем точнее вы это реализуете.

Чем быстрее и гармоничнее происходит процесс, тем более важной частью команды Вы становитесь:

• Программирование — это командный вид отрасли, если хотите преуспеть в ней, то с этим придется считаться;

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

• Если вы гениальны в программировании и считаете, что компания с большим (хорошо, уточню) многомилионным оборотом и выше будет расположена к вам, то вы ошибаетесь. Скорее всего вы окажетесь за бортом. Объясняю на своем примере: от меня должностные обязанности требуют управления командой разработчиков. Другими словами, на мне лежит ответственность за сроки разработки и качество кода разработки. А вот с чем я сталкиваюсь, когда беру в команду гениального программиста:

Первое. Продукт должен быть доставлен в срок. Гениальный программист никогда не соблюдает сроки, и причина проста: он ВСЕГДА пытается найти наилучшее решение, не понимая, что лучшее — враг хорошему.

Второе. Продукт должен быть надлежащего качества. Гениальный программист всегда будет добиваться чтобы качество было наилучшим и, к сожалению, это во вред срокам и работе всей команды.

Третье. По мнению гениального программиста, продукт есть действие его самого, а не всех участников команды, и его гениальный мозг не терпит чтобы вы что-то поменяли в его архитектуре без его ведома.

Четвертое. Гениальный программист не понимает, что, если в контроле «КНОПКА» обнаруживается текст «КНОПКО» — для заказчика это баг.

Отсюда главный совет — ваша задача, если хотите быть профессионалом, то быть частью команды, а если знания позволяют, то быть её значимой частью. В помощь — ответы на актуальные вопросы.

Как отличить хороший код от плохого?

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

Что нужно всегда помнить при разработке программ?

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

Сколько и чему нужно учиться чтобы стать востребованным (и хорошо оплачиваемым) разработчиком?

Текст объявления: «Нужен личный водитель до 20 лет с навыками эксперта по рукопашному бою, умению пройти тренировочный рубеж спецназа ГРУ за минуту в водолазном скафандре, при этом поджарив одновременно 10 пирожков на одной сковородке». Примерно так обычно описываются должностные обязанности. Но это совершенно не значит, что вам все это нужно выполнять. В требованиях, как правило, указан максимум. Выделите из всего круга то, что вы знаете и умеете, добавьте немного артистизма и красок, и вперед — убеждать наших менеджеров по персоналу. Но прежде чем это сделать, все-таки оцените трезво свои знания. А то у некоторых есть один очень хороший симптом под названием «Я знаю очень много», который сразу говорит о том, что вы обладаете посредственным багажом знаний. С другой стороны, если у вас большое количество вопросов и вы начинаете понимать, как мало вы знаете, то это уже показатель, что ваш багаж знаний солидный и можно претендовать на уровень разработчика, а не джуниора.

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

• достичь уровня начинающего разработчика (junior) вполне можно за 6 месяцев;
• достичь уровня разработчика (developer) — за 12-18 месяцев;
• продвинутого разработчика (key developer) — 2-5 лет;
• экспертного уровня(seignior) — от 7 лет и выше.

С чего начать?
В качестве ответа на этот вопрос хорошо подходит высказывание Лао-Цзы: «Даже самое долгое путешествие начинается с первого шага».

Сначала нужно решить для себя: а хочу ли я стать программистом и постоянно учиться, есть же много других замечательных профессий: кондуктор, например, или водитель трамвая? Если же все-таки решились, то открываем книги и вперед. В качестве базовых книжек и ресурсов я бы порекомендовал Троелсона «Язык программирование C# 5.0 и платформа .NET 4.5.» и ресурс для более глубоко изучения Джефри Рихтер «CLR via C#». Удачи!

В последующих статьях будем рассматривать уже конкретные примеры и реализации на языке C# платформы .NET.