Обновить
9
0

Пользователь

Отправить сообщение
Все верно, «ПО без багов» — это на практике не интересно. Это не критерий.
Я не о том. Ключевое слово там было «обычно». У нас люди идут обследоваться, когда у них что-то заболит, а тестирование проводят, когда, возможно, еще ничего не известно о качестве этого софта. Вот в чем разница.
Про требования и анамнез — согласен. А вот про тестирование и диагностику — не совсем. Когда тестируют, то обычно полагают, что софт ничем не болен. Это не всегда так, конечно.
Минусующим неплохо было бы ознакомиться с биографией Тьюринга сначала.
Попробуйте погуглить на тему «Theoretical Computer Science» и поймете разницу.
Конечные автоматы имеют большое практическое значение, в отличие от МТ, практическое значение которой в основном сводится к возможности доказательства очередной теоремы из CS.
Возможно, это и к лучшему, что вы с ним не знакомы, учитывая известные о Тьюринге факты из личной биографии.
Большое спасибо автору за интересную статью!
Ну зачем вы так прибедняетесь (" не могу отнести себя к касте программистов"). Много людей бы позавидовали вашему опыту, уверен.

Мне меньше лет, чем Вам, я изучал много Computer Science в университете, и хорошо знаю, что на ИТ рынке компании отбирают программистов совершенно по-разному. Я сам бывал на собеседованиях, где кандидатов отсеивали по принципу «знает мало функций стандартной библиотеки Oracle», при этом они даже не проверяют, умеет ли они вообще писать и анализировать код, знает ли он механизмы работы со основными структурами данных и таблицами, итд Можно бы было зазубрить 40-50 функций и выглядеть супер-программистом. Поэтому, ваши истории — ничего удивительного в них нет. У тех, кто отбирает программистов та же самая проблема, которую вы обозначали — смещенный фокус. Они думают, что отбирают программистов, на самом деле рискуя тем, что код писаться будет тяжело. Они сами не понимают, что они делают.

PS. Про Computer Science в 90-ые: Я хорошо знаю, что существует некоторое количество университетов, где и в 90ых это было. Нельзя сказать, что нигде не было.
Совершенно верно. Максимальная сложность алгоритма сортировки не ограничена. Это с точки зрения той самой Computer Science.
Статья правильная. Команды, где приветствуются перечисленные в ней принципы (вроде того, что «упал модуль — твои проблемы») — лучше оттуда бежать.
Это так, но заминусовали то зря человека :)
Любая реклама западного товара должна была начинаться с показа панорам Кремля и шагающих офицеров с автоматами, чтобы они всегда помнили свое место :)
Это вы по нынешнему московскому нерусскому судите? :)
Статья понравилась. Велосипед годный. Вышеуказанный замечания по поводу безопасности, конечно, справедливы.

Сам бы так не стал реализовывать, если делал бы именно велосипед. Смотрите: у вас апдейтер (который перекопирует файлы) — это сама программа (тот же exe файл). Можно бы было сделать 2 отдельных приложения:

1) программа, которая умеет скачивать новую программу и запускать апдейтер
2) программа апдейтер, которая не изменяется никогда

Таким образом, ключей запуска бы не потребовалось вообще.
Если вдруг понадобиться изменить логику апдейтера из пункта 2), то можно в пункте 1 скачивать логику апдейтера в dll. еxе файл же меняться не будет.
Специально для минусующих: каждый сам решает. где ему работать. Вы можете работать там, где хотите :)
Вывод из статьи, ИМХО, один: в госорганизациях (чуть менее, чем всех) некрен делать и попадать туда на работу не надо. Пусть сами со своими высокообразованными ламерами спотыкаются о провода.

За два года работы в инспекции я поудалял «фотошопы, неры, винрары» и поставил «гимпы, сидибёрнеры, 7зипы»


Чтобы налоговая не попала на свои же налоги :)

Возможно, это смешно, но годовой бюджет отдела на все про все выделялся: в 2010 году 70 тыс. руб., в 2011 97 тыс. руб.


Да, это смешно.

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


И это смешно. Выгнать нафиг этих секретарш-ламеров.
Автору большой респект и удачи в нелегком деле общения с end-users.
Никакой clean code c помощью подобных книг писать не научиться. Clean code приходит с опытом работы в проектах, в постоянном сравнении и оптимизации того или иного кода, тех или иных практик. Поэтому, здесь я полностью согласен с автором статьи, что для программистов без опыта такие книги не предназначены.
А что может автор данной статьи рассказать о плюсах данной книги? Указанные недочеты — это не вся книга.
Какие «все алгоритмы» написали? Проблем, для которых нет эффективных алгоритмов предостаточно.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность