Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (1)

Наибольший вклад в теги

Все теги (18)

Лучшие ответы пользователя

Все ответы (10)
  • Лучший способ обучения?

    @ruGuardian
    Теорию и практику следует правильно дозировать в правильное время. Всегда делал так:
    1) Начинаешь изучение новой технологии, больше читаешь, чем пишешь, но обязательно пробуешь задачи, примеры, экспериментируешь до тех пор пока суть не вобъется в голову. Именно поэтому, если я должен выучить новый язык, книгу без задач я не возьму. Здесь цель - понять, как это работает и в каких случаях применяется.
    2) Применяешь на практике новые знания, иначе не закрепится. Придумываешь себе задачу на пару вечеров (займет неделю). Больше пишешь, чем читаешь, все проблемы решаешь справкой или погуглив. Здесь цель - выполнить задачу. Не растекаясь на выяснение деталей. Если затык, goto п.1.
    3) По окончанию собираешь все мутные темы, с которыми столкнулся, все вопросы, которые решил просто погуглив не разобравшись по сути и goto с ними в п.1.
    Это решит твою проблему, когда пишешь в конспект, а не в голову.
    Ответ написан
    Комментировать
  • Сумасшедшие тормоза после выхода из "Сна" или "Гибернации" на Windows 10 v.1709 (OS Build: 16299.64)?

    @ruGuardian
    Надо отключить Control Flow Guard: зайти в Защитник Windows > Управление приложениями и браузером > Параметры защиты от эксплойтов и выключить CFG, потом ребут.
    Ответ написан
    5 комментариев
  • Пишут ли сейчас на чистом Си?

    @ruGuardian
    Огромное количество кода пишется на Си в области встроенного ПО систем реального времени для авиации, космоса и в целом для армии и транспорта. Это целый мир, который в интернете почти не заметен, если специально не интересоваться. В целом, Си необходим, если:
    1) вам интересно низкоуровневое программирование - здесь на Си будут писать, когда вы на пенсию выйдете. Любая новая железка, новый проц - это сперва работа на низком уровне, и только потом - API, использование прикладниками и проч.. А новые железки будут всегда.
    2) вам интересны ОС и *nix в частности - аналогично. Никто ядро Линукса на Rust переписывать не будет.
    3) вам интересно ПО систем реального времени - будет актуально ещё лет 25 минимум. Реалтаймщики даже С++ в полном объеме не используют - любой конструктор с выделением памяти может разрушить детерминизм по времени исполнения. Для ПО от реакции которого в строго заданное время зависит жизнь людей - это непозволительно.
    Вот те области для Си программиста, весьма почетные и профит соответствующий (и в деньгах, и в инженерном профессионализме).
    Ответ написан
    Комментировать
  • Как точно подсчитать время создания программного продукта?

    @ruGuardian
    В теории теория и практика совпадают. А на практике...
    Можно очень долго пытаться строить из себя тайм менеджера крупного звена, играться с формулами, учитывать коэффициэнты форс-мажоров и никогда не стать вангой. Но сама жизнь подсказывает вам решение. Я с удовольствием использую этот метод и не подводило никогда. Следует набросать план и умножить срок на Пи. И признаться себе в том, что несмотря на твою гениальность и работоспособность - так оно и будет. Это психология нас подводит. Даже самый детальный план с десятками подзадач не включает такие пункты как: обед, сон, я заболел, я напился, кошка окотилась, теща приехала и т.д.. Оценивая задачу вы исходите из 100% занятости и максимальной фокусировке. Умножайте время на Пи это гарантированный прогноз (к финансовым тратам это относится аналогично).
    Ответ написан
    Комментировать
  • На основании чего составляются тестовые сценарии?

    @ruGuardian
    Ответ на подобный вопрос зависит от ответственности ПО. Вообще сценарии составляются на основе требований. Не абстрактных лозунгов, которые обычно пишутся в ТЗ, а требований с однозначными техническими характеристиками. Если проект ответственный, требующий сертификации (ПО для транспорта, например), это вопрос регулируется соответствующими стандартами, по которым производится сертификация. В частности для гражданской авиации, есть документ DO-178 (российский перевод - КТ-178 и менее требовательный аналог ГОСТ-51904), определяющий например, что на основе требований к системе, разрабатываются требования верхнего уровня к ПО (параллельно - к железу), на основе которых создаётся дизайн и требования нижнего уровня, на основе которых уже код, а тестировщики пишут тесты верхнего уровня по требованиям верхнего уровня (проверка функционала всего приложения) и тесты нижнего уровня по требованиям нижнего уровня (юнит тесты). Получается реализация и независимая верификация по общим исходным данным для программиста и тестировщика. Причём здесь не нужно полагаться на опыт и изощрённость тестировщика, он просто достигает цели по явным критериям, это прозрачно и управляемо. Но это очень дорого и долго.
    В вашем случае, конечно, процессы разработки будут гораздо проще, но здесь вы должны понимать, что усиление процесса верификации неизбежно потребует затрат. Чудес не бывает, как и тестировщиков которые без документации покрывают как боги. Здесь явно требуется бОльшая формализация, а значит хотя бы ещё один уровень детализации после ТЗ. Насколько детализировать - зависит от того, сколько вы готовы на это потратить. Процент выгребания багов будет соответствующий.
    Ответ написан
    1 комментарий

Лучшие вопросы пользователя

Все вопросы (3)