<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Автор, вы молодец, хорошую тему подняли, пишите еще
Готов подписаться под всем списком! )
Молодец. +1
Эх жаль, что нет чего-то типа книги знаний — с содержанием, с рубриками и с другими понтами. Через время эта статья затеряется в ворохе других. А жаль…
2VasilyKushnir обещаю продолжить, если людям понравится то что я написала. так что заходите на блог
правильные слова.
Все правильно. Молодец!
Особенно п.3.
Интересно 1С-овцы следуют этому принципу.
Судя по типовым конфигурациям — нет.
Хорошо! Понравилось.
Когда читал про + и — регистров, вспомнил про конфигурацию, над которой мне приходится работать и которую мне поставляют «сверху» от франча. Так вот там есть один регистр НАКОПЛЕНИЯ, в который идут только движения «+». На мой вопрос «а какие документы делают расход по этому регистру? Может я их просто не заметил?» мне ответили: «никакие. Вы всё правильно подметили.». Далее я спрашиваю: » А почему тогда этот регистр не ОБОРОТНЫЙ?». Ответ: «Да, НАВЕРНОЕ, вы правы. Но это сейчас для нас не главное, и, ЕСЛИ буднт исправлено, то как минимум через гола полтора!»
Вот такие вот пироги… (а это конфигурация распространяется во все регионы России)
Все правильно, есть в словах истина! За это плюс!
Да. Повешу с офисе плакат с этим письмом. Самое обидное что сколько не тычь носом программеров в их код почему то не получается вдолбить все это в их голову.
П.С. Правда и гуру совершают тупые ошибки просто потому что слишком уверены в себе. И считают лишним проверить банальные операции (типа проверки документа на открытие или еще хуже не проверить на синтакс контроль)
Про воробьев, бабочек и собак понятно.
Проверяете чужую работу — понятно.
Чем занимается тетя Маша — тоже ясно
А кем работаете, за что отвечаете?
Критиком что-ли.
Распечатал, повесил плакат в офисе! Раздал копии разработчикам… Огромный респект автору…
Статья скорее ориентирована на безответственных программистов, нельзя всех грести под одну гребенку
2 Oygen да, статья орентирована на и безответственных. хочеться заранее предупредить людей что я считаю безответственностью и чтоб такого не было. не нравится что ругаю? ну что ж, не сахарные, не расстают.
2 Valentin57 отвечаю за проект. технический лидер, аналитик и тестировщик — пишу ТЗ, принимаю у программиста и сдаю работу заказчику. а вы кто и за что отвечаете?
>статья орентирована на и безответственных.
А по мне — просто на придурков 😉
2 Abadonna искренне надеюсь что правильно люди поймут. если я нервничаю и объясняю, значит мне не все равно и я хочу научить.
2 beigka Да я же не возражаю 😉
Просто мысли вслух :))))
2 beigka: Твоим разработчикам «Совершенный код» в зубы — все будет тип-топ!
Для студентов, которые только открыли первый раз конфигуратор.
Можно аналог написать — как свести с ума разработчика — про ТЗ, которые часто ставят перед ними. «Хочу, чтобы все!»
Проблема реально существует.
Но она — макроэкономическая.
Когда в целях быстрого развития страдает качество.
И 1с, головная, много делает глюков и нелепостей.
Но они выполняют свою КОНЦЕПЦИЮ РАЗВИТИЯ, а не создают сервис по конфорту для тети Маши.
Всем трудно. Но это и есть суть работы. А испытателям, спасателями т.д. — сам бог велел пострадать за Отчизну.
Есть такие профессии — Родину защищать.
——————————————————
Система «фрачайзи» предполагает, что все занимаются развитием и тестированием. Все участники одного дела.
При этом, либо ты вписываешься в процесс с осознанием дела и совершенствуешь,
либо являешься тормозом развития, и Отчизна не будет благодарна.
Так же есть ТО, ТЗ и экономическое обоснование проекта. Ну и конечно деньги и время на выпонение заказа.
То есть, оптимальность решения задачи — многокритериальна. Попросту — из многих зол выбирают меньшее.
И если стажер-программист будет изучать Ваши инструкции — он свихнется и дуба даст. Он же живой!!!
Как программисту работать — определяют непосредственные руководители.
А у Вас — назидания 5-летнему ребенку, который от Вашего воспитания скорее бестолковым станет.
——————————————————
По моим наблюдениям, качество 1с действительно падает. И мы все за это в ответе.
Мы все в ответе а решает — ЛПР, лицо принимающее решение, в 1с.
Ну сейчас так всем выгодно жить.
Но обсуждать надо профессионально и предметно.
А так… Ну жаль мне Вас, ну свечку в церви поставить можно.
А когда придет время — маятник сново качнется в сторону ГОСТ-ов.
Полностью согласен
(20) Такое уже есть — чтобы «хочу, чтобы все!» — см.
(21) если буду писать «красиво» (я в принципе стараюсь не писать некрасиво) — с голоду помру…
Valentin57 сейчас стажер слушает и делает, а через год или два сам будет проектировать системы. а если боится, что дуба даст, то пусть не программирует, а в менеджеры идет.
>Система «фрачайзи» предполагает, что все занимаются развитием и тестированием. Все участники одного дела.
я думаю, что наличие отдельного тестировщика на проекте — это отлично. только 1с никам нужно доказывать, что тестировщик нужен.
а вообще, я выложила свои требования к качеству. если с нуля проектировать, то должно быть хорошо. если у вас другое мнение и идеи как улучшить качество — с удовольствием предметные вещи б почитала. в статье я просила делиться идеями для пополнения списка, а пока не густо.
2 Душелов не все. а вот точно по пунктам хочу.
потому что:
— непосредственно функциональный код занимает 10 строк, а обвеска защита от дурака — 40 строк.
Боян, конечно, но еще раз повторюсь — есть 3 пункта: время разработки, качество и цена.
Одновременно работают только 2. Любые. На ваш выбор. И все.
Чаще всего, заказчики выбирают — быстро (время) и дешево (цена), соответственно, качество падает.
Ну и т.д.
2 Душелов как в анекдоте — быстро, дешево, качественно. выберайте 2!:) некоторые делают вообще только одно из 3х, так что 2 — это тоже гуд.
(27)На практике ранжируешь эти показатели.
На первом месте всегда время. Надо быстро.
Ну если по всем правилам — потом сопровождение.
И только потом спецификация и детализация устранение мелких и множественных шероховатостей,
которые (23)НЕ СОСТОВЛЯЮТ ТЕХНОЛОГИЧЕСКОЕ ЯДРО ПРОГРАММЫ.
Такова ЭВОЛЮЦИЯ развития.
А за Вашу бюрократию, волокиту и формализм — кто расплачиваться будет.
Тогда нужна нянка или психоаналитик.
2 Valentin57 здоровое количество бюрократии — это порядок, планирование (работа стабильная и не сверхурочная), это хорошо регулируемый уровень качества, ну и возможность делать красивые приложения. но это ответственность перед командой. нянька не нужна. работаю я с мужчинами. психоаналитик — не знаю. иногда стоит обсудить что человеку мешало сделать как надо:)
(26 Сhe Burashka)Искренне поддерживаю.
Иногда такой интерфейс надо городить по просьбе юзера, что первичная цель забыта и похоронена.
И даже не оценена пользователем изюминка.
(30)ВСЕ РЕШАЕТ КОНЕЧНЫЙ ПОЛЬЗОВАТЕЛЬ!!!
И что красиво, и что хорошо. Заказчик всегда прав.
Так было и так будет. АМИНЬ;)))).
Есть такая мудрость.
Если сделать программу, что и дураку будет понятно,
так только дурак и будет пользоваться.
неужели ни у кого нет идей чтоб добавить в список?
Valentin57 Если сделать программу, что и дураку будет понятно то она будет называться программой с интуитивно понятным интерфейсом. и с УПП дураку тяжело будет…
(34) 1 пункт:
2 Душелов второй бы список расширить
(2) а второй список пользователь должен писать.
(36) В СТУДИЮ МЕТОДОЛОГИЮ.
И ЭТО ОЧЕНЬ вразумительно.
«Короткий цикл обратной связи (Fine scale feedback)
Разработка через тестирование (Test driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
Парное программирование (Pair programming) »
(37) т.е.
(39) Там ссылочки есть 🙂
Разрабо́тка че́рез тести́рование (англ. test-driven development) — техника программирования, при которой модульные тесты для программы или ее фрагмента пишутся до самой программы (англ. test-first development) и, по существу, управляют ее разработкой. Является одной из основных практик экстремального программирования.
Разработка в стиле TDD состоит из коротких циклов (длительностью от 2 минут, в зависимости от опытности и стиля работы программиста). Каждый цикл состоит из следующих шагов:
Из репозитория извлекается программная система, находящаяся в согласованном состоянии, когда весь набор модульных тестов выполняется успешно.
Добавляется новый тест. Он может состоять в проверке, реализует ли система некоторое новое поведение или содержит ли некоторую ошибку, о которой недавно стало известно.
Успешно выполняется весь набор тестов, кроме нового теста, который выполняется неуспешно. Этот шаг необходим для проверки самого теста — включен ли он в общую систему тестирования и правильно ли отражает новое требование к системе, которому она, естественно, еще не удовлетворяет.
Программа изменяется с тем, чтобы как можно скорее выполнялись все тесты. Нужно добавить самое простое решение, удовлетворяющее новому тесту, и одновременно с этим не испортить существующие тесты. Большая часть нежелательных побочных и отдаленных эффектов от вносимых в программу изменений отслеживается именно на этом этапе, с помощью достаточно полного набора тестов.
Весь набор тестов выполняется успешно.
Теперь, когда требуемая в этом цикле функциональность достигнута самым простым способом, программа перестраивается (см. рефакторинг) для улучшения структуры и устранения избыточного, дублированного кода.
Весь набор тестов выполняется успешно.
Комплект изменений, сделанных в этом цикле в тестах и программе заносится в репозиторий (операция commit), после чего программа снова находится в согласованном состоянии и содержит четко осязаемое улучшение по сравнению с предыдущим состоянием.
Этот цикл упрощенно описывается Кентом Беком в своей книге как «красный-зеленый-рефакторинг». Красный и зеленый — это цвета полоски в среде тестирования JUnit, которая показывает, все тесты сработали или нет. При этом на первом («красном») этапе необходимо добиться того, чтобы программа просто компилировалась, без срабатывания добавленного теста.
А еще лучше скачайте и почитайте книгу Кента Бека «Экстремальное программирование»:
(35)Ну опять Вам трудно, тяжело, душевное потрясение.
Психологи отмечают бурный рост иждивенческого и потребительского подхода.
Отсутствие склонности к созидательному труду.
Учиться, учиться и учиться.
Иногда сам в шоке пребываю.
Уровень развития такой, что программа становится протезом интеллекта для пользователей.
Стало трудно найти бухгалтера, чтобы он знал бухгалтерию.
К тому же тенденция к отчуждению и самоизоляции.
А многие даже хотят, чтобы программист читал мысли и желания, жил в их мозгу, заменял им мозг
и был бы одновременно их мозгом и «козлом отпущения».
Это все просто идет к уменьшению финансирования на работников (операторов), чем ниже интеллект, тем ниже зарплата, потому и требуют от разработчиков писать такой софт, с котором и обезбяна бы могла работать.
(45) Но стаким софтом короткий анекдот -«Обезьяна с гранатой».
Вот и вылизываешь кнопочки, картинки.
Не дай бог не туда или не так нажмет и прога не спасет от беды дитятку.
2 Душелов я тут не спрашиваю как процесс организовывать. я спрашиваю про то, на что стоит обратить внимание начинающего программиста, контрольные моменты, где нужно было б чтоб четко работало. и желательно именно для 1с ника пишущего экономического ПО.
2 Valentin57 мне не трудно. я как раз и занимаюсь созидательным трудом. учу стажеров, статьи пишу, проекты идут. а клиента и пользователя созидательному труду учить не хочу.
(46) начинающему программисту лучше сначала конфигурации пообновлять, отчетики пописать для магазинов и небольших фирм, а не лезть в разработку экономического ПО 🙂
Экономит ваша фирма на спецах, раз стажеров на такие проекты берете, которые пишут так, как приведено в статье.
Уровень развития 8.0 и 8.1, что кроме диплома, надо 1-2 года юзером побыть,
да в подмастерьях побывать.
Бывает лучше чтоб интерфейс загнулся у юзера, чем он все данные загробил.
(48) Душелов не экономит а учит.
ладно, безпредметный разговор. скучно.
Вот такое «парное катание».
(49) >Бывает лучше чтоб интерфейс загнулся у юзера, чем он все данные загробил.
За эти слова готов +5 баллов поставить.
На практике приходиться иногда инсценировать глюк, чтобы думали.
А был случай имитации аварийного завершения, по причине не перепроведения документов.
(50) Согласен. Скучно. Зато компания экономит деньги на спецах 🙂
Да и попробуйте , спеца и стажера посадить рядом.
(50) Скучно?!
Душа хотела социальной мясорубки с песнями и танцами?
«Какой хороший день, какой хороший пень, какой хороший я и песенка моя».
А оказалось и здесь надо трудиться (от слова трудно).
А про парное программирование — так как раз и надо УЧИТЬ И ПРИУЧАТЬ. Ведь что посеешь …
(55) 2 Душелов. ну вы право, как в старом и не актуальном анекдоте. у иженера в ссср маленькая зарплата. а в америке негров не любят.
я не спрашиваю, кого мне возле стажера садить. и вообще, брать ли стажера на проект. и какой уровень должен быть у стажеров чтоб с ним можно было работать.
(57) Valentin57 парное программирование я со своими сотрудниками обсуждала.:) они гришковца вспоминают. как палубу мыть вдвоем — один моет а другой волнуется:)
(58)Нахожу тоже полезным.
Помните, «Котенок по имени гав». На крыше вдвоем боялись.:))))
Ну может еще не время, а может не появился этот «новатор», не вызрела пока достойная уважения личность,
способная понимать и тех и других и управлять ситуацией.
(57) а что спрашиваете? хотите идей — я вам предлагаю.
Не хочет.
Низы все время не хотят, верхи всегда могут.:)))
(58) обсудите экстремальное программирование 🙂
Не ужели и этот караван не пойдет быстрей из-за самого медленного верблюда.;)
Бабочек жалко… 🙁
Есть хороший способ проверить работоспособность программы. Если программа не упала под Чебурашкой — значит не упадет никогда :)))
Проверено 😉
А зачем тогда тестировщик? Постановку задачи делает руководитель проекта. Или у тестировщика ума больше чем у руководителя, забавно- садись и пиши, а то на разрабртке умных людей меньше и меньше. (кто не умеет сам- тот учит, кто не умеет учить — тот руководит), а вообще все укладывается в 2 понятия, так можно делать, а так нельзя. Отделить можно от нельзя очень сложно, и тем кто это умеет платят большую зарплату.
2 map5 про то зачем нужен тестировщик в какой то другой статье написано…
Здравствуйте beigka. Ваша статья довольно интересная, но у меня к ней есть ряд замечий. Во-первых, название «…. о стандартах разработки ПО»… Честно говоря не встретил у Вас в статье ни единого слова о настоящих стандартах, вся статья построена только на Ваших эмоциях — это разочаровало. Мне кажется, что перед началом написания статьи Вам следовало заглянуть в стандарты 😉 например SWEBOK, IEEE 830, ну или хотя бы в ГОСТ. (мысли о Гостах уже упоминали в комментариях). Во-вторых, Вы пишете о качестве, но у меня сложилось впечатление, что сами точно не представляете что это такое. Хотелось бы узнать что такое качество в Вашем понимании? В третьих, я с Вами не согласен в том что, программист должен думать комплексно, желательно конечно, но это не есть недостатком. Например Ваш пример с регистром… Представим что я конечный программист который реализует функционал документа что пишет регистр в «+». Скажи пожалуйста, зачем мне узнавать кто и как будет писать его в «-«. Эту работу еще на этапе анализа должен проделать архитектор, который планирует систему и потом пишет ТЗ, программист как конечный исполнитель не обязан знать что происходит там дальше… Еще так же не согласен, о том что разработчик должен общаться с пользователями и узнавать как и что у них работает. Для этого есть аналитики которые собирают начальные требования и описывают бизнес-процесс при старте проекта на этапе детального обследования. Ваши мысли (хотя статья очень эмоциональная, так что скорее эмоции) не совсем соотносимы с реальностью, с нормальным проектным подходом к работе. Кстати, вопрос о четкой постановки задачи разработчику тема для отдельной статьи … кстати было бы интересно прочитать ее от Вас. Так как Вы упоминали, что занимаетесь обучением, интересно узнать, Вы говорите своим ученикам, что бы они отказывались работать при не четкой постановке задачи или отсутствии ТЗ?… Жду Ваших мыслей… А вообщем, так как это Ваша первая статья, то довольно не плохо 🙂
Например, такой пример.
Написал отчет по многофирменному учету (УТ 8 ). Отчет очень сложный, здесь таких не видал.
Учет без головного контрагента, продажи внутри базы по вертикали и по горизотали.
В одной базе 17 фирм, список номенклатуры — 32 000, все виды деятельности.
Регистры вставлять для зеркальных документов поздно. База работает 3,5 года, размер — 5 Гб.
Море пользователей!!!
Анализ — требует участия опытных и знающих пользователей.
И кодинг и планирование анализа работы отчета — ПОГЛОТИЛО.
ПОБОЧНЫЙ РЕЗУЛЬТАТ — У НЕКОТОРЫХ ПОЛЬЗОВАТЕЛЕЙ НЕ ОТКРЫВАЕТСЯ, У ДРУГИХ ВИСНЕТ ПРИ ИСПОЛНЕНИИ.
Причина — права доступа пользователей (вылетело из головы).
Хорошо пользователи опытные и поняли, что это мелочь, это не суть, неизбежное упущение. Не это, так другое при заданном времени.
————————————————
ЖАЛЬ НЕ БЫЛО ТОЛКОВОГО ТЕСТЕРА !!!
ЕСЛИ НАЙДЕТСЯ — ПИШИТЕ t3731081@ya.ru, отнесусь с уважением.
О стандартах. Личное наблюдение.
Отсутствие жестких стандартов — дает свободу творчеству для всех, возможность креативных решений.
Правда требует от людей более прочных связей в отношениях, гибкого и глубокого взимопонимания.
На деле же — люди отдаляются. Но слава богу не всегда.
Тем более ценен человечный человек.
Стандарт же дает гарантии, надежность, но замедляет развитие.
В системе общества все эти моменты всегда цикличны, и колеблются возле золотой середины.
И сама природа так действует в поисках лучшего, отсекая самые крайние формы.
to Valentin57. О стандартах. На самом деле все зависит от руководителя, всегда можно найти компромиссное решение, между стандартизированным подходом и местом для самореализации конечного разработчика. Как вариант, можно требовать придерживания стандартов при реализации особенно сложным задач, там где гарантировано нужно получить качественный результат и в срок, кроме того это не означает слепое следования стандарту, конечно возможен и приветствуется отклонение, применение новых подходов, но стандарты облегчат поддержку и подальшее развитие этой задачи. Но для этого при оценке задачи необходимо давать время на реализацию с коэффициентом хотя бы 1,5, для того что бы разработчик не боясь мог потратить некоторое время на осмысление задачи и возможно поиск более оптимального решения чем уже существует. А на счет того что стандарт замедляет развитие — не согласен. Главное не принимать все строго и четко как написано. Стандарт можно использовать как вектор направления с каким то допустимым отклонением и тогда не будет ущемления работников для развития, главное понимать, что нет ничего абсолютно правильного, так же как и нет ничего абсолютно не верного 🙂 везде есть чему по учится и от чего отклонится 🙂
(71)На самом деле вопрос философско-методологический.
1. Компримиссное решение — для кого, для чего ?
___Для хозяина — оптимум — ПРИБЫЛЬ ЗА ПЕРИОД. А потом хоть потоп, хоть гибель всего человечества.
___Для разработчиков — оптимум — часто, больше з/п, меньше работы.
На деле компромисс определяют руководители по приоритетам хозяина.
Остальные, не зная главных целей, занимаются пересудами и душещипательствами, выбивая у начальства,
каждый для себя выгодное положение в системе организации.
2. Стандарты.
Согласно продвинутым воззрениям, все в природе циклично.
Иначе, подчиняется сеобщим законам развития, законам диалектики.
Простая и наглядная модель — маятник, круг, цикл. В математике — два периода.
Проще, эволюционный (медленные) период накопления перспективных изменений и медленное угасание устаревших.
В этом периоде способны только самые сильные вживлять новое, которому сопротивляются — почти ВСЕ.
В следующем, революционном и быстром новое вытесняет старое.
Как раз в этот момент и нужны стандарты.
Но какой стандарт лучше — объективная истина понятная единицам и только им.
Остальные догоняют постепенно, с опозданием осознают, а некоторые (на деле оказывается большинство) — НИКОГДА.
Всегда же существует вопрос критерия качества стандарта — (1) Для кого и для чего, его субъективность.
И связь с глобальными процессами, историческими по масштабам.
Для сплоченного коллектива, если они на перспективном пути развития стандарты не нужны. Они у них в привычках, в сформированной нравственности.
Для такого коллектива нужен психологический климат и материальные условия.
В этот момент люди сами на себя берут управленческие функции, их самосознание находится на самом высоком уровне.
Введение же бюрократии — создаст напряженность и повысит конфликтность в коллективе и некоторым единицам это выгодно.
Главным же стержнем сплачивающем людей в данный период — система общечеловеческих ценностей.
Именно она выступают стабилизирующим фактором.
Но приходит время … и опять, одни создают стандарты. От детских и бредовых до фантастических и грандиозных.
Другие обсуждают их и постепенно начиннают сплачиваться вокруг наиболее перспективных,
которые проверят практика экономическими, математическими и друми методами оценивания.
И так МАЯТНИК КАЧАЕТСЯ ВЕЧНО.
(71) Еще добавлю.
К чему привела деятельность людей в области создания СТАНДАРТА пород… например, пород собак ( у людей же породы нет :)).
С одной стороны и есть красивые и сильные и выносливые и быстрые и…
С другой, болезненные, маложивущие, зависимые и от людей и от окружающей природы.
Многие на воле просто вымрут.
Вот и пример субъективности подхода и отсудствия абсолютной истины.
2 Valentin57 (73, 72, 70, 69, 61, 59, 56, 54, 53, 51, 49, 47, 44, 43, 39, 33, 32, 31, 29, 21, 11) спасибо за коментарии и то что вы так болеете за эту тему.
2 artmicro (68) вам тоже не болеть.
это статья действительно не о настоящих стандартах. эта статья подписана мною, потому это статья о моих стандартах. и она не о обеспечении качества как процессе, а о некоторых параметрах работы прогрраммиста.
вам не нравится — у меня слишком высокие требования? ну, команда сильна своими игроками. я хочу сильной игры, а для этого нужен какой то начальный уровень. хочется делать красивые и сложные программы.
мое мнение о четкой постановке задачи… мне бы тоже было интересно почитать статью о постановке задач от 1Сника.
Извините, увлеклись, про автора забыли.
Уважаемые коллеги beigka, Valentin57, Душелов и все-все-все… 🙂
Возьму на себя смелость посоветовать прочесть совершенно шикарную книгу :
Фредерик П. Брукс — Мифический человеко-месяц или как создаются программные системы.
Прочел в свое время первое издание — СУПЕР !!!
Для развития (само)дисциплины программирования очень помогает…
Например, вот отсюда:
З.Ы. (37) Законы Мэрфи сегодня актуальны, как никогда !!! 🙂
2 vkr читали, читаем и будем читать. законы мерфи не люблю. вообще не люблю читать об отрицательном опыте. интересуюсь прежде всего положительным.
Вы там с идиотами работаете, или в студсовете… Жаль Вас искренне…
2 molot. а вы один работаете? у каждого своя беда.
первую статью прочитали — не понравилась. вторую вот…
спасибо за мнение.
Завидую тем, кто работает в большом коллективе с постановщиками, программистами, отладчиками и пр.
У нас же решили, что и программисты уже не нужны. Посокращали всех. На аутсорсинг думают переходить. Результат аудиторской проверки вышестоящей организации. Да и раньше никаких постановщиков не было, программист во всем сам разбирался, безо всяких ТЗ, «с колес». Думаю, что только в Гос.компаниях остались в штате и постановщики, и программисты, и тестировщики. Кризис?