Дальше разбираться в этой абсурдной ситуации я не стал. Что было с мальчиком, с соседом и полицией — не знаю. Но я запаролил точку доступа, ибо «программистов» и неадекватных людей в этой стране больше, чем тех, с кем я был готов поделиться своим интернетом.
#10768: Сначала думаю, потом пишу
12:15 29.03.2013, IT happens
Написал код, который работает на атомной станции, и теперь страшно? Можно узнать почему? С чего вы взяли, что программа обязательно должна глючить? Я программист, и я не понимаю.
Есть алгоритм программы — он должен быть составлен так, чтобы не допускать незапланированных ветвлений. Для этого всего лишь надо продумать его логику до того, как набивать код.
Есть входные данные — они могут поступать из разных источников, значит, надо продумать защиту от того, чтобы эти данные могли привести к сбоям.
Есть опечатки в коде — для этого в нормальных языках программирования предусмотрены специальные инструменты. И никакая «неопределённая переменная» вам не будет страшна. Кстати, не забывайте инициализировать переменные — это ведь нетрудно!
Есть ошибки, когда кто-то перепутал местами переменные или использовал не ту функцию, но для этого у вас должен быть продуман сценарий тестирования модуля. Сделали — собрали — протестировали. Ведёт себя не так, как должен? Устраните проблему! И делайте это на уровне отдельных модулей, ещё до того, как готовая система уйдёт в отдел тестирования.
Не надо городить сложноинтегрированные системы. Разбивайте их на отдельные функциональные блоки! Каждый блок должен работать идеально. Надо будет — лучше потом написать ещё один интерфейсный блок для сопряжения.
Не используйте говнобиблиотеки, «потому что модно». Если решили использовать какую-то стороннюю библиотеку, постарайтесь разобраться в вопросе, не забывайте предусмотреть проверку данных и продумать защиту от нарушения логики на стороне библиотеки.
Остаются, конечно, сбои аппаратуры типа посыпавшихся дисков, глюков микросхем памяти и помех в линиях связи. Но этим вопросом должны заниматься те, кто разрабатывает аппаратуру: существуют методы защиты от искажения данных, помехоустойчивое кодирование с избыточностью, аппаратное дублирование и так далее. Если коротко — просто не надо гнаться за самым дешёвым оборудованием.
Ну вот, чувствую, как на голове материализуется фуражка Капитана Очевидность. Вам ведь наверняка всё это уже говорили, писали в книгах по программированию. Так откуда же берутся горе-программисты, которые привыкли быстренько, тяп-ляп, практически не думая, набросать код, который вроде примерно как надо работает, но в определённую фазу Луны при снижении котировок куриных окорочков на Нью-Йоркской бирже во время снегопада в Норвегии начинает вести себя совершенно непредсказуемо?
Может быть, причина в модных тенденциях программирования, когда код пишется по наитию, в режиме ошпаренной кошки, или тремя программистами за одним монитором, или на основе монстроидальных фреймворков без понимания их устройства, или с бездумным использованием чужих наработок по принципу «нагуглил и скачал»?
Не знаю. Я работаю по старинке: сначала думаю, потом пишу. Что характерно, на глюки потом никто не жалуется. Может быть, потому, что я уверен в своём коде.
#10769: //это код
12:45 29.03.2013, IT happens
Довелось мне унаследовать работу одного, несомненно, талантливого программиста. Был у него всего один недостаток: не писал он комментариев. Во многих тысячах строка кода изредка лишь вкрапливалось что-то типа //new, //modified. Самый информативный комментарий, который мне попался: //product.
Коллеги-программисты! Не умеете описывать свои гениальные функции по стандартам — хотя бы не ленитесь писать информативные комментарии между строк, если не хотите, чтобы вас прокляли.
#10770: От нашего стола — нашему столу
12:15 30.03.2013, IT happens
Работаю IT-консультантом в крупной компании. Cегодня познал рекурсию: у пользователя на рабочем столе ярлык, ведущий на рабочий стол. Долго думал.
#10771: Помни о подводном истребителе
12:15 30.03.2013, IT happens
Говорят, парашютные инструкторы больше всего не любят учеников, которые не боятся.
Вы знаете и используете юнит-тесты, интеграционные тесты, выстраиваете красивые архитектуры, пишете идеальный код? Отлично! Но почему вы уверены, что в нём нет ошибок? Почему вы не боитесь? Ни один из имеющихся у человечества инструментов, включая формальную верификацию программ, не позволяет доказать её корректность.