О программах и программистах

[Lion2032]

Я понял, почему так медленно исправляются программа.

Разрабы просто не хотят терять работу: https://habr.com/post/425351/

[MS$]

[Lion2032]

- У нас работал ужасный программист. Сначала вроде всё нормально было, а как уволился и наняли замену, так выяснилось, что он там всё так запутанно наделал, что одному не распутать, пришлось еще двух нанимать. Но до сих пор то одно не работает, то другое... Не повезло нам с тем программистом!

[Fogel]

Ну, так нормальные системы так и делают, что в один пятачок там сложно нагадить, только колегиально, не менее двух админов могут глобально гадить

а увольнять программиста надо или _очень_ внезапно или не увольнять вообще. Одного у нас так уволили... Через неделю приняли назад, но зарплату он попросил в пять раз больше чем до того была

[MS$]

[MS$]

[MS$]

[Fogel]

Ситуация: ребёнку послезавтра сдавать рисунок и она (ессно) бежит к папочке. То, что папочка давно уже расслабился бо сдал деточку замуж (оппа, а внуки оказывается равнозначны детям) и более не расчитывает на такие сюрпризы - оставим побоку. Где ребенок был за неделю до этого - темпаче. А сдавать надо лист А3 изрисованый гжелью. Разумеется, не на компьютере. Папа с матами выкатывает компрессор, ищет аэрограф, бо шесть коробок гуаши валявшейся годами на полке, были выкинуты этим летом - нафиг она кому нужна? Ватман (слава запасливости!) находится дома (дело часов в восемь вечера), потом с матами разыскивается шланг, не находится, все сабирается на изоленту и... такая мелочевка с таким соплом не выходит - рисунок слишком плотный.

День второй: посещена лавка и затарены и белая краска и синие чернила. На струйном плоттере сделана разметка заготовки тонкими линиями (однофигственно расплывутся). Отмывка, общий тон аэром, короче папа сам доволен как это выглядит к двенадцати ночи. И что он делает? Да как обычно - в углу листа размашистая подпись, расшифровка, дата.

Короче, спать я вчера лег сегодня

[MS$]

[MS$]

[MS$]

[Lion2032]

8 заповедей программиста

 

 

 

8 причин, почему программисты попадают в ад

 

 

У каждой профессии есть грехи, за которые можно попасть в геенну огненную; разработка — не исключение.

Качественный код — это то, к чему должен стремиться каждый уважающий себя программист. Но то ли мы ни к чему не стремимся, то ли игнорируем элементарные правила хорошего стиля, потому что код, за который нужно отправлять людей в ад, можно встретить очень часто.

1. Котел с соленой водой: без комментариев
   

Часто бывает так, что понять, что делает код, очень сложно, даже если ты писал его сам. Поэтому всегда оставляйте комментарии, чтобы вас не ненавидели другие разработчики. Вы и сами будете готовы бить себя плеткой-семихвосткой, когда понадобится что-то поправить.

Такой код можно сравнить с соленой водой — пить можно, но однажды замечаешь, что у тебя камни в почках.

1. Котел с пельменями: из огня да в полымя
   

Поздравляю, вы увеличили свои шансы попасть в рай. Но если в комментах вы решили писать фразы вроде «не трогать», «хы-хы», «пельменей бы навернуть» или «сгоняю за пивком, а потом допишу», поздравляю — вы попали в котел с пельменями (да и те разварились и пригорели к днищу).

1. Котел с пробитым дном: GOTO
   

Операторы вроде GOTO сильно путают даже самых матерых программистов, потому что разобраться в бесконечных переходах часто бывает невозможно. И такие конструкции могут сбить с толку, если не заметить несчастный оператор:

 

10 a = 5;

20 a = a + 5;

30 GOTO 60

40 a = a * 235;

50 a = a / 567;

60 a = a * (a+2)

70 write a;

Пользуясь такими операторами, вы попадаете в котел, где вам предстоит пробивать одно фальш-дно за другим, пытаясь найти настоящее. Но не найдете.

1. Котел неопределенности: рандомные имена
   

