Есть какая то чёткая методика - как взять код, и узнать время его исправления? На мой взгляд - такой методики нет. Есть только два пути - гадание и разбор кода. Анекдот помните - за постучать 5 копеек, а за то, что знать, где постучать - 5 рублей. Вот разбор кода, это, по сути, и есть выяснения места, где именно надо постучать.
Хорошая статья. Коротко, без разглагольствований и лишних отступлений. И, реальный, а не высосанный из пальца пример. По больше бы таких статей. Плюсанул.
Проект в целом может быть новым для вас, но при этом состоять из частей, понятных для оценки.
Очень расплывчато. Что значит "понятных для оценки". Если речь про транспортную логистику, то всегда можно открыть карту с дорогой и вычислить путь с точностью до километра, можно посмотреть статистику по пробкам. А если разрабатывать программу - то карты нет! Что бы открыть код и сказать "ваша хотелка будет реализована через такое то время" понадобиться ... время. И, как показывает практика, "время на оценку времени" сопоставимо с "временем реализации" хотелки.
Иногда слышу "но, ты ведь делал что то подобное? давай будем считать, что время будет такое же". Но, если добавили какую то фичу для одного места программы (например, для документа определённого типа), абсолютно не факт, что это время будет как то сопоставимо с добавлением такой же фичи для других места программы. В других местах программы реализация такой же (с точки зрения пользователя) фичи может по сложности (и по времени) быть в разы больше или меньше.
Программисты - это тоже люди. А люди, они разные. Добрые и злые, мягкие и жестокие, целеустремлённые и пофигисты. Не обязательно хороший программист - это хороший человек.
да, хотелось бы фотку литографа поближе. и, если уж сделано такое "прорывное" устройство - кто его сделал? где фото улыбающегося народа, который это чудо сделал? помню, по ящику показывают завод, и диктор читает победную реляцию "обновили станки", а лейбочки на станках - замылены.
На 3dnews под аналогичной новостью комментарии удалили (оставили только два) и повесили "Комментарии к этой теме были закрыты". Грустно... Технологическое отставание на 2024-1997 лет. Опять таки, хотелось бы какие то технические подробности типа - длинна лазера, какова производительность, какой размер подложки?
Работал в банке. База АБС была на оракле. База очень красивая - была нормализована по теории. Т.е. ни чего не дублировалось, куча таблиц. Запросы генерировались в программе. Но, была проблема - производительность. Конечно, это периодически как то лечили добавляя индексы и пересобирая статистику. Однако, процесс это не быстрый и требующий админа. А поскольку отчёты требовались "здесь и сейчас", приходилось брать сгненерированные запросы и добавлять хинты. Иногда скрипт, быстро работавший вчера, сегодня уже тупил. И, приходилось опять подкручивать его хинтами. Потом АБС поменяли. В базе новой АБС были "широкие" таблицы. Т.е. всё, что можно - добавляли в одну таблицу с кучей полей. Казалось, что архитектор базы забил на нормализацию. Но... внезапно, всё работало очень быстро. Как то попал на собеседование. Пришёл, а там предлагают написать хинты, которые знаю, объяснить - зачем нужны конкретные хинты и т.д. Понял, что за несколько лет как страшный сон уже забыл, что такое хинты! И, кроме того, понял - что если здесь нужны такие знания, то ты будешь не код писать, а постоянно воевать с производительностью системы. Сделал вывод - такая работа не нужна...
Сначала на собеседовании спрашивают, что такое SOLID. А потом, как откроешь реальный код приложения и интересуешься у тимлида "и, где тут SOLID?", он глупо так улыбается "ну, не везде, конечно. но - надо же стремиться...".
Недавно искал новую работу. Звонит девочко HR и зачитывает вопросы. После вопроса "чем put отличается от post" последовал вопрос "что такое SOLID". Ответил "если вы покажете ваши реальные коды, тут же покажу - где у вас SOLID отсутствует"...
Купил "EF в действии" в "правильном переводе". Есть испорченные рисунки (например, рис 2.7, рис.3.3, рис.5.2) - пришлось скачать PDF с английской версией, что бы найти картинку и понять - что же на ней. Есть просто опечатки (например, вместо пункта 2.4.2 указано 2.1.2, в п.2.3.1 надо исправить с "на рис. 2.7" на "на рис.2.8"). Но, самое плохое - очень много воды, когда можно выкинуть кучу слов, при этом смысл не потеряется. Например, сократить "можно приступить к написанию кода" до "напишем код". И так - постоянно. Интересно, в этой книге так же?
Да, спустя какое то время флешки отрубили. Пришли безопасники, покопались в биосе, и опечатали системник... Но, это не самый хульший вариант. В другом банке, где работала моя жена, безопасники суперклеем заливали USB. Я даже сначала не поверил в такую дурость, но жена прислала фотку.
// Сцепляем имена с использованием функционального подхода string functionalConcatenatedNames = string.Join(" ", names);
Есть метод, реализованный программистами MS. В программе вызван этот метода. Не понимаю: в чём тут скрыт "функциональный подход"? Пожалуйста, поясните.
В описании метода public Task<Result> ExecuteOperation(int id, OperationType type) указан OperationType, который enum. При вызове через API ExecuteOperation в него передаётся int. Вот и хочется заставить swager сделать, что бы с одной стороны метод продолжал принимать int, а с другой - что бы можно было выбрать значение из списка. И, что бы в этом списке отображалось пара "число - текстовое значение". А уже если совсем набраться наглости, "число - описание из summary".
и использовать его могут любые пользователи MS Office без технических навыков: бухгалтеры, менеджеры, аналитики.
Угу... Могут в том смысле, что у них есть доступ к функционалу, но не могут в том смысле, что ума им не хватает, и не хотят потому, что каждый уже занят своим делом (например, бухгалтерам надо крыжить), потому брать не себя новые обязанности - не будут.
Интересно, сколько % от имеющегося функционала MS Oddis-а знает программист и рядовой пользователь?
С 15 года кубик-рубика имеет другое внутреннее устройство (не то, которое показано на фотографии в статье). Сейчас внутри кубика получается почти идеальный шар. В результат кубик движется плавнее.
В вашем приложении будет несколько описаний той работы, которую ему нежно выполнять (например, создать запись ToDo, изменить имя пользователя и т. д.).
Из всего вышесказанного так и не понял:
Есть какая то чёткая методика - как взять код, и узнать время его исправления? На мой взгляд - такой методики нет. Есть только два пути - гадание и разбор кода. Анекдот помните - за постучать 5 копеек, а за то, что знать, где постучать - 5 рублей. Вот разбор кода, это, по сути, и есть выяснения места, где именно надо постучать.
И да, метод "гадания" очень нравится руководству.
Хорошая статья. Коротко, без разглагольствований и лишних отступлений. И, реальный, а не высосанный из пальца пример. По больше бы таких статей. Плюсанул.
А как можно оценить время на разработку?
Очень расплывчато. Что значит "понятных для оценки". Если речь про транспортную логистику, то всегда можно открыть карту с дорогой и вычислить путь с точностью до километра, можно посмотреть статистику по пробкам. А если разрабатывать программу - то карты нет! Что бы открыть код и сказать "ваша хотелка будет реализована через такое то время" понадобиться ... время. И, как показывает практика, "время на оценку времени" сопоставимо с "временем реализации" хотелки.
Иногда слышу "но, ты ведь делал что то подобное? давай будем считать, что время будет такое же". Но, если добавили какую то фичу для одного места программы (например, для документа определённого типа), абсолютно не факт, что это время будет как то сопоставимо с добавлением такой же фичи для других места программы. В других местах программы реализация такой же (с точки зрения пользователя) фичи может по сложности (и по времени) быть в разы больше или меньше.
Программисты - это тоже люди. А люди, они разные. Добрые и злые, мягкие и жестокие, целеустремлённые и пофигисты. Не обязательно хороший программист - это хороший человек.
Безмасочная технология приказала долго жить. Получено научное обоснование, что технология нежизнеспособна.
да, хотелось бы фотку литографа поближе. и, если уж сделано такое "прорывное" устройство - кто его сделал? где фото улыбающегося народа, который это чудо сделал?
помню, по ящику показывают завод, и диктор читает победную реляцию "обновили станки", а лейбочки на станках - замылены.
На 3dnews под аналогичной новостью комментарии удалили (оставили только два) и повесили "Комментарии к этой теме были закрыты".
Грустно... Технологическое отставание на 2024-1997 лет. Опять таки, хотелось бы какие то технические подробности типа - длинна лазера, какова производительность, какой размер подложки?
Работал в банке. База АБС была на оракле. База очень красивая - была нормализована по теории. Т.е. ни чего не дублировалось, куча таблиц. Запросы генерировались в программе. Но, была проблема - производительность. Конечно, это периодически как то лечили добавляя индексы и пересобирая статистику. Однако, процесс это не быстрый и требующий админа. А поскольку отчёты требовались "здесь и сейчас", приходилось брать сгненерированные запросы и добавлять хинты. Иногда скрипт, быстро работавший вчера, сегодня уже тупил. И, приходилось опять подкручивать его хинтами. Потом АБС поменяли. В базе новой АБС были "широкие" таблицы. Т.е. всё, что можно - добавляли в одну таблицу с кучей полей. Казалось, что архитектор базы забил на нормализацию. Но... внезапно, всё работало очень быстро.
Как то попал на собеседование. Пришёл, а там предлагают написать хинты, которые знаю, объяснить - зачем нужны конкретные хинты и т.д. Понял, что за несколько лет как страшный сон уже забыл, что такое хинты! И, кроме того, понял - что если здесь нужны такие знания, то ты будешь не код писать, а постоянно воевать с производительностью системы. Сделал вывод - такая работа не нужна...
Сначала на собеседовании спрашивают, что такое SOLID. А потом, как откроешь реальный код приложения и интересуешься у тимлида "и, где тут SOLID?", он глупо так улыбается "ну, не везде, конечно. но - надо же стремиться...".
Недавно искал новую работу. Звонит девочко HR и зачитывает вопросы. После вопроса "чем put отличается от post" последовал вопрос "что такое SOLID". Ответил "если вы покажете ваши реальные коды, тут же покажу - где у вас SOLID отсутствует"...
Купил "EF в действии" в "правильном переводе". Есть испорченные рисунки (например, рис 2.7, рис.3.3, рис.5.2) - пришлось скачать PDF с английской версией, что бы найти картинку и понять - что же на ней. Есть просто опечатки (например, вместо пункта 2.4.2 указано 2.1.2, в п.2.3.1 надо исправить с "на рис. 2.7" на "на рис.2.8"). Но, самое плохое - очень много воды, когда можно выкинуть кучу слов, при этом смысл не потеряется. Например, сократить "можно приступить к написанию кода" до "напишем код". И так - постоянно. Интересно, в этой книге так же?
Да, спустя какое то время флешки отрубили. Пришли безопасники, покопались в биосе, и опечатали системник... Но, это не самый хульший вариант. В другом банке, где работала моя жена, безопасники суперклеем заливали USB. Я даже сначала не поверил в такую дурость, но жена прислала фотку.
// Сцепляем имена с использованием функционального подходаstring functionalConcatenatedNames = string.Join(" ", names);
Есть метод, реализованный программистами MS. В программе вызван этот метода. Не понимаю: в чём тут скрыт "функциональный подход"? Пожалуйста, поясните.
В описании метода public Task<Result> ExecuteOperation(int id, OperationType type)
указан OperationType, который enum. При вызове через API ExecuteOperation в него передаётся int. Вот и хочется заставить swager сделать, что бы с одной стороны метод продолжал принимать int, а с другой - что бы можно было выбрать значение из списка. И, что бы в этом списке отображалось пара "число - текстовое значение". А уже если совсем набраться наглости, "число - описание из summary".
Но, ведь нужен int!
До времени, пока Маск не показал, что можно делать дешевле.
не, это 40 ватт. А речь про 100:
Помню, в 93-м пытался решить подобную задачу. Увы, тогда это мне не удалось.
Угу... Могут в том смысле, что у них есть доступ к функционалу, но не могут в том смысле, что ума им не хватает, и не хотят потому, что каждый уже занят своим делом (например, бухгалтерам надо крыжить), потому брать не себя новые обязанности - не будут.
Интересно, сколько % от имеющегося функционала MS Oddis-а знает программист и рядовой пользователь?
Опечатка?