У большинства программистов есть когнитивные заблуждения, которые они даже не замечают. Рассказываем, какие они и можно ли с ними вообще как-то бороться.
- Заблуждение 1. Ты считаешь себя «очень хорошим разработчиком»
- Заблуждение 2. При одном взгляде на код большого проекта ты говоришь: «Я могу лучше»
- Заблуждение 3. Ты говоришь, что твой код ужасен, и поэтому никому его не показываешь
- Заблуждение 4. Ты ничего не знаешь о парадигме структурного программирования
- Заблуждение 5. Ты заявляешь о том, что «новый фреймворк X — самый лучший»
- Заблуждение 6. Ты игнорируешь race condition
- 7. Ты думаешь, что в университетах надо учить Java, а не фигне типа Pascal
- 8. Кто-то сказал, что незачем оптимизировать код, а ты и не поверил
Из этого списка можно составить собственный чек-лист когнитивных заблуждений и посмотреть, подвержены ли вы им. При этом, конечно, если даже вы собрали все пункты из этого списка, это не будет означать, что вы плохой программист.
Это адаптированный перевод статьи 8 Signs You Are Not As Good A Programmer As You Think. Повествование ведется от имени автора, Джозефа Круза.
Заблуждение 1. Ты считаешь себя «очень хорошим разработчиком»
По-настоящему хороший программист совершенствуется, в том числе читая тонны чужого кода. Он ищет более творческие, элегантные и эффективные решения. По пути он замечает, что самые лучшие решения — это результат работы команды, а не одного человека.
Поэтому хороший разработчик вряд ли будет оценивать свой уровень как «выше среднего» — он слишком много видел и понимает, что вряд ли бы написал код лучше, так еще и в одиночку.
Заблуждение 2. При одном взгляде на код большого проекта ты говоришь: «Я могу лучше»
У программиста есть собственное видение кода, а иногда даже узнаваемый стиль, что придает кодовой базе свои особенности. Позже код усложнится еще сильнее в ходе разработки, особенно под влиянием других разработчиков.
Но это еще не все. В ходе разработки также меняются инструменты и программное обеспечение. Требуется все больше новых, утонченных решений — например, работы с неопределенностью параллелизма (подробнее об этом в шестом пункте). Если программист работал на крупном проекте, то он видит кодовую базу в контексте всех этих изменчивых факторов.
Заблуждение 3. Ты говоришь, что твой код ужасен, и поэтому никому его не показываешь
Это распространенная проблема новичков. Да, они понимают, что их код предназначен не только для чтения процессором. Они пишут код на высокоуровневом языке, предназначенном для других людей. Что делать, если код вышел ужасным? Уж точно не прятать его — показывайте свою работу другим и учитесь на обратной связи, которую получаете. И научитесь писать в общепринятом стиле.
Заблуждение 4. Ты ничего не знаешь о парадигме структурного программирования
Структурное программирование влияет на все современное программирование. Его основа — иерархия блоков (control structures). У этих блоков только одна точка входа, но несколько точек выхода. Дискуссии на эту тему не утихают, но для нашей статьи нужно лишь знать, что подобные ограничения имеют две веские причины.
Первая причина в том, что благодаря блокам мы можем пользоваться высокоуровневыми абстракциями при написании кода.
Вторая причина существования блоков в том, что это эффективный для процессора способ обращаться к данным — он либо держит все данные неподалеку (spatial locality), либо переиспользует конкретные данные в течение ограниченного промежутка времени (temporal locality).
Хороший программист сможет в двух словах объяснить, что структурное программирование это использование читабельной иерархической структуры блоков, какие у парадигмы есть преимущества и недостатки, как она взаимодействует с архитектурой и дизайном железа.
Читайте также: Чему мидлы и сеньоры могут научиться на Хекслете: девять направлений
Заблуждение 5. Ты заявляешь о том, что «новый фреймворк X — самый лучший»
Или не фреймворк. Тут можно подставить любое название библиотеки или языка. Еще программист может сказать что-то типа «C и Ассемблер скоро исчезнут", или еще хуже — будет предсказывать, что «C++ заменит C в операционных системах". Все это звучит одинаково ужасно.
У каждого языка есть преимущества и недостатки, которые проявляются в контексте работы над конкретной задачей. Для одних задач подходят одни языки, для других задач — другие. Например, все языки кроме C управляют памятью так дорого или так неэффективно, что у C просто нет конкурентов. Ассемблер тоже незаменим — в таких специфических случаях, как управление регистром, кэшем, буфером TLB, и так далее. И говорить, что одно заменит другое, или что какие-то технологии однозначно во всем лучше других — достаточно некомпетентно.
Заблуждение 6. Ты игнорируешь race condition
Мы уже говорили про race condition (иногда говорят «состояние гонки» или неопределенность параллелизма) во втором пункте. Это когда несколько потоков одновременно обращаются к одному общему ресурсу, и происходит несогласованность вывода данных.
Это обычное дело в современном мире, где мы используем многопрограммные модели, параллельные и распределенные вычисления. Даже веб — это пример многопрограммной модели, когда на одном процессоре запускается несколько программ.
Проблема параллельного пользования общим ресурсом в том, что возникают рандомные ошибки. Если тестировать компоненты в отдельности, все нормально, но запускаешь их вместе — все ломается (и то через раз). Решить проблему нелегко. Надо изучать фундаментальные концепции и много практиковаться.
7. Ты думаешь, что в университетах надо учить Java, а не фигне типа Pascal
Это популярный аргумент среди противников университетского образования. Они считают, что ВУЗ дает устаревшие знания, но вместо этого он должен давать актуальные для рынка компетенции.
Да, первая задача начинающего программиста — это понять, что такое алгоритм и как он представлен в самой распространенной модели. Я бы сказал, что эта модель — высокоуровневая, последовательная, императивная. На ум приходят Java и C++.
Подобные языки отличаются тем, что разработаны с учетом математической модели. Они помогают понять объектно-ориентированное программирование с его структурами и абстракциями. Но начинать обучение с этих сложных языков? Они только создадут кашу в голове, а еще закрепят дурные привычки написания кода, от которых в будущем будет очень сложно избавиться.
8. Кто-то сказал, что незачем оптимизировать код, а ты и не поверил
Иногда рефакторинг не имеет смысла, и проще скомпилировать код, чтобы уменьшить его размер. Новичкам это кажется странным, но чтобы понять смысл сказанного, нужно понимать, как все работает на уровне железа. Это про управление виртуальной памятью, кэшем, характеристиками TLB, и так далее.
Есть реальный пример, когда компиляция уменьшила размер кода — ядро Linux. Скорость процессоров росла быстрее, чем скорость RAM, поэтому кэш стал очень важным компонентом архитектуры.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
