Программирование — это относительно узкоспециализированная техническая профессия. В мире огромное количество программистов. Каждый день люди обсуждают, какой язык программирования лучший, что делает программиста хорошим, и так далее. Далее давайте рассмотрим самые спорные мнения о программировании.
1. Программисты, которые не программируют ради удовольствия в свободное время, никогда не сравнятся с теми, кто любит программировать.
Я считаю, что даже самые умные и талантливые люди, если они относятся к программированию только как к работе, никогда не станут по-настоящему выдающимися программистами. Те, кто получает удовольствие от программирования, работают над небольшими проектами в свободное время или возятся с различными языками программирования и программистскими идеями.
2. Модульные тесты не помогают писать отличный код.
Единственная причина писать модульные тесты — убедиться, что уже работающий код не сломается. Писать тесты первыми или писать код, чтобы пройти тесты, — совершенно абсурдно. Если вы пишете тесты до кода, вы не знаете, каковы граничные случаи. Хотя вы можете заставить код пройти тесты, проблемы всё равно возникают в непредвиденных ситуациях. Более того, хорошие разработчики стремятся уменьшать связанность, поэтому новый код не должен ломать существующий код.
3. Единственная лучшая практика, которая применима везде, — «думай своей головой».
Слишком многие любят гоняться за модными технологиями и пытаются применять различные методы, паттерны и фреймворки в неподходящих местах. Новые технологии и мнения известных экспертов не равнозначны тому, что действительно работает в реальных ситуациях.
4. Комментарии в большинстве кода на самом деле являются порочным проявлением дублирования кода.
Большую часть нашего времени мы тратим на поддержку кода, написанного другими (или нами самими), и плохие, неверные, устаревшие и вводящие в заблуждение комментарии, безусловно, одна из самых раздражающих вещей в коде. Многие в конце концов их удаляют. Усилия следует направлять на улучшение читаемости кода, рефакторинг при необходимости и избегание идиом и хитроумных приёмов. Кроме того, многие учебники до сих пор проповедуют, что комментарии даже важнее кода, что приводит к появлению больших объёмов многословных, бессмысленных комментариев.
5. Нет ничего плохого в том, чтобы полагаться на Google.
Такое заявление наверняка разозлит учёных и эрудированных. Но разве всем не нужно что-то искать? Правильный ответ — это правильный ответ, независимо от того, взят ли он из какой-то секретной книги, частного обучения или Google. Важно по-настоящему понять и предложить успешные программные решения, которые удовлетворят клиентов и начальство.
6. Программисты не рождаются равными.
Менеджеры часто думают, что программист A == программист B, потому что у них похожий стаж. В действительности один разработчик может быть в десять или даже сто раз эффективнее другого.
7. Я действительно не могу понять, почему Java — лучший первый язык для университетского преподавания.
Во-первых, я считаю, что первый язык программирования должен быть сосредоточен на изучении потока управления и переменных, а не объектов и синтаксиса. Во-вторых, думаю, что люди, которые не отлаживали утечки памяти в C/C++, никогда не смогут полностью понять изначальное предназначение Java. Более того, естественная последовательность должна идти от "как мне это сделать" к "как мне найти библиотеку, которая это делает", а не наоборот.
8. Если вы знаете только один язык, то, как бы хорошо вы им ни владели, вы всё ещё не отличный программист.
Некоторые считают, что достаточно хорошо владеть C#, Java или любым другим первым языком, который вы выучили. Я не согласен. Каждый новый язык, который я изучаю, даёт мне новые идеи о программировании, которые я могу применять в своей работе. Тот, кто ограничен одним языком, не может полностью реализовать свой потенциал. Более того, отсутствие любопытства и готовности исследовать — это не черты отличного программиста.
9. Время от времени писать мусорный код — это нормально.
Иногда для конкретных задач достаточно быстрого и грязного кода. Забудьте о паттернах, ORM, SRP (принцип единственной ответственности) и всём таком.
10. Операторы print — эффективный метод отладки.
Я считаю, что использовать операторы вывода вроде System.out.println для отладки кода — это нормально. Часто это быстрее, чем формальная отладка, и можно сравнивать результаты вывода разных запусков. Но обязательно удалите эти операторы перед выпуском в продакшен или превратите их в операторы логирования.
11. Ваша задача — сделать себя заменяемым.
Программное обеспечение, которое вы пишете, должно быть понятным и поддерживаемым любым другим разработчиком за небольшое время. ПО должно быть элегантно спроектировано, код — ясным и последовательным, форматирование — чистым, документация — подходящей, ежедневные сборки, надлежащее управление версиями. Если вас собьёт машина, вас уволят или вы уволитесь, компания должна быстро найти вам замену. Если нет, то вы слишком трагичная фигура. Интересно, что чем больше вы это делаете, тем ценнее вы для компании.
Кто-то прокомментировал исходный пост: если вас нельзя заменить, то вас также нельзя повысить.
12. Геттеры и сеттеры используются чрезмерно.
Тысячи людей говорят, что публичные поля — это зло и они должны быть приватными с геттерами и сеттерами. Я думаю, на самом деле разницы нет, если только программа не многопоточная, или аксессоры не содержат бизнес-логику или логику представления (что было бы странно). Я не выступаю за публичные поля; я просто против того, чтобы делать вид, будто обёртка аксессорами или свойствами — это инкапсуляция или сокрытие информации.
13. SQL — это тоже код, пожалуйста, относитесь к нему так же.
SQL ничем не отличается от C#, Java или других объектно-ориентированных или процедурных языков. Обращайте внимание на форматирование, читаемость и поддерживаемость.
14. UML-диаграммы переоценены.
Некоторые диаграммы, безусловно, полезны, например диаграммы классов для паттерна Composite. Но многие UML-диаграммы бесполезны.
Примечание редактора CSDN: Я помню, как Роберт Мартин в «Agile Software Development (C# Edition)», обсуждая UML, по сути показал диаграмму и затем сказал, что она вроде бы не полезна, я не часто ею пользовался... Под тем же вопросом был также связанный ответ: code == design. В нём утверждается, что код на высокоуровневом языке эффективнее UML-диаграмм и документации.
15. Читаемость — самый важный аспект кода.
Даже важнее, чем корректность. Читаемый код легко исправлять, оптимизировать, модифицировать и понимать. Другие разработчики также могут извлечь из него пользу.
16. XML сильно переоценён.
Многие, кто вскочил на подножку XML, не продумали это до конца. XML хорош для веб-приложений, потому что изначально был для этого предназначен. Для других постановок задач и идей проектирования XML следует по возможности избегать.
17. Разработка программного обеспечения — это просто работа.
Я люблю разработку программного обеспечения. Сейчас я работаю в стартапе, 60 часов в неделю, за низкую зарплату, только потому, что команда отличная и работа интересная. Но с более высокой точки зрения это всё ещё просто работа. Она не так важна, как семья, моя девушка, другие друзья, счастье и т. д. Если бы у меня было достаточно денег, я бы лучше катался на мотоциклах, яхтах или занимался сноубордингом. Многие разработчики забывают, что программирование — не конечная цель; оно лишь создаёт нам условия, чтобы с радостью заниматься самым важным в жизни.
Примечание редактора CSDN: Это, похоже, противоречит пункту 1.
18. Разработчики должны уметь писать код.
В прошлом году я провёл много собеседований. В основном я проверяю мышление человека и то, как он реализует относительно простые алгоритмы на доске. Часто я начинаю с такого вопроса:
Учитывая, что Pi можно вычислить с помощью функции 4 * (1 – 1/3 + 1/5 – 1/7 + …), где большее число членов даёт большую точность, напишите функцию для вычисления Pi с точностью до 5 знаков после запятой.
Это задача, которую можно решить в 10 строках C#. Но многие кандидаты на собеседовании вообще не имеют об этом представления. Поэтому мне приходится задавать такие вопросы:
Учитывая, что площадь круга равна Pi, умноженному на квадрат радиуса, напишите функцию для её вычисления.
Удивительно, но больше половины людей не смогли написать эту функцию ни на одном языке! Увы, разработчики должны уметь писать код, а теперь даже это стало спорным мнением...
19. Паттерны проектирования приносят больше вреда, чем пользы.
Проектирование программного обеспечения, особенно хорошее проектирование, чрезвычайно разнообразно, и его нельзя содержательно свести к паттернам, особенно к тем немногим паттернам, которые все помнят. Более того, эти паттерны слишком абстрактны; на самом деле мало кто действительно помнит многие из них. Поэтому паттерны проектирования не очень полезны. С другой стороны, слишком многие очарованы концепцией паттернов проектирования и пытаются использовать их повсюду — в результате код часто почти не содержит проектирования, кроме каких-то бессмысленных синглтонов и абстрактных фабрик.
20. Меньше кода — лучше.
Если пользователи не видят вашей работы, значит, вы всё делаете правильно. Слава — в другом.
Другие популярные ответы включают:
21. Производительность действительно важна.
22. Корпоративные приложения нелепы. Требование n лет опыта — бессмыслица. Программы получения степени по информатике — чистой воды обман.
23. Модульные тесты не помогают писать хороший код, а большинство так называемых лучших практик в программной инженерии нужны лишь для того, чтобы плохие программисты не нанесли слишком много вреда.
24. Каждый программист должен быть знаком с современной компьютерной архитектурой.
25. Пишите маленькие методы.
26. PHP действительно отстой!
27. C++ — один из худших языков за всю историю.
28. Большинство профессиональных программистов плохи.
29. Чтобы стать программистом, сначала нужно научиться печатать.
30. Чем больше правил процесса вне программирования, тем хуже качество кода.
Старший игровой программист Джеймс Хейг (известного блога Prog21) также увидел эту статью и счёл эти мнения не очень спорными. Он написал пост в блоге и предложил взгляды, которые считал более спорными, многие из которых указывали на другие его ранее опубликованные статьи.
31. Информатику следует предлагать только как дополнительную специализацию.
32. Знакомить начинающих программистов с объектно-ориентированным программированием до того, как они поймут, как декомпозировать задачи и превращать решения в код, — большая ошибка.
33. Сложные оптимизации компилятора почти бесполезны, даже если они дают более быстрый код. Они сильно замедляют компиляцию и, вероятно, приводят к появлению трудноустранимых ошибок, затрудняя поиск и устранение проблем с производительностью.
34. Не позволяйте людям с опытом программирования менее десяти лет писать библиотеки для использования другими. Проигнорируйте это правило, и вы пожалеете об этом всю жизнь.
35. Неважно, уродлив код или нет. Наличие или отсутствие форматирования почти не связано с тем, работает ли код и надёжен ли он; автоматизированные инструменты могут справиться с форматированием.
36. Чистое функциональное программирование не очень полезно. Но если немного смешать его с императивным кодом, получается довольно хорошо.
37. Устоявшийся образ мышления в программной инженерии на самом деле помешает вам создавать великие творения.