Чтобы не забыть, что находится в переменной, достаточно дать ей очевидное название: promocode, userID, houseSquare и так далее. Но вместо этого программисты любят придумывать совершенно необоснованные имена: SkyrimIsTheBest, Puten, Dimon, ProshayShkola, AK, asjdvirowda, Hermione, SupernaturalDean, SupernaturalSam, Gulag, YobaEtoTi и так далее.

 

По их названию невозможно понять, какое у них предназначение. Так и вам в котле будут предлагать угадать, в какой переменной правильный пароль для выхода из ада.

1. Котел на медленном огне: переименованные функции
   

Предыдущий пункт доходит до такого абсурда, что люди создают новые функции, только чтобы изменить название старых. Например, так:

 

function bobby(message) {

alert(message);

}

Это не только путает других разработчиков, но и замедляет работу кода. А теперь представьте, что ваш котел стоит на медленном огне, а вы можете отключить функцию, которая за него отвечает. Но вы мало того что не знаете ее названия, так еще и пламя становится больше, когда вы ошибаетесь.

1. Котел на дровах: разные форматы имен
   

Представьте, что вы читаете чужой код и видите переменную carPenalty, через несколько минут встречаете car_penalty, а потом и penaltyCar с penalty_car в придачу. Да, порой бывает сложно придумать названия для схожих переменных, но можно же хотя бы не менять стиль.

 

Попробуйте как-то уточнить и назвать их toyotaPenalty, audiPenalty, ladaPenalty и так далее. В конце концов, никто не отменял массивы — penalty[‘toyota’, ‘lada’, ‘audi’].

 

Каждая переменная может содержать как воду, так и новые дрова, а вы можете подкинуть их в огонь — и можете спастись или усугубить ситуацию.

1. Адская банка шпрот: отсутствие форматирования
   

Бывает очень сложно разбирать код, в котором нет никакого форматирования — всё просто свалено в кучу:

 

<? include("database.php"); $query = "SELECT * FROM articles WHERE id='$_GET[id]'"; $result = mysqli_query($database, $query); if($result) {$array = mysqli_fetch_arrray($result); echo $array['text'];} else {echo "Ошибка!";} ?>

Хорошо, если он элементарный; но если это что-то сложное, то без мирового запаса пива не обойтись. Хотя уже давно есть возможность автоматически выровнять код, глаз все равно начинает дергаться, когда видишь что-то подобное.

 

Так и вы будете спрессованы в одну кучу с другими мастерами сокращения.

1. Котел слияния: разное форматирование
   

Другая беда, когда форматирование есть, но оно разное:

 

<?include('database.php');

if(isset($_POST['id'])) {$id = $_POST['id'];}

if($id == 0) {

echo "Попробуйте ввести другой ID!";

}

if($id != 0)

{

$query = "SELECT * FROM articles WHERE id='$id'";

$result = mysqli_query($db,$query);

if($result)

{

$array = mysqli_fetch_array($result);

echo $array['text'];

}

else echo "Ошибка!";

}

?>

Создается ощущение, что даже этот простой запрос в базу данных писал доктор Франкенштейн. И вас пришьют к другим мученикам, чтобы вы могли чувствовать и их боль тоже.

 

б/н: Гриль плохой поддержки

До этого мы говорили только о коде, но пора обсудить и готовые программы. Часто их делают спустя рукава, а чтобы избежать последствий, разработчики придумывают миллионы отмазок:

 

На моем компьютере все работает.

Наверно, это вирус.

Кто-то трогал мой код.

Вы что-то делаете неправильно.

 

На выходе мы получаем новый Assassin's Creed, которому нужен патч в первый же день релиза — отличный повод для барбекю.

 

 

Edited January 11, 2019 by Lion2032

[doctorraz]

>8 заповедей программиста

млин, а тут пошутить слабо? нафиха кудато посылать?

[Lion2032]

>8 заповедей программиста

млин, а тут пошутить слабо? нафиха кудато посылать?

 

Исправил

[Lion2032]

Как программирует инженер:

 

 

 

Ну, вот пример: простейшая программа прочностного анализа, скажем, расчет балки по формулам сопромата. Что напишет умеющий программировать инженер-расчетчик: две-три строчки — ввод исходных данных, две-три строчки — собственно вычисления и четыре-пять строчек — печать результатов расчета. Всей программы — десяток строк кода. И написание ее займет от силы полчаса. Ну хорошо, если человек только осваивает компьютер, — два часа. А дальше инженер будет этой программой пользоваться всякий раз, когда ему надо посчитать балку.

 

 

 

