Написать код легко. Если у вас в голове сложилось решение, и вы уверенно владеете синтаксисом вашего любимого языка программирования, то напишете код с лёгкостью. А может быть у вас есть LLM, которая напишет за вас целые функции? Тогда ещё проще. Но сложнее всего не писать код, а читать. Требуется время, чтобы загрузить себе в голову ментальную модель системы. Вот это по-настоящему трудозатратно.
Ментальная модель складывается у вас в голове, когда вы читаете код. Это ваша внутренняя «карта», по которой понятно, как работает система, где находятся самые хитрые её части, что от чего зависит. Не имея такой карты в голове, вы просто смотрите на текстовые строки.
Когда я выполнял работу по заказу, большинство из моих заданий начинались одинаково. Мне ставили задачу пофиксить баг или добавить новую фичу в приложении, которое я видел впервые. Сначала моя ментальная модель была как чистая доска. Чтобы приступить к её заполнению, я открывал домашнюю страницу и разбирался, на что она похожа. Я открывал исходный код страницы: это React? jQuery? Сторонний плагин? Я просматривал базу кода, чтобы выяснить, используется ли у них где-нибудь ещё такая карусель, которую они просят поставить на первой страницы. Знакомился с их сборочным процессом, конфигурацией для тестирования, с тем, каким инструментарием они пользуются. Каждая мелкая деталь, которую я обнаруживал, встраивалась в ту модель, которая складывалась у меня в голове.
Ощущение было такое, как будто я переехал в незнакомый город. Вы выходите за порог вашего номера, проходите пару улиц, обращаете внимание, где выезд на шоссе, где овощной магазин, постепенно начинаете ориентироваться на местности. Примерно так ощущается и чтение кода: вы постепенно выстраиваете в уме мысленную карту, поэтому не заблудитесь, в очередной раз свернув куда-то в программе.
Допустим, вам требуется понять простую функцию, такую как getUserPreferences(userId). Чтобы построить её ментальную модель, вам нужно проследить следующие вещи:
Где именно определена эта функция?
Что она возвращает? Это промис? Какова форма данных?
Как именно она обращается к базе данных — напрямую или через API?
Участвуют ли в работе какие-либо уровни кэширования?
Что произойдёт, если пользователя не существует?
Кто ещё вызывает эту функцию и в каких контекстах?
Есть ли у неё побочный эффект?
Чтобы понять смысл конкретной функции, вам, возможно, придётся переключаться между схемами баз данных, промежуточным ПО для обработки ошибок и множеством точек вызова. Только выстроив такую сеть отношений, вы приобретёте достаточно подробный контекст, с опорой на который сможете спокойно что-то менять.
Это медленно. Поэтому читать код сложнее, чем писать. Гораздо сложнее. Когда вы пишете код, вы движетесь вперёд, укладываете свежий асфальт. Читая код вы, как правило, вынуждены ступать по чьим-то следам, а значит — переходить от файла к файлу, выслеживать вызовы функций, догадываться о побочных эффектах и расшифровывать намерения, которые автор кода только подразумевал. Чтобы понять функцию, зачастую требуется заглянуть в пять и более файлов. Только после этого у вас будет примерная карта, с которой можно хотя бы начать.
По той же причине отладка сложнее программирования. Один из самых распространённых комментариев на Stack Overflow, который можно встретить под плохо сформулированным вопросом — «Можете показать, что именно вы сделали»? Не проследив шаги, читатели треда не могут составить в голове картину того, что именно происходило. Опять же, именно поэтому то и дело всплывает проблема XY. Спрашивают о симптоме, не сообщая контекста, который помог бы отвечающему восстановить всю картину.
Меня до сих пор удивляет тот адвокат, который применил ChatGPT в суде. Он предоставил записку по делу, в котором процитировал шесть эпизодов, как оказалось — несуществующих. Все его спрашивали: почему вы не прочитали эти дела? Ответ тот же: чтобы выстроить модель, требуются силы и время. Ему следовало бы проследить каждое дело, прочитать его, а затем вставить в более широкий контекст юридического прецедента. Читать сложно. Генерировать легко.
Прочитать код – означает не просто разобрать его строку за строкой. Вам также придётся проработать документацию, посмотреть ревью кода, попрограммировать вместе с коллегами. На самом деле, есть решения, помогающие ускорить выстраивание ментальной модели. Но, даже помня об этом, всё равно придётся читать и вникать. Вы заметите, что программисты зачастую предпочитают написать всё с нуля, потому что «старый код отстой». В данном случае самое «отстойное» — это необходимость прочитать и понять.
Именно поэтому в LLM заключена такая сила, и одновременно они так опасны для программиста. Что бы ни генерировал ИИ — совершенный код или галлюцинации, вам всё равно придётся это прочитать. Проследить, как предположительно должен работать этот код, как он взаимодействует с оставшейся частью системы, каковы его побочные эффекты. Чем длиннее сгенерированный код, тем больше времени требуется, чтобы выстроить на его основе ментальную модель. Справившись с этой задачей, вы сможете увидеть в коде проблемы, места, где сгенерированный код неуместен, либо тихо ломает что-то ещё.
Притом, что LLM может в неограниченном количестве генерировать код или текст, всё время остаётся соблазн это не читать. Но без модели не обойтись. Вы не хотели бы загрузиться в чужую игру и оказаться посреди схватки с боссом. Именно такие ощущения вас ждут, если вы унаследуете или сгенерируете код, который не понимаете.
Так что вот самое главное узкое место в разработке ПО. Не писать, а понимать.
Пока у нас нет аналога LLM для понимания. Нет инструмента, который мог бы мгновенно переносить полную ментальную модель из системы прямо вам в голову. Пока он не появится, это узкое место никуда не денется. Мы решили проблему «медленной печати». Теперь мы можем сгенерировать больше кода, чем вообще в состоянии прочитать. Но пока мы не решим проблему с пониманием, стоимость разработки ПО не изменится: она стоит столько, сколько нужно времени человеку, чтобы осмыслить код.
Вот что реально скрывается за использованием ИИ-инструментов. Лучше не ставьте ИИ задачу сгенерировать большой кусок кода, а попросите его помочь вам понять уже имеющийся код. Не измеряйте продуктивность по количеству строк кода, а проверьте, насколько быстро команде удаётся построить точную ментальную модель создаваемой системы.
Возможно, будущее программирования — не в ускорении генерации кода, а в ускорении его понимания. А эту проблему решить гораздо сложнее.
Хотим напомнить, что у нас стартовала осенняя распродажа ?
Условия акции:
16–28 сентября 2025 г.
Скидка 35% на все бумажные книги по купону — Бумажная
Скидка 50% на все электронные книги по купону — Электронная
Комментарии (0)
Emelian
19.09.2025 14:00Прочитать код – означает не просто разобрать его строку за строкой. Вам также придётся проработать документацию, посмотреть ревью кода, попрограммировать вместе с коллегами. На самом деле, есть решения, помогающие ускорить выстраивание ментальной модели. Но, даже помня об этом, всё равно придётся читать и вникать.
Я, когда работаю с чужим, опенсорсным, кодом, поступаю проще. Первое – это добиться его компилируемости. Далее, уже смотришь, куда влепить свою затычку.
Особенно трудно, когда код, скажем на Си, для Линкса, а его надо адаптировать под «Форточки». Допустим, это код видео проигрывателя FFPlay.c. Чтобы адаптировать его в свой проект на C++ / WTL (см. скриншот моей неопубликованной программы «МедиаТекст» : http://scholium.webservis.ru/Pics/MediaText.png), мне пришлось переделать FFPlay.c в FFPlay.cpp и организовать там соответствующую систему классов. Это была муторная работа, но не безнадежная. Кстати, я так и не встретил на Гитхабе безпроблемного демо-проекта запускающего FFPlay.c в оконной программе. Что-то, конечно, было, но, сложное, громоздкое и некрасивое. Поэтому, как говорил «дедушка» Ленин: «Мы пойдем другим путём!».
Кроме того, пришлось не просто перекомпилировать код, но и внести туда достаточное количество изменений.
Короче говоря: «Дорогу осилит идущий!».
P.S. А, вот, написать код, подобный FFPlay.c, я не смог бы в принципе, так что тезис «писать проще, чем читать» – достаточно спорный.
mvv-rus
19.09.2025 14:00Первое – это добиться его компилируемости. Далее, уже смотришь, куда влепить свою затычку.
Основная проблема при таком подходе (если он заранее не был придусмотрен в программе изначально) - как добиться того, чтобы эта затычка ничего не сломала, не заткнула что-нибудь лишнее и т.п.
PS А ещё ваше объяснение напомнило мне историю в картинках, как нарисовать сову: здесь самое сложное, как раз - найти куда влепить, точно так же, как в упомянутой истории в картинках - нарисовать остальную сову: в обоих случаях работа требуется весьма творческая.
Emelian
19.09.2025 14:00Основная проблема при таком подходе (если он заранее не был предусмотрен в программе изначально) - как добиться того, чтобы эта затычка ничего не сломала, не заткнула что-нибудь лишнее и т.п.
Немного странное возражение. Я ведь на конкретных примерах рассуждаю (см. ссылку на скриншот), а не «вообще». Там достаточно сложный код консольного видеопроигрывателя, который удалось адаптировать под GUI-проект на C++ / WTL. Уже одно это (компиляция чужого пода под другую платформу) ценно само по себе, тем более, что хороших примеров в Интернете не найти.
Более того, «затычек» там вставлено более, чем. «Сломать» – страха не было, поскольку легко откатится к исподникам или к предыдущей итерации. Кстати, это мой основной метод программирования: итерационно-модульный. Сделал одну итерацию проекта – перешел к следующей. Напартачил – откатил назад. Дешево и сердито! Не раз выручало! Так, что – рекомендую!
PS А ещё ваше объяснение напомнило мне историю в картинках, как нарисовать сову: здесь самое сложное, как раз - найти куда влепить, точно так же, как в упомянутой истории в картинках - нарисовать остальную сову: в обоих случаях работа требуется весьма творческая.
Чтобы найти «куда влепить», я использую отладчик. С его помощью, относительно быстро нахожу нужное место. Только, чтобы пользоваться отладчиком проект должен компилироваться. А это, очень часто, проблема еще та. Даже бинарники авторы проектов не всегда прикладывают. Поэтому, еще раз, добился компиляции чужого проекта – решил половину своих проблем.
mvv-rus
19.09.2025 14:00Немного странное возражение. Я ведь на конкретных примерах рассуждаю (см. ссылку на скриншот), а не «вообще».
Возражаю чисто в контексте статьи - она-то про "вообще".
Напартачил – откатил назад. Дешево и сердито!
Дёшево. Но загвоздка в том, что не все ошибки проявлются сразу и явно. Впрочем, если делать программы для себя и таких же кодокопателей, можно и так. Но в кровавом энтерпрайзе так, наверное, лучше не делать.
PS Ну и пропущенное, из прошлого комментария:
А, вот, написать код, подобный FFPlay.c, я не смог бы в принципе.
А другие, которые хорошо знакомы с той математикой, которая лежит в основе методов кодирования? Полагаю, что о них вы судить не можете.
Emelian
19.09.2025 14:00Возражаю чисто в контексте статьи - она-то про "вообще".
Тогда это вообще ни о чём. Прочитал и забыл! Общие слова плохо воспринимают не только люди, но и ИИ. У вас в голове складывается одна ментальная модель, у меня другая. Как мы можем понять друг друга?
Дёшево. Но загвоздка в том, что не все ошибки проявляются сразу и явно.
Это, вообще-то, другая тема. Называется «тестирование». Для этого есть команда тестировщиков, напрягайте их. А если их нет, то, причем тут «чтение»? Т.е., вы либо исправляете чужие ляпы, либо что-то разрабатываете, с привлечением чужого кода. В этом случае, он вам не обязан быть «хорошим»,
Впрочем, если делать программы для себя и таких же кодокопателей, можно и так.
О чём мы вообще спорим? Вы говорите, чтобы изменять чужой код, его надо сначала внимательно прочитать, семь раз подумать и один раз отрезать. Так? Я же утверждаю, что достаточно делать итерации изменений (можно небольших), а места для изменений искать с помощью отладчика. Что неверно?
Но в кровавом энтерпрайзе так, наверное, лучше не делать.
Почему? В крайнем случае, там должна быть явно определена корпоративная метода разработки и тестирования кода. Следуйте ей, если за это платят деньги. А если ее нет, то, какие вопросы? Ибо у каждого собственные представления о прекрасном! Тогда уж лучше обсуждайте здесь эту самую «корпоративную методу», всяко, больше пользы будет.
А другие, которые хорошо знакомы с той математикой, которая лежит в основе методов кодирования? Полагаю, что о них вы судить не можете.
О чём вы вообще говорите? Это называется «съезжать с темы». Если вы хотите похвастаться, что знаете математику, то я тоже могу похвастаться. У меня два полных дневных высших образования: Политехнический институт и мехмат МГУ (математика). Между ними – работа по распределению, во Всесоюзном НИИ. Если бы не развал СССР, то карьера бы светила суперсногсшибательная. Но, и так неплохо.
mvv-rus
19.09.2025 14:00Тогда это вообще ни о чём. Прочитал и забыл! Общие слова плохо воспринимают не только люди, но и ИИ.
Люди, в отличие от ИИ, могут сопоставить эти высокоуровневые абстракции и следующие из них выводы с окружающей действительностью. А ИИ (современный, который LLM) - таки да, никак: в абстракции он не умеет, он умеет чисто конкретно найти слова, которые обычно стоят после уже написанных
У вас в голове складывается одна ментальная модель, у меня другая. Как мы можем понять друг друга?
Если рассуждать как вы, теоретически, то вас, судя по заявленному вами образованию, должны были этому учить на занятиях по диамату: критерием истины является общественная практика - если обе модели этой практике соответствуют, то они, скорее всего эквиваленты в области, где соответствуют, если вообще не тождественны. А если соответствия практике нет, то надо модель уточнять, т.е., в соответствии с диаматом - двигаться от неподного и неточного знания ко всё более полному и точному. Но в СССР (и, тем более - после) всему этому учили плохо, так что не ваша вина, что вы это не знаете.
Ну, а ещё можно просто попробовать друг с другом поговорить и договориться. На практике часто помогает.
Это, вообще-то, другая тема. Называется «тестирование». Для этого есть команда тестировщиков, напрягайте их.
Тестирование не способно выявить все ошибки программы, то есть, если сказать то же самое другими словами - доказать правильность программы. А ошибки лучше заранее не делать, в том числе - и систематически используя тесты: есть даже такой подход к разработке программ, который это навязывает - Test Driven Development называется.
Я же утверждаю, что достаточно делать итерации изменений (можно небольших), а места для изменений искать с помощью отладчика. Что неверно?
А вы точно уверены, что этот процесс сходится? Точно-точно? И именно к желаемому вами результату? Я вот не уверен, что точно сходится, ибо гарантий тут никаких. А вот для разбухания кода, и превращения его в "Большой комок грязи" такой процесс подходит IMHO идеально. И, кстати, забегая вперед: кровавый энтерпрайз большие комки грязи не любит, ему от них больно, хотя они в нем получаются регулярно.
Если вы хотите похвастаться, что знаете математику, то я тоже могу похвастаться.
Нет, я не хотел похвастаться. Более того, некоторую математику, широко применяемую в программировании - например, ту абстрактную алгебру, без которой сложно полюбить ФП (см. первый каметнт к статье) - я прошел мимо: ну, не преподавали нам эту самую абстрактную (она же - "высшая") алгебру в том физкультурном техникуме с английским уклоном, что в г.Долнопрудный МО, который я закончил. Я всего лишь сделал предположения о причинах ваших затруднений. Ошибся, прошу прощения.
А, как я теперь понял, причины ваших затруднений в другом: и вас не учили (и вы сами не обучались) инженерной дисциплине под условным названием разработка больших программ: понятию об архитектуре, декомпозиции на модули, сложности кода, связей между модулями и влияния их на сложность и т.д.(а если я опять ошибся - заранее прошу прощения и беру все написанные далее в отношении вас слова обратно). Это не удивительно: в советских политехах вообще мало чему учили, тем более - такому новому делу как software engineering, а Мехмат МГУ - это вообще не про инженерное образование.
Меня, если чо, тоже в нашем физкультурном техникуме этому не учили (хотя в графе "квалификация" в дипломе слово "инженер" у меня записано), но я учился всему этому сам - не слишком интенсивно, но весьма долго (и сейчас, если чо - доучиваюсь по необходимости).
А без знания этой дисциплины по настоящему большие и сложные программы действительно не сделать.
Но дело не в этом. А в том, что обсуждаемая статья - она тоже про эту самую дисциплину, про сложные программы: как их читать - и чисто для себя, и чтобы модифицировать. А поскольку (предполагаю) эта дисциплина столь же не входит число ваших понятий, как и, например, законы языка ирокезского, то и ваши суждения по этому вопросу имеют сомнительную ценность: следуя им, легче легкого что-нибудь напортачить в большой и сложной программе. Не зря же великий русский мыслитель Козьма Прутков предупреждал "Рассуждай токмо о том, о чем понятия твои тебе сие дозволяют."
Emelian
19.09.2025 14:00Если рассуждать как вы, теоретически, то вас, судя по заявленному вами образованию, должны были этому учить на занятиях по диамату: критерием истины является общественная практика
Меня, в двух ВУЗах, учили, что критерием истины является практика. Слово «общественная» это уже какой-то новояз. Можете глянуть мою недавнюю статью: «Нужна ли философия и этика для жизни и творчества?» : https://habr.com/ru/articles/939970/ .
в соответствии с диаматом - двигаться от неподного и неточного знания ко всё более полному и точному.
Каким образом? Вы сказали общие слова, без конкретных примеров. Я возразил на конкретном примере. И, вы считаете, что этого достаточно для получения общей ментальной модели? Как минимум, должно быть сотворчество для этого, которого у нас, с вами нет.
Кстати, вы считаете, что современная версия диамата преподается в российских ВУЗах лучше, чем в советских? А, какие аргументы?
Но в СССР (и, тем более - после) всему этому учили плохо, так что не ваша вина, что вы это не знаете.
Не рассказывайте сказки! В СССР учили хорошо, и в школе и в ВУЗах. Вы, например, в обычной школе, учили стереометрию?
А, кроме диамата, что вы ещё учили из общественных наук? Неужели, истмат и политэкономию? В советских ВУЗах были еще «Научный Коммунизм» и «История КПСС». Вы их «проходили»? Ладно, история правящей, в то время, партии, вам может показаться заидеологизированной, но, фактов там, интересных, давали немало. Тоже самое вы можете сказать и про НК. У меня к нему двойственное отношение, но предмет, я считаю, полезным. Более того, я читал раннего Маркса и меня его тексты очень впечатлили, просто, живой гений.
Наш академик Рыбников, который преподавал, в мое время, комбинаторный анализ, опубликовал «Математические рукописи Маркса», на базе архивов Маркса, в Лондоне. Я читал эту книгу. Но, честно скажу, меня она впечатлила меньше, чем диамат (хотя в «Капитале» его арифметическая модель – «конфетка»). Ну, не математик Маркс. Например, он на десятке страниц описывал процесс взятия производной от икс в квадрате. Радовался как ребенок, от новой игрушки, мол, ура, в математике тоже, оказывается, реализована концепция движения – главный принцип диамата! Наверное, все-таки, не стоило публиковать этот труд. Это были всего лишь, по сути, конспекты записей, при изучении математики, в Лондонской библиотеке.
Ну, а ещё можно просто попробовать друг с другом поговорить и договориться. На практике часто помогает.
Ну, я высказал аналогичную мысль, чуть выше – сотворчество. Все остальное это просто общение.
А вы точно уверены, что этот процесс сходится? Точно-точно?
«А вы точно уверены», что этот термин здесь уместен? «Точно-точно?»
И именно к желаемому вами результату?
Ну, да, я так и думал, ментальные модели, о процессе программирования, у нас разные.
Я вот не уверен, что точно сходится, ибо гарантий тут никаких. А вот для разбухания кода, и превращения его в "Большой комок грязи" такой процесс подходит IMHO идеально.
За «разбухание кода» мне деньги не платили. Платили за результат. Какой ценой, никого не волновало. При таком подходе я нередко бывал в минусах, но, чаще, в плюсах.
И, кстати, забегая вперед: кровавый энтерпрайз большие комки грязи не любит, ему от них больно, хотя они в нем получаются регулярно.
Вы бы лучше подробней рассказали бы о своем «кровавом энтерпрайзе». Чувствуется, что у вас был болезненный опыт с ним. У меня другой опыт, потому мы и говорим на разных языках, и, диамат тут ни причем.
А, как я теперь понял, причины ваших затруднений в другом: и вас не учили (и вы сами не обучались) инженерной дисциплине под условным названием разработка больших программ: понятию об архитектуре, декомпозиции на модули, сложности кода, связей между модулями и влияния их на сложность и т.д.
Здесь вы правы! Но, это естественно. В МГУ, когда я учился, были только мейнфреймы с терминалами. Использовать можно было только фортран, для научного программирования. Персоналки (286-ые) появились только на моём пятом курсе, когда я проходил преддипломную практику в «Керосинке» (Институте АН СССР). Там я, на них, моделировал «оптимальное извлечение нефти из безнапорных скважин». Работа моя понравилась, и я выступал по ней на семинаре Академии Наук. После чего мне предложили поступать туда в аспирантуру. Однако, это был уже последний год СССР, дыхание его смерти уже витало в воздухе, обязательное распределение уже отменили, госэкзамены по научному коммунизму – тоже. Нужно было ехать домой.
Помню, тогда у меня брала интервью корреспондент французского радио RFI. Спрашивала про Маршала Ахромеева, который, на следующий год, во время августовского путча 1991 года – покончил с собой. Также, общался, на расстоянии вытянутой руки, с Ельциным и его женой Наиной. Но, это так, к слову.
Тем не менее, одно время, моим научным руководителем был доцент кафедры системного программирования, кстати, он был научруком и для Ильфака Гильфанова (который, правда, учился на другом курсе), автора «широко известного в узких кругах», «народного дизассемблера» IdaPro. Я даже посвятил ему несколько своих статей, на своем сайте ( https://erfaren.narod.ru/ ).
Это не удивительно: в советских политехах вообще мало чему учили, тем более - такому новому делу как software engineering, а Мехмат МГУ - это вообще не про инженерное образование.
Да, как программист, я по сути, самоучка, что помогло мне выжить в «лихие 90-ьые» и кормиться всю оставшуюся жизнь.
Догадываюсь, что вы в своих рассуждениях имеете в виду командное программирование, тогда как я, всё время, программировал один. Но, кто будет проговаривать вслух такие «очевидные» вещи?
А без знания этой дисциплины по настоящему большие и сложные программы действительно не сделать.
Как минимум, должен быть заказчик. Меня пригласили на хорошую фирму купить или разработать (денег не жалели) любую учетную систему, потому, что «солидной фирме, несолидно обращаться в районный вычислительный центр, для обработки бумажной отчетности». Напомню, это было время, когда компьютеризация только-только начиналась, электронную отчетность уже требовали, но программ для нее никаких еще, толком, не было. Все всё делали вручную, в Экселе. Для большой фирмы это было очень трудоемко и, даже, не всегда возможно.
Я купил тогда (на деньги фирмы) все учетные программы, которые, в то время, были. Но, ни одна из них не взлетела. Но, кого это волновало? «Взялся за гуж, не говори, что не дюж!». Поэтому, пришлось срочно ваять собственный вариант учета. Благо, какие-то наработки у меня уже были с прошлой работы. Плюс, несколько месяцев пахал по двенадцать часов в день, без перерыва. Программу, через полгода, я запустил, потом еще пару лет мощно шлифовал, потом еще несколько лет вылизывал, но у же в облегченном режиме. За время ее работы она пережила смену трех государств: Украины, ЛНР и, теперь, России. Потом пришел новый собственник из «старой» России, под него тоже много чего пришлось переделывать. Затем фирму искусственно обанкротили, как и мою предыдущую, по политическим мотивам. Поэтому, сейчас я на вольных хлебах.
Но дело не в этом. А в том, что обсуждаемая статья - она тоже про эту самую дисциплину, про сложные программы: как их читать - и чисто для себя, и чтобы модифицировать. А поскольку (предполагаю) эта дисциплина столь же не входит число ваших понятий, как и, например, законы языка ирокезского, то и ваши суждения по этому вопросу имеют сомнительную ценность: следуя им, легче легкого что-нибудь напортачить в большой и сложной программе.
Может это и так, но, скажу откровенно, статья слабая. Нечего из нее взять, мне, по крайней мере, для своей программистской практики. Пока, до сих пор, меня всегда выручал, только, «Метод здравого смысла».
Не зря же великий русский мыслитель Козьма Прутков предупреждал "Рассуждай токмо о том, о чем понятия твои тебе сие дозволяют."
«Бла-бла-бла», как говорила Грета Тубмерг, не заменят ни учебу, ни практику. Какую бы вы ей цену не назначали.
Ну, чем бы эта статья помогла мне при создании собственной учетной системы, для производственного предприятия, с кучей специфических нюансов? Думаю, что ничем. Ни тогда, ни сейчас. Например, новая бухгалтерша, которая пришла, в свое время, в нашу фирму, говорила, что, скажем, учет заработной платы и рабочего времени, на ее прошлом предприятии делали три программиста два года. Я же всю подобную работу делал сам. И как она не хотела заменить мою программу типовой (со временем их появилось не мало), ничего у нее не получилось, хотя я совершенно не саботировал ее усилия, более того, искренне помогал. Предлагал ей даже внедрить современный «восьмерочный» ЗУП, сначала в тестовом виде, потом, с постепенным переходом на него. Заинтересовалась, но слабо, пахать приходилось мне одному, в конце концов, он поняла, что ЗУП, все же более жесткая система, чем моя и чтобы его внедрить, надо много чего менять в «бизнес-процессах» предприятия и просто что-то делать. На «блюдечке с голубой каёмочкой», подать не получится. Потом пришли новые собственники и сменили все руководство, чтобы, через некоторое время и саму фирму ликвидировать. Такова селява…
SensDj
19.09.2025 14:00Думаю, тот же ИИ может (или сможет) изобразить блок-схему всего проекта - крупными мазками, потом детальнее, потом каждый блок ещё детальнее
kyzyldur
19.09.2025 14:00Только надо будет еще проверить, действительно ли эта схема соответствует реальности или ИИ напридумывал себе всякое )))
mvv-rus
19.09.2025 14:00Думаю, тот же ИИ может (или сможет) изобразить блок-схему всего проекта
Популярная нынче LLM - нет, разве что ее обучили на большом массиве кодов и блок-схем разнообразных проектов: LLM не создает, используя абстракции более высокого уровня, целостную схему: он просто выбирает, с учетом контекста, слова (картинки и т.д.) которые часто стоят в этом месте.
Ну, а про "ИИ вообще" можно только сказать, что помечтать не вредно.
zolandv
19.09.2025 14:00А мне подход к ментальной модели понравился, вполне точно изложена работа профессионала, который прежде чем хвататься за исправление явных ошибок на скорую руку тратит определённое время на понимание общей структуры и логики продукта прежде чем приступить к каким-либо правкам.
Dhwtj
Чтобы облегчить построение ментальной карты придерживайтесь при написании contract driven development + functional programming.
ФП гарантирует что контракт реализован так, как описан в сигнатурах
Что делать при чтении не такого кода? Ругаться, наверное
mvv-rus
Оставлю для начала в стороне прочие ваши утверждения (на мой взгляд, весьма сомнительные) и сосредоточусь на главном несоответствии: речь в статье идет не о написании кода, а о его чтении. Не о том, как разбить задачу на части, из которых потом собрать решенние, а о том, чтобы на основе частей решения понять целое - само решение. Наглядная аналогия того, о чем статья: как написать на основе скомпилированного машинного кода исходны код программы. Хоть эта аналогия упрощенная, но основную сложность - собрать целое из разрозненных и непонятно как взаимодействующих частей - она показывает.
Ну и, ваш рецепт, как сделать решение, которое потом можно легко собрать в концептуальную модель - он, по всей видимости, годится для очень немногих людей вроде вас. Взять то же ФП: оно - не для людей (кроме, может быть, прирожденных математиков), поскольку предполагает мышление понятиями абстрактной алгебры, которые большинству людей чужды.
Dhwtj
Тем от джунов и отличаюсь.
Мой код значительно легче читать. Могу создать костяк приложения, простые части которого допишут другие. И всё равно будет легко читать
mvv-rus
Забыли кое-что что добавить после слова "читать", а именно - "мне и людям, которые мыслят так же, как я" (и есть подозрение, что таких немного, ибо ФП сейчас - далеко не мейнстрим). А это существенно, потому что трудность чтения - показатель субъективный. Так что, хотя спорить по существу не хочу, на излишнюю вашу категоричность я указал.