[СММ-2024] О методе работы разработчика

Посты студентов Методология
, ,
1

photo_2024-08-08_18-02-50
photo_2024-08-08_18-02-501280×720 148 KB

Написан пост о методе вашей собственной работы. Для этого определите, какая работа занимала у вас основное время на прошлой неделе. Опишите метод/способ, которым вы делали эту работу — и используйте для этого какие-то представления из пройденного раздела нашего курса.

Была попытка описать стек программирования и нам заботливо указали на дефицит мозгов. Шла недавно по улице, сидят девочки-работницы кухни и одна из них “Я ей говорю-говорю, а она понять меня не может, потому что нечем!”. Я очень посмеялась тогда. Так вот нам тоже часто нечем подумать. Давайте разбираться, что ж такое программисты делают во время работы.

Я себе на вопрос, почему выбрана именно такая сфера, отвечаю “потому что мне нравится решать задачки”. И там дальше у @ilandikov был в посте вопрос, а почему программистов учат технологиям, хотя технологии не важны. Технологиям учат на курсах, в университете учат не технологиям. В университете учат пласту знаний/объяснений без которых новоиспеченный программист на рабочем месте будет сильно ограничен своим незнанием. Плюс в универе могут поломать голову необходимостью менять мышление. Это достаточно старый спор, зачем и надо ли идти в универ. А после универа надо ли доучиваться прикладным знаниям на курсах или на работе. Когда такого засилия курсов не было, учили “на производстве”. Я например навыки пользования системами контроля версий получила даже не на первой своей работе. Потому что никакого гита не было, был svn. А до него и контроля никакого не было, файлы по ftp заливались на сервер. И до сих пор считаю, что научить нормально ветки создавать/называть/сливать можно на рабочем месте. Если уж каким-то загадочным образом в 2024 году человек приходит работать, имея 2-3 года промышленного опыта, а навыка у него нет. Хуже когда какой-нибудь СА пытается проектировать таблицы в БД, а курса по базам данных университетского у него нет за плечами. И он искренне не понимает почему хранить у нас в таблице название сущности из чужой таблицы это так себе идея. Он пропустил в своей жизни разбирательство, а зачем эти странные люди придумали делать отдельную колонку с уникальным идентификатором в таблице. Довольно часто искусственным идентификатором.

Нормальные курсы по программированию делают как раз что-то типа стажировки. Т.е. примеры учебные, но как нам научный руководитель говорит “по зубам получите тут сразу, чтобы на работе было полегче”. Вот например хороший курс, прям на главной странице написано “Легко не будет, будет результат”. А дальше внимательный читатель заметит две особенности: 1) препод тебя будет перепосылать в процессе ревью столько раз, сколько надо пока у тебя в голове шестерёнки на место не встанут (это прививка от нежности в плане критики твоего кода) 2) ценник по времени активной работы берём и считаем - 25 недель основного курса плюс месяц финальной работы по 10-15 часов в неделю. Т.к. я знаю ребят, которые там учились, то 15 минимум. А это 435 часов за 7,5 месяцев. 9 месяцев заявлено с поиском работы. Не абы какие курсы, мы же теперь ценники знаем на МиС и СМ. Попробуй без собранности справиться.

На первый взгляд по методу работы мы имеем две части. Первая это “решение задачи”: понимание самой задачи, проектирование решение, уточнение/формализация алгоритма решения, кодирование, тестирование/валидация, приёмка/верификация, передача результата дальше по конвейеру (сильно желательно до конечного пользователя). Массив знаний по первой части со времён, когда я файлики заливала по ftp сильно разросся и продолжает пухнуть. Но его всегда можно найти и дальше запланировать, когда обновиться, добрать то, чего нет. Roadmap - схема, на которой методы не выделены и в целом всё вперемешку: архитектура, тестирование, кодирование, решение конкретных задач (типа поиска или кэширования), куски из devops, security. В описание курса по RoR тоже салат: TDD, деплой, архитектура, gitflow.

Вторая это взаимодействия и предподготовка. С взаимодействием ситуация тоже странная. С одной стороны осталось старое - учишься работать с коллегами непосредственно на производстве. Идеально, если тебе попадались хорошие люди, который тебя научат. Мне попадались: “у вас всё в команде не работает, потому что вы не общаетесь”. С другой стороны товарищи маркетологи всё это назвали “soft skills”. И продают курсы, книжки. Нормального/согласованного roadmap по этим штукам нет. Есть попытки делать его для должностей с менеджерским уклоном. Но там снова дыра в фундаменте. Вместо собранности тайм-менеджмент, вместо онтологики и коммуникации какие-нибудь кривые делегирования и прочее.

