Программирование для гуманитариев

Вы же помните, что мне можно задавать вопросы здесь: @hum_it_bot?

ООП. Абстрактные классы Если вы пропустили предыдущие посты об ООП, советую начать с них: В предыдущих сериях: 1. Что такое классы 2. Что такое объекты классов и как их создавать. Конструкторы 3. Что такое ООП 4. Принципы ООП: абстракция. Инкапсуляция 5. Принципы ООП: наследование Сегодня продолжаем тему наследования. О том, стоит ли использовать наследование в своем коде, ведутся нешуточные баталии. Например, есть мнение, что композиция чуть ли не всегда лучше наследования. Под композицией тут имеется в виду, что один класс можно сделать атрибутом другого класса, и таким образом избежать иерархии наследования. Ещё одно мнение - наследоваться лучше только от абстрактных классов. Но что же это значит? Вспомним наш класс BaseUser из поста про наследование. Чтобы использовать его как абстрактный класс, мы не должны создавать его экземпляры. То есть объектов типа user = new BaseUser() в коде существовать вообще не может. Абстрактный класс нужен только для того, чтобы от него наследовались другие классы. Например, мы можем создать классы User(BaseUser) (обычный пользователь), AdminUser(BaseUser), ModeratorUser(BaseUser) - каждый из них наследуется от абстрактного класса BaseUser и заимствует его свойства. Мы можем создать объекты этих классов, но не базового класса - родителя. Часто в абстрактных классах есть абстрактные методы - то есть такие методы, которые не реализованы в данном классе. Например: class BaseUser() { function sayHello() { throw new NotImplementedException() } } У базового класса BaseUser метод sayHello абстрактный - он не реализован (точнее, реализация есть, но она просто бросает исключение). Таким образом, каждый класс, который наследуется от BaseUser должен будет предоставить свою реализацию метода sayHello. Иначе при вызове этого метода произойдёт ошибка. Существует еще такой тип абстрактных классов как интерфейс. Интерфейс обычно не реализует ни одного метода, в нём все методы абстрактные. Но каждый потомок, который наследуется от интерфейса обязан реализовать эти методы. Интерфейс по сути задаёт требования для своих потомков. Возьмём в качестве примера опять пульт от телевизора. В случае с современными телевизорами пульт - это не обязательно пластиковая коробочка с кнопками, вместо пульта можно использовать и android/ios - приложения, и разные устройства из серии «умный дом». Но чтобы их можно было использовать для управления телевизором, нужно чтобы у них был общий интерфейс - они должны уметь переключать каналы, включать/выключать телевизор и так далее. Эти общие требования к этим устройствам можно вынести в класс-интерфейс - он ничего не реализует сам, а скорее задает стандарт: class IRemote() { // методы не реализованы function turnOn() function turnOff() function nextChannel() … } Для того, чтобы сделать устройство для управления телевизором, нужно написать класс, который будет реализовывать все методы интерфейса IRemote. Я намерено стараюсь рассказывать о наследовании и связанных понятиях без привязки к отдельным языкам программирования. Каждый объектно-ориентированный язык имеет свою реализацию ООП. Например, в одних языках есть ключевое слово abstract для обозначения абстрактных классов, в других языках его нет, и абстрактный класс можно создать только полагаясь на «джентельменские соглашения» - то есть как бы договориться с другими разработчиками проекта, что мы не будем создавать объекты этого класса. В одних языках есть такой отдельный тип как Interface, в других можно имитировать поведение интерфейса с помощью обычных классов. В C++ есть еще, например, такая сущность как виртуальные классы и методы - но всё это особенности конкретных языков, и рассматривать их имеет смысл в том случае, если вы углубляетесь именно в эти языки.

Недавно я посмотрела ряд видео с советами начинающим программистам, чтобы узнать, что рассказывают по теме моего канала другие авторы. В итоге - с одной стороны, не услышала ничего принципиально нового: другие авторы в один голос советуют одно и то же, то же, о чем и я здесь уже писала и не раз - вот как в этом посте, или близкий по теме - о болях работы с новичками. С другой стороны, услышала и спорные моменты, которые, на мой взгляд - отчасти мифы и начинающий программист может истолковать неверно. Разберём сегодня их. 1. Айтишнику необходим английский язык на очень хорошем уровне. Скажем так, и да, и нет. Я - человек как раз с очень хорошим уровнем английского (раньше работала и переводчиком, и преподавала его) - скажу, нет, знать его на таком же уровне, как у меня, необязательно. Если честно, я практически не встречала среди коллег очень хорошего владения английским языком - и ничего, живут же. Необходимая база - умение читать и понимать технические тексты (документацию к коду и к проектам, мануалы и так далее). Всё остальное (умение слушать/говорить итд) - пригодится, но не так уж критично. 2. Айтишник бесконечно учится. Опять-таки - и да, и нет. Если вы представляете айтишника как человека, который все 10-20-30 лет своей карьеры неустанно сидит над книгами и курсами - то, скорее всего, ошибётесь. Учиться-то мы учимся, но чаще всего - в процессе работы. Отчасти гуглим ответы на возникающие вопросы, ищем их в документации, отчасти учимся методом проб и ошибок - но всё это пока выполняем рабочие задачи, а не в режиме вечного студента. Если вы спросите, сколько книг по IT я читаю в год - то ответ будет от нуля до двух. Другое дело - период обучения, когда вы только начинаете осваивать профессию, вот в этот период и курсы, и книги очень нужны. 3. Программисту необходимо осваивать как можно больше технологий. Примерно так звучал совет одного из ютюб-блогеров. То есть - изучаете базы данных - не ограничивайтесь одним SQL, изучайте еще и NoSQL. Изучили PostgreSQL - беритесь за MongoDB, Redis, расширяйте свой стэк максимально. Ожидание - на старте супер-востребованный разработчик с кучей скиллов. А сейчас я расскажу, как всё будет в реальности. Вот вы изучили условный MongoDB своими силами, как смогли. Устраиваетесь на работу - а там MongoDB нигде не используется. Через два месяца вы даже не вспомните, что это вообще такое и как с ним работать. Это во-первых. Во-вторых - не бывает Junior-разработчиков с большим стэком. Всё, что вы изучаете перед тем как устроиться на работу - это некая база, основа. Чтобы хорошо освоить какую-нибудь технологию, нужно с ней плотно работать в течение года-двух-трёх: спотыкаться обо все подводные камни, искать решения для возникающих неожиданных проблем, пару-тройку раз накосячить и потом исправлять это, а в идеале еще и ходить на конференции, и слушать доклады о работе с этой технологией. Вот так вы через пару лет сможете сказать, что шарите, скажем, в PostgreSQL. И только тогда можно всерьез говорить, что эта технология - часть вашего стэка. На этапе учебы происходит лишь поверхностное знакомство. Так что, ну познакомитесь вы слегка с условным MongoDB, и еще десятком подобных проектов (ClickHouse, Tarantool, Cassandra итд) - а толку? Всё, что не используете - забудете. Так что моё мнение - изучать нужно основы Computer Science и некий базовый стэк - скажем, 2 языка программирования, SQL на примере какой-нибудь СУБД, сетевые протоколы итд. Выбирать конкретные технологии нужно исходя из вакансий, на которые вы метите, а не стараться объять всё подряд. (Тут - мой субъективный список требований для бэкенд-разработчика) Я как-то «про запас» проходила курсы по Hadoop - ну потому что модно, молодёжно, популярно - Big Data и вот это всё. Однако, в работе мне он не пригодился ни разу, так что в итоге в памяти остались лишь какие-то базовые термины. Конкретные технологии нужны только если вы будете их использовать, иначе забудете начисто. Так что лучше в порыве перфекционизма не замахиваться на всевозможные технологии, которые в ближайшем будущем не планируете применять.

#вашивопросы Очень-очень хочу узнать Ваше мнение о смене работы. Я Google Ads специалист уровня Middle+/Senior(так сказать Full stack, с большими проектами за плечами). Если сейчас устроюсь на работу то думаю могу ожидать около 2000$ (если получится 2500$) зп. НО я уже изучаю Python (давно), куча курсов, пишу свои проекты, в общем готова идти на собеседования на Júnior Python dev. Скажите, в 10-ти летней перспективе будет ли эта смена профессии правильной? Стоит ли? Может ли девушка реально быть Senior бэкендщиком с зп выше 3,5-4К$? Простите за такой приземлённый вопрос. Программировать - да, нравится и получается, я знаю насколько будет сложно и больно 😅. Но мне правда сейчас страшно перед выбором...смогу ли я достичь такого высокого уровня зп в будущем. Да, рейтинги зп я видела, но хотелось бы узнать насколько реально. Ну что начинать работать программистом будет «больно» - это не факт, возможно, будет как раз интересно. А вот что точно можно сказать - это что по первой поре в должности Junior зарплата будет гораздо меньше, чем вы привыкли получать. Что касается зарплаты больше 3,5к долларов - то есть от 250к рублей и больше - такие вакансии есть, но это зарплата больше среднерыночной, если брать по Москве (скажем, в США разработчики получают больше, чем у нас). Вакансии на 250к и больше - это часто уже уровень Team Lead или айтишников-руководителей, то есть профессии, где нужны будут не только технические навыки и опыт, но и менеджерские скиллы. Чисто разработческие вакансии с такой вилкой тоже встречаются, например, в стартапах, где зарплата бывает выше среднерыночной (но и выский риск банкротства). Также платить больше могут там, где зарплата не «белая» - такие компании не тратятся на соцотчисления, но это незаконно. Но в целом тут всё индивидуально в зависимости от компании. Одни работодатели даже начальнику отдела платят от силы 120к, а другие готовы платить и 300к хорошим разработчикам. Но, как вы, наверно, догадываетесь, найти работу за 300к будет всё же сложнее, чем за 120-200к. Будет ли смена профессии правильной лично для вас - это уже вам решать. Для кого-то идеальная профессия - в оранжерее цветы выращивать, для кого-то - дизайн интерьеров, для кого-то - это наше IT. Зависит от индивидуальных предпочтений и главное от того, чем приятнее и интереснее заниматься. Деньги - это тоже важно, но заниматься нелюбимым делом только из-за денег - это тяжело и грустно. Задать вопрос автору блога можно здесь: @hum_it_bot

ООП. Наследование Праздники закончились, так что продолжим ликбез на тему ООП. В предыдущих сериях: 1. Что такое классы 2. Что такое объекты классов и как их создавать. Конструкторы 3. Что такое ООП 4. Принципы ООП: абстракция. Инкапсуляция Сегодня поговорим о таком столпе объектно-ориентированного программирования как наследование. Наследование означает, что у любого класса может быть класс-родитель. Все свойства класса родителя автоматически проявляются у класса-наследника. Возьмём пример - пользователь какого-нибудь чата, создадим для него класс BaseUser, чтобы подчеркнуть, что от этого класса будут наследоваться другие "дочерние" классы: class BaseUser { string login; string email; function send_message() { // код } } Базовый юзер - это обычный юзер, самый обобщенный вариант. У любого пользователя есть логин, email и любой пользователь может отправлять сообщения. И тут мы хотим создать не обычного пользователя, а «расширенного» - администратора. Во-первых, у него есть такие же аттрибуты и возможности, как и у базового пользователя - логин, email и он тоже может присылать сообщения. И если воспользоваться механизмом наследования, сделать AdminUser наследником BaseUser, то все эти возможности юзер-админ получает автоматически: class AdminUser(BaseUser) { } Тут мы в скобках указали, что BaseUser - это родитель AdminUser, и таким образом всё, что написано в классе BaseUser будет работать и для AdminUser. А то, что есть у AdminUser, но не у обычных пользователей, мы определим только в этом классе: class AdminUser(BaseUser) { function ban_user(user) { // код - забанить какого-нибудь пользователя } } Так админ наследует все возможности базового пользователя, и при этом имеет свои собственные возможности, которых не было у его «родителя». А еще можно переопределить метод, который админ унаследовал у родительского класса, чтобы он работал по-другому, например: class AdminUser(BaseUser) { function send_message() { // код - печатать сообщения красным цветом } } Метод send_message для админов будет печатать весь текст красным цветом. А поля и методы, которые мы решили не переопределять остались такими же, как в родительском классе. Наследование может быть многоступенчатым - например, у AdminUser тоже могут быть классы-наследники, а у них в свою очередь - свои наследники. Но такое многоуровневое наследование может необоснованно усложнять код и приводить к ошибкам. Также некоторые языки поддерживают множественное наследование - это когда один класс может иметь много родителей и наследовать все их свойства (при неразумном использовании тоже может приводить к сложностям и ошибкам). В общем, наследование - удобный инструмент для того, чтобы не дублировать лишний раз код, но не стоит злоупотреблять наследованием и использовать его там, где можно обойтись без него. В следующий раз расскажу про абстрактные классы.

Мне тут пришла в голову еще одна метафора на тему того, почему одни - берут и программируют и становятся разработчиками, а другие «боже, как сложно, я никогда в этом не разберусь». Первые знают, что написать программу - это как собрать стол из IKEA. Стол состоит из простых, понятных деталей: столешница, ножки, крепления. И даже если сперва не совсем понятно, как прикрепить ножки к столешнице, ты понимаешь, что ничего принципиально сложного тут нет, к тому же можно почитать инструкцию. Даже если ты криворукий, худо-бедно с отверткой разберешься. И, в принципе, если ты можешь собрать что-то простое, вроде стола, то и шкаф собрать сможешь. Да, деталей больше, да, сложнее понять, что для чего нужно и куда крепится, но в широком смысле всё то же самое. И еще ты знаешь, что если тебе попалась непонятная дощечка, нельзя надеяться, что она сама куда-нибудь рассосется - надо сидеть и разбираться, куда же ее прикрепить, и как это сделать правильно. Вот и с программированием так же. Любая программа состоит из одних и тех же достаточно простых «деталей» - переменных, циклов, функций и классов, данных. Никакой магии там нет, просто нужно понять, что куда «прикрепить». Даже самая сложная и большая программа сводится к набору «дощечек» и «винтиков», поэтому разобраться в ней - не такая уж сложная задача. А если сидеть в куче дощечек и пытаться их просто скрепить как-нибудь друг с другом, не понимая, где полочка, а где ножки - шкаф не получится, получится какой-то запутанный рандом.

#вашивопросы Как считаете, какие перспективы есть у Flutter и языка программирования Dart? Стоит ли это изучать в 2021? Изучать новые и малоизвестные языки, имхо, имеет смысл по приколу в качестве хобби или просто ради интереса, если есть такое желание. Пока язык не вошел в широкое употребление, практической пользы в его изучении нет. Вот если он наберет популярность, как это произошло с другим языком от гугла - Go, тогда уже появится смысл им заниматься - особенно когда появится много вакансий, для которых этот язык будет требоваться. А гадать заранее, произойдёт это или нет - не вижу смысла. Задать вопрос автору блога можно здесь: @hum_it_bot

#вашивопросы На телефоне у меня есть приложения, очень простые и мне нравится их использовать, но к сожалению у них нет десктопной версии. Есть аналоги этих приложений, но они громоздкие и привязаны к интернету, то есть их почти не возможно использовать вне интернета, то есть без его подключения. 1. Можно ли научиться делать именно десктопные версии приложений без углубления в программирование? 2. Какие языки необходимы, чтобы делать приложения канбан досок и интеллект карт? Я понимаю, что это похоже на изобретение велосипеда, но мне хочется попробовать самой сделать подобные приложения. Отсюда вытекает следующий вопрос: 3. А можно вообще научиться программировать не для общих целей, а например как в моем случае из потребности сделать конкретное приложение? 1. Программирование десктопных приложений - это тоже программирование, так что вопрос можно переформулировать как «можно ли научиться программированию, не углубляясь в программирование». Если ваша цель - только написать 2-3 десктопных программы, которым не нужен Интернет, значит на этом этапе можно проигнорировать, скажем, такие темы, как работа с сетью, HTTP-протокол и всё прочее, что не нужно для ваших потребностей. Но вам понадобятся основы программирования на выбранном языке и умение работать с GUI (графический интерфейс пользователя - то есть визуальная часть приложения - окошечки, кнопочки итд). 2. Какие языки выбрать для десктопных программ - во-первых, можно взять любой язык общего пользования, скажем, Python или Java. К ним понадобятся библиотеки для работы с GUI - например, в Python это tkinter или более новые аналоги. Если приложения хотите создавать под Microsoft, можно использовать платформу .Net (скажем, на языке C#). Еще можно использовать Delphi, но как по мне - это устаревший язык. Ещё один чуть менее очевидный путь - написать веб-приложение на JavaScript и открывать его в браузере - вместо того, чтобы использовать библиотеки для создания GUI. Можно написать его так, чтобы ему не был нужен доступ в Интернет. 3. Ну а что такое программирование для общих целей? Программировать учатся для того, чтобы делать конкретные продукты - будь то веб-сайты, программы, мобильные приложения или что-то еще. Другой вопрос, если ваша цель - сделать ровно 2 программы и на этом остановиться, стоит ли овчинка выделки? Обычно люди не учатся на врача для того, чтобы принять ровно двух пациентов и потом уйти на пенсию. 🙂 И ваши первые программы в любом случае будут достаточно плохо написаны (с другой стороны, если они вас будут устраивать во всём и удобны для использования лично вам - то плохой код не так уж и важен). Впрочем, если интересно и хочется - то почему бы и нет, главное ведь - желание. Может, сейчас ваша цель - только эти 2-3 программы, а потом заинтересуетесь и продолжите развиваться в этом направлении. А может это так и останется вашим небольшим хобби. В любом случае, вреда от этого не будет. Задать вопрос автору блога можно здесь: @hum_it_bot

Ещё про собеседования Открою страшную тайну про собеседования: те, кто вас собеседуют - тоже нервничают во время собеседования, по крайней мере, многие, с кем я обсуждала эту тему. Наверно, когда ты проводишь собеседования каждую неделю и пообщался уже с десятками, а то и сотнями кандидатами, это в итоге проходит, ко всему можно привыкнуть. Но поначалу нервничаешь не меньше кандидатов, особенно если ты интроверт (а это всё же IT). Перед своими первыми собеседованиями в качестве работодателя, ты носишься по офису, волнуешься, и всех спрашиваешь: «Блин, сейчас придёт кандидат. О чём его спрашивать?». Переживаешь, что вопросы будут глупыми, что кандидат решит, что мы тут все тупые (кандидат ведь вполне может оказаться умнее нас). А всё потому что по ту сторону собеседования - такие же люди, как и вы. Собеседование - это не экзамен, вы не студент, а интервьюер - это не строгий профессор. На вас смотрят как на потенциального коллегу, на равного себе, а не «сверху вниз» (если смотрят сверху вниз - это имхо не очень здоровый симптом). Поэтому вы тоже не воспринимайте собеседование как экзамен, лучше смотреть на него как на свидание/знакомство.

Не буду даже пытаться Продолжим тему о багах мышления. Когда я училась в школе, особенно в старших классах, я к учебе относилась по-раздолбайски - домашние задания не делала, на уроках спала (в буквальном смысле), но, тем не менее, получала «четверки»-«пятерки». И из-за моих оценок некоторые одноклассники думали, что я «всё знаю» и поэтому ко мне можно (нужно) обращаться с любой задачей - хоть по химии, хоть по математике: - Ну ты же всё знаешь! - Впервые вижу. - Не ври. Всё ты знаешь В представлении одноклассников, я, видимо, выучила наизусть решебник со всеми задачами, и теперь заранее знаю, как решить что угодно. В чем же была разница между мной и такими оппонентами? Я пыталась. Когда надо было решить незнакомую задачу - я пыталась разобраться. Если тема незнакомая - открывала учебник, читала тему, (которую я как раз проспала), разбиралась. И в итоге не всегда получалось решить идеально, не всегда получалось вообще, но чаще всего этого хватало как минимум на «четверку». А некоторые даже не пытались. Они с порога уходили в отрицание - «я не знаю, я не понимаю, это ты всё знаешь - ты можешь решить, а я не могу». И речь сейчас, конечно, не о школьных годах, а, как обычно, о джуниорах. Некоторые, видимо как в школьные годы, привыкли верить, что другие, более опытные разработчики «всё знают» и «всё умеют», и что, они, наверно всё-всё, что нужно изучили и перепробовали (и выучили наизусть решебник со всеми возможными задачами для программистов). Поэтому и запрос у таких новичков в духе «А дай списать». «Ну ты же всё знаешь, ну что тебе стоит.» А вот не знаем мы всё. Мы каждый день что-нибудь да не знаем. И решебников у нас нет, и задачи каждый раз возникают незнакомые. Иногда такие, что даже в гугле ничего по ним не найти. Так как же мы живём? Мы пытаемся. В тривиальных ситуациях всё просто - находим на каком-нибудь Stackoverflow решения для похожих задач и адаптируем их под свои нужды. Если это не помогает, то ищем новые подходы, придумываем, с какой стороны подступиться к проблеме. Экспериментируем, комбинируем ранее опробованные подходы, а иногда пробуем что-то совсем новое для нас. Читаем документацию, статьи в интернете, исходный код, ищем всё, что можно задействовать в решении. А некоторые джуны в похожих ситуациях склонны пасовать и отнекиваться, мол «я такого не пробовал, не знаю, не умею» (это мы не проходили, это нам не задавали). Вот только правда в том, что мы, айтишники, очень часто делаем такое, чего не пробовали раньше. Это наша работа. Так что пытайтесь. Это ключ к успеху. Честно-честно

С Новым годом, товарищи! Пока вкатываться в рабочий режим еще рано, выложу пару древних, но очень смешных видео на тему IT: The Website is Down - про будни веселого админа: https://www.youtube.com/watch?v=uRGljemfwUE Wat - про странности языков программирования: https://www.destroyallsoftware.com/talks/wat Всё на инглише (sorry)