Если вы думаете, что быть программистом просто, то вы ошибаетесь. Если думаете, что трудно, то тоже ошибаетесь. Так кто такой программист, как писать крутой код и что отличает хороший тон от плохого в Таиланде или без него разбираемся с анонимусом.
Программистами рождаются
Кто бы что ни говорил, а определить потенциально хорошего программиста можно еще до того, как человек начнет изучать какие-либо языки программирования. Как мне кажется, программист — это, прежде всего, человек с нестандартным и гибким мышлением, а выучить какой-нибудь язык программирования — дело наживное.
Собирая команду в той или иной компании, я часто опирался именно на то, как мыслит человек, нежели на то, какой набор знаний с собой этот человек несет. Предполагалось, что часть набора знаний будет передана внутри самой команды, исходя из потребностей, стека технологий, особенностей программного продукта. Как попытаться определить образ мышления? Я приведу пример нескольких задачек, которые когда-то задавали мне на собеседованиях, а после задавал уже я.
Если вы хотите проверить себя или расширить палитру вопросов, задаваемых на собеседовании, думаю, они вам пригодятся. Ведь каждая из этих задач — способ определить отдельные немаловажные критерии при отборе специалиста, такие как «декомпозиция», «поиск алгоритмических ошибок и петель», «умение оперировать простыми элементами», «абстрактность мышления» и т.д.
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 = 7, A = 15. Третья итерация: А = А — В (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). Готово. Можете проверить и с другими числами.
Удачи.
Комментарии (105)
MikhailD
14.03.2017 19:22Первую задачу в общем виде нельзя решить с помощью умножения и деления т.к. одна из переменных может быть равна 0, тогда получим деление на 0.
romanegunkov
14.03.2017 19:44+7Можно без умножения, деления, дополнительной памяти и экономно по процу. Это калька с Асма на Си.
a=a^b; b=b^a; a=a^b;MikhailD
14.03.2017 21:49В задаче требуется использовать только классическую математику (в которую битовые операции, как я понимаю, не входят). В ответе указано, что можно решить используя деление и умножение, но это работать не будет, если одна из переменных равна нулю.
DistortNeo
14.03.2017 22:04+7Насчёт "экономно по процу" уже можно сильно спорить.
Если нужно обменять два значения в памяти, то решения без использования дополнительной памяти просто не существует. Придётся задействовать хотя бы один регистр процессора. В этом случае код с тремя XOR превратится в что-то вроде:
mov r0, [a] xor r0, [b] mov [a], r0 xor r0, [b] mov [b], r0 xor r0, [a] mov [a], r0
Куча дорогих обращений к памяти/кэшу. Зачем?
Если же у нас RISC-архитектура, то одноременный xor и чтение из памяти будут невозможны, придётся использовать два регистра:
mov r0, [a] mov r1, [b] xor r0, r1 ; mov [a], r0 - тут, конечно, можно было бы записывать в память временные результаты ; mov [b], r1 - но зачем? xor r1, r0 xor r0, r1 mov [a], r0 mov [b], r1
А теперь вопрос: зачем нужны эти xor, когда можно просто написать так:
mov r0, [a] mov r1, [b] mov [a], r1 mov [b], r0
Если же нужно поменять значения в регистрах общего назначения, тогда:
xchg r0, r1
И только если нужно поменять значения в регистрах, а xchg нет, тогда можно выкатить вариант с тремя xor:
xor r0, r1 xor r1, r0 xor r0, r1
Ну и не стоит забывать, что современные процессоры суперскалярные, регистры в них логические, и простая пересылка все равно будет эффективнее, потому что три вышеуказанных xor зависят друг от друга, следовательно, суперскалярность не будет задействована.
romanegunkov
14.03.2017 22:56+1Спасибо за подробности, я уже давно не в теме. Просто задачка напомнила институтские времена, когда препод спрашивал как поменять два регистра местами, по-моему ещё на Motorola m68k мы работали. Ностальгия.
potan
15.03.2017 13:29Это смотря какой проц. На PDP-11 запросто. Да и на x86 при желании можно. Правда там и xchg есть.
Ndochp
14.03.2017 21:45+10Я про первую задачу ждал подлянок с переполнением ИНТа в ответе, но про них забыли…
romanegunkov
14.03.2017 22:48Не забыли, просто в тесте переполнение не портит конечного результата, при решении со сложением-вычитанием. Но лучше либо не допускать, либо чётко понимать что происходит.
Torvald3d
15.03.2017 00:27Если учесть, что переполнение — это уб (по крайней мере в с/с++), то лучше так не делать.
DistortNeo
15.03.2017 00:35-1Для вещественных чисел — так точно.
Но в условиях задачи числа небольшие (7, 8), там не нужно универсальный вараинт придумывать.
demonout
14.03.2017 19:22+1Все задачи решил сразу, кроме трубочистов, не читал про них. 7 лет работаю в офисе, но своем личном где я один, утром приезжаю как проснусь и уезжаю когда наработался. На работу в офисе дяди с 9 до 18 тоже аллергия
DjOnline
14.03.2017 20:33>>И лучшее, что я видел для работы с SQL базами — это HeidiSQL.
После удобного MysqlFront этим нагромождённым недоумением нет желания пользоваться. Максимум загрузить дамп, это он умеет делать быстрее.
pil0t
14.03.2017 21:09+112. С компасом дойти мы не скорее всего не сможем, там надо плавать. И не на северный полюс, а на северный магнитный полюс. И даже при всём при этом, точки (именно точки) конечной не будет, т.к. полюс движется в течении суток быстрее чем человек ходит.
AlexZaharow
14.03.2017 21:46Привыкай комментировать практически каждую часть кода, ведь это значительно упростит анализ кода коллегами
Правильная и отличная мысль, можно мне добавить, что комментировать не в стиле зачем (что делает код ясно из самого кода), а в стиле почему. Почему я делаю unshift в array, а не push?
Я сначала комментирую ненужные куски кода, потом через два-три коммита начинаю их потихоньку стирать. Некоторые куски кода оставляю в комментах жить вообще бесконечно, чтобы в будущем не пытаться переписать код к варианту, когда он был оттестирован как неправильный ранее. Даже изменения в коде часто делаю по алгоритму — сначала добавил нужные символы, потому удалил ненужные. (Особенно это касается изменения статических исходных данных, имён таблиц, полей).
Если какой-то код отлажен, приносит пользу и оброс комментариями, то и комментарии тоже копируются вместе с кодом в новый проект.
Если я взял код у кого-то, то даю ссылку на страницу, откуда взято и т.д.
Идея с комментариями ещё может получить дополнительное развитие. Действительно не стоит ими пренебрегать.
vitovt
14.03.2017 21:58+3Все правильно. По Мартину Фаулеру каждый метод должен называться так, чтобы было понятно что он делает, а в этом случае надобность в комментировании огромного количества кода отпадает.
Комментировать стоит только самые сложные или хитрые места кода или тогда, когда «как-то получилось, но второй раз не воспроизведу» вот для этого случая и пишу комментарий, по крайней мере я =)AlexZaharow
16.03.2017 09:35Арнольд Шварцнеггер в своей книге «Вспомнить всё» написал, что для достижения успеха надо тренировать не только то что хочется, но и свои слабые места. Для этого, конечно, сначала надо признать, что они есть ;)
degressor
14.03.2017 21:53+12. не однозначна. Можно подумать что человек будет итти до тех пор, пока не придёт назад на старт. Что его остановит на полюсе? С другой стороны может итти до первого водяного припятствия, которое его действительно остановит.
sbnur
14.03.2017 22:06+6Насчет комментирования — это увеличение времени набора в 1.5-2 раза. лучше давать вместо комментариев вразумительные имена переменным, функциям и прочим сущностям. Числовым константам тоже давать названия.
Задачи оказались известны — попробую рискнуть на свежую
В некой тюрьме решили устоить экзекуцию в виде расстрела заключенным, но соблюдая видимость демократии дали возможность спасти свою жизнь
Заключенным написали сзади произвольные целые числа так, что при построении в колонну каждый заключенный видит числа впереди стоящих. Если заключенный называет свое число, он остается жив, иначе расстреливается на месте.
Какая самая оптимальная стратегия для сохранения большего количества жизней?
И вопрос — а почему анонимностьDistortNeo
14.03.2017 22:32Насчет комментирования — это увеличение времени набора в 1.5-2 раза. лучше давать вместо комментариев вразумительные имена переменным, функциям и прочим сущностям. Числовым константам тоже давать названия.
От языка сильно зависит. Попробуйте пописать на ассемблере без комментирования.
Но для языков высокого уровня верно: код, нуждающийся в комментировании, должен быть переписан.
Самые лучше комментарии — это грамотная структура кода, а самая лучшая документация — это тесты.
Ну и отдельная (не интегрированная в код) документация по API библиотек.
Заключенным написали сзади произвольные целые числа так, что при построении в колонну каждый заключенный видит числа впереди стоящих. Если заключенный называет свое число, он остается жив, иначе расстреливается на месте.
Какая самая оптимальная стратегия для сохранения большего количества жизней?Если число заключённых конечно, то последний стоящий заключённый преобразует номера впереди стоящих в одно число (типа new LongInteger(GetBytesFromString("1,2,3,435"))), а дальше каждый следующий декодирует число обратно в список и называет свой номер по порядку.
sbnur
14.03.2017 23:10с решением отлично как говорится ответ написан явно — но сколько останется в живых?
ассемблер — это же не язык, а код — хотя можно спорить чем код отличается от языка.
В бытность молодым я довольно быстро научился читать тест программы с перфокарт.
Но согласен с вами — пишите программы правильно.DistortNeo
14.03.2017 23:34с решением отлично как говорится ответ написан явно — но сколько останется в живых?
Останутся живы все, кроме одного.
sbnur
15.03.2017 07:34существует все же ненулевая вероятность, что и первый остнется жив, так как числа произвольны
Carburn
15.03.2017 02:36Язык ассемблера
sbnur
15.03.2017 07:06Да так говорят — но это размытие термина.
Ассемблер привязан к архитектуре — то есть он машинно-зависим — то есть по сути это мнемоническая кодировка машинных кодов.
Язык программирования — он прежде всего машинно-независим — это средство записи алгоритмов, которая базируется на определенной структуре данных, базовых алгоритмов и интерфейсов.
Для меня это принципиальная разница
netologyru
15.03.2017 08:29Это был выбор автора, чтобы опубликовать именно анонимно. Мы согласились.
И спасибо за задачу!)
Arseny_Info
14.03.2017 23:28+4чистый процедурный стиль > функциональный стиль > объектный стиль
Т.е. ООП для вас — вершина эволюции, а функциональщина — лишь шаг к этой вершине?
kloppspb
14.03.2017 23:48+1И лучшее, что я видел для работы с SQL базами — это HeidiSQL.
Шутите? Сначала выкиньте из юзкейса слово «Windows». Ах да, оно идёт под вайном же. OK, тогда добавьте слово «postgresql». Как теперь?
Кто из них пойдет умываться?
Надеюсь, оба :)Carburn
15.03.2017 02:51HeidiSQL — MySQL, MSSQL and PostgreSQL made easy
kloppspb
15.03.2017 09:35Под вайном и изи? Вам крупно повезло :) Но удачный запуск поддержку pldebugger всё равно не добавит.
faiwer
15.03.2017 09:55PostgreSQL
Там весьма условная поддержка. У меня оно постоянно вылетало. Как на минном поле. Сюда не жми, туда не ходи...
ainoneko
15.03.2017 11:15+1Кто из них пойдет умываться?
Надеюсь, оба :)
Я помню это каканекдот про логику, психологию и философию.Василия Ивановича послали учиться в Военную академию. По приезде Петька его и спрашивает:
– Ну как, Василий Иванович, чему ты там научился?
– Да много чему, Петька… Вот, например, науки такие: логика, психология, философия…
– Ой, расскажи про науки!
– Ну, как бы тебе объяснить-то… Представь себе, что в сторону бани идут два мужика: один чистый, а другой грязный. Кто из них идет в баню, а кто мимо?
– А черт их знает!
– Эх ты, Петька! В баню пойдет грязный мужик – чистому-то зачем мыться? Вот тебе пример из логики.
– Здорово, Василий Иванович!
– А вот тебе еще задачка: опять идут два мужика: чистый и грязный. Какой из них в баню идет?
– Ну как же, вы же сами сказали – грязный!
– Эээ, нет – подумай, почему он грязный? Потому, что в баню не ходит! Значит, чистый пойдет! Вот это тебе пример из психологии…
– Ну, Василий Иванович, ты даешь!
– А вот еще послушай: идут два мужика…
– Да задрал ты меня своими мужиками!
– А это уже пример из философии…
Jabher
15.03.2017 01:14+1что? серьезно? никто еще не сказал, что жквери не нужен? :)
А если серьезно — прикладные вещи конкретной технологии, типа жквери, не нужны, если ты работаешь с микроконтроллерами, например, так что это тупо выбивается из общего списка.
Carburn
15.03.2017 02:44+1Скажи мне, как может быть такое, чтобы два человека спускались по одной и той же трубе, и один из них испачкал лицо, а другой — нет?! Неужели ты не понимаешь? Весь этот вопрос — бессмыслица, и если ты потратишь жизнь, отвечая на бессмысленные вопросы, то все твои ответы тоже будут лишены смысла!
ИсточникСогласен, ваши задачи бессмысленные.
mad_nazgul
15.03.2017 06:34+1ИМХО любые тесты/задачи проверяют, то что вы умете/знаете ответы на конкретные тесты и задачи.
К мышлению это очень слабо относиться.
Например я уже знал решения для половины ваших задач.
А то что не знал легко нагуглил.
Сейчас, когда информация находится на кончике пальцев, только на испытательном сроке можно понять — может человек работать или нет.
P.S. Код с комментариями очень трудно читать. Т.к. «все лгут», а уж комментарии особенно.
Вместо кучи комментариев, я бы предпочел хотя бы 50% покрытие unit-тестами. :-)
degs
15.03.2017 07:19Обратите внимание как изящно решил проблему Наташи Ростовой автор «Войны и мира» — Пьер Безухов пацифист и пистолета с собой не носит. Всем учиться и учиться у классиков.
perfect_genius
15.03.2017 07:50Мальчику было 6 лет, его сестрёнке — в два раза меньше. Теперь ему 70 лет — сколько лет сестре?
ainoneko
15.03.2017 11:08+1Не больше 68.
(Почему не больше: она и умереть могла и остаться «вечно молодой».)
(Почему не 67: например, на следующий день ей исполнилось 4, а ему всё ещё было 6, потом прошло ровно 64 года. )
Lordi
15.03.2017 08:31+6Про КПД и нахождение в офисе — в точку! Работал когда 5/2, то рабочий день выглядел так:
— 9-11 пил кофе и читал новости/хабр/статьи
— 11-12 очень продуктивно работал
— 12-13 работал так себе и ждал обед
— 13-14 обед
— 14 и до конца работал в ожидании «когда же домой»
Основной объем работы делался дома с 22 до 02.00. Потом устроился в компанию, где в офисе надо было появляться на 2 часа, где обсуждались насущные вопросы, шаги, корректировались сроки. Работал часов 5-6 в день с максимальным КПД и объем работ выполнял в разы выше, чем на графике 5/2.
Думаю большое количество разработчиков (не обязательно программисты) поймут меня. Бывает настроения нет, а бывает, что прям распирает.
dmitry_shabalin
15.03.2017 08:31+1Насчет ООП и Процедурного стиля. Скорость работы не показатель их различия. Не надо как бабка говорить, что — типа переписали и так получилось, если говоришь то ссылка на репозиторий или какие-то конкретные моменты почему так. А то получается ООП медленное г…, а процедурный стиль фонтан.
TripleAction
15.03.2017 08:31A = ((A-B)-A)*(-1)
B = B+(A-B)
bitver
15.03.2017 16:10Эм, пояснить можете?
Я здесь вижу A=B, B=A: хоть ставьте скобки, хоть нет — переменные там взаимоисключаются.
Sencho_Pens
15.03.2017 08:31Задачи не дают никакого челенджа, да и на самом деле на такие задачи не очень трудно натренироваться.
skyandrd
15.03.2017 08:32есть опечатка в ответе на 1ый вопрос:
Первая итерация: А = A + B (7 + 8 = 15), теперь у вас A = 15, B = 8. Вторая итерация: B = A — B (15 — 8 = 7), теперь у нас B = 15, A = 7.
верно так «теперь у нас B = 7, A = 15». а то я подумал, что тут какая-то магия :)
insensible
15.03.2017 08:48Про оду JQuery. Я давно уже не использую в новых проектах, и ничуть жалею. Обнако, недавно имел удовольствие лицезреть при отладке старого кода, ЧТО под капотом делает метод JQuery.remove для элемента. Я думал это примерно как Node.removeChild, оказалось- там множество циклов и кода при вызовах различных достаточно непростых функций. Весьма любопытно, как такое скажется на прризводительности...
XoJIoD
15.03.2017 09:10+2По поводу 6 задачи:
В разработанной вами системе я бы постоянно затаривался товарами со стоимостью <= 24 руб)
Germanets
15.03.2017 16:25+1С тем же успехом сейчас в большинстве магазинов можно затариваться товарами, стоимостью меньше 1 рубля… Причём даже округления нет — копейки всегда отбрасываются… Вот только товаров таких нет)
Electrohedgehog
15.03.2017 10:15+6Какая чудесная, мотивирующая статья! Она так прекрасно описывает мир ваших радужных фантазий! Приступы кода, интересные задачки, фронт или бэк, #ТАЙ! Не верьте в эту херню.
Есть постоянное изучение фреймворков, языков, библиотек и апи, есть дибилы-заказчики и упыри-аутсорсеры, есть сайты на ___ПЯТЬСОТ МЕГАБАЙТ КОДА И СОТНИ ЧЁРТОВЫХ БИБЛИОТЕК ___, есть надо сделать вчера, есть случайные падения сервера, есть падения гита которых не ожидаешь, есть твои приложения, которые менеджер передумал выпускать.
При условии того, что ты проплаваешь во всём этом дерьме года три а лучше пять ты сможешь уехать в #ТАЙ и писать на аутсорс говнокод не парясь по поводу его качества.
Только это довольно хреновый путь. Потому, что толком программировать ты так и не научишься, зато научишься пихать в любой проект Angular и jQuery, потому что это «ускоряет» разработку.
Программистами не рождаются а становятся. Изучая теорию, читая чужой код, разбираясь в принципах работы сетей, учась администрировать сервера. Тратя на это почти всё своё свободное время. А эта статья о том, что ты избранный и тебя ждёт #ТАЙ, просто маркетинговый буллшит.
Dimusik
15.03.2017 10:54А почему нельзя сначала перевезти волка, потом капусту, а потом козу?
GlukKazan
15.03.2017 11:14потому что пока вы возите волка, коза съест капусту
Dimusik
15.03.2017 11:16Так капуста же с волком будет, на другом берегу (уже перевезенная). А коза будет в лодке плыть последней. Как она капусту съест?
bfDeveloper
15.03.2017 12:37Формулировка задач страдает от недосказанности и неточности. Что такое переменная и «классическая математика»? В математической нотации все значения неизменяемы. Может вы хотели ограничиться простыми арифметическими операторами +-*/ и императивным ЯП?
Что такое идти на северо-восток? У этого понятия есть 2 трактовки: выбрать направление и идти, не сворачивая; и ваш вариант с непрерывной корректировкой. Про магнитный полюс тоже уже написали выше.NotSure
15.03.2017 13:27Ну вот так и останетесь кодером, который всё, что может — это кодить чётко сформулированные задачи.
kloppspb
15.03.2017 13:52+6Или — нормальным программистом, взаимодействующим с постановщиком задач при любой неясности.
NotSure
15.03.2017 15:35Обычно есть контекст, основываясь на котором можно понять, какое решение будет правильным.
Например, фразаКакая конечная точка будет у вашего путешествия, которое в действительности может продолжаться бесконечно долго, но все же закончится в конкретной точке?
однозначно определяет, что имелось в виду под «идти на северо-восток».
Но я соглашусь, что программист, по-ковбойски интерпретирующий задачу первым пришедшим в голову способом, опасен)kloppspb
15.03.2017 15:44А мне первое что подумалось в этом контексте — окружность нарезать можно бесконечно, но путешествие закончится в точке старта, ибо дальше смысла нет :-)
bfDeveloper
16.03.2017 01:26Ну как бы уже не остался.
Задачи «на логику» сами должны быть чёткими и логичными. Потому что без внесения достаточного уровня абстракции они просто не работают. Невозможно идти постоянно на северо-восток: кроме гор и морей мы упрёмся ещё и в дискретность шага. Если корректировки очень редки, то можно вообще никогда не остановиться. Математика это не влезание в голову к спрашивающему, а работа только своей.
Общение с заказчиком это не головоломка, не математическая задача, это совершенно ортогональный навык. Там как раз наоборот требования нелогичны и противоречивы и часто вообще не соотносятся с тем, что действительно удовлетворит потребности. И безполезно лезть в голову к кому-либо, там всё равно ответа нет. Его надо создать.
А «кодер» как раз ищет наиболее простое логичное решение в задаче. Например, (A, B) = (B, A), потому что «в моём языке так можно».
potan
15.03.2017 13:22+2По поводу первой задачи — в классической математике нет операции присваивания. Если ее можно использовать, то почему бы не использовать и множественное "(A,B) = (B,A)"?
kaman
15.03.2017 13:27И важно понимать, что бэкенд-разработка далеко не всегда связана именно с веб-ресурсами, очень часто мы прячемся под капотом мобильных приложений и различных узкоспециализированных сервисов.
Если вспомнить, что значительная часть мобильных приложений – клиенты различных веб-ресурсов, мобильная разработка получается как раз ближе к фронтенду.
igrishaev
15.03.2017 13:36решения
a=a^b;иa = a + b— это не классическая математика, потому что в математике запрещено повторное присваивание.bitver
15.03.2017 14:34-3Бред не несите. Переменные и в математике переменные.
По вашим суждениям тогда уж и задача бессмысленна.
igrishaev
15.03.2017 14:41+1Повежливей, пожалуйста.
В математике используется одноразовое связывание. Не бывает так, что в начале решения уравнения у вас x = 42, а в середине x = 43.
Задача бессмысленна по своей сути, потому что на высокоуровневых языках пишут
a,b = b,a. A на низкоуровневых языках у вас возникает проблема переполнения, чтобы решить которую понадобиться написать еще несколько проверок.
Labunsky
15.03.2017 17:56Не бывает так, что в начале решения уравнения у вас x = 42, а в середине x = 43
А что мешает-то? Если вас дальше эта пара «х = 42» не интересует, то никто не заставляет убирать целую букву из списка возможных обозначений. Пишете «теперь, положим x = 43» и чешете дальше
Areso
15.03.2017 13:46Обратные скидки, да, прикольно. У меня был другой случай, правда как у клиента, когда кто-то умножил прайс поставщика в долларах на курс и накрутил сверху процент фирмы, а когда курс отломился, на 1…
Заказал кучу техники в тот день в том магазине, но магазин нисколечко не сомневаясь отменил все мои заказы)
immaculate
15.03.2017 14:21+1Почему-то ожидал, что будет статья о работе программистом в Таиланде. Тут уже писал человек, который жил и работал там не удаленно.
igrishaev
15.03.2017 14:41Лучшее мнение о Тайланде, что мне приходилось слышать — http://artgorbunov.ru/bb/soviet/20130304/
jaguard
15.03.2017 19:44Все так, тай расслабляет.
Последние пять лет каждый год провожу по месяцу в тае, с планами «заодно и поработаю». И каждый раз думаю заранее — «ну теперь точно поработаю». И каждый раз оказывается что работать совершенно невозможно… Что-то я, конечно, делаю — но производительность оставляет желать.
Deranged
15.03.2017 17:02+3Нет на свете явления страшнее, чем программист с нестандартным и гибким мышлением.
Myosotis
17.03.2017 13:22Задачу про трубочистов не поняла, в чем ее сакральный смысл? Есть несколько вариантов после того, как они вылезут из трубы:
1) умываться идут оба (один за компанию)
2) умываться пойдет только грязный
3) умываться пойдет только чистый (почему бы и нет)
4) никто не пойдет умываться (им, может, еще раз в трубу надо будет лезть)degs
17.03.2017 18:39Да нет же, задачка вполне детская и построена на том что первый рефлекторный ответ — «умываться пойдет грязный». Ответ подразумеваемый правильным — «грязный посмотрит на чистого и решит что он тоже чистый, а чистый посмотрит на грязного и пойдет умываться»
Myosotis
17.03.2017 19:24Но если у одного лицо испачкано, ему разве об этом не сообщит напарник? Или они просто посмотрят молча друг на друга и пойдут по своим делам? Задание дурацкое, и я бы задумалась об адекватности работадателя, дающего такие «задачки» на собеседовании.
mbait
19.03.2017 04:13Есть два варианта решения второй задачи. В обоих предполагается, что мы рассматриваем движение одной материальной точки в другую и пренебрегаем скоростью вращения земли. Мы также предполагаем, что исходная точка не находится ни на одном из посюсов.
В первом варианте мы выбираем направление и движемся прямо. В этом случае траектория пути будет эллипсом, а двигаться мы будем бесконечно.
Во втором варианте в каждый момент времени вектор скорости движущейся точки указывает на северо-восток. Так как в отличие от севера и юга восток является относительным понятием (задаётся отношением магнитных сил, которые действуют с разных полюсов), с приближением к северному полюсу вектор будет всё сильнее указывать на север, но никогда не покажет строго на него. В результате траекторией движения будет локсодрома. Конечной точкой пути будет северный полюс, но достигаться он будет бесконечно долго. Всё это верно для математической модели. В реальном мире компас при приближении к полюсу перестанет работать.
ainoneko
22.03.2017 14:55Конечной точкой пути будет северный полюс, но достигаться он будет бесконечно долго.
(1) Это если идти всё медленнее и медленнее, иначе дойдём за конечное время (сделав каким-то образом бесконечное число витков воруг полюса).
(2) Для большинства практических приложений достаточно приблизиться к полюсу на расстояние равное размеру атома.
SbWereWolf
офигеть :)) очень здраво