Форум программистов, компьютерный форум, киберфорум
Наши страницы
CoderHuligan
Войти
Регистрация
Восстановить пароль
Оценить эту запись

Шерлок Холмс и планирование. Из найденных записок кодомана.

Запись от CoderHuligan размещена 13.07.2015 в 16:25
Обновил(-а) CoderHuligan 13.07.2015 в 16:34

Сосункам читать не рекомендуется!
Холмс против планирования.
Патриархи от структуры во всех пособиях предлагали и до сих пор предлагают начинать написание программ с планирования. С чёткого представления общей структуры программы. Это так называемая "разработка сверху вниз". Но, как показывает практика, такие заповеди могли родится лишь в теоретических головах кабинетных учёных. На практике всё становится гораздо сложнее.
Причём тут Холмс?
При том, что он против планирования, - он за дедукцию.
Если бы холмс, встретившись с новым для себя делом, сначала запланировал все свои будущие шаги по раскрытию этого дела, то с вероятностью в 99,99% он бы это дело не раскрыл (либо "раскрыл", но посадили бы невиновного).
Холмс знает лишь то, что случилось - факт произошедшего события, поэтому глупо было бы с его стороны начинать планирование начиная со стадии входных данных.
Но задачу как-то необходимо решать. Что мы имеем? Мы знаем, что мы должны получить в результате решения поставленной задачи, то есть - знаем, что будет на выходе. Но мы совершенно не имеем понятия как это должно быть реализовано! Совершенно также как Шерлок Холмс не имеет понятия о том, кто является преступником. Это самое сложное, и в то же время выход существует.
Холмс начинает наблюдать за деталями, которые помогли бы ему раскрыть преступление. Он начинает искать УЛИКИ.
Обьективно - задача уже имеет решение, но это решение далеко лежит за пределами нашего знания. Наша задача вместе с Холмсом просто найти улики, по которым как по ниточке возможно было бы размотать весь хитрый клубок трудной задачи. Планирование здесь не поможет, но у нас имеются улики. Один окурок для Холмса может означать раскрытие всего преступления.
Ведь этот окурок - не просто окурок, а ключ к решению нашей задачи...
Этот окурок может многое для нас значить. Ведь он встроен в строгую логическую схему, по которой выстроено всё здание задачи. Причем однозначная схема!
У нас есть свои улики - необходимые переменные, массивы и т.д. Мы не должны ничего планировать заранее, причём мы должны специально отказаться от планирования!
Мы должны единственно - с твёрдостью волчьей хватки, зацепиться за наши улики, то есть - те данные которыми мы обладаем на данный момент. Эти ключи и приведут нас к победе. Холмс - наш друг, он нам поможет!
Применим дедукцию, цепочку логических умозаключений, применительно к уликам, и постепенно картина будет прояснятся всё чётче и яснее, пока не станет совершенно очевидной.
Возможно по началу мы можем подозревать, что кто-то или что-то имеет цикл(к примеру). Это всего лишь подозрение и мы не должны сразу его использовать, но мы должны вывести необходимость его применения в данном месте только исходя из логических предпосылок, и никак иначе. Более того поначалу полезно совершенно отказаться от применения обычных циклических блочных конструкций и заменить их безусловными переходами. Потом если кодер захочет он может их заменить на обычные. Но если он начнёт их применять с самого начала он натолкнётся на грабли преждевременного планирования, а этого-то мы и хотим избежать, не забыли? ХеХе. Планирование - вред, - скажи преподу!(поговорка) Ура дедукции!!
Улики встроены в цепочку логической структуры программы, и поэтому не трудно применяя логические выводы(методы) выявить её начало и конец. Таким образом программа может строится с любого места, - с середины или с конца и т. д., главное наблюдательность к уликам.
Если отказаться от планирования, то задача будет решаться как по маслу, - программирование превратится в удовольствие, а не в бесплодные попытки втиснусь в прокрустово ложе заранее неправильного плана свои идиотские попытки его реализовать.
Продолжение возможно следует...
Правда если будут найдены другие записки свихнувшегося кодомана...
Размещено в Без категории
Просмотров 728 Комментарии 14
Всего комментариев 14
Комментарии
  1. Старый комментарий
    Аватар для rao
    Не болтайте ерундой.
    Без планирования можно написать разве что только курсовую в путяге. Ни один крупный (т.е. командный) проект без чёткой и продуманной структуры не реализовать.
    Запись от rao размещена 13.07.2015 в 18:36 rao вне форума
  2. Старый комментарий
    Аватар для tezaurismosis
    Авторы многочисленных книг по организации и планированию разработки тихо плачут...
    Нужно различать творческий подход и разгильдяйство.
    Запись от tezaurismosis размещена 14.07.2015 в 08:52 tezaurismosis вне форума
  3. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    Сообщение от rao Просмотреть комментарий
    Ни один крупный (т.е. командный) проект без чёткой и продуманной структуры не реализовать.
    Никто с этим и не спорит.
    Крупный проект всегда делится на множество подзадач, которые обусловлены известными разработчикам начальными условиями на стадии обдумывания целей проекта.
    Дальше уже начинаются сами задачи, которые можно решать по разному.
    Запись от CoderHuligan размещена 14.07.2015 в 13:56 CoderHuligan вне форума
  4. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    Сообщение от tezaurismosis Просмотреть комментарий
    Нужно различать творческий подход и разгильдяйство.
    Верно.
    Разгильдяйство можно выявить "по факту", то есть по результату того или иного творческого подхода к данной задаче. Если конечный продукт работает, работает быстро и хорошо, то совершенно не важно каким способом это достигнуто.
    Конечно, путь который предлагает тот самый кодоман, не всем подходит, так как это зависит от разных характеров и темпераментов людей. Всех под одну гребёнку не причешешь. У меня вроде получается.
    Запись от CoderHuligan размещена 14.07.2015 в 14:25 CoderHuligan вне форума
  5. Старый комментарий
    Аватар для tezaurismosis
    Цитата:
    Сообщение от CoderHuligan
    совершенно не важно каким способом это достигнуто
    Спору нет, но представьте следующую ситуацию.
    У вас есть коробка с сахаром, её нужно пересыпать в большую коробку, у которой есть только маленькое отверстие.
    Способ первый - "спланировать" насыпание - сыпать сахар тонкой струйкой, наверняка просыплется немного.
    Способ второй - просто перевернуть коробку - сколько попало, столько попало, собрать просыпавшееся и снова до полного результата.
    Вопрос: каким путём вы засыплете сахар быстрее?
    Запись от tezaurismosis размещена 16.07.2015 в 17:41 tezaurismosis вне форума
  6. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    Сообщение от tezaurismosis Просмотреть комментарий
    Спору нет, но представьте следующую ситуацию.
    У вас есть коробка с сахаром,
    Правильно, - мы сразу понимаем, что нужно сыпать тонкой струйкой, так как этот способ согласуется с нашими прошлыми унаследованными знаниями и опытом. Сыпать тонкой струйкой - это очевидное решение, которое сразу приходит на ум. Нам и в голову не может прийти, что можно насыпать сахар горкой на другую коробку, а потом ладошкой или ложечкой потихоньку подгребать сахар к отверстию, до тех пор, пока весь сахар, до последней крупинки, не окажется в другом ящике. А можно также насыпав горкой сахар на другой ящик, потом накрыть этот ящик пустым ящиком, в котором находился сахар, а затем начать трясти эти оба ящика, пока по закону вероятности все крупинки не окажутся в нижнем ящике, просыпавшись в отверстие. При этом тоже не пропадёт ни одной крупинки, так как сахар накрыт пустым ящиком, что будет препятствовать его разлёту в разные стороны во время тряски.
    Вот сколько вариантов. И кто знает, какой из них самый оптимальный в данных условиях... Но мы сразу берём самый очевидный вариант и начинаем его осуществлять. И не важно, что надо постоянно напрягать внимание, чтобы попасть точно в центр отверстия, - мы потерпим. И совсем не важно, что сахар вряд ли будет сыпаться тонкой струйкой, так как с точки зрения физики это невозможно. Это только в нашем представлении он будет сыпаться тонкой струёй, на практике же будет большой разлёт, и часть частичек окажется на полу, отскочив от краёв отверстия. Этого-то мы и не учли, - мы сразу ринулись в бой, решать поставленную задачу, по заранее намеченному плану.
    Запись от CoderHuligan размещена 17.07.2015 в 14:41 CoderHuligan вне форума
    Обновил(-а) CoderHuligan 17.07.2015 в 14:43
  7. Старый комментарий
    Аватар для tezaurismosis
    Цитата:
    Сообщение от CoderHuligan
    это очевидное решение, которое сразу приходит на ум
    Оно очевидное по одной из двух причин - либо в детстве сами сыпали навалом и поняли, что нужно аккуратно, либо в том же детстве кто-то из старших посоветовал так сыпать. Сыпать сахар навалом проще, потому что это требует меньше знаний.
    Мне даже страшно представить, сколько лет нужно программировать и работать над реальными проектами, чтобы *каждый* аспект работы кода, любой функционал и проч. казалось очевидным.
    Плюс к этому - то что кажется очевидным, не всегда верно.
    Запись от tezaurismosis размещена 18.07.2015 в 08:42 tezaurismosis вне форума
  8. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    Сообщение от tezaurismosis Просмотреть комментарий
    Мне даже страшно представить, сколько лет нужно программировать и работать над реальными проектами, чтобы *каждый* аспект работы кода, любой функционал и проч. казалось очевидным.
    Плюс к этому - то что кажется очевидным, не всегда верно.
    Совершенно согласен.
    Я и пытаюсь доказать, что на начальном этапе ничего не очевидно. Только в процессе реального кодинга становятся очевидными определённые вещи. Только совершенный гений может(а может - и не может) представить в уме программу во всех своих подробностях, да при этом, ещё и самый оптимальный алгоритм этой программы, так как вариантов написания существует множество.
    Запись от CoderHuligan размещена 18.07.2015 в 16:00 CoderHuligan вне форума
  9. Старый комментарий
    Аватар для Убежденный
    Цитата:
    Сообщение от CoderHuligan
    Сосункам читать не рекомендуется!
    Интересно, здесь кто-нибудь считает себя сосунком ?


    Цитата:
    Сообщение от CoderHuligan
    Если отказаться от планирования, то задача будет решаться как по маслу, - программирование превратится в удовольствие, а не в бесплодные попытки втиснусь в прокрустово ложе заранее неправильного плана свои идиотские попытки его реализовать.
    Обе эти точки зрения являются крайностями. Без планирования невозможен нормальный
    процесс разработки. Или вы будете постоянно что-то переписывать, перепроектировать и в
    итоге, скорее всего, погрязнете в технических долгах. С другой стороны, на этапе
    планирования нельзя сразу предвидеть многих вещей. Но планирование - это в первую
    очередь составление "целой" картины, а не проработка каждой детали до последнего
    винтика. Потом у этой картины постепенно определяются составляющие части, каждая
    часть прорабатывается все глубже и глубже, до той детализации, которая вообще имеет
    смысл на данном этапе, открываются какие-то конкретные проблемы, ранее неучтенные нюансы.
    Для идей, успех которых под сомнением, делаются прототипы. Определяется, какие могут
    быть проблемы с производительностью, сможет ли программа работать на терминалах, не
    будет ли заморочек с безопасностью, можно ли будет работать с ней из-под
    ограниченного аккаунта, в каких направлениях будет расширяться программа и т.д.
    Для отдельных подсистем и бизнес-уровней проектируется свой API, через который
    они смогут обмениваться данными. Все это делается именно на этапе планирования
    техническими специалистами и архитекторами ПО, которые, с высоты своего опыта и знаний,
    могут сходу ответить на все или большинство этих вопросов, не прибегая к созданию
    прототипов и проведению тестов. К тому времени, когда люди сядут писать код, все
    или почти все его критические участки будут уже испытаны в бою. Но и после этого
    планирование не заканчивается, т.к. всплывают ранее незамеченные "грабли", программа
    наталкивается на различные ограничения и тому подобное, и все это нужно своевременно
    обсуждать и корректировать курс. Вот что такое планирование, IMHO, а вовсе не
    составление плана в стиле "что я буду делать во вторник вечером 2029 года".
    Запись от Убежденный размещена 18.07.2015 в 19:32 Убежденный вне форума
  10. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    Сообщение от Убежденный Просмотреть комментарий
    Интересно, здесь кто-нибудь считает себя сосунком ?
    Хочу определится с тем, кого считать или не считать таковым. Те кто знаком со статьёй, которую написал Эд Пост из Орегонской компании Tektronix в 1983году:http://lib.ru/ANEKDOTY/non_pas.txt те поймут о чём идёт речь. Сосунки это не те зелёные юнцы, которые только начинают учиться программированию, - совсем нет. Сосунки это те, кто боится использовать операторы goto; это те, кто клал на алгоритм ради приверженности какой-то парадигме программирования, будь то ООП или чисто структурный стиль. Это те, кто коверкает свой код, только ради того, чтобы их не записали в быдлокодеры, которые пишут говнокод. Я считаю, что как раз всё наоборот. Потому что эти парадигмы против истинной структуры - Алгоритма.
    Цитата:
    Вот что такое планирование, IMHO, а вовсе не
    составление плана в стиле "что я буду делать во вторник вечером 2029 года".
    Это разработка сверху вниз в классическом варианте. Она уже неоднократно подвергалась критике за трудность тестирования отдельных кусков кода пока не будет написана последняя его строчка. В этом смысле разработка снизу вверх намного лучше как рекомендуют делать некоторые фортеры. В этом случае можно сразу начинать тестировать программу с нижних уровней, постепенно подбираясь к верху. Сначала пишутся процедуры, потом из этих процедур составляются другие блоки кода и т.д, - получается иерархичная структура.
    Я не против планирования как такового. Важно понять - что такое правильное планирование. На мой взгляд, план - это всего лишь постановка задачи вместе с её исходными данными, не более того.
    Запись от CoderHuligan размещена 19.07.2015 в 14:28 CoderHuligan вне форума
    Обновил(-а) CoderHuligan 19.07.2015 в 14:29
  11. Старый комментарий
    Аватар для Убежденный
    Цитата:
    Это разработка сверху вниз в классическом варианте.
    Вовсе нет. Здесь проектируется и общий план, например, формирование API, и
    прорабатываются конкретные детали реализации, из-за которых этот план
    может меняться. Неуклонное следование догматическому "сверху-вниз" или
    "снизу-вверх" - это тупик, настоящий процесс сложнее, итеративнее, в нем
    больше живого и непосредственного, чем в этих формальных принципах.

    Цитата:
    Важно понять - что такое правильное планирование. На мой взгляд, план - это всего лишь постановка задачи вместе с её исходными данными, не более того.
    И в чем тогда смысл такого планирования ?

    Цитата:
    В этом смысле разработка снизу вверх намного лучше как рекомендуют делать некоторые фортеры. В этом случае можно сразу начинать тестировать программу с нижних уровней, постепенно подбираясь к верху. Сначала пишутся процедуры, потом из этих процедур составляются другие блоки кода и т.д, - получается иерархичная структура.
    Давайте на конкретном примере.
    Допустим, у нас есть задача реализовать для корпоративной среды сервис быстрого
    обмена сообщениями между сотрудниками. С возможностью обмена файлами, проведения
    видео/аудио-конференций, сохранением истории, также должна быть интеграция с
    Active Directory и шифрование. Предполагается, что серверная часть будет на платформе
    Windows Server, а клиентская - на чем угодно, мобильные устройства в том числе.

    Ваши действия ? С каких конкретно процедур вы начнете писать такую систему ?
    Запись от Убежденный размещена 19.07.2015 в 19:01 Убежденный вне форума
  12. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    Здесь проектируется и общий план, например, формирование API
    Ну, API совершенно другое дело. API - это интерфейс между задачей и пользователем, и к делу не относится. Хотя на сегодняшний день он поглощает почти всё внимание программистов, и до некоторой степени тоже должен подвергаться логическому анализу с точки зрения наилучшего взаимодействия с клиентом.
    Цитата:
    И в чем тогда смысл такого планирования ?
    В том, что это самая главная часть проекта.
    Чем больше мы получим входных данных(т.е. то что мы должны получить на выходе), тем яснее выявится структура будущего проекта в процессе его реализации. Самое главное, ведь, выявить структуру, оптимальный алгоритм решения проблемы. Как говорится: хорошее начало - половина дела. А хорошее начало в программировании это - как можно больше получить параметров на стадии предварительного анализа. Просто - параметров задачи, т.е - что мы хотим конкретно получить. Такая чёткая постановка задачи, на мой взгляд, и есть правильное планирование на стадии предварительного анализа проблемы. Дальше уже в процессе кодинга выявится и вся структура самой задачи. Ну, или должна выявится.
    Цитата:
    Ваши действия ? С каких конкретно процедур вы начнете писать такую систему ?
    Вы хотите чтобы я за вас написал подобную систему?
    Я не силён в групповых политиках Windows Server.
    Можно предположить, что на стороне клиента должна работать какая-то утилита, которая будет взаимодействовать с серверной частью Active Directory, обеспечивая шифрование со стороны клиента, идентификации и пр. Наверно начал бы с этой процедуры. Но это к специалистам.
    Запись от CoderHuligan размещена 19.07.2015 в 20:27 CoderHuligan вне форума
  13. Старый комментарий
    Аватар для Убежденный
    Цитата:
    API - это интерфейс между задачей и пользователем
    Не только.
    Есть еще API для взаимодействия подсистем между собой, которого конечный
    пользователь вообще никогда не видит. И проектировать такой API заранее
    очень важно, чтобы разработчики могли работать над отдельными частями
    системы, не мешая друг другу.

    Цитата:
    Можно предположить, что на стороне клиента должна работать какая-то утилита, которая будет взаимодействовать с серверной частью Active Directory, обеспечивая шифрование со стороны клиента, идентификации и пр. Наверно начал бы с этой процедуры.
    Ну вот я примерно об этом и толкую.
    Дело в том, что на данном этапе еще не ясно, какие протоколы будут использоваться
    для обмена данными, под управлением чего будет серверная часть, будет ли это
    клиент-серверная или пиринговая модель и т.д. Нету даже набросков GUI.
    Какой смысл делать, к примеру, обмен сообщениями по TCP, если позже окажется,
    что следовало делать это с помощью RPC или MSMQ ?

    Разработка "снизу-вверх", на мой взгляд, эффективна для небольших проектов или
    отдельных компонентов, или когда успех всей затеи под сомнением. Вот тогда, пробуя
    один вариант реализации за другим и постепенно достигая определенных целей, можно
    формировать поверх них API, всякие абстракции и тому подобное, двигаясь от
    частного к общему. В таких ситуациях это действительно более удачная модель.
    Но на старте больших проектов, которые представляют из себя уравнение с сотнями
    неизвестных - вряд ли.
    Запись от Убежденный размещена 19.07.2015 в 20:54 Убежденный вне форума
  14. Старый комментарий
    Аватар для Avazart
    Я вот тоже применил "снизу-вверх" прочитал с начала комменты, и запись читать не захотелось ))
    Запись от Avazart размещена 22.03.2016 в 21:48 Avazart вне форума
 
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Рейтинг@Mail.ru