Предподготовки нет. Потому что ролей стало много, каждый сидит в своей коробочке и дальше неё не видит. Или “не моё дело”.

Работать методом “дайте чёткие условия задачи - я вам её решу” уже давно не получается. Думала, на что у меня уходит основное время - на роль детектива. В целом нынешняя работа скорее похожа на ролевую игру (RPG). Надо пойти к хранителю леса, предварительно успешно миновать ворота “Неопределённости системного и бизнес анализа”. Когда хранитель найден, надо отгадать от него 33 загадки. Получить, а чаще сделать самому артефакт и только потом идти в свои катакомбы гномов, изготавливать “сапоги-скороходы”.

Пример работы по методу.

  1. Заметить::метод проблему::предмет метода.
    Несколько раз уже была проблема, ломается сборка в разных ветках из-за обновления библиотек.
  2. Описать::метод проблему::предмет метода. Рабочий продукт - описание. Описание заносится в задачу в таск-трекере::документ. Сама по себе задача это работа, на которую ставится исполнитель (я). Сроки не ставятся, потому что надо искать причину. Сроки я ставлю, когда у меня этап реализации выбранного решения. А до него ещё долго.
  3. Подумать::метод о возможных причинах проблемы. Определяем место проблемы в процессе разработки. Это место это CI. И это стык работы двух команд (нашей и devops).
  4. Изучить::метод файл с описанием процесса CI для наших репозиториев. Его бы ещё найти надо, но я знаю, где он. Потому что и мои строчки там есть.
  5. Подумать::метод какие особенности сборки кода не учтены. Там у devops чаще всего нет объектов внимания, потому что они не до конца понимают как у нас язык программирования работает. Один из таких объектов, которые я нашла в прошлый раз это версия языка. Когда мы переходим на новую версию, это делается постепенно. Для dev сред заезжает новая версия, потом тестируется и только потом она поедет дальше к людям. Т.е. процесс переезда растянут во времени. И в разных ветках на уровне CI должны быть поддержаны обе версии (старая и новая). Новый объект, который упущен это набор версий библиотек.
  6. Подумать::метод на что влияет набор версий библиотек. А ещё когда он меняется. И мы опять получаем что у нас в разных ветках может быть разный набор версий. Почему? Поход в документацию пакетного менеджера, указывает что есть определённая гибкость в описании какую версию библиотеки брать. Там только один вариант жёсткий, когда версия указана целиком (“0.12.4”). Тогда она прибита намертво. Её можно поменять только руками. А в других вариантах (как у нас), при получении библиотек будет попытка обновить версию в заданных рамках. Вот это первая проблема, самопроизвольное обновление версии происходит в CI, а соседние ветки ищут старую версию и сборка ломается.
  7. Кодируем::метод фиксацию версий библиотек. И думаем дальше.
    Если версии “прибиты гвоздями”, что может пойти не так? Они всё равно будут меняться, мы же их обновляем время от времени. И мы снова в разных ветках получим разный набор. Очередной потерянный объект - CI не знает о наборе библиотек в конкретной ветке. Но у нас есть однозначное описание этого набора - lock файл пакетного менеджера. Решение - дописать в файле с CI необходимость учитывать этот файл.
  8. Поиск::метод прописывания lock-файла в CI. Я погуглила и в прошлом проекте посмотрела. Нашла два варианта.
  9. Передать::метод описание решения проблемы в части CI девопсу. Примеры собрала, ссылки приложила, причинно-следственную связь описала. Дальше жду, всё-таки репозиторий чужой.

Сможете по моему описанию вычислить процентное соотношения применения знаний из backend roadmap и чего-то остального? Кстати что это за остальное? Процент именно технических “работ лопатой” очень скромный. Если глаза на блок знаний в голове по техничке закрыть (а он нужен конечно, никуда не денешься), то большую часть времени я работала навыками из МиС. А говорят непонятно, как применять эти ваши онтологики в работе. Хотя наверно уже из СМ тоже, удерживать важные объекты…

4 лайка
2

После понимания сразу проектирование? Не пропущен ли этап классификации понятой задачи, а затем уже выбор алгоритма/проектирование исходя из того класса, к которому отнесена задача?

3

Мм, поясните. У меня сейчас на это две мысли. 1) зачем мне классификация, это же не задачи из учебника по физике или математике 2) некая классификация (типизация скорее) происходит в голове автоматом.

