Знаете, мне кажется, что в норме, нужно обобщать накаливаемый опыт. И образование должно в спрессованном виде этот опыт предоставлять. Но для этого нужна определённая (и, при том, весьма значительная) доля публичности в деятельности компаний. Но никто не готов публиковать свою историю. Так и живём.
Цитата на ночь:
В наше время происходит тоже самое. Отставание от графика, несоответствие функциональности, системные ошибки — все это из-за того, что левая рука не знает, что творит правая. По ходу работы участвующие в ней несколько бригад понемногу изменяют функции, размер, быстродействие своих программ, явно или косвенно меняют допущения относительно входных данных и использования выходных.
Например, исполнитель функции, осуществляющей оверлейную загрузку программ, может столкнуться с проблемами и снизить быстродействие, основываясь на статистических данных, указывающих на редкость использования этой функции в прикладных программах. В то же время его сосед может разрабатывать важную часть супервизора таким образом, что она крайне зависит от скорости выполнения этой функции. Это изменение скорости выполнения, в сущности, становится значительным изменением спецификаций, о нем нужно широко объявить и оценить с точки зрения системы.
Фредерик Брукс. "Мифический человеко--месяц или как создаются программные системы"
Если разработчики занимаются чем-то, в результате что-то получается, и это кем-то потребляется, то однозначно понимают...
Мы каждый день пользуемся не очень хорошим программным обеспечением. Да, оно как-то работает. Но оно не очень хорошее. У него много проблем. Начиная с удобства и заканчивая безопасностью. Что-то разработчики понимают. Но совсем не то, что хотелось бы. А другого программного обеспечения у нас нет. Можно, что-то написать для себя. Но на это нужно время.
Мой вопрос касается реальности. Можно подумать, что в реальности разработчики производят много неудачного кода. Какое значение, кто и за что отвечает, если, всё-равно, всё время приходится исправлять постоянно возникающие ошибки?
А мы-то думаем, зачем софтверным гигантам такие мощные дата-центры? Может быть, там тщательно затабулированы таблицы Брадиса и статистические таблицы Большева (Большев Л.Н., Смирнов Н.В, "Таблицы математической статистики")? Тогда понятно, зачем программа будет ходить в интенет. ;-)
Размер программы – это объективное техническое требование, из которого растёт всё остальное.
Вот это я никак не могу понять. Размер программы определяется исключительно реализацией. Какие библиотеки, какие алгоритмы.
Пора уж опомниться, зачем рисовать 20 кнопок и жамкать на них мышкой?!
Вообще-то, ещё бывают и обыкновенные настольные компьютеры, а у ноутбуков может не быть отдельной цифровой клавиатуры. Иногда можно и "жамкнуть". Всё-равно, в ОС должен быть калькулятор. Вот и вопрос в том, как его делать.
А мне не понятно, почему, вообще, здесь возникает вопрос о размере программы? 50 Мб — это что, исполняемый файл? Можно в Кб засунуть. Диапазон чисел определяется задачей. А про задачи у Вас ничего не сказано.
Калькулятор должен производить вычисления с числами от 10^-99 до 10^99.
Не думаю, что выбор некоторого фиксированного предела на все случаи жизни полезен. Всё-таки, калькулятор используется в конкретных обстоятельствах. Иногда нужно включать и "научный режим". (Конечно, если у пользователя есть GPU, то можно будет просто здорово извернуться.)))
Калькулятор должен производить вычисления с точностью не хуже 8 знаков после запятой.
Следует напомнить, что у каждого вида вычислений своя точность. Чтобы обеспечить определённую точность результата, нужно требовать соответствующую точность у операндов. Не всегда точность можно гарантировать. Не всегда высокая точность имеет смысл.
Можно затребовать оба интерфейса сразу, по крайней мере такой вариант мы видим в типичном десктопном калькуляторе. Стоп, а почему мы решили, что у нас десктоп, а не мобилка? Неужели для простейшей программы надо учитывать контекст применения? Получается, да. Или нет?
Если мы создаём приложение, то нас, конечно, будут волновать эти вопросы. Но, если мы создаём компонент Калькулятор, то мы должны описать некий протокол, в соответствии с которым на вход будут поступать одни команды (Вы же должны понимать, что сами числа — это один тип команд, а, собственно, команды для операций — это другие команды), а на выходе формируются другие.
(Здесь, о сути, происходит разделение на front-end и back-end.)
А уже другие разработчики, руководствуясь Вашим протоколом будут отдельно делать конечное приложение для каждой платформы.
Фактически у нас получился типичный минимальный прото-юскейс из 4-х шагов:
Программа предоставляет возможности ввода исходных данных и выдачи команды
Пользователь вводит исходные данные и даёт команду
Программа выполняет запрошенную команду над данными
Программа сообщает пользователю результат выполнения команды
Любопытно, что, при таком неожиданном обобщении, мы получили описание, под которое подпадает практически любое приложение.
Например, я захожу и интернет-магазин, выбираю нужные мне товары и нажимаю кнопочку "Заказать", а программа на выходе сообщила мне (на выбор из трёх вариантов):
Заказ оформлен и оплачен.
Заказ не может быть оформлен, потому что кончились такие-то товары.
Заказ не был оплачен, потому что на Вашей карте не имеется достаточно средств.
Рассмотрим, как может выглядеть работа по созданию ТЗ на несложную программу.
О_о! Очень хорошее начинание! Чрезвычайно интересно посмотреть, можно ли раскрутить эту тему до конца. Будет ли этот конец достигнут. За какие сроки. И т. д. И т. п.
Калькулятор должен демонстрировать числа, с которыми происходят вычисления, в графическом пользовательском интерфейсе.
А почему не рассматривается такая возможность, как реализация некоторого внутреннего для ОС компонента и организации соответствующего пользовательского интерфейса?
Калькулятор должен уметь считать. Это суть главное. У него на входе — строка (содержащая набор операций над числами) и на выходе — строка (содержащая результат выполнения операций). То есть, калькулятор — это компонент, который производит преобразование одних строк в другие. (Понятно дело, что мы говорим пока только об обыкновенных численных калькуляторах. В принципе, много чего можно интерпретировать, как калькулятор.) И это должен быть некий компонент без какой-либо привязки к пользовательскому интерфейсу. Другое дело, что пользователю этот самый пользовательский интерфейс очень нужен. Это всё надо понимать и отдавать себе отчёт в том, что, смешение двух различных сущностей в рамках одного приложения породит постоянно действующие проблемы в реализации.
Таким образом, первейший вопрос создания калькулятора — это вопрос о том, что именно делается: приложение или компонент. Понятное дело, что создаётся и то, и другое. Но ТЗ на приложение и ТЗ на компонент будут, очевидно, различаться.
Когда у вас появляется новый джун, динамика команды сразу меняется. Возникает атмосфера, в которой задавать вопросы — это нормально и даже необходимо, а обучение — это постоянный процесс. Мы больше говорим о динамике команды в моменте.
Время, которое вы тратите, чтобы подтянуть джуна, иногда окупается неожиданно быстро. Время летит ☺️ Когда мы нанимаем сотрудников, мы часто переоцениваем сеньоров так же сильно, как и недооцениваем джунов. От стереотипов пользы мало.
Если бы так было везде... Тогда можно было бы легко устроиться на работу, а на работе никто не дремал бы и не почивал бы на лаврах.
Потому что взять в команду человека, который пишет код — совершенно не то же самое, что создавать код автоматически. Такой код можно получить откуда угодно: из Stack Overflow, Copilot, мало ли откуда ещё. Да и это даже неважно. В таком случае у вас нет циклов обратной связи, на другом конце провода нет человека, который постепенно учится и работает над собой, нет влияния на вайб и культуру вашей команды.
А вот это уже вопиющая наивность автора! Именно над этим и работают. Только опасность здесь будет заключаться в том, что, однажды, эта пирамида перевернётся, и наверху окажется ИИ. Только в уже не будет возможности установить истину и проверить качество работы, потому как все критерии качества будут в руках у ИИ. (Я, конечно, сильно утрирую, но опасность такая есть. В это и заключается опасность, исходящая от разработчиков ИИ. Ктож их знает, что они на самом деле задумали? Всё — всего, лишь, видимость.)
Вы хотели сказать "продолжать"?
Знаете, мне кажется, что в норме, нужно обобщать накаливаемый опыт. И образование должно в спрессованном виде этот опыт предоставлять. Но для этого нужна определённая (и, при том, весьма значительная) доля публичности в деятельности компаний. Но никто не готов публиковать свою историю. Так и живём.
Цитата на ночь:
Мы каждый день пользуемся не очень хорошим программным обеспечением. Да, оно как-то работает. Но оно не очень хорошее. У него много проблем. Начиная с удобства и заканчивая безопасностью. Что-то разработчики понимают. Но совсем не то, что хотелось бы. А другого программного обеспечения у нас нет. Можно, что-то написать для себя. Но на это нужно время.
Пока больше. Всё ещё может сильно измениться.
Мой вопрос касается реальности. Можно подумать, что в реальности разработчики производят много неудачного кода. Какое значение, кто и за что отвечает, если, всё-равно, всё время приходится исправлять постоянно возникающие ошибки?
А немного подробнее про эти режимы рассказать можете?
Скорее всего, это не правильно.
Нетрудно сообразить, что такой родственнический протекционизм может не очень приветствоваться.
Можно было бы обойтись и без такой характеристики.
А мы-то думаем, зачем софтверным гигантам такие мощные дата-центры? Может быть, там тщательно затабулированы таблицы Брадиса и статистические таблицы Большева (Большев Л.Н., Смирнов Н.В, "Таблицы математической статистики")? Тогда понятно, зачем программа будет ходить в интенет. ;-)
Вот это я никак не могу понять. Размер программы определяется исключительно реализацией. Какие библиотеки, какие алгоритмы.
Вообще-то, ещё бывают и обыкновенные настольные компьютеры, а у ноутбуков может не быть отдельной цифровой клавиатуры. Иногда можно и "жамкнуть". Всё-равно, в ОС должен быть калькулятор. Вот и вопрос в том, как его делать.
Пишите обязательно. Я то же буду думать над ТЗ. Надо добить хотя бы один рабочий пример до конца. Если, конечно, это возможно.
А мне не понятно, почему, вообще, здесь возникает вопрос о размере программы? 50 Мб — это что, исполняемый файл? Можно в Кб засунуть. Диапазон чисел определяется задачей. А про задачи у Вас ничего не сказано.
Разные задачи — разные калькуляторы — разные ТЗ.
Как-то так. ;-)
Не думаю, что выбор некоторого фиксированного предела на все случаи жизни полезен. Всё-таки, калькулятор используется в конкретных обстоятельствах. Иногда нужно включать и "научный режим". (Конечно, если у пользователя есть GPU, то можно будет просто здорово извернуться.)))
Следует напомнить, что у каждого вида вычислений своя точность. Чтобы обеспечить определённую точность результата, нужно требовать соответствующую точность у операндов. Не всегда точность можно гарантировать. Не всегда высокая точность имеет смысл.
Если мы создаём приложение, то нас, конечно, будут волновать эти вопросы. Но, если мы создаём компонент Калькулятор, то мы должны описать некий протокол, в соответствии с которым на вход будут поступать одни команды (Вы же должны понимать, что сами числа — это один тип команд, а, собственно, команды для операций — это другие команды), а на выходе формируются другие.
(Здесь, о сути, происходит разделение на front-end и back-end.)
А уже другие разработчики, руководствуясь Вашим протоколом будут отдельно делать конечное приложение для каждой платформы.
Любопытно, что, при таком неожиданном обобщении, мы получили описание, под которое подпадает практически любое приложение.
Например, я захожу и интернет-магазин, выбираю нужные мне товары и нажимаю кнопочку "Заказать", а программа на выходе сообщила мне (на выбор из трёх вариантов):
Заказ оформлен и оплачен.
Заказ не может быть оформлен, потому что кончились такие-то товары.
Заказ не был оплачен, потому что на Вашей карте не имеется достаточно средств.
О_о! Очень хорошее начинание! Чрезвычайно интересно посмотреть, можно ли раскрутить эту тему до конца. Будет ли этот конец достигнут. За какие сроки. И т. д. И т. п.
А почему не рассматривается такая возможность, как реализация некоторого внутреннего для ОС компонента и организации соответствующего пользовательского интерфейса?
Калькулятор должен уметь считать. Это суть главное. У него на входе — строка (содержащая набор операций над числами) и на выходе — строка (содержащая результат выполнения операций). То есть, калькулятор — это компонент, который производит преобразование одних строк в другие. (Понятно дело, что мы говорим пока только об обыкновенных численных калькуляторах. В принципе, много чего можно интерпретировать, как калькулятор.) И это должен быть некий компонент без какой-либо привязки к пользовательскому интерфейсу. Другое дело, что пользователю этот самый пользовательский интерфейс очень нужен. Это всё надо понимать и отдавать себе отчёт в том, что, смешение двух различных сущностей в рамках одного приложения породит постоянно действующие проблемы в реализации.
Таким образом, первейший вопрос создания калькулятора — это вопрос о том, что именно делается: приложение или компонент. Понятное дело, что создаётся и то, и другое. Но ТЗ на приложение и ТЗ на компонент будут, очевидно, различаться.
Давайте, тогда, рассмотрим какие-нибудь конкретные задачи. Вот была одна задача, а возникла другая... Чтобы оценить сложность.
Если бы так было везде... Тогда можно было бы легко устроиться на работу, а на работе никто не дремал бы и не почивал бы на лаврах.
А вот это уже вопиющая наивность автора! Именно над этим и работают. Только опасность здесь будет заключаться в том, что, однажды, эта пирамида перевернётся, и наверху окажется ИИ. Только в уже не будет возможности установить истину и проверить качество работы, потому как все критерии качества будут в руках у ИИ. (Я, конечно, сильно утрирую, но опасность такая есть. В это и заключается опасность, исходящая от разработчиков ИИ. Ктож их знает, что они на самом деле задумали? Всё — всего, лишь, видимость.)