INFOSTART EVENT 2018 EDUCATION

Второй тур голосования за доклады.
Окончание 5 сентября.

Денисов Александр | Аналитик производительности БД | ГК Софтпоинт

«Неочевидные проблемы производительности: важность системного подхода при анализе»

• Распределенные взаимоблокировки: в чем опасность, как диагностировать и что делать дальше? «Распределенные блокировки», «синхронизация транзакций», «распределенные системы» — обычно это словосочетания, характерные для крупных систем, где сотни пользователей подключаются к геораспределенным репликам, а аналитики ищут вдохновения в измерениях олап-кубов. В секторе Small &Medium Business другие проблемы. Но даже если у вас все пользователи работают с одной-единственной клиент-серверной базой, вы все равно можете столкнуться с распределенными взаимоблокировками. Хуже того, из-за сложности диагностики программисты и администраторы могут не видеть, насколько серьезна ситуация. Мы разберем механику возникновения таких взаимоблокировок, способы диагностики и исправления ситуации. • «Железом» не прикрыть неоптимальный код. Когда аппаратное расширение уже не помогает. «Железом» не прикрыть неоптимальный код. Когда аппаратное расширение уже не помогает. Многие организации считают, что в случае острой необходимости они всегда могут «откупиться» от плохого кода вложившись в более мощную «железку» — дорого, зато быстро. Но из любого правила есть исключения. Мы разберем ситуацию, когда еще до закупки нового оборудования стало понятно, что это никак не ускорит систему.

Учебный курс. Повышение качества разработки. Вводная лекция

Программирование - Теория программирования

111
Учебный курс по теории и практике программирования. Бесплатно. В виде структурированного текста.

1 Предисловие к курсу

1.1 История создания и цели
Имея долгий опыт совместной разработки и сопровождения программ постоянно сталкиваюсь с одними и теми же проблемами в методологии разработки. Несколько лет назад решил задачу по преодолению указанных проблем для себя и для отдельно взятого предприятия. Метод прост – систематическое обучение и контроль усвоения материала.
Со временем понял, что проблема имеет большие чем я ожидал масштабы и постоянно усугубляется. Размышления над данным явлением вылились в настоящую исследовательскую работу, результаты которой, я не планирую публиковать в чистом виде, так как это послужит лишь для удовлетворения академического интереса небольшой части коллег. Полученные материалы я решил использовать для переработки своего учебного курса и последующей его публикации для широкой аудитории.
В этой лекции будут рассмотрены основные принципы определения хорошей программы, проблемные зоны качества и зоны его роста.


Каждая последующая лекция будет посвящена определенной теме. Структура курса построена по принципу возрастания доли практики. Если первые лекции посвящены теоретическому анализу, кристаллизации большого массива практического опыта в краткие формулировки, то последующие будут посвящены решению конкретных проблем с использованием предложенной методологии. Таким образом курс можно условно разделить на теоретическую и практическую часть. Был большой соблазн начать именно с практической части, как наиболее интересной и доступной, но это бы противоречило базовым концепциям, о первичности понимания принципов, над знанием отдельных фактов. Нельзя слепо копировать даже успешный опыт.  Ведь любой практический опыт ценен лишь в конкретном контексте заданного момента времени, тогда как понимание общих принципов позволит в разных контекстах применять правильные решения… в том числе путем копирования :-)

1.2 Главная цель, стоящая перед данным курсом 
   - Повысить общую грамотность разработчиков
   - Улучшить среднее качество программ.

1.3 Предупреждение об использованных материалах:
Для подготовки лекций специальные источники практически не использовались, курс основан на оригинальном исследовании. В тех случаях если буду использовать цитаты или выдержки из чужих работ обязательно укажу это. Если увидите где-то плагиат, прошу сообщить.


1.4 Условия распространения 
- разрешается перепечатка и «репостинг» в некоммерческих целях при сохранении исходного текста условий распространения и ссылки на источник
- разрешается цитирование с обязательным указанием источника.


2 Об истоках
Современные средства разработки, многократно умножили возможности программистов. Даже «деревянный» конфигуратор 1с, это отличный многофункциональный инструментарий по сравнению с примитивным текстовым редактором. Поэтому «то, о чем всё время говорили большевики» наконец свершилось - даже домохозяйка может писать код. Нет я ничего не имею против «домохозяек». Даже за. Даже на проекте (это спойлер).
Но это стало вызывать проблемы. Проблемы стандартные для любой технологической революции – отсутствие достаточного количества обученных кадров, носителей производственной культуры. Поэтому общие методики их преодоления позаимствованы у предков – наставничество, систематическое обучение, контроль качества. Вообще, анализируя проблемы современности, мне постоянно приходилось обращаться в прошлое и находить там или истоки проблем, или их предыдущие инкарнации с набором правильных, неправильных и приемлемых решений. Что не удивительно, ведь природа человека меняется не так быстро, а законы физики в обозримом интервале времени вообще не меняются, поэтому в сходных ситуациях люди будут вести себя примерно одинаково независимо от эпохи и уровня технологий.


В те времена, когда компьютеры были большие, а программистов было мало, написание программ считалось чуть ли не магией, а о программистах в экстренных ситуациях, вручную вводивших машинные коды напрямую в процессор, ходили легенды, и они вполне могли быть реальностью. Программы были маленькими, за пределы НИИ и заводов не выходили, операций было немного и долго работая с тем или иным процессором можно было выучить его инструкции наизусть. Но со стороны, осмысленный ввод двоичных данных выглядел эффектно. Наверное, с тех пор и сложились стереотипы о программистах, кои не без смеха можно было наблюдать в таких характерных художественных фильмах как Хакеры и Матрица.


Разумеется, подобные программисты есть и сейчас, может быть они также ходят в растянутых свитерах и потертых джинсах, но они прочно заняли свою нишу «программистов микроконтроллеров» и подавляющее большинство населения даже не догадывается об их существовании. Их слава и сопутствующие стереотипы достались в наследство новому поколению высокоуровневых (прикладных) программистов. Но прикладник от железячника отличается примерно так же как циркуль от паяльника. Если железячник действительно общается с компьютером на его языке (сейчас уже не совсем так, но не сомневаюсь, что могут), то прикладник пишет на вполне себе человеческом языке. Бедном на выразительные средства, очень примитивном и ограниченном, но человеческом языке с приятной и знакомой структурой.