Как программирует программист:

 

 

 

Теперь представим, что задание написать программу расчета балки получил профессиональный программист. Первое, что он сделает… нет, не бросится к компьютеру программный код писать, он вооружится блокнотом и пойдет «пытать» инженера-расчетчика: итак, какие же у нас исходные данные? Геометрические размеры — пролет балки и ее сечение. Ну, допустим, простейший случай — брус, высота и ширина. OK. И что программа должна делать, если пролет нулевой? Выдать сообщение об ошибке и остановиться? Какое сообщение? OK, записываю. А если пролет отрицательный? Как это может быть? Да элементарно, рука дрогнула, случайно на кнопку «минус» нажала. Так чтó, выдать сообщение об ошибке и остановиться или напечатать предупреждение, поменять знак числа и продолжить? Теперь аналогичные вопросы касательно высоты и ширины. OK, записываю…

Обычно, к этому моменту «подследственный» начинает звереть и ерзать на стуле, а ведь мы, по-хорошему, еще даже не начинали. Проверка на допустимые значения параметров по отдельности, это так… даже не разминка. Переходим к проверке соотношений параметров. Формулы сопромата для расчета изгиба балки базируются на допущениях теории Эйлера-Бернулли, коими не буду морить читателя, но скажу лишь, что результаты расчета хорошо согласуются с экспериментом, когда балка — действительно балка, т.е. нечто такое удлиненное по сравнению с сечением (но не слишком). Скажем, книжная полка: пролет метровый, а доска дюймовая. В самый раз. Или брус перекрытия пролетом шесть метров, с высотой сечения 20 см. Тоже нормально. А если мы восьмидюймовым брусом перекроем пролет в в один фут, то это как? А это, извиняюсь, уже не балка будет и считать такую конструкцию (скорей похожую на стеновую панель) надо совсем по другим формулам. И если двухметровый пролет перекроем, к примеру, миллиметровым металлическим листом или затянем пленкой, как в теплицах, то это тоже не будет балкой и считать придется по формулам теории все того же вездесущего Леонарда Эйлера, только совсем другой теории — статики гибкой нити. Инженер все эти вещи «печенкой чует», он интуитивно классифицирует и выбирает метод расчета (а хороший инженер и считает-то «для очистки совести»; он заранее знает результат, моделируя работу конструкции — сопротивление материала — каким-то необъяснимым, помимо сознания, способом, но при этом — безошибочно и весьма точно; если он настоящий инженер, конечно).

Увы, компьютер начисто лишен интуиции и все «входные» ограничения требует формулировать явно и однозначно. Даже для нашего примитивнейшего случая это далеко не просто… А кстати, мы тут оперируем метрами, сантиметрами, дюймами. А ведь для расчета все размеры надо привести в одну единицу измерения. В какую? В сантиметры? OK. И для входных данные считать, что все задано в сантиметрах? Ах, пусть пролет в метрах, а сечение в сантиметрах? А дюймы-футы? Ага, значит прежде задания размеров из меню выбирается система измерений: метрическая или имперская. А если пользователь ввел в метрах-сантиметрах, а потом решил пересчитать в дюймы-футы? Ага, вводим специальный пункт меню «пересчет». А может пусть указывает единицу измерения при каждом числе? Неудобно? Тогда, значит, пусть будут «правила по умолчанию», возможность выбора системы измерений из меню, режим пересчета, а дополнительно еще чтоб можно было указать единицу измерения при любом индивидуальном размере. Уф! Теперь это все запрограммировать и будет… всего навсего будет ввод геометрических размеров. А еще у нас есть ввод физико-механических свойств материала. Для простейшего изотропного линейно-упругого материала это два числа — модуль Юнга и коэффициент Пуассона. Наше счастье, что второй — безразмерный. Зато первый… та же головная боль с единицами измерений: континентальные килограммы на квадратный сантиметр или может имперские килофунты на квадратный дюйм, а то и вовсе новомодные мегапаскали. И всякие пересчеты между ними. Плюс, конечно, проверки на допустимые диапазоны значений (для обоих параметров) и диагностические сообщения в случае нарушений… А еще у нас ввод нагрузки: проверки, игры с единицами измерений и пересчетами, диагностические сообщения… И это мы топчемся пока всего лишь на вводе данных. А потом еще будет сам расчет, где программист, помимо двух строчек расчетных формул, будет долго и нудно специфицировать все мыслимые и немыслимые ошибки вычислений, реакции на них и опять же диагностические сообщения. Посчитав, наконец, приступаем к печати результатов. Так, во-первых короткая распечатка для рабочих нужд: вывод на экран или консольную пишущую машинку только чисел и минимальных обозначений при них. Теперь дальше: печать в табличной форме для многократных прогонов — чтоб сравнивать варианты. Эх, еще бы графики-эпюры построить. Не беда, что не производятся пока графические принтеры и дисплеи — примитивные графики можно «рисовать» звездочками на текстовых принтерах. И еще не все. Нужна «официальная», полная распечатка, которая будет подшиваться в проект со всеми, кстати, реквизитами проекта (которые тоже надо вводить, как и параметры, задающие форматирование и управляющие процессом печати)…

