Обычные пользователи редко задумываются над тем, какая работа предшествует выходу готового приложения. Между тем его разработка зачастую длится не один год. И в этом процессе задействована целая команда программистов, каждый из которых вносит свой вклад в создание инновационного продукта. По мнению самих специалистов, написать код с первого раза без единой ошибки сродни фантастике. Чтобы узнать, как создаются программы, мы побеседовали с ведущим iOS-разработчиком, проект-менеджером SFERA Дмитрием Нгуеном.
2451 просмотров
— Дмитрий, скажите, какие специалисты обязательно должны присутствовать в команде разработчиков?
— Если рассмотреть на примере разработки простого приложения, то потребуется 2 iOS-, 2 Android-, 2 backend- и 2 frontend-разработчика. Также нужны 2 дизайнера, архитектор, тестировщик и системный аналитик. Можно обойтись и без системного аналитика, но увеличивается время на разработку.
— Чем конкретно занимаются эти специалисты?
— Backend-программисты специализируются на серверной части. Frontend пишут код для видимой части приложения или сайта. Разработчики ядра приложения создают универсальное ядро, которое можно будет внедрять в разные платформы: на Android, iOS или web-сайт.
Я пытался изучить программирование с нуля за 7 дней и вот что получилось в итоге
Архитектор разрабатывает данные, которые нужно передавать, просчитывает архитектуру всего приложения, как работает back и frontend, ставит задачу программистам. Он обладает знаниями по этим направлениям, в курсе возможных нюансов.
Системный аналитик решает сложные организационные задачи и распределяет их. Ищет варианты оптимизации процессов, согласовывает их с руководством. Взаимодействует с подрядчиками по вопросам внедрения новых решений, анализирует, нужны ли они бизнесу. Оформляет пожелания заказчика в бизнес-требования. Хорошо, если он в то же время и scrum-мастер, который помогает специалистам понять суть программной платформы, разрешает трудности в процессе разработки.
— В чем состоят ваши обязанности как проект-менеджера?
— Совместно с тимлидом мы распределяем задачи между командами программистов и обозначаем сроки выполнения. Предварительно всё согласовывается с руководителем проекта. Также на мне ответственность по контролю за действиями подрядчиков.
— Как вы выстраиваете работу в команде?
— Например, за 2 недели мы должны подготовиться к одному релизу. Мы обдумываем, что нам нужно для этого сделать. Далее распределяем задачи и проводим ежедневные митапы, чтобы оценить успеваемость команды и понять, на какой стадии находится разработка. Именно анализ задач и их распределение занимает большую часть моего времени как проект-менеджера. (В остальное время я пишу код для iOS.)
Для того чтобы выстроить эффективный рабочий процесс, необходимо понимать зависимость команд друг от друга. Так, у нас есть backend (серверная часть), frontend и разработчики ядра приложения.
Так, фронтенд зависит от бэкенда и ядра. А ядро — от серверной части и в какой-то мере от фронтенда, поскольку он находит актуальные баги. Бэкенд предоставляет функционал, который не виден пользователю, для того чтобы приложение работало как единая экосистема (в нашем случае). Ядро, зная структуру данных сервера, приступает к разработке. Параллельно фронтенд начинает верстку.
Программирование. Как начать писать программу?
Когда всё сверстано, ядро завершает свою работу и можно внедрять. То есть сначала идут работы по серверной части, затем на ядре и фронтенде. Такое распределение задач позволяет задействовать всех сразу.
— Как оцениваются результаты работы?
— Разработка продукта ведется по методологии Agile. Для более точной организации рабочих процессов и отслеживания результатов мы используем SCRUM и Kanban.
Задачи распределяются и реализуются согласно поставленным срокам. Мы должны их придерживаться. Решение каждой задачи оценивается по часам. Когда же задача закрывается, проверяется предполагаемое и фактическое количество часов. Выявленную разницу мы учитываем при постановке предположительного времени.
В дальнейшем это помогает проводить более точный анализ временных затрат на реализацию той или иной задачи.
Как я уже сказал, спринты у нас по две недели. За это время происходит один релиз. Когда фронтенд заканчивает работу, мы делаем активные функции и отправляем всё это тестировщикам. Они в течение одного-двух дней проводят проверку. Непосредственно перед релизом мы правим баги и отправляем всю сборку на релиз.
— С какими проблемами в своей работе вы сталкиваетесь систематически?
— Основная проблема у нас — неточное ТЗ от отдела дизайна. При написании кода мы должны учитывать любое состояние окон, которое может быть в приложении. Все эти окна должны быть отрисованы. Все возможные недочеты должны закрываться еще на этапе проектирования приложения. И такие проблемы в основном возникают из-за недостаточности знаний и неопытности тех, кто разрабатывал и дизайн, и ТЗ.
— Что поможет избежать ошибок и переписывания кода?
— Большое значение имеет правильно составленное ТЗ. Этим также занимается системный аналитик. При этом нужно максимально декомпозировать все задачи для написания кода. Требования следует формулировать как можно конкретнее. Нам, программистам, при разработке очень нужна и важна точность.
Идеального ТЗ в своей жизни я еще не видел. Но если что-то непонятно, всегда можно обратиться к знающему человеку и спросить. Самое важное в любой работе — это общение. Без взаимопонимания ничего не получится.
— Какие проблемы возникают при работе с программистами?
— Зачастую это непонимание того, что требует бизнес. Неумение работать в команде. Бывает, программист говорит: «Вот мой кусок кода — его не трогайте». А иногда появляется необходимость посмотреть этот код. И проект-менеджер «лезет» в этот код. А в дальнейшем могут возникнуть разногласия. Поэтому разработчикам очень важно научиться работать сообща.
Проект-менеджер должен так выстраивать рабочий процесс, чтобы была достигнута задача заказчика в обозначенные сроки.
— Как избежать неприятных моментов в работе?
— HR должен правильно подбирать персонал. На собеседовании обязательно задать ряд вопросов, по которым можно определить, есть ли у кандидата soft skills. Это первый фильтр. Далее HR советуется с командой и принимает решение, сможет ли специалист взаимодействовать с коллегами. Такой подход уменьшит вероятность конфликтов в будущем.
— Дмитрий, расскажите, какие навыки необходимы для того, чтобы стать тимлидом или проект-менеджером?
— Чтобы стать тимлидом или проект-менеджером, помимо специальных знаний по разработке, необходимы хорошие soft skills. Самодисциплина, тайм-менеджмент, умение выстраивать личную и командную работу. Hard skills можно наработать, это сложно, но можно. Но наличие гибких навыков — на первом месте.
Даже высококлассному разработчику будет тяжело работать в проекте без умения налаживать контакты с другими людьми. И самое главное — решать задачу бизнеса.
— Как сформировать команду из квалифицированных специалистов и где их найти?
— Основная масса таких программистов идут работать в известные компании. При этом хороший разработчик пойдет в стартап, если проект ему покажется интересным. В начале придется нанимать джунов и сформировать из них команду. Мидл не пойдет в проект, если там никого нет. Тенденция на рынке труда такова, что средних и старших разработчиков (middle и senior) привлечь очень сложно.
Они соглашаются работать за достойную зарплату. Поэтому на их оплате труда сэкономить не получится.
И если, пребывая в проекте 2-3 года, мидл или сеньор не видят перспектив для себя в плане знаний, то они уходят из него. Получив опыт корпоративной разработки, они могут пойти работать в стартап и сформировать свою команду разработчиков.
При наличии высококлассных специалистов разработка отвечающего всем запросам пользователей приложения — лишь дело времени. А полноценному релизу такого продукта предшествует длительная и кропотливая работа его создателей — программистов. Необходимо согласовать множество рабочих моментов как со своими программистами, так и с подрядчиками. А иногда и полностью переписать тысячи строк кода. И при его написании учитывать все возможные действия пользователей.
Источник: vc.ru
Как программисты пишут программы
Итак, у вас появилась идея для отличной программы, однако вы и понятия не имеете, как ее реализовать? Не беда, поможем. Правда, придется потратить немало времени на то, чтобы выучить язык программирования, но это нормально. Скажем даже более, многие успешные программисты — самоучки. Выучив основы, вы сможете создавать простые программы, тратя на это минимум времени.
Создание более сложных программ, конечно, является более серьезной задачей, но, как говорится, терпение и труд все перетрут!
Ваши программы – это ваше наследие. Решайте сами, как долго оно будет существовать.
Жизнь заканчивается, но программы не обязательно должны умирать.
После серии моих твитов на тему того, как нужно писать программы, меня попросили раскрыть эту тему. Предупреждаю, что редко в каком проекте удаётся чётко следовать всем семи правилам. У меня самого это часто не получается. Но чем больше правил вы соблюдаете, тем больше ваши программы проживут. Каждый символ добавляет что-то к общей экосистеме, и наша задача, как инженеров, поддерживать экосистему в чистоте и порядке.
Что можно получить, выдавая хороший код? Разве не имеет права на жизнь подход в обучении под названием «двигайся быстрее, ломая всё на своём пути?» Нет. Обучиться писать код – это навык, это доступно каждому. Обучиться писать хороший код – это искусство. Это требует усилий, времени и целеустремлённости.
Разве вы хотите оставить после своей смерти миру ещё больше SEGFAULT-ов? Хотите ли вы, чтобы сисадмины занимались починкой систем, которые сломались из-за вашего дерьмового кода? Чтобы ваш менеджер проектов вспоминал вас как инженера, работа которого бесила пользователей?
Ничего плохого в быстром продвижении вперёд нет, но в какой-то момент нужно осознать, что низкокачественный код далеко вас не уведёт.
Когда вы приходите к врачу, тот сначала задаёт вам много вопросов, чтобы понять, что с вами случилось. Он не выписывает лекарства перед постановкой диагноза. Точно так же важно разобраться, действительно ли с вашим кодом что-то не так.
1. Накат обновлений отнимает много времени и сил?
2. Система рушится даже от небольшого обновления?
3. Выкатывали ли вы когда-нибудь сломанный код на продакшн, причём это становилось известно только после жалоб пользователей?
4. Знаете ли вы, что именно нужно делать, когда система падает? Как добраться до бэкапов и восстановиться из них?
5. Проводите ли вы больше времени за сменой окружений, повторных выполнений одних и тех же команд, запуска каких-то утилит – чем за самим написанием программ?
Если вы ответили «да» – эта статья для вас. Читайте, а лучше прочтите два раза.
1. Делите на модули
Мозг человека – сложное устройство, сложнее любого процессора, при этом он не справляется с решением сложных задач. Допустим, сложно сразу умножить 13*35. Но если разделить эти операции на простые: 35*10 + 30*3 + 5*3 = 455, то подсчёт упрощается. Разбивая задачу на простые и независимые, мы приходим к ответу.
Так же и с программами. Разбейте программу на несколько частей, файлов, директорий. проектов. Все зависимости выведите в одно место, используйте принцип MVC или его вариант. Такой код и читать проще, и отлаживать легче. В большинстве случаев отладка приведёт вас к нескольким строкам кода, а не к файлу из тысячи строк.
Накатывая апдейты одного модуля, вы не сломаете всю остальную систему.
2. Тестируйте
Фу, тесты. Брррррр!
Такая реакция естественна, потому что нас учили, будто тесты не являются частью программирования. Вас учат шаблонам в С++, но не тому, как их тестировать. В этом и проблема. Некоторые считают, что тесты над писать до самой программы.
Мне всё равно, когда вы пишете тесты, если вы их пишете. Не надо геройствовать, начните с простого (print(add(1, 1) == 2)), а затем уже переходите на фреймворк для тестов в вашем языке.
Тогда вы начнёте понимать сложность вашей программы, учиться делить её на модули, части, которые можно тестировать по отдельности. Получается, что используя тесты, вы уже будете выполнять два из семи правил.
3. Непрерывная интеграция
Тесты должны успешно отрабатывать, причём в разных окружениях (например, в разных версиях Python). Также тесты надо проводить после каждого изменения. Вместо того, чтобы делать это вручную из командной строки, удобнее и быстрее создать платформу для непрерывной интеграции.
Непрерывная интеграция (НИ) – это практика разработки, при которой код интегрируется в репозиторий несколько раз в день. Каждый раз проверяется автоматически, что позволяет отслеживать проблемы на ранней стадии.
Для своих проектов я использую TravisCI и Drone.io. Когда я делаю новое дополнение кода, платформа делает билд и выполняет тесты.
4. Автоматизируйте
У больших проектов всегда есть куча мелких вспомогательных задач. Некоторые люди делают текстовики с командами и копируют их оттуда. Но проще освоить скрипты на bash (и/или Python). Вот некоторые задачи, которые необходимо автоматизировать скриптами:
— преобразование README.md в другие форматы
— автоматическое тестирование (включая создание тестовых серверов и данных, удаление временных файлов и т.д.)
— заливка кода на сервер разработки
— размещение программы на продакшене
— автоматическое обновление зависимостей
5. Избыточность
Первое, что вы видите на git-scm.com:
Git – бесплатная распределённая система контроля версий с открытым исходным кодом, предназначенная для работы как с малыми, так и очень большими проектами, с высокой скоростью и эффективностью.
Распределённая. Это ключевое слово. Ущипните себя, если вы хоститесь только на гитхабе. Потому, что это единая точка отказа. Если гитхаб падает, или во время push-операции вы повредили файлы, ваш процесс разработки останавливается.
Залогиньтесь на Bitbucket и выполните следующее в вашем репозитории:
Теперь, когда вы заливаете код, изменения идут как на Github, так и на Bitbucket. Никогда не знаешь, когда что-либо сломается. И всегда полезно иметь бэкапы. Вот, как это работает у меня:
— весь код живёт в директории Codebase в Dropbox. Автоматическая синхронизация.
— почти весь код живёт на Github
— самый важный код живёт на двух частных зеркалах – одно в школе, другое на моём AWS
Я потеряю свой код, только если настанет конец света.
6 Коммиты
Это должно быть вам знакомо. Загляните в историю, и вы увидите что-то вроде:
Исправил? Какую ошибку? В каком модуле?
Многие расценивают систему контроля версий как бэкап, а не как способ хранить историю. История из таких сообщений бесполезна. Допустим, через неделю после этого коммита вы решили что-то вернуть назад, потому что оно привнесло в проект новый баг. Но поскольку описания действия нет, вам нужно просматривать все изменения. Именно для предотвращения этого и создавались системы контроля версий.
Чтоб не напрягаться, просто воспользуйтесь следующей шапргалкой:
— у каждого коммита должен быть смысл. Исправление ошибки, добавление новой функции, удаление существующей?
— только одно изменение на один коммит
— включайте номер проблемы в сообщение о коммите
— включайте описание изменений. Это зависит от правил текущего проекта, но обычно вы упоминаете, что приводило к ошибке, как вы её исправили и как это тестировать
— пишите осмысленное сообщение:
добавил новую форму в заголовок, чтобы было легче собирать ссылки. закрыл #3
удалил всякое, ибо почему бы и нет, хех
7. Планируйте
Даже если вы выполняете все предыдущие правила и чувствуете себя богом программирования, всё равно может случиться всё, что угодно. Имейте план на самый плохой случай. Что, если трафик побьёт рекорды? Откуда вы возьмёте бэкапы, если система упадёт? Кому звонить ночью, если сервер навернётся?
Продумайте, но не перестарайтесь. Автоматизируйте всё, что возможно. Затем задокументируйте всё подробно. Так, чтобы тот, кто получит ваш код, тоже смог следовать плану. Иметь план – не только значит выглядеть умнее, это значит реально быть умнее.
Вот такие правила и определяют хорошую программу. Если вас они не убедили, ответьте мне на два вопроса:
1. Ожидаете ли вы от новичка, присоединившегося к вам, что он поймёт существующий код с лёгкостью?
2. Является ли рефакторинг кода простым и быстрым делом?
Если нет – перечитайте заново. Сохраните, поделитесь с командой.
Эти правила поначалу могут показаться очевидными. Так и есть. Плохой код постоянно создают, и, в конце концов, он умирает. Ваши программы – это ваше наследие. Решайте сами, как долго оно будет существовать.
Программирование – процесс творческий и интересный. Для того, чтобы создавать программы не всегда нужно знать языки. Какой же инструмент нужен для создания программ? Вам необходима среда программирования. С ее помощью ваши команды переводятся в понятный для компьютера бинарный код. Вот только языков существует очень много, а сред программирования еще больше.
Мы рассмотрим список программ для создания программ.
PascalABC.NET
Отблагодарите автора, поделитесь статьей в социальных сетях.
Источник: planshet-info.ru
Как программисты пишут программы? — Дока. Инженер ваших душ. — ЖЖ
Многие считают это ремесло непонятным настолько, что нет никаких шансов разобраться в принципах даже теоретически.
Попытаюсь объяснить как это происходит, что называется, на пальцах.
Для написания программ используются языки программирования, которые разделяют на низкоуровневые, высокоуровневые и сверхвысокоуровневые, а какой из них какой и чем отличается станет ясно чуть позже. Но забегая вперед добавлю, что каждый язык создан для определенных задач и не всегда одну и ту же задачу можно реализовать на разных языках.
Для понятности, буду приводить примеры на бытовых приборах и задачах, с которыми мы сталкиваемся каждый день.
Итак, задача — нарезать хлеб к обеду. Для человека простейшая задача — чего его там резать-то, взял и нарезал, правда?
Самый главный навык программиста, без которого ничего не получится — умение разделять задачу на последовательность действий. Чем ниже уровень языка программирования, тем более детально нужно описывать эту последовательность.
Приведу пример, как выглядела бы программа по нарезке хлеба для нашего тела
Задача «нарезать хлеба» на языке программирования высокого уровня
__1.Открыть правой рукой хлебницу;
__2.Взять булку хлеба правой рукой;
__3.Положить хлеб на разделочную доску; (предположим, что доска уже лежала на столе)
__4.Открыть правой рукой верхний ящик стола;
__5.Найти блестящий нож, длиной 20 см, с черной ручкой;
__6.Взять нож в правую руку;
__7.Поднести нож к хлебу;
__8.Зафиксировать хлеб левой рукой, взявшись за левый край булки;
__9.Расположить нож строго над правым ребром булки хлеба;
__10.Повторять следующие действия 5 раз:
____10.1.Отступить влево на сантиметр;
____10.2.Повторять следующие действия, пока лезвие ножа не не коснется доски:
________10.2.1.Прижать нож к хлебу;
________10.2.2.Совершить ножом возвратно поступательное движение вперед-назад;
____10.3.Поднять нож вверх;
__11.Положить нож в ящик;
__12.Отпустить левой рукой хлеб.
//
Все, программа по нарезке хлеба в количестве пяти кусков готова, можно ее продолжить, описав стирание крошек со стола, укладывания нарезанных кусочков на тарелочку и т.д.
Отладка программы
Запускаем программу и смотрим, как она работает:
Ой. вместе с пятым куском и палец отрезал.
чёрт! остановить программу!
Я же не написал как именно нужно зафиксировать хлеб левой рукой, схватился как попало и большой палец торчал в сторону.
Возвращаемся к строчке «Зафиксировать хлеб левой рукой, взявшись за левый край булки;»
После нее пишем:
«Поджать большой палец левой руки влево, к ладони;»
Запускаем программу
Ой. на строчке «Положить нож в ящик;» нож упал на пол.
Проклятье! оказывается, стол стоит немного под наклоном и ящик сам закрылся.
Возвращаемся к коду и перед строчкой «Положить нож в ящик;» пишем «Открыть правой рукой верхний ящик стола;»
Заметили ошибку? Нет?!
Как мы можем открыть ящик правой рукой, если в этой руке нож? Значит, сначала нужно положить нож на стол, потом открыть ящик, снова взять нож и т.д.
И делаем мы это до тех пор, пока хлеб не будет нарезан как следует, без повреждения мебели и пальцев.
Вот, примерно так происходит отладка
С опытном начинаешь писать программы, которые работают с первого раза, допуская минимум ошибок, а проверка «открыт ли ящик», перед складыванием в него чего-то, входит в привычку.
Когда какие-то операции совершаются постоянно, такие как нарезка хлеба, мойка посуды и т.д., то программисты их описывают в виде процедур.
Процедура — набор определенных действий, спрятанный под одной командой.
Таким образом, текст программы, который я приводил выше, можно поместить в процедуру под названием НарезатьХлеба(параметр), где в качестве параметра будем указывать количество кусков
в результате, программа с использованием процедур будет выглядеть так:
__ЗайтиНаКухню();
__НарезатьХлеба(5);
__ПоставитьХлебНаСтол();
__ПомытьПосуду();
и нет предела совершенству
Теперь о языке низкого уровня
на нем пришлось бы описывать эту задачу еще более детально, вплоть до того, какими пальцами и с каким усилием нужно держать нож, что «открыть ящик» — это совершить последовательность действий все той же рукой с использованием кисти, пальцев, мышц предплечья, усилий в килограммах на сантиметр и т.д. Пришлось бы даже описать что такое правая рука, где она находится и не забыть проверить есть ли она вообще в наличии.
Но когда-то, не было и низкоуровневых языков программирования и его писали на машинных кодах, т.е. программа выглядела в виде последовательностей единиц и нулей, это были темные времена.
Стоит немного рассказать что такое высокоуровневый язык и зачем нужен низкоуровневый, если проще писать на высокоуровневом?
Высокоуровневый язык был написан на низкоуровневом, в него были заложены команды, в виде процедур, подразумевающие последовательность действий, таких как «открыть ящик», «взять нож в руку» и т.д. но если по какой-то причине потребуется взять нож только двумя пальцами, потому что ручка сломана или отсутствует, например, то сделать этого не удастся, ибо команда «взять нож в руку» подразумевает использование всех пяти пальцев. Для таких ситуаций в высокоуровневых языках есть возможность делать вставки кода на низкоуровневом языке и вместо стандартной команды «взять нож в руку» пишется код на низком уровне под нож со сломанной ручкой.
Человек все эти операции делает не задумываясь, но машина так не умеет, ей нужно подробно объяснить что, как и в какой последовательности.
Сверхвысокоуровневые языки являются узкоориентированными на определенные задачи, например, для работы на кухне, они включают набор специальных команд и код на них выглядел бы примерно, как программа с использованием процедур, что описана выше.
Вы наверняка сталкивались с тем, что какие-то программы работают только под Windows, например, и их нет под Android или наоборот, хотя функции, казалось бы, обычные, и почему на телефон с Windows Phone нельзя установить Android?
Объясню на примере все той же программы для кухни: в тексте программы сказано «Найти блестящий нож, длиной 20 см, с черной ручкой в верхнем ящике стола», например, это для Windows. Однако, в андройде нет верхнего ящика стола, ножи там хранятся в настенном шкафу, т.е. процедура открытия ящика должна быть заменена на процедуру открытия шкафа, согласитесь — они разные!
Но и нож там лежит длиной не 20 см, а в 25, он вовсе не блестящий и ручка у него не черная, а синяя. Поэтому, чтобы нарезать хлеба, нужно существенно переписать программу, хотя результат будет такой же. Для этого существуют кросплатформенные программы, которые могут работать под разными системами, т.е. на разных кухнях, ибо программисты предусмотрели оба варианта.
Это, конечно, замечательно, но у них есть и минусы: если у вас всегда используется только кухня с ящиками в столах, то зачем вам код, который умеет работать со шкафами? А место он занимает. Это все равно что купить миркроволновку, у которой в комплекте идут две дверки, одна предназначена для открывания влево, а другая вправо и еще у этой печки есть ниша, в которую можно положить ненужную дверку, но из-за этой ниши микроволновка выше на 10 мс. Вы поставите нужную дверку, а ниша будет занимать место.
Почему андройд нельзя заменить на виндовс или наоборот?
Ну, на самом деле можно, но на примере той же кухни это будет выглядеть так: выносите одни шкафы, которые по размеру идеально вписывались в помещение и заносите другие, они шире и не вмещаются, придется отпиливать, раковина не слева, а справа — не хватает труб, надо как-то наращивать, розетки слишком низко, столы их перекрывают, придется долбить стены, чтобы перенести и т.д.
Почему у программистов обычно неопрятный вид и они будто не от мира сего?
Ну, во-первых, далеко не все такие, а во-вторых, они часто обдумывают код, даже двигаясь в плотном потоке машин или прогуливаясь с девушкой под ручку. Она рассказывает ему какую-то историю, а у него мелькают мысли, он раскладывает операцию на последовательность действий, подбирая наилучший вариант. Поверьте, это бывает увлекательнее, чем читать самую интересную книгу.
И именно поэтому они могут не спать сутками, пока пребывают в этом состоянии. И именно в этом состоянии они могут выглядеть ненадлежащим образом 🙂 Это состояние называют «прет». Но бывает и непруха, когда делаешь-делаешь, а каменный цветок так и не выходит, в этом случае нужно все бросить и отвлечься.
но говорят, что бывает и такое 🙂
А теперь представьте, насколько сложен наш мир глазами программиста.
Искусственный интеллект — это программа, способная к самосовершенствованию, которая, отрезав палец, должна понять, что что-то пошло не так, пойти в код и исправить ошибку! Возможно ли это?
Надеюсь, у вас хватило терпения дочитать это до конца и кое-что стало более понятным.
Источник: artur-s.livejournal.com