Pull to refresh
4
0
Сергей @S-type

Программист

Send message
IMHO, надо уже запрещать статьи про «аккумуляторы, которые всех порвут».
Просто БРАВО!
Спасибо.
С нетерпением жду продолжения.
Как то не разглядел в статье — как же именно реализован WhereOverlap.
Наглядно показано, что проблемы у нас не где то, а (по большей части) в своей же голове.

Выходит мозг — как мышцы. Чем больше нагружаешь (тренируешь) тем он лучше работает.

Спасибо за хорошую статью.
Помню, решил банк (в котором я на тот момент работать) установить сеть терминалов самообслуживания. Дал объявление «требуются...» Пришёл товарищ, рассказывает «я уже развернул в банке, где работал, сеть банкоматов и терминалов». Спрашиваю «а как, собственно, вы это делали»? — «Да как. Вызвал зама и сказал, что бы установили банкоматы и терминалы».
Автору спасибо за статью, некоторые утверждения сильно затронули мой личный опыт, особенно из области «когда остаешься один на один со своим стектрейсом».

Присоединяюсь. Золотые слова.

Кстати, бывает такое, что со временем сложность программы начинает перерастать «вычислительные возможности» программиста. Когда осознаёшь, что уже не хватает головы, что бы впихнуть всё. Вот тогда приходится думать «как упростить/как разрезать на части».
Помнится, как то работал на Маслосырзаводе. Сижу, думаю над кодом. Заходят шоферА. Увидели меня: «А, программист, у тебя работа лёгкая — клавиши нажимать». Встаю и говорю «Давай посмотрим, у кого работа легче. Я сейчас буду твою тяжёлую работу делать — сяду за руль, и буду молоко развозить. А ты мою лёгкую — садись за компьютер.». Он опешил «так ты же пять лет учился»…
Скорее, об отношении к It. Ведь хирург привык решать проблемы «не по мере поступления», а предвидеть их, продумывать действия «на перёд». Должен чётко знать «из чего устроен другой человек». Как в программировании. Прежде чем лезть в программу, надо изучить язык, изучить бизнес-логику. И лишь потом соваться внутрь… Программисту држе проще — даже при наличии дедлайна ни кто не умрёт, и всегда можно в гите откатиться…
Помню, пришёл работать в банк. Как то меня позвали поучаствовать в решении одной проблемы. Я сказал, что проблема тяжёлая, надо разобраться как с фронта передать на бэк, почитать документацию, выяснить api, оценил работу по времени. Через какое то время интересуюсь «когда делать то»? Мне в ответ «плохой ты программист, вот наш взял и быстро сделал». Интересно стало. А сделал он просто — прямо из JS делал запись в базу. Из фронта в базу, минуя бэк. На мой вопрос «а ты уверен в правильности такого архитектурного решения», он сказал «мне пофигу на архитектуру, работает — и ладно». Через какое то время это парень с банка уволился. И, где то через пару лет я встретил его за обедом (на бизнес ланче) в одном кафе. Разговорились, спрашиваю — где работаешь. Он говорит — в мебельном магазине. Сначала работал рядовым продавцом, потом поставили руководить другими менеджерами. Сказал, что работа ему очень нравится. Интересуюсь — а зачем ты тогда в программирование пошёл? Говорит — у меня папа программист. С детства заставлял программировать. Он и научился. Но, душа к этому абсолютно не лежала. А теперь он работает с компрьютером только как пользователь — в программе бланки заполняет. И, не рвётся больше в программисты. Не потому, что не может, а потому, что не хочет.
К чему это я? Да к тому, что можно любого научить каким то азам программирования, что он даже будет что то делать. Но, если тебе это не приносит удовольствия, вряд ли ты станешь действительно хорошим программистом. И, надо прекратить мучить себя, а найти работу, на которой будешь действительно счастлив.
Это только одна из нескольких историй, когда люди уходили из It и были счастливы.
Программа, даже если она написана так, что можно легко понять «что делается», не содержит информации «для чего это делается». Иногда читаешь код и думаешь «понятно, что делается — но зачем это делается?» Например, «понятно, что тут из заявки удаляются все, кто согласовал. Но зачем удалять именно сдесь?». И, после неудачно попытки рефакторинга (перенести удаление согласующих, которые согласовали на «попозже») приходится возвращать всё назад и добавлять небольшой комментарий «а если не удалить — то дальше возникает такая то проблема...» Конечно, можно взять и ту проблему тоже устранить. Но, нет гарантии, что возникнет ещё что то.
Идеальный код в реальных условиях, увы, часто не достижим. Тем и полезен комментарий.
Блин, а ведь это мысль! Когда работаешь в банке — флешка отключена, файлообменники запрещены (тот же Yandex.Диск), а Git-ом доступен (каждый день пользуюсь). Теперь можно будет спокойно слушать на работе музычку…
Когда то прочитал, что из хирургов выходят хорошие программисты. Перед операцией хирург должен продумать многое: точный порядок действий, возможные осложнения и пр. Продумать надо всё заранее, потому что в момент операции (которая часто ограничена во времени) ему уже некогда думать — надо делать. Потом жизнь свела меня с одним действительно Специалистом, и он попросил меня приобрести ему компьютер. В начале 2000-х я многим друзьям, занкомым (и даже каким то малознакомым знакомых друзей) заказывал компьютер «в разборе», собирал, устанавливал ПО и проводил «первичное обучение». Так вот. У многих это обучение было, скажем так, довольно тяжёлым. Приходилось повторять по несколько раз одно и тоже, приходить по несколько раз к людям домой и показывать — как в Excel-е сложить две ячейки. Но вот с хирургом всё было просто великолепно — на лету схватывал, всё сразу запоминал. Один раз увидел, как я устанавливал драйвера к принтеру, потом сам научился устанавливать драйвера — следующий принтер он уже сам подключал.
Мне кажется, умение программировать — это просто что то, зашитое в генах. Как объём лёгких. Если он у тебя маленький — тебе нечего делать в силовых видах спорта. Как кенийские бегуны, которые берут медали на олимпиадах не потому, что долго тренировались, а потому, что это их гены.
Да, аппаратура в те времена была довольно хрупкой, и вариантов «как повредить железо» было много. Например, пятидюймовые HDD надо было «парковать», т.е. запускать специальную программу, которая переводила головку чтения диска в специальное место — иначе при выключении компьютера диски могли повредиться.
Вспомнилась такая история.
В конце 90-х устроился в Сбер. Хожу по банку и вижу в каждом отделе кактусы. Просто нереальное количество. Садишься что то сделать — колючки экран загораживают. Раскритиковал, сказал — убрать. Через какое то время приходит целая делегация и приносит вырезанные из Компьютерры листы, на которых изображена схема — как правильно расставлять кактусы вокруг монитора. И так хором давай рассказывать мне, какой я неуч, вот в журналах пишут, а ты физику не знаешь… Сначала отсмеялся, потом подождал, пока народ выговорится и показываю — вот видите, внизу листа написано «1 апреля»…
В своё время очень любил читать «Компьютерру». Увы, при переезде мой БК-0011 куда то пропал…
Огромное спасибо за статью. Давно так запоем не читал!
Какой то вы прям — агрессивный… На счёт «интуитивно-понятные» — не согласен. В принципе, все ограничения можно убрать. Вопрос только в цене — сколько это потребует усилий от авторов СУБД. Чем сложнее вьюшка, тем меньше вероятность, что вы сможете сделать её «на запись» — это факт. Потому, чем больше будут разниться первоначальная схема данных от текущей, тем больше вероятность, что вы столкнётесь с вариантом, что не получится сделать вьюху «на запись». IMHO, потому, для данной задачи перевода приложения на микросервисы лучше сразу считать вьюхи read-only.
вам бы матчасть изучить, а потом уже про базы данных писать:


А в чём претензия? Вы дали ссылку на то, что не любая вьюшка может использоваться «для записи». Конечно, вьюшка типа «select * from одна_таблица» — да, может использоваться как для чтения, так и для записи. Но, чем сложнее код вьюшки, тем меньше шансов, что данные можно будет сохранить.
Спасибо, буду знать.

Information

Rating
Does not participate
Location
Краснодар, Краснодарский край, Россия
Date of birth
Registered
Activity