Новички приходя в профессию с радостью узнают, что «код писать просто», и подчиняясь ложному стереотипу о магичности работы программиста, начинают воспринимать это как профессиональный антураж, подобный аналогичному антуражу, обставляющему работу фокусника-иллюзиониста. Таким образом сакрализация процесса написания кода разрушает нашу современную работу. Ведь это не работа мага или фокусника. Конечно процесс решения изобретательских задач, внезапные озарения имеют своё магическое очарование, но творческие способности присущи всем людям, и не являются чем-то особенным. И получается, что если отбросить творческий элемент как общий знаменатель, то получится, что написание кода сродни написанию школьного сочинения с требованиями как к содержанию, так и к оформлению.
Отсюда вполне очевидный вывод, что написание прикладных программ должно подчиняться не только математической логике, но и правилам того языка на котором пишет программист. Повествование должно быть ясным, основная мысль выражена четко, в структуре присутствует завязка, кульминация и эпилог. Т.о. текст, соответствующий школьным требованиям будет понятен любому человеку, умеющему читать.

3 Базовые принципы
Для начала, определю концепции которыми я руководствуюсь в работе и которые послужили основой для данного учебного материала. Обязательное изложение концепций — это тоже одна из концепций которой я следую - важнее хорошо и глубоко понимать принципы событий и явлений, чем знать максимально возможное число отдельных «правильных» фактов.

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

3.2 Не шифруй, а пиши.
Программа – это книга, которую программист пишет для другого программиста. Идеал - комментарии как эпиграф к главе. Нужны только для отдельных функций или разделов, потому что сам код легко читается и не нуждается в отдельных пояснениях.

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

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

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

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


- «Карго-культ» инструментов разработчика. Ошибка в позиционировании первичности инструмента, над фундаментальными знаниями о предмете (отсюда споры «в 1с нет ООП», нездоровый ажиотаж вокруг расширений и.т.д.). Природа этого явления, очень древняя, возможно одна из самых древних, уходящая корнями ко времени первых орудий труда. Использование орудий труда являлось важнейшим эволюционным фактором в истории человека, и примитивные попытки осознания важности этого события приводили к подмене причины и следствия. Фактически, деятельность человека усложнилась и ему потребовались дополнительные инструменты, которые он изготовил или освоил если речь идет о навыках. Но для обывателя это имело очевидный сакральный смысл. Ведь гораздо проще представить, что заостренный камень ценен сам по себе и является даром богов, чем представить тот колоссальный объем умственной работы который сопутствовал развитию трудовой деятельности и созданию орудий труда.
- Культ «Тайного знания». Мистификация процесса разработки и работы программ. Представление процесса разработки неким таинством, обрядом. Проблема по генезису аналогичная предыдущему пункту – банальная подмена, где «обряд» или иной фетиш признаётся первичным, по отношению к мыслительной деятельности и результатам реального труда. При этом как и любая деятельность, требующая длительного сосредоточения внимания, программирование требует предварительной подготовки, втягивания в процесс, что вполне может быть обставлено как магический обряд.
- Культы «Святого писания» и «Знания Древних». Трепетное отношение к ранее написанному коду, как к непреложной истине и боязнь не только вмешательства, но и простого исследования. К старому правилу «работает – не трогай» относится косвенно, но тайные культисты часто используют его для маскировки своей религиозности.


3.4 Контролируй нетерпимость ко «злу».
Нетерпимость ко злу естественное свойство человека. Но так, как и сам человек и наш мир в целом весьма несовершенны, то нетерпимость нужно контролировать и направлять. При этом полный отказ от нетерпимости считаю ошибочным и вредным. Если существует проблема, шерховатость, которую быстро исправить нельзя, а само «зло» маленькое и не проявляет себя, то не нужно тратить время. Лучше запишите свои соображения в специальное место. Если в будущем вам или вашим коллегам придется снова столкнуться с «обителью зла», то она будет уже подписана и возможно даже каталогизирована, что позволит сократить затраты на идентификацию и поиск проблемы. Если зло большое, то об этом нужно в первую очередь уведомить руководство, для оперативной корректировки планов. 


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


3.5 Холодная и горячая голова.
Для понимания этого принципа необходимо предварительно разделить работу программиста на два типа:
   - Изложение своих мыслей (написание кода, формальное описание мыслей)
   - Творческий поиск (генерация мыслей)
Это принципиально разные виды умственной деятельности, с разными требованиями к состоянию человека.
При написании кода старайтесь всегда соблюдать трезвость сознания. Любые состояния измененного сознания как правило приводят к отвратительному качеству кода. При этом нет разницы, чем именно замутнено ваше сознание: воодушевление и азарт не менее вредны чем уныние и гнев. Написание именно кода – т.е. изложение ваших мыслей на языке программирования должно производиться на трезвую голову. В то же время творческий поиск и мозговой штурм редко бывают удачными в холодной голове. Поэтому важно научиться применять разные состояния для разного типа умственной работы.


3.6 Проверяй свою работу
Нельзя недооценивать способности человека совершать невероятно нелепые ошибки. ВСЕГДА проверяйте свою работу. Даже если вы просто переименовали переменную или поставили разметку. При этом желательно проводить трёхуровневую проверку:
- Прочтение измененных функций. Позволит проверить внутреннюю связность логики.
- Сравнение с предыдущей версией. Это позволит выявить очевидные ошибки в логике и опечатки.
- Тестирование. Это позволит выявить менее очевидные ошибки и опечатки. Если тестирование будет выполняться другим человеком или машиной, результаты будут еще лучше.


4 Определение хорошей программы
Целью курса было объявлено повышение качества программ. Но понятие «хорошая программа» очень неопределенное. Поэтому прежде чем рассматривать методику достижения качества, необходимо определиться с тем, что такое качество, его определение и методики оценок.