Ещё возможно слово “алгоритм” превратно понимается. Опять же это не математика, где на каждую задачу есть чёткий алгоритм.

Вот то решение, которое я описала по шагам, вы бы как классифицировали? Там по мне в процессе разбирательств решение вылезло.

4

Ахахаххах ору)))

Действительно так, но почему тогда после универа программисту надо еще доучиваться? Потому что технологий нн дают?

Как это разбирательство/предмет называется в ВУЗе?

5

А почему у нас есть фундаментальная собранность, а есть прикладная? И методология тоже) Везде конкретное прикладное приходится доучивать. Его же много разного, его ни в одно обучение во всём разнообразии не засунешь. Я сейчас работаю на языке программирования, которого просто не существовало, когда я училась в универе)

“Базы данных” у нас назывался семестровый курс. Но это я опять про нормализацию и денормализацию в реляционных БД намекаю. Если просто складывать все данные в строку (плоско), таблица пухнет. А ещё данные в колонках повторяются. Люди подумали и решили. На повторяющиеся данные можно сделать справочник отдельно, т.е. в другую таблицу их вынести. Вот пишут например - первая нормальная форма.

Сейчас этому даже в части про моделирование в “Рациональной работе” (МиС) учат. Потому что если мы хотим людям дать нормальную табличку в экселе заполнять, там анкеты какие-то например. То сначала надо подумать как смоделировать данные, которые у нас будут в колонках. И чтобы все не писали что попало, им хорошо бы сделать выпадающий список с вариантами (это и есть справочник). Когда данные хорошо смоделированы, с ними потом работать удобнее.

6

Именно! Автоматом!
Я имел ввиду, что мы очень часто пропускаем выбор метода, точнее автоматом берем привычный метод и сразу начинаем работать работу. Нас учат, что не надо так.
Соответственно, после выполнения классификации задачи, мы можем выбрать из уже существующих методов для данного класса задач, вместо изобретения велосипеда.

Вашу задачу я бы отнес к классу задач Проблемы конфигурации и выбирал бы из известных решений в этом классе. Вы собственно так и сделали: “Я погуглила и в прошлом проекте посмотрела. Нашла два варианта”. Возможно явная классификация помогла бы лучше погуглить/написать промпт.

1 лайк
7

Обычно “Организация баз данных”.

8

Это окей, спасибо. Думаю весь курс методологии про это. Мы только начали) Но у меня выбор метода он внутри проектирования решения скорее.

Это слишком абстрактный и широкий класс. Вообще из него ничего не понятно. Давайте эксперимент. Если бы я сейчас заново решала эту же задачу. Область я определила это CI. Если как нас учили в моделировании, идти правильно. То мы идём всегда от индивида. Индивид тут - CI для репозиториев Elixir на платформе gitlab. И снова уточнение про то, что это Elixir у меня есть итак в голове. И оно само собой учитывалось при поиске. А вот gitlab всмысле поиска в интернете проблему не уточняет.

Или не можем, потому что готового решения нет. Его надо изобрести, чем мы в итоге и займёмся. Ведь не смотря на то, что CI есть везде, он везде свой конкретный.

Я ещё подумала, как бы шаблонное решение найти. И там опять довольно широкий класс “идеальный CI для приложений на Elixir”. Собери себе сам)

1 лайк
9

Давайте. Я очень далек от мира Elixir. Вот я накидал промпт с указанием типа задачи и ее кратким описанием.
I have a configuration issue with CI for Elixir repository on gitlab. Sometimes, in different branches we can have different library versions and as result we have a broken deployment. Give me the list of known best practices for such types of tasks with pros and cons.

Перед ним там общий промпт, не специфичный для вашей задачи. Вот ответы от двух LLM, оцените пожалуйста, насколько они помогли бы вам в решении?

Claude

P.S. Я не уверен, что первая ссылка будет работать без регистрации, перед объяснениями он выдал такой список:
2.1 Best Practices:

a) Use a lock file (mix.lock)
b) Implement version pinning in mix.exs
c) Utilize environment-specific configuration files
d) Implement a staging environment
e) Use GitLab CI/CD caching
f) Implement a dependency update strategy
g) Use Docker containers for CI/CD
h) Implement branch-specific builds
i) Automate dependency updates
j) Implement comprehensive testing

1 лайк
10

Ага, не работает

По делу a и b. А дальше как раз то, что к языку не относится. Но гуглится как Best Practices для CI в целом.