Ну вот, вроде бы все. На собеседования с будущим пользователем программы ушел хорошо если один рабочий день, а то и два (это называется на нашем жаргоне «обследованием» или «постановкой задачи»). Думаете, теперь-то программист пошел программировать? Ха, как бы не так! Он пошел писать документ под названием «техническое задание» и хорошо, если сам наберет его на компьютере и там же отпечатает. Тогда за пару-тройку дней справится. А вот если он пишет от руки на бумаге, а потом печатают девицы из машбюро, тогда, считай, уйдет неделя. Затем документ читается и согласовывается пользователем (почти всегда при этом — уточняется, правится и переписывается). Наконец утверждается начальством и… всего лишь две-три недели спустя программист приступает собственно к программированию. Помните, что инженер уложился в десять строчек кода? Так вот, программисту со всеми этими проверками, диагностиками и пересчетами придется написать эдак строк двести-триста…

 

 

 

 

Почему так получается

 

 

 

Соль в том, что считает по-прежнему сам инженер, используя программу (линейку, калькулятор) просто как инструмент. А ежели так, то нужен ли ему в программе миллион проверок? Нет, он сам все проверяет и контролирует. Интуитивно. Ему нет нужды вникать в детали расчета, достаточно взглянуть на результат и… все сразу ясно: правильный он или лажовый. Так что, нужна ему только голая «считалка» для трудоемкого расчета, которую он и запрограммирует за полчаса…

 

 

А вот наш брат программист делает программу для расчета автоматического (это когда вообще без участия человека) или же автоматизированного (при участии «безответственном», например, клерка, который проверить результаты не в состоянии, бо не знает сопромата; его самого контролировать надо, правильно ли исходные цифры ввел). У компьютера же, как известно, с интуицией напряг, он — очень быстрый и старательный идиот, тупо исполняющий команды. А мы — программисты — представляем интересы этого бедолаги в мире людей. Зная, что сам он не в состоянии предусмотреть аж ничего, решить «интуитивно» («по аналогии», «исходя из здравого смысла») аж никакой, самый крохотный вопросик, вынуждены мы с раздражающим педантизмом, со скурпулезностью нечеловеческой предусматривать самые нелепые, невозможные ситуации, искать ответы на самые дикие, кретинские вопросы. И все эти «а что если?» закладывать в программы, отчего те разбухают неимоверно — в десятки, в сотни раз…

 

 

 

Главная проблема разработчиков:

 

 

«Немота специалистов». На эту тему написаны груды книг, подводящих под эту беду бездну психологических, эпистемологических и даже кибернетических обоснований невозможности автодескрипции. Но без ученого мудрствования горький факт таков: специалисты (замечательные, многоопытные, бесспорные специалисты) не могут сами составить вразумительные технические требования, т.е. детально описать собственную деятельность. Подавляющее большинство (за редчайшими исключениями) при искреннем желании сделать это — не могут. На вопросы отвечают охотно и подробно. Но… как неспециалисту знать, какие именно вопросы задавать? Замкнутый круг! Пример с инженерными расчетами (который я привел выше) и вообще все, что основано на строгих формализованных правилах и формулах — это как раз самое простое, человек с общематематической подготовкой как-нибудь да разберется (наша задача ведь не в отыскании новых методов расчета, а в том, чтобы растолковать себе и компьютеру существующие). Но вот технология работы, взаимосвязи между подразделениями, нюансы отношений с поставщиками и потребителями, неформальные, неписаные законы, приемы, обычаи (как мы их называем — «практики»). Вот их клещами не вытянешь. Не потому, что специалист боится разгласить свои секреты. Он знает, что ты ему не конкурент. Просто он эти секреты никогда не формулировал, они живут в его голове на невербальном уровне

 

 

 

 