4.1 Ключевые признаки хорошей программы
- Работоспособность. Программа должна выполнять свою работу, в идеале хорошо, но минимум на достаточном для получения результатов уровне. Таких программ очень много. Думаю, что каждый без труда назовет несколько таких.
- Гибкость. Программа должна быть готова к модификациям. Подобное требование, по логике вещей, является обязательным, но практика показывает, что программ, соответствующих данному критерию меньшинство.
- Сопровождаемость. Программа должна быть легкой в сопровождении – легкой для понимания, обеспечивающей простой доступ к различным узлам и блокам. С этой частью определения проблемы возникают чаще. Довольно мало программ, которые имеют хорошую документацию, а также внятный и читаемый с первого раза код.
Итак, мы определили три критерия по которым можно определить хорошую программу, при этом легко заметить, что первый признак лишь косвенно зависит от остальных, тогда как второй и третий имеют сильную взаимозависимость. Но так или иначе мы имеем достаточно четкое определение хорошей программы. Следовательно, анализируя соответствие этим признакам, мы легко можем определить качество не только программы в целом, но и отдельных её компонент вплоть до функций и фрагментов кода.
Вооружившись таким простым и мощным средством познания вы можете на досуге провести оценку сопровождаемых вами программ или их фрагментов. Метод универсальный, и позволяет хорошо структурировать и определить негативные ощущения от работы с плохими программами. Таким образом, ваш обычных гнев мы можем обратить в гнев благородный. Конечно гнев это само по себе плохо, но нужно с чего-то начинать.


4.2 Методика оценки качества
В этом разделе мы рассмотрим общую логику оценки качества программы по трём ключевым признакам.
 

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

Гибкость.
Свойство не всегда очевидное и далеко не всегда нужное. Основная проблема заключается в том, что знание о необходимости этого свойства приходит внезапно. Следовательно, если нет явных требований по гибкости и модульности, то нет никакой нужды проектировать программу на все случаи жизни. Плата за универсальность, обычно берется ценой и качеством работы программы. Любая нишевая программа по определению лишена гибкости. Поэтому, чтобы исключить возможные спекуляции, определимся с необходимыми требованиями к гибкости.
Программа должна быть готовой к существенным изменениям в пределах своей сферы применения. Никто не упрекнет разработчика, за то, что его специализированная медицинская программа для гинекологической клиники не подходит для ветеринарной службы племенного завода крупного рогатого скота. Но изменение некоторых процессов или добавление смежных направлений деятельности, не должно застать разработчика врасплох. Из последних примеров вспоминается аварийных запуск с космодрома Восточный в конце 2017 года, когда была использована негибкая программа в непривычных для неё условиях и без привычного контролёра который за ней присматривал и корректировал ошибки.
 

Сопровождаемость.
Предлагаю совершить мысленный эксперимент и обратиться по памяти к недавнему коду. Его можно просто прочитать или нужно расшифровывать, вооружившись лупой, блокнотом и двумя высшими образованиями? Конечно, человек умеющий читать и обладающий известной степенью усидчивости разберется в любом запутанном алгоритме, но потери времени будут неизбежны. Вспомните сколько времени обычно уходит на перечитывание программы и поиск подводных камней в запутанном и плохо структурированном коде. А ведь от того насколько быстро можно прочитать и понять текст напрямую зависит стоимость поддержки и объем (в том числе вашей) оперативной работы в ущерб проектной.

Несмотря на то, что по этому критерию отсеивается большая часть некачественных программ, у этого признака есть огромный потенциал. Это наиболее понятный и доступный всем практикующим программистам метод оценки. Исключения в моей практике встречались, но они подтверждали правило - это были случайные люди в профессии. Подавляющее же большинство разработчиков, даже производящих некачественный код, могут с различной степенью точности, но определить степень сопровождаемости программы. 
При анализе важно не забывать о психологии. Легче всего оценивать чужой код – вы не знаете контекста, хода мыслей и характера другого программиста – вы видите просто код, все ошибки и огрехи в нем. Свой код анализировать намного сложнее. Для облегчения этой задачи есть несколько приёмов:
- Изначально писать так, словно вы рассказываете другому программисту, что, как и зачем вы делаете.
- Если позволяет время, делать паузы между окончанием написания кода и анализом. Как правило, код написанный вчера, воспринимается иначе чем свежеиспеченный.

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

5 Заключение

В рамках данной лекции были сформулированы базовые проблемы, а также их генезис. Были определены ключевые признаки хорошей программы и базовые принципы оценки по этим критериям. Настоятельно рекомендую перед чтением следующей лекции провести некоторую самостоятельную работу и потренироваться в оценке доступных вам программ или их фрагментов. Понимание методики оценки (не данного текста) является необходимым условием для усвоения последующего материала.

Следующая лекция: //infostart.ru/public/835693

111

См. также

Комментарии
Сортировка: Древо
1. Anatolii Korol 10.05.18 11:58 Сейчас в теме
Отлично написано, очень напоминает "Совершенный код" Макконелла.
CyberCerber; Adam12345678; gubanoff; +3 Ответить
2. Артано 606 10.05.18 12:10 Сейчас в теме
(1)
Совершенный код" Макконелла
не читал, не знаю насколько верно сравнение. А вот "Чистый код" Мартина читал после публикации первой версии этого курса. Там много похожего было по практике программирования. Пути и мысленные размышления что привели к тем или иным решениям разные конечно, а вот выводы сходные. Впрочем неудивительно, если решать сходные задачи, то и результаты будут сходные. Но можете убедиться, что здесь присутствует оригинальная мысль, хотя бы по стилю изложение. Конечно сложно сравнивать компактный конспект к лекции и полноценную книгу, в публикации старался довести и ход мыслей, а не только выводы.
3. zqzq 17 11.05.18 09:34 Сейчас в теме
(2)
Совершенный код" Макконелла не читал
А стоило бы, там это (большая часть) и многое другое подробно изложено. И простым языком.

"Чистый код" Мартина
меньше Макконела понравился, сильнее на ООП завязан и более субъективная что ли, меньше фундаментальных вопросов затронуто.
4. Артано 606 11.05.18 10:25 Сейчас в теме
(3) Спасибо за комментарий, но к сожалению он вызвал больше вопросов чем дал ответов.

1. Я конечно рад что у Макконелла в целой книге рассказано больше чем у меня во введении, но всё же хотелось бы видеть указания на ключевые сходства и отличия. Причем не столько для себя сколько для читателей. Полагаю читатели оценили бы ваш труд, если бы вы сделали сравнительное описание. Готов даже оказать дополнительную информационную поддержку в этом деле. Информация об еще одном источнике ценной информации не может быть бесполезной.