Мне кажется мы пришли к одному и тому же. Некая классификация “запроса” сужает горизонт поисков. Причём та, которая у меня отработала автоматом, отработала правильно. Но это скорее идеи объектов, о которых можно бы подумать. Причём из такого длинного списка, их ещё надо будет фильтровать/покритиковать, если у нас нет бесконечного времени на реализацию. И получается, что кругозор даёт беглость в классификации. А там где беглости нет, уже надо формально садиться и классифицировать.

2 лайка
11

Вопрос не “почему есть?”, а “почему не учат?” В ШСМ как раз и дают и фундаментальную, и прикладную.

Вот здесь вопрос, где и как разделять фундаметнальное и прикладное. Ну вот те же “базы данных” - насколько это фундаментальное или прикладное? Например, в embedded этих баз просто нет. С другой стороны, для какого-нибудь фронта HTML и JS - самый фундаментал.

Вот здесь мне проще согласиться, наверняка существовал язык, ошибки которого призван поправить тот, на котором вы пишете ;))) ну или парадигма та же как минимум существовала.

12

третий семестр не именно это, но во взаимодействии проявится в первую очередь

тут отчасти за аналитиков, у которых лапки + по вашим текстам, не первый раз, есть части орг изменений (это везде где вы пошли что-то выяснять, и что-то изменилось)

1 лайк
13

Этих нет, но должно быть что-то другое. Если состояние каких-то объектов сохраняется, то это происходит в результате работы по какому-то методу.

14

Ну там объекты понятнее, например, если написана на C виртуальная машина для вариации Java, то там достаточно написать стандартизированную модель объектов этой вариации Java, но вот мучиться с тем, как эти данные разбить не надо, об этом уже подумали те, кто писал стандарт)

15

Всё разнообразие технологий в прикладной собранности ШСМ тоже не даёт. В соседнем топике по МиС парень пишет, что у него и трелло, и обсидиан, и в ворде он что-то пишет. Зачем мы его не будем спрашивать. Но собранность даже прикладная даёт знания и принципы, инструмент будь добр выбери под свои потребности и интересы. Хотя какие-то ссылки на инструменты есть (вот тебе фокус туду).

Я что-то изначальную притензию к вузу уже потеряла в нашей беседе. Напомнишь, что именно не так? То, что студент выйдя из универа как будто бы не может сразу выйти на работу каким-то конкретным программистом (фронтендером, или мобильщиком, или devops’ом). И к тому же когда он решит, кем он хочет быть, у него в голове будет часть “ненужных” знаний, а части нужных может не оказаться? Там знания и технологии/инструменты.

Насчёт фундамента для фронтов, карта тоже есть. И я бы скорее ждала, что фронтендер в качестве фундамента в состоянии по системным уровням вниз спуститься - он хоть как-то представляет, как вообще интернет работает. Тут мне сложно не набрасывать. HTML даже не язык программирования, это язык разметки и учится он быстро.

Но я ещё раз к универу вернусь. У меня и по вебу был семестровый курс, как раз там был HTML, css, js. Вуз в моем понимании даёт знания (computer science), погоняет по разным уровням (аппаратура, низкоуровневые языки, операционные системы, компиляторы, компьютерные сети, высокоуровневые языки и там вся пачка парадигм программирования, чтобы в обморок не падать столкнувшись с любым новым языком), технологии (есть часть, которая учит именно мыслить как программист, и это часто старые языки, а есть и современные языки, но они не в разрезе как сейчас же выйти на работу, а опять к какому-то курсу привязаны). Могла я с теми технологиями, которые давали сразу найти работу? Да вообще-то могла. У меня были универсальные - C++, C# (java можно было бы быстро по аналогии взять), python. Полностью предметный - 1С. Дальше уже отклонения в математику - Mathlab. А можно было и в админы идти, пока devops ещё не вылупились. Почему я пошла доучиваться? Потому что мне видите ли показалась перспективой веб-разработка. А курс был маленький и бекенда там не было. Хотя мне не хватило мозгов, вспомнить что на питоне тоже пишут бекенд для веб. И препод нам про это говорил. Как раз в разрезе “если прям очень надо будет на хлеб заработать, джанго подучите и вперёд”. Но это где-то на третьем курсе было. А мне тогда казалось, не, мы ж серьёзные ребята, раз C++ не подавились, то какой питон. Питон для слабаков. Админить не захотелось, потому что “это там где парни шкафы носят в серверную, и провода тянут под потолком”. 1С слишком девочковый. Если бы я хотела совсем девочковую работу, я бы в педагогический пошла с одноклассницами на ин.яз. Не для того три года математики вынесла.

