Полнится интернет статьями и перечнями с советами программистам. И я от них наверное не отстану, тоже напишу на эту тему. Но пока поговорим о том что есть. Есть советы хорошие, есть плохие. Есть бесполезные. Есть странные. А есть те, от которых мороз по коже бежит. Разберу сегодня перечень, который «порекомендовал» мне Дзен. Прикладываю ссылку на статью если кто-то потом скажет что я вырвал цитату из контекста и вообще идиот. Название многообещающее – «7 профессиональных советов программисту». Ну чтоже – почитаем.
Залог профессионального развития – это постоянная практика. Лучше регулярно программировать, не стоит пускать процесс на самотёк. Возможно получится масса плохих программ с кривым кодом, но с каждым разом удастся извлечь урок и стать немного умнее. Даже понимание, почему программы плохие, является признаком профессионального роста.
Так стоп. Что-то я уже ничего не понимаю. Совет в том чтобы программировать даже вне работы? Странно. Человек, изучающий разработку программного обеспечения или занимающийся этим профессионально – и так постоянно практикуется. Ну да ладно. Предположим. У меня основная претензия в другом. Когда мы ищем себе врача – мы ищем человека, который владеет базовыми знаниями о биологии и медицине. Тоже самое касается буквально любого другого специалиста. Даже дворника мы предпочитаем такого, который знает в каком направлении надо мести улицу. Но когда дело касается программирования – начинается какой-то «ад и израиль». Учись на практике. Пиши код и разбирайся. Эмм. А вы не пробовали сначала базовые знания получить? Нет, не только синтаксис языка. А еще паттерны, базовые знания об архитектуре. Объектный анализ. Алгоритмы. Это всё потом? Ну, отличная идея. Только не надо удивляться тому что трудно найти работу новичку – вы ни хрена не умеете. Да, текст содержит напоминание необходимости учиться, но в финале – «Метод проб и ошибок до сих самый эффективный».
Всегда помните, что программный код – это ваше лицо, смотря на работу сразу вырисовывается представление человека. Стоит выработать особые правила оформления, свойственные именно вам. Главное соблюдать основные правила и подобрать самый удобный стиль. После окончательного подбора стоит придерживаться собственных правил и не менять их.
Вот тут точно пробежал мороз по коже. Представьте проект, на котором работает 5-10 разработчиков (это совсем не много). И у каждого «свой узнаваемый стиль». Ваша работа тут же превратится в ад. Поддержка кода – ад. Ревью кода – ад. Развитие и доработки – ад. В здравом уме вам такое ни один программист не посоветует. Только тот, который хочет, чтобы вас уволили как раковую опухоль команды.
Часто программист смотрит на программный код и понимает, что в нём что-то не так. «Дурной аромат» – это явный признак некачественной программы. Лучше проявить храбрость, полностью стереть его и написать снова.
Благородно конечно. Полезно для проекта. Но вы понимаете, что любую работу этим удваиваете? А еще работаете за другого. Ну хорошо, разок вы исправили. Но если на проекте работает 5 человек. 3 из них пишут ерунду, а вы один из оставшихся двоих, которые храбрые и все переписывают – вы в меньшинстве. Плохой код будет расти раза в 3 быстрее чем исправляться на хороший. Храбрость тут нужна чтобы донести мысль до коллеги – как делать правильно, а не подметать за ним мусор.
Периодически появляется работа, которая явно выходит за пределы знаний и понимания. Хватит паниковать, ведь это отличный способ обогатиться новым, полезным опытом. В будущем проект можно занести в резюме, так удастся выйти на новый уровень. Важно смотреть на проблему с аналитической точки зрения. Сначала создать прототип программы и пошагово достигать поставленной задачи.
Такое ощущение что автор – фрилансер и не понимает что подавляющая часть программистов в мире – офисные служащие. Мне не надо искать возможность занести проект в резюме – я его вношу поскольку я на нем работаю. Ну а последний совет пахнет каким-то нелепым студенчеством. В большинстве случаев программа уже есть. Не прототип и прямо программа. И выполнение поставленной задачи будет выполняться не в рамках прототипа, а в рамках текущего состояния проекта. Вы же не собираетесь создавать прототип с одной фичей, а потом пытаться мигрировать его на рабочий проект? Идея крайне странная.
Специфика информационных технологий заключается в стремительном развитии, в сфере крайне быстро назревают и появляются изменения. Замедление развития IT наступит точно не в ближайшем будущем. Сегодня можно создавать отличные приложения на Паскале для консолей, но количество конечных потребителей будет незначительное.
Ооох. Ну, развитие конечно идет – с этим глупо спорить. Темпы развития – вещь спорная. Например, нам постоянно говорят, что вот-вот придет толпа роботов и мы останемся без работы. Ну да ну да. Только вот первые промышленные роботы были созданы еще в 60-ых. За 60 лет технология конечно развилась, но почему-то крупные компании предпочитают роботизации – дешевую рабочую силу в Азиатских и Африканских странах. О причинах можно долго спорить. Согласно марксисткой теории – прибыль берется из неоплаченного труда рабочих, а у робота нет такого понятия. У него взять нечего. Плюс у нас явно подменили понятие AI-искуственного интеллекта и ML-машинного обучения. Это не одно и то же. Второе действительно развивается довольно бурно, а вот первое…не очень. Ну и последнее – насчет консольных приложений. Во-первых компьютеру плевать на Pascal это приложение или на C++. Во-вторых – а почему собственно количество будет незначительное? Современное программное обеспечение это не только GUI. Например, на моем проекте на одно веб-приложение приходится 20 консольных приложений выполняющих сопутствующие задачи. Синхронизации данных с внешними сервисами, разбор очередей и прочее. Разработка консольных приложений вполне востребована в рамках текущих популярных и востребованных сервисов.
Сегодня сохраняется тенденция перехода инноваций в IT с западных стран. Все лучшие форумы, блоги и документации преимущественно пишутся на английском, так как язык является международным. Английский язык имеет первенство, все инновации сразу появляются на англоязычных сайтах, а техническая документация потребуется всем.
Хоть тут бесспорный полезный совет. Я, правда, не знал двух вещей. Первая – что это совет уровня профессионального программиста, а не очевидная хрень. Вторая – мы этот язык в школе и профессиональных образовательных учреждениях учим. Неужели учат настолько плохо, что техническую документацию читать не получается? Ах да – ведь чтобы стать программистом не нужно учиться. Хватит курсов и книжек по программированию. Ну тогда добавляем еще и книжки и курсы по английскому языку.
Уже сформировано ряд книг, которые являются обязательными к прочтению всем уважающим себя разработчикам. Лучше сделать эти книги настольными и периодически перечитывать их, возможно отдельными главами или полностью.
Согласен с этим пунктом полностью. Правда, учитывая, что было написано выше – я что-то малость сомневаюсь, что автор эти книги сам читал. Список можно и нужно дополнять, корректировать. Плюс нужны пояснения - какая литература подойдет новичку, а какая требует подготовки. Например, совет читать Кнута лично мне слабо понятен, так как книга крайне тяжеловесна и по объему и по качеству содержимого. Может быть перевод плохой. А паттерны проектирования от «банды четырех» не имеют описания практического применения этих паттернов, что для новичка обернется паттерном «золотой молоток» и применения ради применения.
Почему я вообще занимаюсь разбором подобных статей и советов? Лично я боюсь что новичок, мечтающий стать программистом, прочтет подобное и получит искаженную картину. Столкновение с суровой реальностью может обернуться глубоким разочарованием. Окажется, что существующие проекты не горят желанием поспевать за «темпами роста технологий». Окажется что советы, которые дает фрилансер, плохо применимы для офисной работы. Поэтому читая подобные статьи (и мои в том числе) неплохо было бы включить критическое мышление. Любой автор пишет на основании собственного опыта, а он не всеобъемлющий по определению.