После окончания университета через несколько лет работы по специальности у меня появилась мысль прийти на кафедру программирования и предложить организовать лекцию для студентов старших курсов, где я бы рассказал им, как вообще работается программистом, и что я сам хотел бы знать об этом, когда учился. Это по разным причинам не случилось, но идея осталась, и я решил реализовать ее в виде статьи. Текст написан для студентов без опыта работы.
Немного о себе. Я занимаюсь веб-программированием, у меня 12 лет опыта, основной язык PHP. Проекты, где я работаю, это обычно крупные системы, над которыми работает команда программистов, и которые нужны какому-то бизнесу для его деятельности. Такие проекты называют словом "энтерпрайз". Например, это интернет-магазины и связанные с ними внутренние системы.
Языки программирования
Начнем с языков программирования. Мы в университете изучали C++ на первых курсах. Про него нужно знать следующее. Если вы разобрались с классами, указателями, и пишете все лабы на C++, это не значит, что вы знаете C++. Там есть много технических нюансов - undefined behavior, умные указатели, виртуальные деструкторы, и много чего еще. Также надо знать основные библиотеки - std, boost. Если вы этого не знаете, на реальные вакансии вас не возьмут. Если только на стажировку, которая есть далеко не везде. Даже профессиональные программисты на C++ иногда жалуются на техническую сложность C++.
Более современные низкоуровневые языки это Rust и Go. Есть более высокоуровневые языки - например Java, C#, PHP, Python. Все они очень распространены, нет необходимости хорошо знать именно C++. Но в целом понимание, как всё работает на низком уровне, это плюс.
Языки Lisp и Prolog в чистом виде не используются. Функциональные языки, которые используются на практике, это например Haskell, Scala, Erlang, F#. Но их доля относительно императивных языков не очень большая. Нужно знать, что есть такая концепция неизменяемых переменных, у нее есть свои плюсы, и на таких языках тоже можно писать программы.
Могу посоветовать изучить HTML, CSS и JavaScript, даже если это не требуется по программе. Браузер имеет хорошие возможности по отображению графики, в нем удобно делать лабораторные работы, где нужен интерфейс пользователя, но не требуется какой-то определенный язык программирования.
Веб-программирование сейчас очень распространено, обычно в таких проектах есть база данных и серверный язык, который генерирует HTML для браузера, или возвращает в браузер нужные данные, а интерфейс создается с помощью приложения на JavaScript. Серверный язык может быть любым, часто это один из тех, которые я написал выше. JavaScript тоже используется в качестве серверного языка.
Для любых языков важно знать не только сам язык, но и распространенные библиотеки и фреймворки для него. Вас не будут брать на работу, если вы не знаете хотя бы один фреймворк.
Базы данных
Базы данных широко используются. Проектов, где не нужно хранить данные, довольно мало, а если их нужно хранить, то обычно для этого используются базы данных, а не просто файлы. Нужно знать SQL и уметь с ними работать. Реляционную теорию знать не нужно, нормальные формы никто не спрашивает. Нужно знать, как разделять данные на таблицы и как их соединять через внешние ключи. На практике чаще всего используются INNER JOIN и LEFT JOIN, другие формы использовать не рекомендуется, так как их сложно понимать. В джойнах лучше писать только условие равенства ключей, дополнительные условия лучше писать в WHERE.
В контексте теории баз данных есть распространенное утверждение, что искусственные (суррогатные) автоинкрементные первичные ключи использовать не рекомендуется, лучше найти уникальные естественные ключи. Это не так. В реальности любые 2 объекта могут иметь одинаковые характеристики. Характеристики, которые можно использовать в качестве первичного ключа, это такие же искусственные ключи, просто придуманные для некомпьютерного учета. Обычно они тоже имеют инкрементную природу, например, инвентарные номера или номера телефонов. При этом не нужно использовать номер телефона в качестве первичного ключа для таблицы со списком людей, у человека может быть 2 номера или ни одного. Номер телефона может являться первичным ключом только для таблицы телефонов.
Искусственные ключи, которые уже существуют в предметной области, обычно не оптимальны для производительности, поэтому делают числовой автоинкрементный первичный ключ, а на поле, которое можно считать уникальным, добавляют уникальный индекс. Первичный ключ нужен для самой системы, чтобы можно было программным способом идентифицировать и различать соответствующие объекты, поэтому нужно делать так, чтобы это было удобно с технической стороны.
Случай, где отдельный автоинкрементный ключ использовать не нужно - это промежуточные таблицы для связи многие-ко-многим. Связь подразумевает 2 объекта, которые она соединяет, поэтому первичный ключ для нее состоит из ключей этих объектов. Для других связей промежуточную таблицу обычно не делают, поэтому для них используется первичный ключ основной таблицы.
Cистемы контроля версий
Cистемы контроля версий тоже широко используются. Основные это Git, Mercurial, SVN. Самая распространенная система это Git. Они нужны для хранения истории изменений, отслеживания и управления изменениями, особенно при работе в команде.
Если вы с ними не знакомы, и пробовали разрабатывать какую-то большую программу, то у вас скорее всего была необходимость делать копии текущего состояния, которое точно работает, и на которое можно вернуться, если новые изменения не работают. В результате у вас были папки вида "ProjectName v1", "ProjectName v2", "ProjectName v3". Система контроля версий упрощает эти действия, и имеет более развитые возможности, в том числе для работы многих людей над одним проектом. Нужно знать, что такое коммит, ветка, мерж-реквест, и как с ними работать.
Связанные дисциплины
Физику знать не нужно. Желательно иметь представление на школьном уровне об основных терминах, в основном связанных с электричеством, чтобы понимать, о чем идет речь, если она где-то об этом идет.
Математику подробно знать не нужно. Но ее изучение показывает, насколько хорошо вы можете разобраться в незнакомой информации. Также надо иметь представление об основных концепциях, вдруг где-то понадобится - проценты, синус-косинус, логарифмы, матрицы.
Отдельно надо отметить математику, связанную со сложностью алгоритмов. Нужно иметь представление, что такое сложность алгоритмов, как она оценивается. Обычно в работе это не требуется, но иногда все-таки требуется. Несмотря на это, про нее часто спрашивают на собеседованиях, так как это один из способов проверить хотя бы какие-то знания из области ИТ за несколько минут. Сортировки, деревья, графы. Обычный цикл - линейная сложность, вложенный цикл - квадратичная, дерево или рекурсия обычно логарифмическая, но зависит от ситуации. Лучший и худший случай могут иметь разную сложность. Константный множитель не считается.
В работе более важно не знание чего-то, а умение изучать незнакомый материал. Но чтобы изучать, надо хотя бы что-то знать.
Английский язык
Английский язык желательно знать. Он помогает в чтении документации и при поиске работы. Во многих зарубежных компаниях идет общение на английском, и уровень владения им оценивается на собеседовании.
Процесс поиска работы
У тех, кто еще не искал работу, часто есть неправильное представление об этом процессе.
Кажется, что это происходит так. Вы прочитали объявление "Требуется программист", приходите такие, спрашиваете "Еще ищете программиста? - Да - Я согласен - Знаете то-то и то-то? - Да, там вот так-то и так-то - А вот это знаете? - Нет, но я разберусь - Хорошо, вы приняты, начинайте работать". Такого не бывает.
Обычно происходит так. Компания проводит собеседования пару недель, потом из кандидатов выбирает лучшего. Даже если вы ответили на все вопросы, далеко не факт, что возьмут именно вас. Если у другого человека опыт работы на 6 месяцев больше, или есть какие-то дополнительные курсы, проекты, выступления, или он отвечал более подробно и уверенно, возьмут его, а не вас, даже если он проходил собеседование позже. Так, чтобы взяли первого подходящего, происходит крайне редко.
Если вы чего-то не знаете, никто не будет проверять, разберетесь вы или нет. Компания не будет платить вам деньги, чтобы это проверить. Специалисту с хорошим опытом могут поверить, вам без опыта никто не поверит. Поэтому и нужно знать хотя бы один распространенный фреймворк для вашего языка, так выше шансы получить работу, где он используется.
Иногда не берут никого из первых кандидатов и продолжают искать, месяц, два, или дольше. Потому что уволить плохого специалиста не так просто, проще подождать и взять нормального.
Собеседований может быть одно или несколько. Обычно сначала разговор с HR, потом техническое собеседование с программистом, чаще всего с руководителем команды (тимлидом). В небольших компаниях может быть одно сразу техническое, в больших 3-4.
HR-специалисты бывают не всегда компетентны. Технические специалисты, которые проводят собеседование, иногда бывают неприятными в общении людьми, пытаются показать превосходство, задают слишком сложные вопросы, спрашивают не то, что нужно в реальной работе. Надо понимать, что так бывает. C HR-специалистами после приема на работу вы обычно не будете сталкиваться, а вот если вам встретился такой технический специалист, то надо подумать, действительно ли вы хотите работать в такой компании.
Заведите аккаунт на GitHub или Bitbucket, напишите пару небольших проектов с хорошо оформленным кодом и выложите туда, добавьте ссылку в резюме. Тестовые задания тоже обычно просят выложить на GitHub.
Пока у вас нет опыта, берите любые тестовые задания. Это даст вам представление, какие задачи вообще бывают. Нормальное тестовое задание можно сделать за один вечер. Тестовые задания на неделю это странно, такие компании лучше избегать. Можно сделать такое задание из интереса, но не отправлять результат. Иногда дают небольшое задание, и разрешают прислать в течение недели, это нормально.
В тестовом задании важно не только то, что оно должно работать, а еще и стиль кода, структура классов, насколько код понятен и легко читается. Не нужно комментировать каждую строку, это наоборот минус. Нужно выравнивать отступы, понятно называть переменные, классы и методы, разбивать большой код на разные методы, выносить группы связанных методов в разные классы. Нужно использовать общепринятые подходы, даже если для небольшого задания они кажутся избыточными. Тут есть сложность, что если нет опыта, то непонятно, какие подходы общепринятые. Тут ничего не сделаешь, нужен хотя бы косвенный опыт. Уточняйте у проверяющего, что было не так с тестовым заданием, читайте технические книги и статьи, изучайте код open-source проектов, пробуйте сами что-то писать.
Часто на собеседованиях спрашивают, есть ли у вас вопросы. Говорят, что если ничего не спрашивать, то это минус, будто бы показывает, что вы не заинтересованы. Это конечно не так, пока нет опыта, хоть какую-то работу бы найти, но не все HR-специалисты это понимают. Я обычно спрашиваю, сколько человек работает в команде, и еще что-нибудь по ситуации.
Если у вас уже есть какой-то небольшой опыт тут и там, возникает желание добавить всё в резюме. Частая смена места работы у HR вызывает подозрение. Это может говорить о том, что вы плохо взаимодействуете с коллективом и не можете удержаться на одном месте. 2 года и больше на одном месте считается нормально, 1 более-менее, меньше 1 уже странно. Пока у вас мало опыта, объясняйте в описании каждого места, почему ушли - может это был небольшой разовый проект, и вы его завершили, или зарплату платили меньше, чем обещали. Подумайте о том, чтобы объединить несколько мест в одно с названием типа "Разовые проекты" или "Фриланс", без лишних подробностей.
Отзываться плохо о бывших коллегах не рекомендуется, особенно в разговоре с HR. Если на прошлом месте работы были проблемы с поддержкой плохого кода, ищите нейтральные формулировки, или просто не сообщайте подробностей. В разговоре с программистом можно осторожно обсудить технические недостатки решений, он хотя бы поймет. Но без особой причины тоже лучше не нужно. Идеального кода не бывает, везде есть какие-то недостатки, вопрос только в том, насколько приемлемо их количество.
Процесс работы
После приема на работу вы будете работать в команде, поэтому умение взаимодействовать с людьми очень важно. Это называется soft skills. Их проверяют на собеседованиях. Нужно уметь вежливо общаться, защищать свою точку зрения без грубости, даже если кто-то грубит вам, нужно уметь слушать и не перебивать, давать высказать другому человеку его мысль, нужно уметь идти на компромиссы, принимать другую точку зрения, и делать что-то, с чем лично вы не согласны.
Практически на любой работе есть процесс код-ревью. Вы сделали свою задачу, написали код, создаете мерж-реквест с изменениями, и кто-то из других программистов его просматривает. Для этого используются системы контроля версий и связанные с ними инструменты. Код должен не только работать, но и быть понятен для других. Потому что потом задача на изменение этого кода может попасть к другому программисту, и для компании лучше, если он не будет тратить время на то, чтобы разобраться, что вы там написали. Во время код-ревью проверяется соответствие общепринятому стилю, структура и понятность кода, код анализируется на возможные ошибки.
Можно также отметить процесс тестирования. Для кода часто делают юнит-тесты, они находятся вместе с основным кодом проекта, их пишут программисты. В тесте задаются правильные входные и выходные данные для какого-то кода, это гарантирует, что если в дальнейшем при внесении изменений в этот код будет допущена ошибка, из-за которой выходные данные изменятся, то это будет заметно. Такие тесты запускаются перед каждой выкладкой новых изменений на рабочий сервер ("в продакшн"), а также сразу при создании мерж-реквеста.
Кроме этих тестов есть отдел тестирования. Тестировщики тестируют работу проекта с точки зрения пользователя, они проверяют основные сценарии вручную или с помощью специальных автотестов, которые управляют браузером или окном приложения и имитируют взаимодействие пользователя с элементами интерфейса. Иногда такие тесты тоже пишут программисты.
Задачи назначаются в трекере задач, их много разных, самый популярный это Jira. У задачи есть номер, обычно его нужно указывать в сообщении коммита. Так другие программисты в дальнейшем смогут найти, почему было сделано какое-то изменение в коде. Часто есть требование заносить в задачу примерное время, которое на нее было потрачено. Это нужно для отчетов и планирования, в нормальных компаниях никто у вас не будет спрашивать доказательства, почему вы потратили 2 часа вместо 1. Некоторые компании требуют устанавливать средства контроля, которые делают снимки экрана, чтобы проверить, что вы действительно работали, их лучше по возможности избегать. Уточняйте это на собеседованиях.
Часто используется подход, когда рабочий день начинается с общего созвона через интернет или сбора в офисе, где все рассказывают, что они делают, какой прогресс по задачам, и есть ли какие-то проблемы или вопросы.
Удаленная работа практически ничем не отличается от офисной, только в офис ходить не надо. Обычно есть рабочий чат, где можно обсудить любые вопросы.
Книги
Могу посоветовать 3 книги, которые стоит прочитать:
Макконнелл - Совершенный код
Гамма, Хелм, Джонсон, Влиссидес - Приемы объектно-ориентированного проектирования. Паттерны проектирования
Эванс - Предметно-ориентированное проектирование (Domain-Driven Design, DDD): структуризация сложных программных систем
Комментарии (55)
maisvendoo
02.04.2024 17:10+7Реляционную теорию знать не нужно
...Физику знать не нужно.
...Математику подробно знать не нужно.
Ничего знать не нужно...
michael_v89 Автор
02.04.2024 17:10Программирование знать нужно)
maisvendoo
02.04.2024 17:10+3Программирование бывает разное. Может вебщикам на "пыхе" клепающим CMS-ки для сайтиков интернет магазинов и достаточно знать таблицу умножения, я не знаю, бесконечно далек от веба, не интересно. Но программирование не ограничивается сайтиками и php, там есть масса отраслей, где и физику и математику знать надо.
И вообще - программирование это скорее не сколько наука, сколько ремесло. А любое ремесло, опирается на фундаментальные основы той предметной области, в которой используется.michael_v89 Автор
02.04.2024 17:10+1Я же не сказал, что таких отраслей вообще нет, я описал ситуацию в среднем. Понятно, что всегда можно найти исключения, все знают, что есть NASA, и там физика для программ нужна, и т.д. Просто даже если все будут знать физику и математику, то столько программистов таким отраслям все равно не нужно, и большинство будет работать в других. Будет неплохо, если вы поделитесь описанием, где это требуется, и что именно надо знать.
werevolff
02.04.2024 17:10Идеальный скилл-сэт для продавца Пятëрочки.
З.Ы. это при том, что я, не имея высшего образования, ориентируюсь в области принципов построения реляционных БД, физики, математическом анализе. А вы приходите в ВУЗ и учите тому, что ничего из этого знать не нужно! Так может, следуя вашей логике, следует закрыть факультеты, которые готовят программистов? А то, смотрю, вузовские разработчики в последнее время лавируют между "институт даëт хорошую базу" и "я учу своих студентов, что математику знать не нужно".
michael_v89 Автор
02.04.2024 17:10+6это при том, что я, не имея высшего образования
То есть вы в вузе это не изучали, и это не помешало вам работать программистом и изучить это всё по ходу дела, при приеме на работу у вас этих знаний не требовали. Это только подтверждает мои слова.
ориентируюсь в области принципов построения реляционных БД, физики, математическом анализе
Ну так разговор же не о том, в чем вы ориентируетесь, а о том, как часто вы используете эти знания в работе программистом.
"Ориентироваться в области" и "хорошо знать" это все-таки не одно и то же. В статье я указывал примеры, что нужно знать, чтобы ориентироваться в области.Так может, следуя вашей логике, следует закрыть факультеты, которые готовят программистов?
Это не моя логика. Если честно, я не вижу логики в утверждении "Программистам физика обычно в работе не требуется, значит надо закрыть факультеты, которые готовят программистов".
werevolff
02.04.2024 17:10+1То есть вы в вузе это не изучали, и это не помешало вам работать программистом
Не совсем так. Это не мешает начать кодить. Однако, без этих знаний вы не будете программистом. Только кодером.
Ну так разговор же не о том, в чем вы ориентируетесь, а о том, как часто вы используете эти знания в работе программистом.
Кроме физики, остальные знания используются довольно часто. Несколько раз в день. Реляционная теория нужна для проектирования таблиц БД с учëтом нормализации и оптимизации выборки. Математика, в той или иной мере, используется при выборе алгоритмов. Есть огромная разница между человеком, который может прокрутить в голове различные параметры качества выбранного алгоритма, или оценить применимость выбранной структуры данных, и человеком, который не может этого сделать.
Что же касается физики, то, как минимум, понимать принцип работы компьютерного железа, человек обязан. Трудно работать с программистом, который считает, что в ОЗУ сидят волшебные феи, которые запоминают целые слова и картинки. Не так ли?
Если честно, я не вижу логики в утверждении "Программистам физика обычно в работе не требуется, значит надо закрыть факультеты, которые готовят программистов".
Видимо, это связано с вашими утверждениями о том, что математика программистам не нужна. Поскольку, следуя вашему повествованию, получается, что вы ходите в ВУЗ, чтобы рассказать студентам о том, что они получают там бесполезные знания. Хотя, по сути, можно найти кучу примеров, когда простейшие знания математики или теории реляционной модели данных позволяют быстро и эффективно найти решение задачи.
polearnik
02.04.2024 17:10+3Я знаю как работает ОЗУ но за все время работы програмистом все что мне понадобилось узнать это обший обьем этой самой ОЗУ . Если бы я думал что для программы не хватает фей чтоб ее обслужить и надо или добавить коробочку фей или оптимизироваь программу то ничего бы не поменялось.
event1
02.04.2024 17:10+1Ну теперь кафедры физики и схемотехники можно смело распускать. Наконец-таки в древнем споре поставлена точка! Человеку из интернета не понадобилось знание о том, как работает ОЗУ! Это явно доказывает, что знание это лишнее, и его можно не знать.
polearnik
02.04.2024 17:10схемотехника и програмирование немного разные вещи. зачем закрывать кафедры непонятно .пусть выпускают физиков и схемотехников. вопрос зачем это надо програмистам остается открытым. математику сюда приплетать надо только в случае если переобучаются математики. ДЛя того чтоб вырастить програмистов достаточно програмисткой фигни и доп нагрузки в виде устройства компа и истории кпсс добавлять не надо
event1
02.04.2024 17:10вопрос зачем это надо програмистам остается открытым
Обоснование вида "мне не пригодилось, значит никому не надо" просто антинаучно
ДЛя того чтоб вырастить програмистов достаточно програмисткой фигни
Много ли вы вырастили программистов? Каковы их успехи? Откуда вы тогда знаете, чего достаточно для того, чтоб их вырастить?
polearnik
02.04.2024 17:10вот 5-го обучаю. 4 предыдущих успешно работают мидлами. затыки случаются но достаточно сказать как гуглить проблему или скинуть особо удачную статью на эту тему. я понимаю что часть знаний у них на уровне магии но и я не очень понимаю как устроен процессор . мне достаточно что если я его прошу поделить 2 числа то он возвращает правильный результат . а как там это происходит внутри него мне не важно
piton_nsk
02.04.2024 17:10доп нагрузки в виде устройства компа
Возможно это снова вопрос определений, что именно такое "устройство компа". Но архитектура ЭВМ и ассемблер нужны чтобы лучше понимать код. По моему опыту люди без таких знаний не понимают указатели и кодировки строк. Реальный пример из жизни - чел читает строку из файла, там крокозябры, полнейший ступор, решение типа "посмотри какая кодировка и укажи явно при вызове функции" не понимает, что делать не знает в принципе, вообще глухо.
michael_v89 Автор
02.04.2024 17:10Однако, без этих знаний вы не будете программистом.
Мы будем таким же программистом, как и вы, и точно так же узнаем их во время работы.
Реляционная теория нужна для проектирования таблиц БД с учëтом нормализации и оптимизации выборки.
По моему опыту это всегда была логическая связь и техническая необходимость. Я не знаю на память теоретические определения нормальных форм, и в работе это не требуется.
Математика, в той или иной мере, используется при выборе алгоритмов.
Ну я вот выбираю алгоритм "Оплатить заказ, отправить пользователю письмо о заказе" или "Отправить пользователю письмо о заказе, оплатить заказ". Как мне математика в этом поможет?
как минимум, понимать принцип работы компьютерного железа, человек обязан
Обычно это более высокоуровневые знания, чем университетский курс физики.
Не так ли?
Да нет, если в работе это не мешает. В разговорах обычно подразумевают, что данные записываются в оперативную память, без деталей как именно это происходит. Пусть и феями. Это и называется "абстракция")
В случае чего говорим "Да ты что, какие феи, там ячейки памяти, которые подпитываются электричеством, данные состоят из 0 и 1, и в ячейках это задается как "есть заряд" и "нет заряда"". Если он это не понял, значит он плохой программист.
что вы ходите в ВУЗ, чтобы рассказать студентам о том, что они получают там бесполезные знания
Я не хожу в вуз, это была идея, которая никогда не случилась на практике. И да, некоторые знания бесполезны. Но процесс получения некоторых знаний небесполезен.
Хотя, по сути, можно найти кучу примеров
Хорошее замечание, давайте обсудим. Приведите пожалуйста несколько примеров.
werevolff
02.04.2024 17:10Ну я вот выбираю алгоритм "Оплатить заказ, отправить пользователю письмо о заказе" или "Отправить пользователю письмо о заказе, оплатить заказ". Как мне математика в этом поможет?
Как в том анекдоте: если бы этот дуб умел говорить, Наташа, он бы сказал, что он - тополь.
Математика здесь вам поможет понять, что обозначенный вами юз-кейс не является алгоритмом в контексте написания программирования. Программисты под "алгоритмами" понимают последовательность операций в коде для получения требуемых значений. Например, результатов поиска, ближайших адресов или отсортированного списка.
michael_v89 Автор
02.04.2024 17:10+1У слова "алгоритм" есть общепринятое определение, это порядок действий для решения задачи.
"Cовокупность точно заданных правил решения некоторого класса задач или набор инструкций, описывающих порядок действий исполнителя для решения определённой задачи."
В данном случае задача это создание заказа. Порядок действий для ее решения это алгоритм. Надо понимать, почему надо сначала сохранить данные, а потом отправлять письмо, а не наоборот, и уметь выразить это в программном коде. А математика в этом не помогает.
SwetlanaF
02.04.2024 17:10+1Чисто ради информации. В курсе "Теория алгоритмов" в самом начале первой лекции рисуют классификацию ЯП в зависимости от математической модели алгоритма (детерминированная машина Тьюринга, частично-рек. функция, исчисление предикатов). Для языков процедурных определением алгоритма является тезис Тьюринга, т.е. в рамках этой мат.модели алгоритм - ДМТ- программа. В школьном определении алгоритма тоже говорится гораздо больше. Что алгоритм должен выполняться детерминированно, что должен существовать формальный исполнитель, способный выполнить инструкции и проч.
werevolff
02.04.2024 17:10+1Такое ощущение, что автор живëт в США или Канаде, и у него на момент публикации было 1 апреля. Потому, что читать этот жирный троллинг от 2 апреля - это too much!
ZirakZigil
02.04.2024 17:10Однако, без этих знаний вы не будете программистом. Только кодером.
Если не сложно, изложите набор критериев, по которым определяется программист. Если вдвойне не сложно, объясните свой выбор.
werevolff
02.04.2024 17:10Программирование - это процесс создания программного обеспечения. Само словосочетание "программное обеспечение" состоит из двух слов. Хотя, по множеству ГОСТов и ISO стандартов, "Программа" и "Программное обеспечение" взаимозаменяемые, словосочетание является составным. Слово "обеспечение" означает "продукт". Ещë, можно сказать, что это некоторый код, выполняющий какую-то работу. В английском эквиваленте - это -ware из слова Software.
А вот слово "программное", или Soft из слова Software означает некоторые качественные признаки Программы. То есть, совокупность данных, инструкций, алгоритмов и архитектуры. Соответственно, скрипт, выполняющий некую работу, является, в большей степени текстом, продуктом работы кодера. Он представляет собой Программное Обеспечение только тогда, когда рассматривается в совокупности с алгоритмами, архитектурой, входными и выходными данными.
Поэтому, вполне очевидно, что программист - это специалист, разрабатывающий и/или прорабатывающий весь состав Программного Обеспечения. И ТС, когда рассказывает о своей опыте, явно упускает простой момент: он не прорабатывает используемые алгоритмы, не строит определëнную архитектуру. Даже не задумывается об окружении и экосистеме, в которой выполняется его код. Он просто использует готовые решения и пишет простые скрипты для их интеграции. Соответственно, его код можно назвать Программным Обеспечением с большой натяжкой. Точнее, можно, но, скорее-всего ему либо спускают алгоритмы лиды, и он не видит результат в целом, либо пишет сам, но его код может не пройти стандартные экспертизы качества и состава. Кодер не прорабатывает совокупность составляющих ПО. Он пишет скрипты. Программист делает программный продукт, то есть, прорабатывает алгоритмы, входные и выходные данные, архитектуру, тесты, скрипты и инструкции для инфраструктуры и т.д.
michael_v89 Автор
02.04.2024 17:10простые скрипты для их интеграции
Любая программа на любом уровне абстракции это лишь интеграция более низкоуровневых готовых решений. Программа на ассемблере это скрипт для интеграции готовых машинных команд.
А вот слово "программное", или Soft из слова Software означает некоторые качественные признаки Программы.
У слова Soft из слова Software есть вполне определенное словарное общепринятое значение. Оно используется как противоположность слова Hard (железо). Ваше значение вы придумали сами.
он не прорабатывает используемые алгоритмы, не строит определëнную архитектуру
Прорабатываю и строю, просто для этого мне не нужны те теоретические знания, которые давали в университете. Странно, что вы всему обучились без университета, но отказываете другим в этом праве.
werevolff
02.04.2024 17:10Ваше значение вы придумали сами.
Нет, приводимое мной значение является компиляцией определения слову, данное Робертом Мартином в книге "Чистая Архитектура", а также, ГОСТ 19781—90, ГОСТ Р 51904-2002, ГК РФ ст 1261.
Это вы ваши инфоцыганские песни придумываете сами. А я вам даю только проверенную и качественную информацию. Можете открыть книгу, открыть стандарты и убедиться.
Странно, что вы всему обучились без университета, но отказываете другим в этом праве.
От выпускников технических ВУЗов на собесах я не жду, что они будут вкатываться в IT. Они должны приходить с базой. Для вкатывающихся джунов или стажëров другие критерии. Но, опять же, в долгосрочной перспективе они либо заполнят пробелы в знаниях, либо окажутся "не вкатившимися".
michael_v89 Автор
02.04.2024 17:10данное Робертом Мартином в книге "Чистая Архитектура", а также, ГОСТ 19781—90, ГОСТ Р 51904-2002, ГК РФ ст 1261
ГОСТ 19781—90
Программа - Данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма
Программное обеспечение - Научная и практическая деятельность по созданию программ
Программирование - Совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программГОСТ Р 51904-2002
программное обеспечение (ПО): Совокупность компьютерных программ и программных документов, необходимых для эксплуатации этих програмГК РФ ст 1261
Программой для ЭВМ является представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств в целях получения определенного результата.В книге Мартина именно определений я не нашел. Про программное обеспечение там написано следующее.
"Компьютерная программа — это подробное описание политики преобразования входных данных в выходные"
"Первая ценность программного обеспечения — его поведение."
"Вторая ценность программного обеспечения заключена в самом названии «программное обеспечение» Слово «обеспечение» означает «продукт»; а слово «программное»... Как раз в нем и заключается вторая ценность. Идея программного обеспечения состоит в том, чтобы дать простую возможность изменять поведение компьютеров. Для достижения этой цели программное обеспечение должно быть податливым — то есть должна быть возможность легко изменить его."Ссылку не привожу, так как книга защищена авторским правом.
В этих определениях нет ничего про "качественные признаки" или "прорабатывание алгоритмов".
Приведите пожалуйста цитаты из сторонних источников, где указано ваше значение слова "Soft".
Они должны приходить с базой.
База это то, без чего нельзя делать определенные действия. Если без знания определений нормальных форм можно проектировать структуру таблиц в реальной СУБД, значит это не база.
Пока что выглядит так, что вы путаете теоретические знания и практические навыки, и возмущаетесь тем, что я как будто бы предлагаю не иметь практических навыков. Практические навыки нужны, а реляционную теорию никто не спрашивает, это факт.werevolff
02.04.2024 17:10В этих определениях нет ничего про "качественные признаки" или "прорабатывание алгоритмов"
Простите, но обычно, в этом случае у таких как вы спрашивают по поводу любовных утех посредством органов зрения.
Программное обеспечение - Научная и практическая деятельность по созданию программ
Программа - Данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма
Программирование - Совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ
Программой для ЭВМ является представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств в целях получения определенного результата.
Что же касается Мартина, то если бы ваши очи не были такими "замутнëнными", то они бы заметили, что слово "Программное" Или Soft Мартин связывает с архитектурой ПО. Собственно, вам достаточно было просто ознакомиться с обложкой книги, чтобы найти на ней слово на букву "А". Впрочем, полагаю, что и Русский Язык вы считаете "ненужным".
michael_v89 Автор
02.04.2024 17:10Ну то есть цитат у вас нет, вы сами додумали, как понимать написанное. То, что вы выделили, прекрасно применимо и к скрипту, выполняющему некую работу, который вы противопоставляете термину "программное обеспечение". Любой скрипт обрабатывает информацию в целях реализации определенного алгоритма и является совокупностью данных и команд.
Впрочем, полагаю, что и Русский Язык вы считаете "ненужным".
Неправильно полагаете. Я уже говорю это второй раз, поэтому предлагаю вам попробовать понять, о чем пишет собеседник, а не спорить с тем, что вы сами придумали.
k4ir05
02.04.2024 17:10+3Нужно знать, как разделять данные на таблицы и как их соединять через внешние ключи.
Как вы это предлагаете делать без знаний реляционной модели и нормальных форм?
polearnik
02.04.2024 17:10почитать статьи в интернете? ТАм же прочитать что чаще всего надо наоборот денормализовать данные чтоб быстрее запросы выполнялись. и тут оказывается что знание математики не нужно. прочитать статью где обьясняются джойны на примере диаграмм вьете гораздо быстрее и полезнее чем изучать всю область математики
werevolff
02.04.2024 17:10А в диаграммах объясняется, какой индекс лучше выбрать для поиска по связанным таблицам? Или, может, есть предостережение о декартовом произведении?
michael_v89 Автор
02.04.2024 17:10Очень просто, берешь и делаешь) Так же как мы в коде без реляционной теории выделяем классы с набором свойств. На практике это сводится к действию "указать id из одной таблицы в полях другой таблицы", достаточно понять, что это просто ссылка на данные.
k4ir05
02.04.2024 17:10Это просто если доменная модель простая. Значит, предлагаете самостоятельно "переизобретать велосипед" методом проб и ошибок.
michael_v89 Автор
02.04.2024 17:10Хорошо, сможете привести пример сложной доменной модели, для создания которой в БД нужны именно теоретические знания, включая определения нормальных форм, и которая не сводится к "указать id из одной таблицы в полях другой таблицы"?
werevolff
02.04.2024 17:10Фактически, для большинства баз данных, так или иначе требуется проработка. От журнала дежурств на складе - и до электронного дневника. Вы просто не понимаете необходимость нормализации, но это не проблема архитекторов - только ваша. Вы - не первый, кто кричит о том, что БД можно запилить на коленке. И не первый, кого эта коленка выставляет за дверь организации, когда заказчик понимает реальный уровень специалиста, накодившего ему не обслуживаемое решение.
michael_v89 Автор
02.04.2024 17:10Меня пока еще никто не выставлял за дверь, заказчики довольны качеством моей работы.
Я понимаю необходимость нормализации, я говорю о том, что теоретические определения нормальных форм для практического умения делать нормализацию не требуются. Просто у вас похоже какое-то свое понимание того, что такое теоретические знания.
werevolff
02.04.2024 17:10Меня пока еще никто не выставлял за дверь, заказчики довольны качеством моей работы
Ну это вы так говорите. А в других статьях на тему того, что должен знать младший программист, или какая сейчас ситуация на рынке, прямым текстом пишут, что такие "не знающие" Специалисты сейчас никому не нужны. Так что, годика два назад я бы с вами согласился. А сейчас, стажëров нанимают работать бесплатно. И, если они после стажировки не будут готовы рассказать минимум на собесе, то пойдут ещë работать бесплатно.
Такими темпами, будет очень хорошо, если люди, придерживающиеся вашего кодинг-гедонизма, не будут через год доплачивать за стажировку.
michael_v89 Автор
02.04.2024 17:10Приведите пожалуйста ссылки и цитаты на эти статьи, где пишут, что специалисты должны знать теоретические определения нормальных форм.
В таких статьях пишут про незнание практических навыков. И как раз наоборот говорят, что есть много кандидатов, которые зазубрили теорию, но не знают, как применять ее на практике.
В очередной раз убеждаюсь, что вы неправильно представляете, что такое реляционная теория, а также путаете понятия "знать" и "ориентироваться в области", и предполагаете, что я говорю, что даже ориентироваться в области не нужно, что конечно же не так.
hoack
02.04.2024 17:10Для создания модели знания о нормальных формах не нужны. Для грамотного дизайна схемы базы данных необходимо понимание того, что такое нормализация, а также когда и почему от нее нужно отказаться.
michael_v89 Автор
02.04.2024 17:10Все верно, только для этого не нужны теоретические определения нормальных форм. Главное понять концепцию. Выделяем сущности, делаем для них таблицы. Если часто нужна агрегация типа количества, сохраняем ее куда-нибудь. Иногда это может быть поле родительской таблицы в СУБД, иногда кеш вне СУБД.
k4ir05
02.04.2024 17:10Так проектирование БД никогда к этому не сводится. Прежде, чем связывать таблицы, нужно ведь определить эти таблицы. И нормальные формы описывают как это делать целесообразней.
Простой пример - журнал автосервиса. Вы же не станете хранить данные автомобиля и информацию об обслуживании в одной таблице? Иначе это будет нарушением 1НФ.
Недавно тут как раз была статья. Тоже наглядный пример даже на не сложной модели.
michael_v89 Автор
02.04.2024 17:10+1И нормальные формы описывают как это делать целесообразней.
Нет, не описывают. Таблицы определяются предметной областью и технической необходимостью.
Приведите пожалуйста пример задачи, где вам надо было знать, чем отличается 3НФ от 4НФ (или любые другие), которую вы бы не смогли сделать, или сделали хуже, или потратили больше времени, если бы не знали.Вы же не станете хранить данные автомобиля и информацию об обслуживании в одной таблице? Иначе это будет нарушением 1НФ.
Я не стану так хранить данные, потому что это будет неправильная модель или это будет неудобно обрабатывать технически. Какое там у 1НФ определение, на мое решение не влияет.
А вот для заказа надо дублировать цену товара, потому что в товаре она со временем изменится, а в заказе должна остаться какая была на момент заказа.Тоже наглядный пример
Пример чего именно? Я там не вижу необходимости знать нормальные формы или другую информацию из реляционной теории.
piton_nsk
02.04.2024 17:10Как вы это предлагаете делать без знаний реляционной модели и нормальных форм?
Как человек, который сдуру когда-то изучал реляционную теорию, ответственно заявляю - все необходимые знания реляционной теории можно изложить за час. Современные БД бесконечно далеко ушли от голой реляционной теории.
k4ir05
02.04.2024 17:10Разве? В MySQL, PostgreSQL и т.п. реляционная теория не работает?
piton_nsk
02.04.2024 17:10+1Есть множество вещей, который к реляционной алгебре отношения не имеют, но которые надо знать - индексы, вьюхи, хранимки, триггеры, права доступа, профилирование. Есть специальные типы данных - xml, json, spatial. Есть более специфические СУБД - графовые, key-value, объектные, time-series. Есть в реляционной алгебре, к примеру, операция деления, а в СУБД ее нет. В SQL есть аггрегаты, который в РЛ нет и т.д. и т.п. Да и вообще говоря таблица это не совсем отношение из реляционной алгебры.
Поэтому достаточно дать историческую справку откуда что пошло. А дальше уже учить как непосредственно SQL, так и СУБДшные штучки типа триггеров и разграничений прав доступа.
piton_nsk
02.04.2024 17:10+1Ничего знать не нужно...
Физика не нужна кроме редчайших случаев. Да и в редчайших случаях надо знать скорее математику, типа как дифуры численно считать.
Про математику тут скорее вопрос определений, что именно значит "подробно". Тем более что в среднем техническом ВУЗе все равно в математику глубоко не залазят. Поэтому получается что для серьезных вещей знаний все равно мало, а для типичных айтишных задач условное ТФКП не нужно.
michael_v89 Автор
02.04.2024 17:10для типичных айтишных задач условное ТФКП не нужно
Да, я это и подразумевал под словом "подробно", в качестве примера подробностей представлял как раз ТФКП) Ее изучают в курсе математики, но если не знаете ТФКП, то все равно можно нормально работать программистом.
NeoCode
02.04.2024 17:10+7Я бы сказал так. Современный мир предоставляет просто роскошные возможности учиться. Такого реально никогда не было. Разнообразные мобильные устройства с огромной вычислительной мощностью, высокоскоростной интернет, любые лекции на ютубе, любые электронные книги, любые профессиональные форумы, искусственный интеллект который ответит на любые вопросы и разжует любую непонятную информацию. Поэтому - если вы студент - пользуйтесь моментом.
Учите программирование, что бы там ни говорили про то что ИИ вытеснит программистов. Учите много, разные языки, разные платформы одновременно. Отдавайте предпочтение более высокоуровневому, но знайте и низкоуровневое. Отдавайте предпочтение более фундаментальному (теория, алгоритмы, структуры данных, ООП, ФП...), но знайте и прикладное.
Учите иностранный язык (хотя опять таки можно сказать что ИИ переводит лучше человека, как минимум быстрее). В современном мире это очень важно. mp3-плеер с аудиокнигами на иностранном языке должен быть с вами в дороге всегда.
Учите фундаментальную науку. Математика всех направлений (физика тоже нелишняя, т.к. она на 90% тоже математика). Языки программирования приходят и уходят, а вот математика вечна. И мало того что она - отличная разминка для мозгов, так еще и вполне может оказаться нужна на практике.
Устанавливайте контакты с преподами (особенно с теми которые сами имеют много контактов, в т.ч. зарубежных), участвуйте во всяких научных проектах на кафедре, если есть возможность участвовать в программах студенческого обмена - тоже участвуйте.
Ну и гуманитарные знания тоже не стоит отбрасывать. Сейчас большинство ВУЗов имеют статус университета, а университетское образование на то и университетское, что универсальное. Гос.пропаганду, которую сейчас стали преподавать, конечно фильтруйте, а в целом такие науки как философия, психология, социология, экономика - весьма полезны для общего развития.
Не спешите зарабатывать бабки в ущерб учебе. Заработать всегда успеете, а вот незаконченное высшее образование это полная фигня. А диплом - это своеобразный пропуск в другой мир. Пусть не в высшую элиту, но все-же.
Если есть возможность выбирать где подрабатывать, сразу предпочитайте удаленную работу (лучше международную), фриланс или даже собственный бизнес. Приучайтесь к лучшему, в офисе успеете насидеться.
c0r3dump
02.04.2024 17:10+4Предлагаю добавить ещё про важность знания английского языка хотя бы в достаточной мере чтобы понимать документацию, книги и лекции - не ждать же пока для вас все переведут, а многое и никогда не переведут. Я сам самоучка, из "не благополучной семьи", в свое время пришлось убежать из дома в 17 лет, не окончив даже 11 класс школы, конечно же никакого институтского образования. Способность к языкам сильно помогла мне выжить, я собственно так и выучил вначале английский на практике, из-за не желания ждать пока интересующие меня книги по интересным фреймворкам и технология. переведут на русский. В то время (середина 200х) это был Ruby on Rails и пока на русский переводили книгу, могла выйти уже новая мажорная версия и информация устаревала быстро. Сейчас и того быстрее. Ну и можно сравнить количество ответов по той или иной теме на stackoverflow на английском и др. языках, и станет ясно. Также рекомендую сразу ставить локаль английскую во всем софте и ОС. Это просто вопрос эффективности. Также можно сравнить количество результатов поисковой выдачи если загуглить сообщение об ошибке на английском и русском. Если с переводом документации и тп ещё может помочь chatgpt и аналоги, то при поиске по конкретному сообщению об ошибке это уже сложнее тк перевод бывает разный и точно предсказать текст оригинала по переводу не всегда возможно. Номера ошибок и названия классов исключений помогут, конечно, но они есть не везде.
Также это поможет при устройстве в международные компании.
Gremlinquisitor
02.04.2024 17:10+2В общих чертах расписано толково.
Конечно, в каждой области свои нюансы. Физика и математика не так нужны на фронте и многих частях бэка, однако порой профиль компании предполагает их знание. Поэтому лучше учить, пока есть возможность.
Меня после вуза сильно выручили полтора года "фриланса" - время, когда я с друзьями дополнял наш ролевой сайт написанными мною же на PHP модулями (а-ля внутренний магазин, всякие мини-игры и ивенты тематические), когда на JS клепал скрипты всякие. Т.е. уже хоть что-то, а не девственная пустота в резюме и скромное "Теремок" в трудовой. Главное расписать с нужных ракурсов.
Автор не упомянул, но язык нужен (если, конечно, вы не 1С выбрали). Английский. Хоть какой. Просто потому что переменные а-ля chisloOdin и функции poschitai выглядят отвратно. Да и читать документацию порой приходится. И код чужой. Переводчики, конечно, сейчас удобные, но не всегда точные и не всегда под рукой.
iamoutsidious
02.04.2024 17:10На мой взгляд получилась слишком одностороннем позиции, которая релевантна для автора, но никак не может транслироваться как что-то универсальное для всех начинающих разработчиков. Попытки "усреднить", что что-то нужно, а что-то не нужно, что серверный язык генерирует html, по процессам собесов и т. д. возможны с очень большими, что так очень далеко не везде и подробным описанием бэкграунда и области автора
michael_v89 Автор
02.04.2024 17:10+1Это описание того, что большинство студентов может ожидать в реальной работе. Для примера можно открыть hh.ru и проверить описания вакансий на первой странице. Исключения есть всегда, но их немного.
sedyh
Go - высокоуровневый язык.
michael_v89 Автор
Ну если сравнивать Go и Java, то Go все-таки можно считать более низкоуровневым, как мне кажется. А так конечно, по сравнению с машинным кодом все языки это языки высокого уровня.
rukhi7
есть очень простой критерий "низко-уровневости": вставки на ассемблере можно писать или целые функции? Если можно, то язык низкоуровневый, по моему вполне логично.
werevolff
Низкоуровневые и высокоуровневые языки отличает уровень абстракции.
Низкоуровневые языки позволяют писать код, используя только машинные команды для его аллокации и выполнения. То есть, это языки, которые позволяют работать напрямую с устройством выполнения, посредством команд.
Высокоуровневые языки обладают набором инструментов в компиляторах и интерпретаторах, которые позволяют вынести процесс написания машинных команд для часто встречающихся абстракций, под капот. То есть, предлагают абстракции, которые позволяют писать более человекочитаемый код. Например, если вам не нужно выделять вручную область памяти для инкапсуляции, а достаточно просто написать class или struct, определив в нëм области видимости свойств и методов, то это абстракция над машинным кодом. Аналогично, абстрагированию поддаются монады, полиморфизм, реализация структур данных и т.д..
Высокий или низкий уровень языка определяется не просто вставками на ассемблере, а общим стилем написания кода. Либо код, в большей степени, построен на использовании абстракций, либо предлагает выполнять машинные команды для управления устройством исполнения. Так-то, теоретически, мы можем сделать расширение для любого высокоуровнего языка, чтобы на нëм можно было напрямую выполнять машинные команды. Но это не сделает язык низкоуровневым, поскольку, он, так или иначе, будет иметь большой стек абстракций, позволяющих уйти от написания машинных команд в любой момент времени.