Если конечно ваш комментарий не написан в порыве чувств. Уже сталкивался с подобными комментариями к первой публикации. Например говоря о принципе "Холодной и горячей головы" - сослались на Мартина (автора Чистого кода), что он де об этом уже писал, но когда у меня дошли руки его прочитать, то выяснилось что не совсем так. Да конечно, как о явлении он писал и свой практический опыт изложил. Но он и не пытался анализировать почему так происходит и для чего нужна "горячая голова", он просто отбросил это состояние сознания как безусловно вредное.

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

Макконела обязательно прочитаю. Но уже после, чтобы не смешивать работы и мысли, уже внес его в планируемые к прочтению книги.
5. starik-2005 1406 11.05.18 11:34 Сейчас в теме
Хорошо написано. Среди комментов сразу выявился адепт "тайного знания", "культа карго" и всего прочего )))

Макконнелл хорошо пишет, грамотно, много приводит ссылок на литературу и исследовательские работы - в этом огромный плюс заграничных книг, в отличие от отечественных, во многих из которых "адепты тайного знания" учат чему-то недалеких молокососов, ссылаясь только на себя любимого и якобы "оригинальное исследование", списанное с карнег и прочих дейлов (не про Вас, автор, но мало ли - мы же не читали еще продолжения). Если приводить конкретику, то Макконнелл описывает подходы к разработке (через тестирование, парное программирование, инспекции кода, прочие методологические механизмы поиска ошибок и, следовательно, повышения качества продукта, определяя, например, парное программирование и инспекцию кода, как лидеров по первоначальному поиску ошибок в коде и минимально потраченному времени, что закрепилось в итоге в CMM), механизмы оптимизации (табличная оптимизация, хеширование, деревья - алгоритмическая составляющая, описанная словами, а не мат.языком). В каждом утверждении он ссылается на опыт крупнейших корпораций (например, замена тестирования инспекцией кода в корпорации Боинг увеличила производительность труда в 8(!) раз). Ну и т.д. и т.п.

Отсюда как бы совет: будьте собой, но не пренебрегайте лучшими практиками. И если что-то утверждаете, приведите пример или ссылку на исследование.
Артано; +1 Ответить
6. Артано 606 11.05.18 13:09 Сейчас в теме
(5) Спасибо за ёмкое описание работ Макконелла. По крайней мере понял теперь что мог иметь ввиду предыдущий комментатор. По этому поводу могу сказать, что с ним пересекаться буду, но не слишком часто.
Во-первых, нет доступа к настолько масштабным экспериментам
Во-вторых он судя по всему работает с внешними источниками, я с собственным опытом.
В-третьих, как можно заметить из предисловия и "захода издалека" к прикладным проблемам, суть исследования моего строилась на поиске причин проблем. Таким образом я не просто говорю что такое хорошо и что такое плохо, а выполняю анализ причин, почему плохо происходит. Т..е начинаю с базиса, а не с внешних признаков.
Ну и в четвертых, есть у меня некоторая психологическая травма от бездумного применения западных "бест практик" на живых русских людях. Возможно это тоже проявление еще неведомого науке культа, который еще ждёт своего исследователя, но фактор это существенно повлиял на решение делать своё исследование, а не верить на слово забугорным спецам.

За совет спасибо, стараюсь, но с оглядкой. Полагаю из текста выше это стало понятнее =)
7. acsent 1071 11.05.18 14:58 Сейчас в теме
А есть ли рабочие методики: "КАК" достичь всего этого. А то это все больше похоже на фразу: Пишите код хорошо
8. Артано 606 11.05.18 15:12 Сейчас в теме
(7) Если речь про мануалы типа "how to", то наверное не существует готового и стопроцентного рецепта. Иначе бы и не было это публикации и многих других на эту тему.
Как сказано в предисловии, данный курс рассматривает причины проблем. В следующих лекциях будут предложены "правильные" практики решения проблем, но опять же в тех пределах которые удалось охватить. Как уже отвечал выше, не имея доступа к масштабной экспериментальной базе, сосредоточился на теоретической подготовке. Собственно, это второе (первое для широкой публики) издание курса
9. starik-2005 1406 11.05.18 17:07 Сейчас в теме
(7) "всего этого" - это чего конкретно? Повысить качество разработки? Автор пока говорит так: "проверяй свою работу", ну и советует прогнать создаваемую программу через критерии работоспособности, гибкости и сопровождаемости. Если программа работает, она "гибкая" и "сопровождаемая" (т.е. кто угодно может ее развивать), то качество разработки - высокое.

Но, с другой стороны, всегда есть другие критерии. Например, производительность. Если программа работает, сопровождаема и "гибка", но при этом не удовлетворяет критериям производительности ключевых операций, то она недостаточно качественная (на мой взгляд) и ее нужно допилить. При этом может оказаться, что любой допил будет снижать производительность или не сможет повысить ее до необходимого уровня (например, применена попытка перебрать все варианты при раскладке/разрезке/упаковке, а это факториал от количества вариантов в пределе, при этом система просто ищет луший из всех вообще - тут никакой подход не сможет помочь, ибо при сотне вариантов время операции будет уходить в бесконечность). Как бы мораль: если не знаешь алгоритма, можешь и не решить проблему, при том создав сопровождаемую, "гибкую" и работающую на 10 тестовых элементах программу.
10. Артано 606 11.05.18 17:30 Сейчас в теме
(9)
Но, с другой стороны, всегда есть другие критерии. Например, производительность
Работоспособность это и есть внешнее качество программы - насколько она соответствует стоящим перед ней задачам, как она выглядит снаружи, как взаимодействует с железом. Недостаточно развернул определение работоспособности. Спасибо.

Про зависимость свойств между собой писал отдельно. Программа может хорошо выполнять свою работу, но быть абсолютно негибкой и с трудом сопровождаемой . В остальном же согласен. Именно это и хотел сказать. Мы формулируем для себя простые критерии оценки, а далее в зависимости от требования момента и собственных способностей проводим эту самую оценку.
11. Артано 606 11.05.18 17:39 Сейчас в теме
(9)
например, применена попытка перебрать все варианты при раскладке/разрезке/упаковке, а это факториал от количества вариантов в пределе, при этом система просто ищет лучший из всех вообще - тут никакой подход не сможет помочь, ибо при сотне вариантов время операции будет уходить в бесконечность


