Все программисты попадают в #ТАЙ
Если вы думаете, что быть программистом просто, то вы ошибаетесь. Если думаете, что трудно, то тоже ошибаетесь. Так кто такой программист, как писать крутой код и что отличает хороший тон от плохого в Таиланде или без него разбираемся с анонимусом.
Программистами рождаются
Кто бы что ни говорил, а определить потенциально хорошего программиста можно еще до того, как человек начнет изучать какие-либо языки программирования. Как мне кажется, программист — это, прежде всего, человек с нестандартным и гибким мышлением, а выучить какой-нибудь язык программирования — дело наживное.
Собирая команду в той или иной компании, я часто опирался именно на то, как мыслит человек, нежели на то, какой набор знаний с собой этот человек несет. Предполагалось, что часть набора знаний будет передана внутри самой команды, исходя из потребностей, стека технологий, особенностей программного продукта. Как попытаться определить образ мышления? Я приведу пример нескольких задачек, которые когда-то задавали мне на собеседованиях, а после задавал уже я.
Если вы хотите проверить себя или расширить палитру вопросов, задаваемых на собеседовании, думаю, они вам пригодятся. Ведь каждая из этих задач — способ определить отдельные немаловажные критерии при отборе специалиста, такие как «декомпозиция», «поиск алгоритмических ошибок и петель», «умение оперировать простыми элементами», «абстрактность мышления» и т.д.
1. У вас есть 2 переменные А и В. Представим что А = 7, а В = 8. Поменяйте значения этих переменных местами, используя только классическую математику. Нельзя использовать 3-ю переменную, а также нельзя применять функции из известных вам языков программирования. Попробуйте применить только классическую математику. И да, решение не должно быть частным и должно работать с любыми числами.
2. Представьте, что вы стоите на какой-то точке земного шара. У вас в руках компас. Я говорю вам: «Идите на Северо-Восток». Какая конечная точка будет у вашего путешествия, которое в действительности может продолжаться бесконечно долго, но все же закончится в конкретной точке.
3. Из трубы вылезают два трубочиста. Как бы парадоксально не звучало, но у одного чистое лицо, а у другого — грязное. Кто из них пойдет умываться? Тут важно знать, что одного решения у этой задачи нет — решений несколько. И каждое из них можно и нужно обосновать.
4. Классическая задача «Волк, коза, капуста». Чрезвычайно простая задача, но я очень люблю её. Звучит примерно так. Вы лодочник, вам надо перевезти на другой берег вышеуказанные объекты. Но есть некоторые условия. Вы не можете брать в лодку больше одного объекта, и вам нельзя оставлять вместе волка и козу, так как он ее съест, и козу с капустой по той же самой причине. Вперёд!
5. Вы ученый. Перед вами чашка Петри, в которой находится очень опасный вид бактерии. Вам известно, что численность это бактерии увеличивается каждую минуту в 2 раза. Мы точно знаем что в 12:00 чашка будет полностью заполнена этим чрезвычайно активным видом бактерии, и нам нужно торопиться. Ответьте на вопрос: в какое время чашка будет наполовину полной (или наполовину пустой, кому как нравится)?
6. Задачка на округление. Предположим, вы разрабатываете систему для компании, которая работает с розничной торговлей. Их девиз: «никаких копеек». Но наша задача округлять не просто до копеек или до десятков рублей, а округлять до 50 рублей. То есть, 130 рублей округляются в 150 рублей, а 115 рублей — в 100 рублей. Как сделать округление по такому принципу?
* Ответы я напишу в самом конце статьи. А вы пока подумайте.
Куда пойти, куда податься
Выбор языка программирования полностью за вами. Но раз речь у нас идет о веб-разработке, мы рассмотрим выбор между фронтендом и бэкендом.
Если вы еще не знаете что это такое, то говоря простыми словами фронтенд — это то, что вы видите на веб-ресурсе, пользовательский интерфейс и рычаги взаимодействия с технической частью ресурса. А бэкенд — это то, что вам как пользователю, никогда не увидеть.
Фронтенд скрывает всю силу логики любого веб-ресурса, на котором вы находитесь. Если проводить аналогию с автомобилем, то фронтенд — это салон автомобиля, а бэкенд — это то, что скрывается внутри, под капотом и обшивкой. Безусловно есть ресурсы, где большая часть логики лежит как раз на плечах фронтенд-разработчика. Однако в превалирующем большинстве веб-ресурсов за логику отвечает именно бэкенд.
Если вы стоите перед выбором, какую сторону силы вам занять, то я бы рекомендовал вам попробовать себя на обоих фронтах разработки.
«Потрогаете» и уже решите, что вам ближе к сердцу, быть может, вы вообще станете универсалом, который сможет писать качественный код на обеих сторонах. Кстати, поделюсь с вами своим наблюдением. Часто те, кто пишет бэкенд-часть, может писать и фронтенд. Но это правило редко работает в обратную сторону.
Я не хочу обидеть многочисленную армию фронтенд-разработчиков — это всего лишь личное наблюдение. И важно понимать, что бэкенд-разработка далеко не всегда связана именно с веб-ресурсами, очень часто мы прячемся под капотом мобильных приложений и различных узкоспециализированных сервисов.
Советы из практики
Если вы все-таки решили стать разработчиком, я хотел бы поделиться с вами некоторыми наблюдениями, ошибками и парой историй из своего опыта.
Синдром «Наташи Ростовой»
В моем кругу появилось такое определение, когда в интернетах появилась шутка про будни программиста:
«Представь, что ты писатель и поддерживаешь проект «Война и мир». У тебя ТЗ — написать главу, как Наташа Ростова гуляла под дождём по парку. Ты пишешь «шёл дождь», сохраняешь, и вылетает сообщение об ошибке: «Наташа Ростова умерла, продолжение невозможно». Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение «Поручик Ржевский умер». Выясняется, что он в следующей главе облокачивается о столб, которого уже нет…»
В чем соль данной истории, я думаю вы поняли. Важно сделать правильный вывод, когда вы проектируете какие-то новые блоки системы, или же правите старые — будьте более дальновидными, и не ленитесь потратить время на всестороннее изучение возможных последствий, к которым может привести ваша доработка. Вы скажете, ведь для этого есть тестировщики, и это их задача — находить такие провалы. Да, верно, но есть и нюансы.
Представьте, что вы вносили горячие правки в ресурс, через который проходят какие-либо финансовые операции, и тестировщик отнесся к своей работе так же, как и вы. Компания — пользователь ресурса, рискует получить финансовые убытки, и причина этих убытков — вы. На моем личном примере был случай, когда разработчик внедрил скидку в ИМ (интернет-магазин), но по известной ему одному причине, он сделал её обратной, то есть скидка на товар была не 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% случаев программист продолжал работу дома в то время, когда он почувствует в себе силы, а не тогда, когда это требует время пребывания в офисе. Но это мое мнение и опыт из моей практики. Может, в вашем случае вам нравится офис в душной Москве с 10 до 19. Это ваш выбор.
Любите программистов, берегите их, и ваша компания получит более качественные продукты, и больше не будет практики вроде: «Хуяк-хуяк и в продакшн».
Ответы на вопросы в начале статьи
1. Многие помнят эту задачу из курса математики школы или университета. Решений два, и они достаточно простые. А = 7, B = 8. Для того чтобы поменять местами значения без третьей переменной, нам нужно как-то сохранить «память» о текущих значениях, и это позволят нам сделать или сложение, или вычитание.
Первая итерация: А = A + B (7 + 8 = 15), теперь у вас A = 15, B = 8. Вторая итерация: B = A — B (15 — 8 = 7), теперь у нас B = 15, A = 7. Третья итерация: А = А — В (15 — 7 = 8), теперь у нас А = 8, В = 7. Готово! То же самое можно сделать, используя умножение и деление.
2. В этой задаче важно понимать, что наша земля — не плоская карта на вашем столе, а сферическая геометрическая фигура. Теперь образно отметьте на этой сфере стороны света. Берем компас и идет в путь. Если мы будем идти по компасу только на северо-восток, то мы, рано или поздно, придем на северный полюс — это будет конечная точка путешествия указанного в условии задачи.
3. Я не буду здесь описывать все варианты решения, так как это займет очень много времени. Я предложу вам прочитать притчу о трубочистах. Названий много, напишите в Гугле «раввин и трубочисты» или «Сократ и двое в дымоходе». В общем, очень рекомендую почитать.
4. В этой задаче стоит помнить, что условие не ограничивает вас в том, что вы не можете возить объекты в оба направления, то есть забирать обратно. Таким образом, мы сначала забираем козу и перевозим её на другой берег. Возвращаемся и забираем, например, волка и перевозим его, высаживаем и забираем козу. Вернувшись с козой, забираем капусту и высаживаем козу. Перевозим капусту и возвращаемся за козой. Все просто.
5. Тут тоже просто. В условии задачи написано, что популяция бактерии удвивается каждую минуту, и в 12:00 у нас будет полная чашка Петри. Поэтому легко можно сказать, что чашка будет заполнена на половину в 11:59.
6. Так как у нас минимальная купюра из задачи — это 50 рублей, то мы будем опираться на это число. Чтобы 130 рублей округлить до ближайших 50, делаем следующее:
130 делим на 50 и округляем до целого значения (130 / 50 = 2.6 = 3), а результат умножаем на 50 (50×3 = 150). Готово.
Аналогичную операцию проделываем со 115 рублями (115 / 50 = 2.3 = 2) (2×50 = 100). Готово. Можете проверить и с другими числами.
Удачи.
Комментарии (5)
SbWereWolf
14 марта 2017 в 19:00
0↑
↓
офигеть :)) очень здраво14 марта 2017 в 19:22
0↑
↓
Первую задачу в общем виде нельзя решить с помощью умножения и деления т.к. одна из переменных может быть равна 0, тогда получим деление на 0.
romanegunkov
14 марта 2017 в 19:44
0↑
↓
Можно без умножения, деления, дополнительной памяти и экономно по процу. Это калька с Асма на Си.
a=a^b; b=b^a; a=a^b;
14 марта 2017 в 19:22
0↑
↓
Все задачи решил сразу, кроме трубочистов, не читал про них. 7 лет работаю в офисе, но своем личном где я один, утром приезжаю как проснусь и уезжаю когда наработался. На работу в офисе дяди с 9 до 18 тоже аллергия14 марта 2017 в 20:33 (комментарий был изменён)
0↑
↓
>>И лучшее, что я видел для работы с SQL базами — это HeidiSQL.
После удобного MysqlFront этим нагромождённым недоумением нет желания пользоваться. Максимум загрузить дамп, это он умеет делать быстрее.
