Я прочитал очень интересную статью о важности алгоритмов , вывод из которого мне показался весьма спорным Во-первых, диссертация.
Я утверждаю, что знание алгоритмов и даже системное образование не делают вас хорошим разработчиком.
Можно выразиться жестче — для большинства задач вы будете непригодны по профессионализму, даже если вы владеете теорией графов, знаете вычислительные сложности алгоритмов и прочитали всего Кнута.
Дело в том, что разработка программного обеспечения — это не только алгоритмы или языки.
1. Во-первых, сводить все к знанию только алгоритмов — мертвая идея.
Если программист не разбирается, например, в сетевых технологиях, не понимает, как работает операционная система и т. д., знание быстрой сортировки и всех структур данных ему не поможет. Итак, если программист не имеет понимания доступных ему готовых инструментов в среде *nix и пишет свои (для запуска заданий - он изобретает свой cron, условно говоря) - то это труба.
Либо человек не понимает устройство сетей и даже не может предположить, что определенная часть данных не загружается в его веб-приложение из-за неправильно заданных маршрутов или лагающего DNS-сервера.
2. Во-вторых, без опыта использования реальных стеков технологий (как программных, так и осей/железа) программист с сильными теоретическими знаниями может блистать топкодером, но не справится с самой примитивной задачей по созданию масштабируемого приложения.
О нюансах поведения Java/различных компиляторов/интерпретаторов можно прочитать десятки тысяч статей.
3. Без глобального мышления, понимания работы приложения в целом на всех уровнях (не только в его песочнице, но и внутри оси/аппаратной/сетевой инфраструктуры), программист не может называть себя программистом.
Условно говоря, если веб-программист думает только о том, как установить новую либу на сервер, но совершенно не озадачивается тем, как админы потом будут ее обновлять на 200+ серверах (и что будет, если это станет критично для приложения, а после очередного обновления OSI оказывается, что он вообще не компилируется).
4. Безопасность.
Это приходит только с опытом; на лабораторных или олимпиадах вас этому не научат. 5. Архитектура.
Я с радостью наблюдаю, как выходит следующий язык/фреймворк, а затем толпа бросается за ним себе.
Или — еще лучше — используйте его для своих стартапов.
Не понимая, как потом поддерживать зоопарки из 5+ технологий (особенно когда они не будут поддерживаться — привет GWT и сотням других), ни как масштабировать новомодную хрень на несколько серверов, ни как решать проблемы при отсутствии коммьюнити.
Что вам следует использовать? Это зависит от каждого конкретного случая, но зачастую более обкатанный и распространенный инструмент предпочтительнее нового, только что появившегося.
Могу привести такой немодный язык Pure C, на котором написаны драйвера, системы, Postgres и миллион других вещей, который людям не нравится из-за его негламурности (и сложных указателей, со множеством мест, куда можно стрелять) сам в ноге, скажем прямо - что накладывает дополнительные требования к разработчику), но имеет длительную историю и накопленный опыт использования.
6. Проектирование базы данных и оптимизация запросов.
Все проходят через всякие нормальные формы, но опыт выбора СУБД и создания масштабируемой структуры реальных данных с последующей оптимизацией работы приходит только с практикой.
Но мы не будем называть программиста, знающего красно-черные деревья и решающего олимпиадные задачи, неполноценным просто потому, что у него нет опыта и понимания того, как работает оптимизатор запросов в PostgreSQL, почему лучше ставить такой составной индекс, а не тот. и почему необходима тонкая настройка параметров сервера под текущую нагрузку чтения/записи.
7. Наконец, мы не можем просто игнорировать общий уровень интеллекта и мягких навыков людей, EQ/эмпатию.
Например, если человек умен и обладает здравым смыслом, то он понимает, что язык — это инструмент. И он не будет писать в реальной работе на Java то, что написано прекрасно на плюсах и работает без тормозов и бубнов (а также толстых серверов и дорогих коллег).
При этом он с радостью возьмет Java и весь стек, если уже есть готовый фреймворк, библиотеки и ПО с открытым исходным кодом, решающее проблемы.
А навыки общения с руководителем позволят ему проработать требования и подобрать всю инфраструктуру, разработать архитектуру и т. д. с учетом возможных изменений и требований бизнеса (а не только интересов типа саморазвития или вечного кайфа от ковыряния).
новые игрушки, такие как Scala).
Поэтому, уважаемые коллеги, я бы все же относился к другим бережнее и с меньшим пафосом и эмоциями.
Возможно, кто-то забыл базовые алгоритмы или структуры данных, которые он когда-то читал, но его компетентность в той же архитектуре или безопасности настолько превосходит вашу, что он может смотреть на вас свысока.
Желаю нам всем больше сопереживать, чаще делиться с коллегами интересными связями (в том числе показывать пользу от приобретения новых знаний и навыков), а не делить на своих и чужих.
ПС.
Если вы чувствуете, что алгоритмы все равно будут полезны, на Coursera есть отличный курс: один раз , два Живи долго и процветай.
Теги: #программирование #архитектура #опыт #т-образный #программирование #проектирование и рефакторинг #Алгоритмы
-
Летняя Стажировка В Mars Is: Взгляд Изнутри
19 Oct, 24 -
О Геймдеве С Настольной Выставки
19 Oct, 24 -
Android Расширяет Свое Лидерство В Сша
19 Oct, 24 -
Разработка Приложения Для Racios.com
19 Oct, 24 -
Фотографии Профиля Google
19 Oct, 24