Сдаётся мне, что есть способы обойтись без полного перебора. По краней мере ест ьсмутные воспоминания когда математически какие-то площади и объемы делили и резали на нужные куски. Но это надо Ильдаровича призывать и создавать отдельный топик =)
12. starik-2005 1406 11.05.18 18:13 Сейчас в теме
(11) необязательно. Фактически существует несколько алгоритмов, которые в той или иной степени способствуют решению данного класса задач с некоторыми допущениями. Есть простой алгоритм "в лоб" - жадный, с помощью которого у того же Ильдаровича реализован пример 3д-упаковки в запросе. Я в своей статье сформулировал данный принцип просто: "бери больше - кидай дальше". Алгоритм далеко на оптимальный, но есть возможность через дополнительные перестановки улучшить показатели. Есть различные варианты генетического алгоритма и алгоритма "отжига", при котором используется свойство атомов кристаллической решетки занимать энергетически самые выгодные позиции. Все эти алгоритмы эффективно позволяют найти локальные минимумы и из них - глобальный, но, конечно же, не всегда. Дальше существуют оптимизации с динамическим программированием, которые ищут максимально лучшие варианты, но при этом используют много памяти.

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

Я считаю, что программист должен знать алгоритмы работы с данными в принципе. Любая программа - это преобразование аргументов функции в ее результат через присваивание (в частности присваивание вычисленного выражения) и ветвление. Все остальное - это детали (например, цикл - это ветвление по признаку окончания цикла, но важно понимать, что цикл можно организовать и с помощью рекурсии, а при обходе дерева такой подход - единственно достойный внимания). В итоге реальный способ повышения качества программ - это прокачка скилов в области обработки данных, когда программист не просто умеет присваивать и "ветвить", но и понимает, в каком случае чего и куда присваивать, а где производить ветвление. И если программист не знает, что в упорядоченном списке можно найти элемент за O(log2N) то это - плохой программист.
13. Артано 606 11.05.18 18:53 Сейчас в теме
(12)
Любая программа - это преобразование аргументов функции в ее результат через присваивание (в частности присваивание вычисленного выражения) и ветвление. Все остальное - это детали (например, цикл - это ветвление по признаку окончания цикла, но важно понимать, что цикл можно организовать и с помощью рекурсии, а при обходе дерева такой подход - единственно достойный внимания).


Об это подробнее будет во второй лекции.
14. CSiER 19 12.05.18 07:48 Сейчас в теме
(12)
Я считаю, что программист должен знать алгоритмы работы с данными в принципе.

Нельзя не согласиться. Можно добавить ещё знание ходовых структур данных (массивы, связанные списки, графы и т.д.) и особенности их применения.
(12)
И если программист не знает, что в упорядоченном списке можно найти элемент за O(log2N) то это - плохой программист.

Судя по Вашим прошлым комментариям здесь опечатка (когда имеется ввиду массив и классический binary search).
15. starik-2005 1406 12.05.18 10:10 Сейчас в теме
(14)
имеется ввиду
Здесь имеется ввиду любой упорядоченный список. В нем найти элемент гарантировано можно за Log2 N итераций, где N - количество элементов в этом списке. Что имеете ввиду Вы - не ясно.
16. CSiER 19 12.05.18 17:03 Сейчас в теме
(15) Я имею ввиду то, что описанную Вами задачу нельзя решить с указанной сложностью. Если бы в Вашем условии было написано "массив" вместо "списка", тогда задача сводится к простому binary search. Просьба поправить меня, если не прав, приведя описание алгоритма с указанной оценкой сложности для следующего примера: найти заданный элемент в односвязном упорядоченном по возрастанию значений элементов списке мощностью N (single linked list), имея ссылку на его первый элемент (head node). Более детально: имеем односвязный список 1->2->3->...->100 и ссылку на его первый элемент (на 1->) - нужно найти элемент со значением 80 за log2 N (log2 100) итераций.
17. Артано 606 12.05.18 17:23 Сейчас в теме
(16) Навскидку из примитивного - метод половинного деления -вполне уложится в этот норматив
18. CSiER 19 12.05.18 18:03 Сейчас в теме
19. Артано 606 12.05.18 19:38 Сейчас в теме
(18) То что ссылка была я заметил, только удивился зачем использовать англоязычный термин при наличии русского аналога. Вопрос то вы задавали другой, что двоичный поиск не справится с задачей в рамках норматива log2 N, тогда как даже небольшой умственный эксперимент показывает обратное.
Или мы вас оба неправильно поняли или вы неправильно поняли условие задачи
21. CSiER 19 13.05.18 09:03 Сейчас в теме
(19) в том то и дело, что не справится - прочитайте внимательно:
Просьба поправить меня, если не прав, приведя описание алгоритма с указанной оценкой сложности для следующего примера: найти заданный элемент в односвязном упорядоченном по возрастанию значений элементов списке мощностью N (single linked list), имея ссылку на его первый элемент (head node)
- двоичный поиск можно применять только при наличии возможности получения значения элемента за О(1) - поэтому и попросил автора коммента уточнить - не опечатался ли он.
Ссылки на англоязычную страницу вики привожу потому, что там все описано детальнее, к тому же есть ссылка на аналогичную статью на русском (в самой вики слева блок ссылок на других языках).
22. Артано 606 13.05.18 09:32 Сейчас в теме
(21)
- двоичный поиск можно применять только при наличии возможности получения значения элемента за О(1) - поэтому и попросил автора коммента уточнить - не опечатался ли он.
Ссылки на англоязычную страницу вики привожу потому, что там все описано детальнее, к тому же есть ссылка на аналогичную статью на русском (в самой вики слева блок ссылок на других языках).


Теперь понял, что ты ввиду имел. Для односвязного по определению двоичный поиск не будет работать. Но опять же вопрос - где в 1с есть односвязные списки в которых нужно искать значение? Мы же всё таки про 1С говорим. Нужно отделать мух от котлет, и не заниматься буквоедством, иначе за отдельными фактами не увидим суть.

Вообще тема алгоритмов очень обширная и было бы интересно и полезно провести практическую работу по адаптации различных алгоритмов (того же поиска) к прикладной специфике 1с. Есть желание взяться?
24. CSiER 19 13.05.18 10:07 Сейчас в теме
(22)
Для односвязного по определению двоичный поиск не будет работать
- поэтому и уточнил что автор коммента имеет ввиду под списком - оказалось список (см. "Возможности доступа").