В моем понимании ребята из вуза выходят достаточно универсальные. Отсутствие трансдисциплин не обсуждаем. Хотя и тут подвижки есть. Вон притащили уже СМ мастера в вуз. Но если тратить 4-5 лет на это не хочется, хочется чуть более прикладное и быстрее на работу это средне-специальное образование. Колледжи учат вроде больше про набор чем работать, а не про как думать.

1 лайк
16

Это, конечно, оффтоп, про “язык разметки” против “языка программирования” – но это как раз то, что могут обсуждать олдовые программисты, а выпускники программистских ПТУ – не могут.

И, конечно, Accidentally Turing-Complete

Это могло бы изучаться в школах, вместо сегодняшней информатики. Заодно и то, чем квантовый компьютер отличается от обычного – хотя оба вроде полны по тьюрингу, и почему это “аналоговые процессы в физических устройствах выдают математически точные результаты без накопления ошибки при повторениях” – нетривиальный ведь вопрос!

Получается, что computer science – это естественная наука, а не подраздел математики. Это Дойч обсуждал.

Вот это понятие “вычисления”, а потом обобщение его до “трансформации в физическом мире” – это должно быть в базе знаний о программировании. Увы, нигде этому не учат. Иногда-иногда в каких-нибудь западных спецкурсах, да и то – для создателей аппаратуры, а не программистов. А потом появляются легенды типа “в любой достаточно сложной программе со временем заводится внутри кривой и медленный интерпретатор коммон лиспа” )))

3 лайка
17

К нам не так давно скоропостижно заходил новый СТО. Его представили в общем “инженером” чате. И я почти в шутку поинтересовалась “какой у вас любимый язык программирования”. На что получила в ответ “SQL”. Парни в команде знатно расстроились, мы ещё полдня гадали писал ли он какие-то сложные штуки на PL/SQL или он жёсткий DBA, который нам щас даст за то, как у нас таблицы спроектированы. Но потом вскрылся опыт работы и там очень резкий поворот в менеджмент почти в начале карьеры. Парни расстроились окончательно. Должность для всех вслух была заменена на “руководителя разработки”. Что особо ситуацию не спасло.

18

Ну, это распространённый разговор, про SQL как полноценный тьюринг-полный, причём функциональный. Более того, SQL есть в TIOBE индексе, TIOBE Index - TIOBE – сейчас это седьмой по популярности язык программирования на планете )))

Но это уже совсем оффтоп. А вот учат ли моделированию данных в вузах, учат ли концептуальному моделированию, чем люди занимаются в DDD и чем это всё отличается друг от друга и как связано с разными онтологическими идеями – это вот вопрос.

При этом я как-то попросил сделать людей, которые занимались зависимыми типами, чатик по типам в языках программирования, моделирования и представления знаний (это ж всё одно – я часто об этом писал, например Алгоритмика, информатика, моделирование, далее везде: ailev — LiveJournal и там можно по ссылкам пойти), там почти полтыщи человек набежало – Telegram: Contact @typeslife, и вот там собрались люди, которые что-то про теорию языков программирования понимают и математику. Но там получилось, что они так и остались на уровне обсуждателей машины Тьюринга и теории типов, а вот что там по линии моделирования мира этими самыми типами в языках программирования – они в этом не очень тянут.

Это больное место: каким образом в языке программирования можно отражать модели окружающего нас мира, включая модели организаций. Этому вроде как нигде в вузах не учат, беда.

19

технологий не дают, да. По крайней мере у меня так было. И проблема не в технологиях технических, т.к. оглядываясь назад я понимаю что на уровне джуна я вполне себе нормально владел и языками программирования и базами данных и всякой всячиной вокруг фреймворков особо не знал(но их тогда не то чтобы многие знали так что норм).
А вот каких технологий не хватало:

  • как брать задачи, как их уточнять, как их доводить до продакшн-состояния
  • как понять что в решении задачи важно, а что нет
  • когда стоит остановится, а когда продолжать
  • как вообще поменять свое мышление с closed-world на open-world

Т.е. не хватало всего вокруг непосредственно CS технологий.

1 лайк
20

Кажется, причем, что этого не хватает просто_всем_выпускникам. У меня знакомый один пытается найти программистов в фирму, которые вовремя приходить на работу умеют =)

3 лайка