Анонимный разработчик написал статью для «Нетологии» о том, кто такие программисты, как ими становятся, и почему все программисты попадают в свой собственный Таиланд. При условии, если они пишут читабельный код, конечно же.
Если вы думаете, что быть программистом просто, то вы ошибаетесь. Если думаете, что трудно, то тоже ошибаетесь. Так кто такой программист, как писать крутой код и что отличает хороший тон от плохого в Таиланде или без него разбираемся с анонимусом.
Программистами рождаются
Кто бы что не говорил, а определить потенциального хорошего программиста можно еще до того как человек начнет изучать какие-либо языки программирования. Как мне кажется, программист — это человек с нестандартным и очень гибким образом мышления, а выучить какой-нибудь язык программирования не сложно.
Собирая команду в той или иной компании, я часто опирался именно на то, как мыслит человек, нежели на то, какой набор знаний с собой этот человек несет. Ведь даже медведи в цирке умеют ездить на велосипедах, а научить человека программировать, наверное даже легче. Как попытаться определить образ мышления? Я приведу пример нескольких задачек, которые когда-то задавали мне на собеседованиях, а после задавал уже я.
Если вы хотите проверить себя или расширить палитру вопросов задаваемых на собеседовании, думаю, они вам пригодятся. Ведь каждая из этих задач — способ определить отдельные немаловажные критерии при отборе специалиста, такие как «декомпозиция», «поиск алгоритмических ошибок и петель», «умение оперировать простыми элементами», «абстрактность мышления» и т.д.
* Ответы я напишу в самом конце статьи. А вы пока подумайте.
Куда пойти, куда податься
Выбор языка программирования полностью за вами. Но раз речь у нас идет о веб-разработке, мы рассмотрим выбор между фронтендом и бэкендом.
Если вы еще не знаете что это такое, то говоря простыми словами фронтенд — это то, что вы видите на веб-ресурсе, пользовательский интерфейс и рычаги взаимодействия с технической частью ресурса. А бэкенд — это то, что вам как пользователю, никогда не увидеть.
Фронтенд скрывает всю силу логики любого веб-ресурса, на котором вы находитесь. Если проводить аналогию с автомобилем, то фронтенд — это салон автомобиля, а бэкенд — это то, что скрывается под капотом. Безусловно есть ресурсы, где большая часть логики лежит как раз на плечах фронтенд-разработчика. Однако в превалирующем большинстве веб-ресурсов за логику отвечает именно бэкенд.
Если вы стоите перед выбором, какую сторону силы вам занять, то я бы рекомендовал вам попробовать себя на обоих фронтах разработки.
«Потрогаете» и уже решите, что вам ближе к сердцу, быть может, вы вообще станете универсалом, который сможет писать качественный код на обеих сторонах. Кстати, поделюсь с вами своим наблюдением. Часто те, кто пишет бэкенд-часть, может писать и фронтенд. Но это правило редко работает в обратную сторону.
Я не хочу обидеть многочисленную армию фронтенд-разработчиков — это всего лишь личное наблюдение. И важно понимать, что бэкенд-разработка далеко не всегда связана именно с веб-ресурсами, очень часто мы прячемся под капотом мобильных приложений и различных узкоспециализированных сервисов.
Советы из практики
Если вы все-таки решили стать разработчиком, я хотел бы поделиться с вами некоторыми наблюдениями, ошибками и парой историй из своего опыта.
Синдром «Наташи Ростовой»
В моем кругу появилось такое определение, когда в интернетах появилась шутка про будни программиста:
«Представь, что ты писатель и поддерживаешь проект «Война и мир». У тебя ТЗ — написать главу, как Наташа Ростова гуляла под дождём по парку. Ты пишешь «шёл дождь», сохраняешь, и вылетает сообщение об ошибке: «Наташа Ростова умерла, продолжение невозможно». Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение «Поручик Ржевский умер». Выясняется, что он в следующей главе облокачивается о столб, которого уже нет»
В чем соль данной истории, я думаю вы поняли. Важно сделать правильный вывод, когда вы проектируете какие-то новые блоки системы, или же правите старые — будьте более дальновидными, и не ленитесь потратить время на всестороннее изучение возможных последствий, к которым может привести ваша доработка. Вы скажите, ведь для этого есть тестировщики, и это их задача — находить такие провалы. Да, верно, но есть и нюансы.
Представьте, что вы вносили горячие правки в ресурс, через который проходят какие-либо финансовые операции, и тестировщик отнесся к своей работе так же, как и вы. Компания — пользователь ресурса, рискует получить финансовые убытки, и причина этих убытков — вы. На моем личном примере был случай, когда разработчик внедрил скидку в ИМ (интернет-магазин), но по известной ему одному причине, он сделал её обратной, то есть скидка на товар была не 5%, а 95%. Естественно, мы очень быстро обнаружили ошибку и устранили ее, но могло быть намного хуже.
Опасный мир
Проектируя свой код и/или участвуя во встречах группы разработчиков любого проекта, заранее старайтесь думать о том, что ваш проект будет жить во враждебной среде. И среди тех, кто будет пользоваться им, найдутся и те, кто будет пытаться либо поломать ваш проект, либо утащить из него данные. Как и в предыдущем случае, приведу пару примеров из собственной практики.
Однажды к нам в компанию пришел менеджер, который активно пытался нам навязать 1С Битрикс (мы пропустим полемику о том, почему это СПИД в компьютерном эквиваленте, и его нельзя пускать в свою компанию). Этот менеджер устроил большую презентацию, где нам всем были розданы специальные логины и пароли, с которыми мы зашли на некоторый демосервер.
Пока менеджер втирал в уши нашему руководство о том, какой это здоровский продукт, я добавил новый товар, в описание которого включил ссылку на JS-скрипт. И уже через минуту мы все сидели играли в змейку на странице каталога товаров. Я на этом не остановился и быстро сделал JS-скрипт, с помощью которого уже через пару минут вынудил его перезайти в Битрикс, и получил его логин и пароль.
Конечно же, после этого презентация была окончательно сорвана, и менеджер с очень задумчивым видом ушел восвояси. Естественно, после этого перед руководством компании подняли вопрос о том, что один такой скрипт, внедренный в описание товара, позволит утащить данные пользователей и может нанести колоссальный ущерб нашей компании.
Аналогичная ситуация была на презентации продукта, который компания-подрядчик планировала внедрять в медицинских учреждениях нашей области. Все один в один, только на презентации присутствовал министр здравоохранения и последствия были печальным для подрядчика: проект пришлось очень долго переделывать.
Так что будьте готовы к тому, что вы в любой момент времени можете столкнуться с подобными дырами. Вы скажете HTTPS? Защищенные соединения? Поверьте мне, цена вопроса эксплойта такого рода — это цена взятки тому человеку, который может вносить хоть какие-то поправки в целой системе (даже обычное редактирование текста в заголовке), а последствия могут быть непредсказуемыми.
Не дели на ноль, юный падаван
Нередко программисты пренебрегают детальным анализом лога ошибок, который генерирует сервер при работе разработанной системы. Некоторые скажут: «Да ну, Notice и Warning никакого вреда не нанесут», и эти некоторые будут чертовски не правы. Так как каждый Notice или Warning требует у интерпретатора времени на то, чтобы он сделал запись в журнал ошибок. Таким образом, если у вас будет цикл, который генерирует всего лишь одну ошибку, и в этом цикле 400 итераций — один «оборот» такого цикла даст вам 50 килобайт мусора в логи, и, помимо этого, отнимет у скрипта примерно треть времени работы.
Пример из опыта: одна информационная система содержала множество аналитических отчетов, в одном их них была операция, которая иногда могла совершить деление на ноль, устранив эту ошибку, я получил ускорение в формировании отчета в несколько раз быстрее. А представьте, если у вас многопользовательская система? В данном случае появление файла журнала ошибок для вас будет приговором — бойтесь его, и всегда исправляйте за собой все возникающие ошибки.
Возлюби Git как брата своего
С первых дней используйте системы контроля версии. Это важный навык, который сейчас используют, если не все, то 99% адекватных и правильных программистов. Систем контроля большое множество — выбор остается за вами. Главное вам понять — это чертовски хорошая привычка. Не зря есть картинка, объясняющая важность умения пользоваться системами контроля версий.
«В случае пожара: закоммить и беги»
На своем опыте я остановился на двух системах GitHub и Heroku. Если первый крайне знаменит, то второй знают очень немногие. Основными преимуществами являются: бесплатная приватность проекта и уникальная https-ссылка на ваш проект. Кстати, очень классное решение при разработке Webhook для Telegram бота.
Дружи с JSON
Не важно какую сторону разработки вы приняли — при передаче данных старайтесь использовать именно JSON. Чрезвычайно удобная и полезная штука, от работы с которой вы не получите ничего, кроме положительных эмоций.
Если вы бэкенд-разработчик в крупном веб-проекте, вам нужно думать о братьях ваших меньших — фронтенд-разработчиках — дарите им данные в формате JSON.
И если фронтенд-разработчик отдает вам данные как попало — научите его пользоваться этим форматом. Поверьте моему опыту, это избавит вас от множества проблем и сделаем передачу данных между фронтом и движком более гибкой.
Ода jQuery
Наверное jQuery — это самая известная и популярная библиотека для фронтенд-разработчиков. Если многими библиотеками можно пренебречь и жить без них, то jQuery — ваш верный инструмент. Кто-то может со мной не согласиться, сказав, что все, что написано на jQuery, можно написать на чистом JS, на что я отвечу: «Да можно, пишите». Эта штука реально избавит вас от головной боли и решит множество ваших проблем. Я бы сказал, что это «швейцарский нож» в мире JS-библиотек — и с этим очень многие согласятся.
Слово о Frameworkах и ООП
ООП — объектно-ориентированное программирование. Очень правильная и нужная составляющая эволюции любого разработчика. И будьте готовы, что эволюция проведет вас по всей цепочке: чистый процедурный стиль функциональный стиль объектный стиль, если вы остановитесь в начале или в середине этой цепочки, то индустрия уничтожит вас как нежизнеспособное создание. Но есть один момент, над которым стоит задуматься как новичкам, так и опытным разработчикам: ООП уместно там, где оно нужно.
На своей практике я не раз встречал коллег, которые при любой ситуации старались применить свои знания на этом поприще. Вот вам простой пример. В одной из поддерживаемых информационных систем был модуль, отвечающий за рассылку PUSH-уведомлений пользователям приложения компании. Так вот, на 7000 пользователей процедурный код делал рассылку где-то за 5–6 минут, когда же код был переписан на ООП по идеологическим соображениями, рассылка стала занимать 10–15 минут.
Многие из нас знают иностранные языки, но мы не говорим на них в любой ситуации. Мы говорим на них только тогда, когда нам это нужно. Это правило работает и для ООП, и для выбора фреймворка для вашего проекта. Пренебрегать этими вещами нельзя: и то, и другое призвано решать определенные задачи в определенных ситуациях, и применять их без необходимости не нужно.
Я уже чувствую, как огромная армия любителей фреймворков сгорает от желания устроить холивар. Успокойтесь, ребята, ведь я не сказал, что это плохо и не нужно, я лишь сказал, что всему свое место. И опыт качественного шаблонного программирования без применения фреймворков очень дорогого стоит, и весит ровно столько же, сколько знание их современных линеек. А на своем опыте я не раз встречал проекты, которые при небольших доработках могли стать очередным фреймворком, коих и так на нашем свете огромное множество.
Итак еще раз подведем итог этого важного момента эволюционного развития разработчика:
Учитесь качественному применению ООП и фреймворков — это важно, но помните, что не нужно применять их везде, даже там, где по сути они не нужны.
Имей хороший инструментарий
Программист, как и любой технический специалист, должен обладать набором хороших инструментов, которые помогают ему решать те или иные задачи. Это касается как и IDE, в котором вы пишите код, и DBManager, в котором вы управляете в базе данных. Можно бесконечно рассуждать на тему плюсов и минусов тех или иных средств разработки, поэтому, в данном случае, я буду опираться на свой опыт.
Прекраснейшее IDE для разработки на PHP — это PhpStorm, большинство с ним наверняка знакомо, и пока ничего лучше я не держал в руках. И лучшее, что я видел для работы с SQL базами — это HeidiSQL. Здесь я готов спорить до хрипа. Если у вас есть возможность удаленно подключиться в БД — забудьте о phpMyAdmin навсегда, все что вы делаете там, тратя 5 минут, я смогу сделать через HeidiSQL за 1 минуту.
А что касается разного рода подсобных инструментов — тут уже каждый специалист со временем наберет свою палитру. Выше я лишь порекомендовал базовый набор, который должен быть на вооружении у большинства специалистов. Да-да, я снова вижу, как у вас появилось желание спорить со мной. Отвечаю.
Важно понимать, что специалист должен пользоваться не только тем, к чему он привык, но и тем, что экономит его время, нервы и силы.
Комментируй всё
Привыкай комментировать практически каждую часть кода, ведь это значительно упростит анализ кода коллегами, или же ускорит память, когда спустя какое-то время сам заглянешь в этот код. Это очень правильная привычка, и ее нужно вырабатывать с самого первого дня. Есть замечательная картинка, которая скажет за меня всё.
Почему #ТАЙ?
Коротко и ясно. Программист — «животное», которому нужны террариумные условия. Есть множество способов создать их искусственно. Начиная от «Пика Балмера», гуглим, и да-да, я считаю это допинговым стимулирующим фактором, и заканчивая идейными инкубаторами вроде Google. В них разработчики живут в компании и, тем самым, регулярно впадают в «приступы кодинга», оказываясь в нужное время в нужном месте. И это дает очень высокий КПД компании.
Но, как и в любом животноводстве, большей пользы можно добиться от животного, которое находится на свободном выпасе, и, как по мне, Таиланд очень подходящее для этого место. Я знаю многих коллег, которые уехали туда и работают теперь в этой жаркой стране.
Если кто-то из HR менеджеров или руководителей компании читает эту статью, знайте, программист сидящий в офисе с 10 до 18 — это программист с искусственно заниженным КПД.
На моей практике, один владелец компании понимал это, и программисты работали с 10 до 14. Они получали тот же уровень зарплаты, потому что начальник знал, что в 90% случаев программист продолжал работу дома в то время, когда он почувствует в себе силы, а не тогда, когда это требует время пребывания в офисе.
Любите программистов, берегите их, и ваша компания получит более качественные продукты, и больше не будет практики вроде: «Хуяк-хуяк и в продакшн».
Ответы на вопросы в начале статьи
Первая итерация: А = A + B (7 + 8 = 15), теперь у вас A = 15, B = 8. Вторая итерация: B = A — B (15 — 8 = 7), теперь у нас B = 15, A = 7. Третья итерация: А = А — В (15 — 7 = 8), теперь у нас А = 8, В = 7. Готово! То же самое можно сделать, используя умножение и деление.
130 делим на 50 и округляем до целого значения (130 / 50 = 2.6 = 3), а результат умножаем на 50 (50×3 = 150). Готово.
Аналогичную операцию проделываем со 115 рублями (115 / 50 = 2.3 = 2) (2×50 = 100). Готово. Можете проверить и с другими числами.
Удачи.
Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.