(22)
Но опять же вопрос - где в 1с есть односвязные списки в которых нужно искать значение? Мы же всё таки про 1С говорим.
- думаю о "курсе по теории и практике программирования" - и конечно в контексте 1С - ведь мы на Инфостарте :)

(22)
Нужно отделать мух от котлет, и не заниматься буквоедством, иначе за отдельными фактами не увидим суть.
- полностью согласен, при этом термины должны трактоваться однозначно и уточняться при необходимости.

(22)
Есть желание взяться?
- идея интересная, но на текущий момент выделить на это время не смогу.
25. starik-2005 1406 13.05.18 14:05 Сейчас в теме
(24)
- поэтому и уточнил что автор коммента имеет ввиду под списком - оказалось список (см. "Возможности доступа").
Даже по приведенной ссылке есть следующее:
Возможности доступа — некоторые списки в зависимости от реализации могут обеспечивать программиста селекторами для доступа непосредственно к заданному по номеру элементу.
Если у списка есть селектор и он упорядочен, то поиск в нем нужного значения можно произвести с приведенным количеством сравнений.

(23) А по поводу "адаптации" алгоритмов к 1С, то это уже сделано неоднократно. От жадных алгоритмов до нейронных сетей. Достаточно поиска по сайту (хотя, конечно, куда проще найти нужную статью в гугле на этом же сайте, чем воспользоваться поиском внутри, ибо о релевантности создатели ресурса знают куда меньше).
26. CSiER 19 13.05.18 14:25 Сейчас в теме
(25)
Даже по приведенной ссылке есть следующее:
- да, выше на это и обратил внимание (написал см. Возможности доступа). Там же написано "Термином список также называется несколько конкретных структур данных, применяющихся при реализации абстрактных списков, особенно связных списков." - аналогичная ассоциация у меня с института, в профильной литературе тоже под списками как правило понимаются именно связанные списки.
(25)
Если у списка есть селектор
- то он обычно называется массивом.
20. starik-2005 1406 12.05.18 21:32 Сейчас в теме
(16) все зависит от того, что называть списком. И зачем спорить с утверждением и тут же его приводить? Странным не находите?

(17) Ну вот, хранители "тайного знания" атакуют, ибо "список" для них - это элемент с одним или двумя указателями (вперед/назад). При том слово "список" вполне может относиться к массиву, таблице значений, списку значений и т.д.. т.е. к тому, что можно получить по индексу. А в списке значений даже слово "список" есть, что хранителей "тайных знаний" все-равно не наводит ни на какую мысль, ибо с их точки зрения список значений - не "список" )))
23. CSiER 19 13.05.18 09:43 Сейчас в теме
(20)
все зависит от того, что называть списком.
- да, это то, о чем я писал в первом комменте. Если для Вас список - "CписокЗначений" в контексте 1С, тогда вопросов нет.
27. webester 28 14.05.18 05:54 Сейчас в теме
Заинтриговали. Где подписаться, что бы читать дальше?
28. Артано 606 14.05.18 06:02 Сейчас в теме
(27) Не уверен что это единственный способ, но можно добавить в друзья. В данном случае приходят уведомления новых публикациях.
29. Артано 606 18.05.18 03:07 Сейчас в теме
******Внимание******

Вторая лекция будет опубликована в субботу. Форматирование текста для сайта занимает довольно много времени, поэтому отложил дату публикации
30. herfis 257 24.05.18 15:09 Сейчас в теме
Написано все правильно и даже неплохо. Все будут согласно кивать головами и хлопать по плечу.
Но полезность для кого бы то ни было - весьма сомнительна, как по мне. А уж называть "учебным курсом" - излишне самонадеянно.
Это ведь не для опытных прогов. Им это не нужно, они и так это знают, впитав "потом и кровью" на "продакшене".
Значит, для новичков? Но новичкам нужны не общие фразы вида "не делай плохо, делай хорошо". Им нужно как можно больше живых примеров и конкретных руководств к действию. Прочитать того же Макконелла будет гораздо полезнее, как по мне.
31. Артано 606 24.05.18 15:47 Сейчас в теме
(30)
Написано все правильно и даже неплохо. Все будут согласно кивать головами и хлопать по плечу.

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

А уж называть "учебным курсом" - излишне самонадеянно.
- называть что? Введение это не весь курс, это именно введение. Определение терминов и базовых принципов.

Это ведь не для опытных прогов. Им это не нужно, они и так это знают, впитав "потом и кровью" на "продакшене".

Не согласен. Опытным этот курс не менее важен чем для новичков. Также не согласен, что опыт можно измерить годами стажа или литрами пролитых пота и крови. Позволю здесь автоцитату: "Опыт не равен стажу. Это не годы жизни, не пережитые испытания, а то как человек это понял и осмыслил. Стаж получают все, опыт - те кто приложил к этому усилия". Так и в нашем деле, можно выработать условные рефлексы по типу "так делать нельзя, потому что я так сделал на продакшене и было очень плохо", но чем мы тогда будем отличаться от собаки?

Значит, для новичков? Но новичкам нужны не общие фразы вида "не делай плохо, делай хорошо". Им нужно как можно больше живых примеров и конкретных руководств к действию.


В комментариях ко второй лекции уже отвечал на подобный комментарий. Хватает практики, на мой взгляд, даже слишком много голой практики. Также в предисловии курса уже дан ответ на это возражение. Заранее!
32. herfis 257 24.05.18 15:59 Сейчас в теме
(31)
Также не согласен, что опыт можно измерить годами стажа или литрами пролитых пота и крови.

Измерить нельзя. Но корреляция всегда прямая.
Тем, кому стаж не дает опыта, никакие курсы уже не помогут. Такое мое мнение. Это случайные люди в профессии.
33. Артано 606 24.05.18 16:14 Сейчас в теме
(32)
Измерить нельзя. Но корреляция всегда прямая.
Тем, кому стаж не дает опыта, никакие курсы уже не помогут. Такое мое мнение. Это случайные люди в профессии.