Взято отсюда: _https://medium.com/@kpem/%D0%B2%D0%BE%D1%81%D0%BF%D0%BE%D0%BC%D0%B8%D0%BD%D0%B0%D0%BD%D0%B8%D1%8F-%D1%81%D0%BE%D0%B2%D0%B5%D1%82%D1%81%D0%BA%D0%BE%D0%B3%D0%BE-%D0%B5%D0%B2%D1%80%D0%B5%D1%8F-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%81%D1%82%D0%B0-e57bd8666ae4

Edited January 30, 2019 by Lion2032

[lcob]

rnrnэто уже надо бить программистов домофона/газа. они криво штрихкод печатают.rnrn

[MS$]

Олдскул

xxx: Да что вы знаете о бекапах, зелёные?

xxx: У нас на заводе есть самописная софтина, где-то на 70к строчек кода

xxx: Так вот, каждые полгода мы РАСПЕЧАТЫВАЕМ весь её исходный код на А4, сшиваем в папки, и сдаём в архив! Где эти распечатки хранятся пол-года.

xxx: Если что случится с исходниками, планируется, что мы достанем эти распечатки и ВРУЧНУЮ НАБЕРЁМ весь код на компах заново.

[amk]

Кстати, вполне реализуемый сценарий. Только надо дополнить эту процедуру каким-нибудь средством контроля, типа контрольных сумм фрагментов. И соответственно написать программу, которая будет осуществлять такой контроль. Далее, программа бьётся на фрагменты, для каждого фрагмента вычисляется контрольная сумма, и фрагмент вместе с КС распечатывается.

70К строк это примерно 1000 страниц формата A4. Даже не очень опытный оператор потратит на страницу A4 не больше часа. На весь текст уйдёт порядка 125 человекодней. Таким образом 10 человек смогут восстановить программу за две с половиной недели.

Программа расчёта КС должна игнорировать мелкие отличия типа изменения числа пробелов и пустых строк, и желательно считать КС отдельно для каждой строки.

[Fogel]

Всё уже придумано задолго до нас - откройте журнал Радио времён Радио-86рк и там все эти контрольные суммы в каждой строчке (ибо печать была та ещё)

P.S. я бы загрузил листы в распознавалку

[amk]

P.S. я бы загрузил листы в распознавалку ;)/>

Я тоже. После чего всё равно придётся править текст в редакторе.

Пример про "Радио" и "Радио-86РК" неплох, но он немного не по теме. Там машинные коды, их надо вбивать точно, нет никаких вариантов.

А в исходниках можно допустить появление дополнительных и исчезновение необязательных пробелов. Также возможна замена пробелы<->табуляция. В частности, могут быть пробелы в конце строки и пустые строки в конце файлов. В распечатке их не видно, и на отлов такого изменения будет уходить слишком много времени. Поэтому я и написал про специальную программу проверки.

В принципе, описание её я и придумал на основе тех журнальных распечаток.

 

P.S. А ещё можно преобразовать файлы в двумерный штрихкод и распечатать его. В сети есть несколько программ, позволяющие сперва распечатать таким образом файл, а потом сосканировать лист и вернуть его в бинарную форму. Файлы сжимаются и снабжаются информацией для восстановления - читаются даже листы с дырами. при размере точки в 0.5 мм на одну страницу при таком способе поместится порядка 60 страниц исходного текста.

[MS$]

[MS$]

[Fogel]

Эй, где винда 3.11 и 10ка?

[MS$]

[doctorraz]

2, 1 0,5 0,25 0,125 0,0625 0.03125

Не понял.. кому платили 100 тыс если они все половинили?

62,5 тыр маловато.. хотя за китайца мож нормуль.. их много

Edited October 22, 2019 by doctorraz