Вот так взял и большую часть трудящейся братии назвал случайными людьми. Я бы обиделся. Не за себя, так за товарищей. Но в прошлом. Сейчас просто объясню.
Нет ничего необычного в ситуации когда длительность стажа, не соответствует объему опыта. Именно по этой причине, существует деление на категории специалистов, на наставников и учеников, на ведущих и рядовых.
Как и в военном деле. Пусть рядовой не знаком с теорией тактики и смутно представляет себе стратегию, но без рядовых бойцов никакое дело не провернуть. Можно конечно изобретать планы и теории и общаться узким кругом "неслучайных" людей, но вся тяжесть практической реализации ляжет на рядовой состав.
Также важно понимать, что рост эффективности в системе: начальник - гений, подчиненные - бараны, быстро упирается в возможности рядового состава. В такой ситуации даже не слишком существенное поднятие уровня подготовки рядового состава, в сумме серьезно повысит возможности всего подразделения. Тогда как поднятие уровня подготовки начальника даже в разы всегда имеет ограничение практической реализации этого уровня.
34. herfis 257 24.05.18 16:45 Сейчас в теме
(33)
Нет ничего необычного в ситуации когда длительность стажа, не соответствует объему опыта.

Увы, соглашусь.
Но мы про программирование.
А для программиста эта ситуация если не необычная, то ненормальная точно.
Слишком динамичная отрасль и слишком широкое поле знаний. Программист обязан уметь в эффективное самообучение.
А при наличии нужной информации в свободных источниках, курсы - слишком неэффективная форма обучения.
Слишком часто курсы выглядят как полезное времяпровождение для людей, которые книжек не читали, на котором они слушают "откровения" людей, которые их таки осилили. Польза такого времяпровождения для первых - весьма сомнительна. Польза для вторых - несомненна, если курсы платные.
35. Артано 606 24.05.18 16:55 Сейчас в теме
(34)
Польза для вторых - несомненна, если курсы платные.

Блин, а так можно было, да? Хотя так и есть, за эти лекции я свои деньги уже получил, и буду получать. Потому что есть в них и объективная необходимость и несомненная польза, а во всем этом времяпровождении даже экономический смысл в виде повышения производительности труда при сравнительно небольших затратах.

А вообще, подобное восприятие мира - завышенные требования к окружающим, суть когнитивное искажение, смысл которого сводится к ожиданию от окружающих таких же способностей как от себя самого. Другими словами - ошибочное причисление себя к среднестатистическому уровню, тогда как фактический уровень много выше. Кстати есть и обратный пример искажения известный как эффект Данннига-Крюгера. Так что советую перечитать про абстракции и культы.
36. starik-2005 1406 24.05.18 18:16 Сейчас в теме
(33)
Также важно понимать, что рост эффективности в системе: начальник - гений, подчиненные - бараны, быстро упирается в возможности рядового состава.
В западной практике сотрудник растет до того момента, до которого позволяет его уровень компетенции. Именно из-за этого часто на руководящих должностях в больших компаниях сотрудники уже доросли до своего предела и с трудом справляются со своей текущей работой, иначе они бы продолжили расти.

По поводу профессиональной карьеры, то всегда есть два варианта развития: вертикальный и горизонтальный рост. При вертикальном росте происходит "прокачивание" навыков работы с другими сотрудниками, умение ставить задачу, умение следить за ее выполнением, умение писать отчеты, которые понятны следующему уровню руководителей, умение, наконец, создавать стоимость. При горизонтальном росте сотрудник растет за счет повышения уровня компетенции в прикладной специфике: джуниор, мидл, синьор, тимлид, архитектор, технический директор... Всегда есть возможность из программиста уйти в РП, если программировать не особо получается, а вот из РП в программиста уйти куда сложнее...
38. Артано 606 25.05.18 12:46 Сейчас в теме
(36)
В западной практике сотрудник растет до того момента, до которого позволяет его уровень компетенции. Именно из-за этого часто на руководящих должностях в больших компаниях сотрудники уже доросли до своего предела и с трудом справляются со своей текущей работой, иначе они бы продолжили расти.

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

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


Быть хорошим разработчиком это не "руками водить" тут думать надо =)
39. starik-2005 1406 25.05.18 13:37 Сейчас в теме
(38)
Да, буквально недавно мне коллеги рассказывали про такой парадокс.
А это не парадокс, а суть мировосприятия западной цивилизации. Т.е. если достижения получены, то они должны остаться. При этом понижение в должности в современном формате скорее всего приведет к тому, что вполне полезный сотрудник уйдет, на его место придется повысить кого-то, кто пока еще недостаточно тянет, а не место того взять или повысить еще кого-то - трудная задача выбора, ибо в любом случае теряется текущая производительность организации, но при замене сотрудника она теряется сильнее, а долгосрочная перспектива в западной модели рассматривается с трудом...

Япония, например, решает проблему просто -- человек всю жизнь растет в должности, а нехватка компетенции восполняется потоком снизу новых идей и людей, которых не тормозят, а доводят до того уровня, где будет принято решение. Именно по-этому японская модель придумала такие штуки, как кан-бан, и это придумали не руководители, а обычные работяги (у них там есть "кружки качества", в которых состоят три-пять сотрудников в самом низу, и они после ВУЗов и прочих техникумов удаль молодецкую тратят на рацио, которое руководство всегда старается применить для пользы дела, а не заворачивает со словами "молодо-зелено", как это делают у нас).
37. Арчибальд 2702 24.05.18 18:31 Сейчас в теме
Хороший стиль, отсутствуют ляпы. Даже ошибок пунктуации (почти) нет. :)
Есть позитивное отличие от всяческих Макконнелов, Мартинов и даже Брукса. А именно: западные авторы вынужденно "заточены" на дебиловатых читателей. Им приходится многократно повторять одно и то же, чтобы у читателя, которого думать в школе не учили, хоть что-то в голове застряло. Это "одно и то же" в большинстве случаев оказывается правильным, но в итоге - замшелый догматизм, порождаемый некритичным восприятием (и сопоставлением с действительностью) текста.
К счастью, автору пока еще позволено адресоваться к людям, нормально мыслящим. Пока ЕГЭ окончательно таких людей не вытравил.
40. Артано 606 15.06.18 09:22 Сейчас в теме
Прошу прощения у всех кого заставил ждать новой лекции. Успокою. Лекция будет. После публикации первых двух и чтения третьей лекции для общественности получил настолько богатую обратную связь, что несколько увлекся.

Впрочем, от этого была и польза. В ходе обсуждения было поднято столько вопросов, что раскрыть их в комментариях было невозможно. Поэтому, по совету коллег, принял решение собрать материалы по контексту в котором создавался учебный курс. Собранный материал станет основой для доклада на Infostart Event. Данный доклад станет ответом на многочисленные вопросы зачем этот учебный курс, какие задачи он выполняет и почему он именно такой. На данный момент материалы собраны, доклад отправлен на голосование и я могу вновь вернуться к переработке лекций в текстовый формат.
41. Adept 16.07.18 17:19 Сейчас в теме
Автор, почему не применяешь свои советы к стилю написания статьи?
Природа этого явления, очень древняя, возможно одна из самых древних, уходящая корнями ко времени первых орудий труда. Использование орудий труда являлось важнейшим эволюционным фактором в истории человека, и примитивные попытки осознания важности этого события приводили к подмене причины и следствия.


Это точно? Это мнение специалиста по данной теме по эволюционной биологии, генетике, психологи и т.д? Есть ли другие мнения у специалистов по этой теме ? Сколько раз воззрения на эту область поменялись за последние 100 лет? Зачем читающему эту статью это знать?
42. Артано 606 16.07.18 17:45 Сейчас в теме
(41)
Зачем читающему эту статью это знать?
Чтобы каждая более-менее разумная обезьяна понимала, откуда у нее эти тараканы в голове, и что это не лечится, но с этим можно жить.
43. Adept 16.07.18 21:20 Сейчас в теме
(42) но это ведь не точно, да ? :)
44. Артано 606 17.07.18 03:19 Сейчас в теме
(43) Если будет время и желание, то поищу ссылки на соответствующие антропологические исследования. Ну а экспериментально легко подтверждается в ходе наблюдения за развитием детенышей и их становлением в полноценных людей.
45. starik-2005 1406 17.07.18 11:47 Сейчас в теме
(44) большинство состояний лечится.
46. Артано 606 17.07.18 12:25 Сейчас в теме
(45) Я бы так не сказал. Можно научиться жить с чем-то. Но это как неизлечимая болезнь, с периодами ремиссий и сезонных обострений. Так называемый человек, своим поведением от обезьяны, только за счет многолетнего нахождения в социуме. Помести человека в дикую среду, и большая часть людей деградирует за удивительно короткий срок, меньшая - за больший. Но уже следующее поколение будет диким.
Также, у человека есть ряд особенностей по сравнению с братьями-обезьянами, которые с одной стороны дали в своё время однозначное эволюционное преимущество, с другой, создают проблемы на высоких этапах развития, не являясь уже однозначным благом:
1. Упорство в достижении непосредственно видимой цели. Когда-то оно было необходимо для методичного создания первых каменных инструментов - та еще работа. В наше время, например, проявляется бюрократизме, педантичности, участвует в формировании "синдрома вахтёра".
2. Упорство во мнении. Единожды сформированное "правильное" мнение, особенно если это мнение пришло готовым от старших по иерархии в группе, очень сложно изменить. Отсюда предрассудки, зашоренность взглядов, фанатизм и др.
3. Гипертрофированная социальность. Про социальные потребности и проблемы их сублимации особо не буду расписывать. Отмечу один важный фактор - интуитивное воспроизведение принятых в сообществе правил поведения. Фактор хороший, если правила в сообществе хороши, но в комментах к третьей статье приводил наглядный пример негативной практики.

Разумеется, человек осознающий себя и обладающий проистекающей из этого осознания волей, способен преодолевать свои инстинкты. Но преодоление инстинктов есть результат постоянной внутренней борьбы врожденных свойств с приобретенными. И это самое "большинство состояний лечится", есть ремиссия вызванная интенсивной терапией, но не полное излечение.
47. starik-2005 1406 17.07.18 14:28 Сейчас в теме
(46)
Разумеется, человек осознающий себя и обладающий проистекающей из этого осознания волей, способен преодолевать свои инстинкты. Но преодоление инстинктов есть результат постоянной внутренней борьбы врожденных свойств с приобретенными. И это самое "большинство состояний лечится", есть ремиссия вызванная интенсивной терапией, но не полное излечение.
Ну если говорить о клинических случаях, то психические именно заболевания - да, с ними непросто что-то сделать, но и это лечится при достаточной мотивации со стороны врача и пациента. А вот с психологическими проблемами все проще, но многие ли из нас обращаются к психологу при трудностях? Вот, например, недавно читал про одного из разработчиков языка "котлин" из JetBrains - он рассуждал на тему психоанализа, что ему психолог очень помогал часто и он даже портал для психологов сделал. А Андрей Курпатов в книге про счастье пишет, что на постсоветском пространстве обращаться за профессиональной помощью не принято и типа "сам должен смочь, преодолеть, побороть" и т.д.

А по поводу инстинктов, то преодолевая их и не "заземляясь", получаешь множественные мышечные блокировки, от которых тоже избавиться непросто. Тут уж спорт, движение, напряжение и прочая физическая активность помогают. Я, например, на прошлой неделе в день по часу-полтора на велосипеде ездил не останавливаясь, вчера другу помогал грушу 50-килограммовую дотащить до его дома (до электрички, потом от электрички на мост, с моста, по мостику через ручей и с прочими препятствиями). Так что деятельность физическая должна идти вместе с нагрузкой умственной, и непросто тем, у кого с физической нагрузкой трудности, в программировании...
Артано; Adam12345678; +2 Ответить
48. user941268 20.07.18 17:50 Сейчас в теме
Даже если Вы опишите прописные истины типа "Пишите код хорошо". С удовольствием прочитаю весь курс. Написано легко. Ожидаю в курсе не столько ссылки на авторитетов, а примеры из личного опыта и рабочей практики, возможно с курьезами и легким юмором.
49. Касаткин 24.07.18 15:28 Сейчас в теме
Мне кажется, или комментарии интереснее статьи?))
50. Артано 606 24.07.18 15:34 Сейчас в теме
(49) Так это же хорошо. Комментарии обогащают и дополняют материал. Прочтение статьи без прочтения комментариев, сделает впечатление неполным.
Оставьте свое сообщение