Шерлок Холмс и планирование. Из найденных записок кодомана.
Сосункам читать не рекомендуется! Холмс против планирования.  Патриархи от структуры во всех пособиях предлагали и до сих пор предлагают начинать написание программ с планирования. С чёткого представления общей структуры программы. Это так называемая "разработка сверху вниз". Но, как показывает практика, такие заповеди могли родится лишь в теоретических головах кабинетных учёных. На практике всё становится гораздо сложнее. Причём тут Холмс? При том, что он против планирования, - он за дедукцию.  Если бы холмс, встретившись с новым для себя делом, сначала запланировал все свои будущие шаги по раскрытию этого дела, то с вероятностью в 99,99% он бы это дело не раскрыл (либо "раскрыл", но посадили бы невиновного  ).Холмс знает лишь то, что случилось - факт произошедшего события, поэтому глупо было бы с его стороны начинать планирование начиная со стадии входных данных. Но задачу как-то необходимо решать. Что мы имеем? Мы знаем, что мы должны получить в результате решения поставленной задачи, то есть - знаем, что будет на выходе. Но мы совершенно не имеем понятия как это должно быть реализовано! Совершенно также как Шерлок Холмс не имеет понятия о том, кто является преступником. Это самое сложное, и в то же время выход существует. Холмс начинает наблюдать за деталями, которые помогли бы ему раскрыть преступление. Он начинает искать УЛИКИ. Обьективно - задача уже имеет решение, но это решение далеко лежит за пределами нашего знания. Наша задача вместе с Холмсом просто найти улики, по которым как по ниточке возможно было бы размотать весь хитрый клубок трудной задачи. Планирование здесь не поможет, но у нас имеются улики. Один окурок для Холмса может означать раскрытие всего преступления. Ведь этот окурок - не просто окурок, а ключ к решению нашей задачи... Этот окурок может многое для нас значить. Ведь он встроен в строгую логическую схему, по которой выстроено всё здание задачи. Причем однозначная схема! У нас есть свои улики - необходимые переменные, массивы и т.д. Мы не должны ничего планировать заранее, причём мы должны специально отказаться от планирования! Мы должны единственно - с твёрдостью волчьей хватки, зацепиться за наши улики, то есть - те данные которыми мы обладаем на данный момент. Эти ключи и приведут нас к победе. Холмс - наш друг, он нам поможет! Применим дедукцию, цепочку логических умозаключений, применительно к уликам, и постепенно картина будет прояснятся всё чётче и яснее, пока не станет совершенно очевидной. Возможно по началу мы можем подозревать, что кто-то или что-то имеет цикл(к примеру). Это всего лишь подозрение и мы не должны сразу его использовать, но мы должны вывести необходимость его применения в данном месте только исходя из логических предпосылок, и никак иначе. Более того поначалу полезно совершенно отказаться от применения обычных циклических блочных конструкций и заменить их безусловными переходами. Потом если кодер захочет он может их заменить на обычные. Но если он начнёт их применять с самого начала он натолкнётся на грабли преждевременного планирования, а этого-то мы и хотим избежать, не забыли? ХеХе. Планирование - вред, - скажи преподу!(поговорка  ) Ура дедукции!! Улики встроены в цепочку логической структуры программы, и поэтому не трудно применяя логические выводы(методы) выявить её начало и конец. Таким образом программа может строится с любого места, - с середины или с конца и т. д., главное наблюдательность к уликам.  Если отказаться от планирования, то задача будет решаться как по маслу, - программирование превратится в удовольствие, а не в бесплодные попытки втиснусь в прокрустово ложе заранее неправильного плана свои идиотские попытки его реализовать. Продолжение возможно следует... Правда если будут найдены другие записки свихнувшегося кодомана...  |
Всего комментариев 14
Комментарии
-
Не болтайте ерундой.
Без планирования можно написать разве что только курсовую в путяге. Ни один крупный (т.е. командный) проект без чёткой и продуманной структуры не реализовать.Запись от rao размещена 13.07.2015 в 18:36 
-
Авторы многочисленных книг по организации и планированию разработки тихо плачут...
Нужно различать творческий подход и разгильдяйство.Запись от tezaurismosis размещена 14.07.2015 в 08:52
-
Никто с этим и не спорит.Цитата:Сообщение от rao
Ни один крупный (т.е. командный) проект без чёткой и продуманной структуры не реализовать.
Крупный проект всегда делится на множество подзадач, которые обусловлены известными разработчикам начальными условиями на стадии обдумывания целей проекта.
Дальше уже начинаются сами задачи, которые можно решать по разному.Запись от CoderHuligan размещена 14.07.2015 в 13:56
-
Верно.Цитата:Сообщение от tezaurismosis
Нужно различать творческий подход и разгильдяйство.
Разгильдяйство можно выявить "по факту", то есть по результату того или иного творческого подхода к данной задаче. Если конечный продукт работает, работает быстро и хорошо, то совершенно не важно каким способом это достигнуто.
Конечно, путь который предлагает тот самый кодоман, не всем подходит, так как это зависит от разных характеров и темпераментов людей. Всех под одну гребёнку не причешешь. У меня вроде получается.Запись от CoderHuligan размещена 14.07.2015 в 14:25
-
Спору нет, но представьте следующую ситуацию.Цитата:Сообщение от CoderHuliganсовершенно не важно каким способом это достигнуто
У вас есть коробка с сахаром, её нужно пересыпать в большую коробку, у которой есть только маленькое отверстие.
Способ первый - "спланировать" насыпание - сыпать сахар тонкой струйкой, наверняка просыплется немного.
Способ второй - просто перевернуть коробку - сколько попало, столько попало, собрать просыпавшееся и снова до полного результата.
Вопрос: каким путём вы засыплете сахар быстрее?Запись от tezaurismosis размещена 16.07.2015 в 17:41
-
Правильно, - мы сразу понимаем, что нужно сыпать тонкой струйкой, так как этот способ согласуется с нашими прошлыми унаследованными знаниями и опытом. Сыпать тонкой струйкой - это очевидное решение, которое сразу приходит на ум. Нам и в голову не может прийти, что можно насыпать сахар горкой на другую коробку, а потом ладошкой или ложечкой потихоньку подгребать сахар к отверстию, до тех пор, пока весь сахар, до последней крупинки, не окажется в другом ящике. А можно также насыпав горкой сахар на другой ящик, потом накрыть этот ящик пустым ящиком, в котором находился сахар, а затем начать трясти эти оба ящика, пока по закону вероятности все крупинки не окажутся в нижнем ящике, просыпавшись в отверстие. При этом тоже не пропадёт ни одной крупинки, так как сахар накрыт пустым ящиком, что будет препятствовать его разлёту в разные стороны во время тряски.Цитата:Сообщение от tezaurismosis
Спору нет, но представьте следующую ситуацию.
У вас есть коробка с сахаром,
Вот сколько вариантов. И кто знает, какой из них самый оптимальный в данных условиях... Но мы сразу берём самый очевидный вариант и начинаем его осуществлять. И не важно, что надо постоянно напрягать внимание, чтобы попасть точно в центр отверстия, - мы потерпим. И совсем не важно, что сахар вряд ли будет сыпаться тонкой струйкой, так как с точки зрения физики это невозможно. Это только в нашем представлении он будет сыпаться тонкой струёй, на практике же будет большой разлёт, и часть частичек окажется на полу, отскочив от краёв отверстия. Этого-то мы и не учли, - мы сразу ринулись в бой, решать поставленную задачу, по заранее намеченному плану.Запись от CoderHuligan размещена 17.07.2015 в 14:41
Обновил(-а) CoderHuligan 17.07.2015 в 14:43 -
Оно очевидное по одной из двух причин - либо в детстве сами сыпали навалом и поняли, что нужно аккуратно, либо в том же детстве кто-то из старших посоветовал так сыпать. Сыпать сахар навалом проще, потому что это требует меньше знаний.Цитата:Сообщение от CoderHuliganэто очевидное решение, которое сразу приходит на ум
Мне даже страшно представить, сколько лет нужно программировать и работать над реальными проектами, чтобы *каждый* аспект работы кода, любой функционал и проч. казалось очевидным.
Плюс к этому - то что кажется очевидным, не всегда верно.Запись от tezaurismosis размещена 18.07.2015 в 08:42
-
Совершенно согласен.Цитата:Сообщение от tezaurismosis
Мне даже страшно представить, сколько лет нужно программировать и работать над реальными проектами, чтобы *каждый* аспект работы кода, любой функционал и проч. казалось очевидным.
Плюс к этому - то что кажется очевидным, не всегда верно.
Я и пытаюсь доказать, что на начальном этапе ничего не очевидно. Только в процессе реального кодинга становятся очевидными определённые вещи. Только совершенный гений может(а может - и не может) представить в уме программу во всех своих подробностях, да при этом, ещё и самый оптимальный алгоритм этой программы, так как вариантов написания существует множество.Запись от CoderHuligan размещена 18.07.2015 в 16:00
-
Интересно, здесь кто-нибудь считает себя сосунком ?Цитата:Сообщение от CoderHuliganСосункам читать не рекомендуется!
Обе эти точки зрения являются крайностями. Без планирования невозможен нормальныйЦитата:Сообщение от CoderHuliganЕсли отказаться от планирования, то задача будет решаться как по маслу, - программирование превратится в удовольствие, а не в бесплодные попытки втиснусь в прокрустово ложе заранее неправильного плана свои идиотские попытки его реализовать.
процесс разработки. Или вы будете постоянно что-то переписывать, перепроектировать и в
итоге, скорее всего, погрязнете в технических долгах. С другой стороны, на этапе
планирования нельзя сразу предвидеть многих вещей. Но планирование - это в первую
очередь составление "целой" картины, а не проработка каждой детали до последнего
винтика. Потом у этой картины постепенно определяются составляющие части, каждая
часть прорабатывается все глубже и глубже, до той детализации, которая вообще имеет
смысл на данном этапе, открываются какие-то конкретные проблемы, ранее неучтенные нюансы.
Для идей, успех которых под сомнением, делаются прототипы. Определяется, какие могут
быть проблемы с производительностью, сможет ли программа работать на терминалах, не
будет ли заморочек с безопасностью, можно ли будет работать с ней из-под
ограниченного аккаунта, в каких направлениях будет расширяться программа и т.д.
Для отдельных подсистем и бизнес-уровней проектируется свой API, через который
они смогут обмениваться данными. Все это делается именно на этапе планирования
техническими специалистами и архитекторами ПО, которые, с высоты своего опыта и знаний,
могут сходу ответить на все или большинство этих вопросов, не прибегая к созданию
прототипов и проведению тестов. К тому времени, когда люди сядут писать код, все
или почти все его критические участки будут уже испытаны в бою. Но и после этого
планирование не заканчивается, т.к. всплывают ранее незамеченные "грабли", программа
наталкивается на различные ограничения и тому подобное, и все это нужно своевременно
обсуждать и корректировать курс. Вот что такое планирование, IMHO, а вовсе не
составление плана в стиле "что я буду делать во вторник вечером 2029 года".Запись от Убежденный размещена 18.07.2015 в 19:32
-
Хочу определится с тем, кого считать или не считать таковым. Те кто знаком со статьёй, которую написал Эд Пост из Орегонской компании Tektronix в 1983году:http://lib.ru/ANEKDOTY/non_pas.txt те поймут о чём идёт речь. Сосунки это не те зелёные юнцы, которые только начинают учиться программированию, - совсем нет. Сосунки это те, кто боится использовать операторы goto; это те, кто клал на алгоритм ради приверженности какой-то парадигме программирования, будь то ООП или чисто структурный стиль. Это те, кто коверкает свой код, только ради того, чтобы их не записали в быдлокодеры, которые пишут говнокод. Я считаю, что как раз всё наоборот. Потому что эти парадигмы против истинной структуры - Алгоритма.Цитата:Сообщение от Убежденный
Интересно, здесь кто-нибудь считает себя сосунком ?
Это разработка сверху вниз в классическом варианте. Она уже неоднократно подвергалась критике за трудность тестирования отдельных кусков кода пока не будет написана последняя его строчка. В этом смысле разработка снизу вверх намного лучше как рекомендуют делать некоторые фортеры. В этом случае можно сразу начинать тестировать программу с нижних уровней, постепенно подбираясь к верху. Сначала пишутся процедуры, потом из этих процедур составляются другие блоки кода и т.д, - получается иерархичная структура.Цитата:Вот что такое планирование, IMHO, а вовсе не
составление плана в стиле "что я буду делать во вторник вечером 2029 года".
Я не против планирования как такового. Важно понять - что такое правильное планирование. На мой взгляд, план - это всего лишь постановка задачи вместе с её исходными данными, не более того.Запись от CoderHuligan размещена 19.07.2015 в 14:28
Обновил(-а) CoderHuligan 19.07.2015 в 14:29 -
Вовсе нет. Здесь проектируется и общий план, например, формирование API, иЦитата:Это разработка сверху вниз в классическом варианте.
прорабатываются конкретные детали реализации, из-за которых этот план
может меняться. Неуклонное следование догматическому "сверху-вниз" или
"снизу-вверх" - это тупик, настоящий процесс сложнее, итеративнее, в нем
больше живого и непосредственного, чем в этих формальных принципах.
И в чем тогда смысл такого планирования ?Цитата:Важно понять - что такое правильное планирование. На мой взгляд, план - это всего лишь постановка задачи вместе с её исходными данными, не более того.
Давайте на конкретном примере.Цитата:В этом смысле разработка снизу вверх намного лучше как рекомендуют делать некоторые фортеры. В этом случае можно сразу начинать тестировать программу с нижних уровней, постепенно подбираясь к верху. Сначала пишутся процедуры, потом из этих процедур составляются другие блоки кода и т.д, - получается иерархичная структура.
Допустим, у нас есть задача реализовать для корпоративной среды сервис быстрого
обмена сообщениями между сотрудниками. С возможностью обмена файлами, проведения
видео/аудио-конференций, сохранением истории, также должна быть интеграция с
Active Directory и шифрование. Предполагается, что серверная часть будет на платформе
Windows Server, а клиентская - на чем угодно, мобильные устройства в том числе.
Ваши действия ? С каких конкретно процедур вы начнете писать такую систему ?Запись от Убежденный размещена 19.07.2015 в 19:01
-
Ну, API совершенно другое дело. API - это интерфейс между задачей и пользователем, и к делу не относится. Хотя на сегодняшний день он поглощает почти всё внимание программистов, и до некоторой степени тоже должен подвергаться логическому анализу с точки зрения наилучшего взаимодействия с клиентом.Цитата:Здесь проектируется и общий план, например, формирование API
В том, что это самая главная часть проекта.Цитата:И в чем тогда смысл такого планирования ?
Чем больше мы получим входных данных(т.е. то что мы должны получить на выходе), тем яснее выявится структура будущего проекта в процессе его реализации. Самое главное, ведь, выявить структуру, оптимальный алгоритм решения проблемы. Как говорится: хорошее начало - половина дела. А хорошее начало в программировании это - как можно больше получить параметров на стадии предварительного анализа. Просто - параметров задачи, т.е - что мы хотим конкретно получить. Такая чёткая постановка задачи, на мой взгляд, и есть правильное планирование на стадии предварительного анализа проблемы. Дальше уже в процессе кодинга выявится и вся структура самой задачи. Ну, или должна выявится.
Вы хотите чтобы я за вас написал подобную систему?Цитата:Ваши действия ? С каких конкретно процедур вы начнете писать такую систему ?
Я не силён в групповых политиках Windows Server.
Можно предположить, что на стороне клиента должна работать какая-то утилита, которая будет взаимодействовать с серверной частью Active Directory, обеспечивая шифрование со стороны клиента, идентификации и пр. Наверно начал бы с этой процедуры. Но это к специалистам.Запись от CoderHuligan размещена 19.07.2015 в 20:27
-
Не только.Цитата:API - это интерфейс между задачей и пользователем
Есть еще API для взаимодействия подсистем между собой, которого конечный
пользователь вообще никогда не видит. И проектировать такой API заранее
очень важно, чтобы разработчики могли работать над отдельными частями
системы, не мешая друг другу.
Ну вот я примерно об этом и толкую.Цитата:Можно предположить, что на стороне клиента должна работать какая-то утилита, которая будет взаимодействовать с серверной частью Active Directory, обеспечивая шифрование со стороны клиента, идентификации и пр. Наверно начал бы с этой процедуры.
Дело в том, что на данном этапе еще не ясно, какие протоколы будут использоваться
для обмена данными, под управлением чего будет серверная часть, будет ли это
клиент-серверная или пиринговая модель и т.д. Нету даже набросков GUI.
Какой смысл делать, к примеру, обмен сообщениями по TCP, если позже окажется,
что следовало делать это с помощью RPC или MSMQ ?
Разработка "снизу-вверх", на мой взгляд, эффективна для небольших проектов или
отдельных компонентов, или когда успех всей затеи под сомнением. Вот тогда, пробуя
один вариант реализации за другим и постепенно достигая определенных целей, можно
формировать поверх них API, всякие абстракции и тому подобное, двигаясь от
частного к общему. В таких ситуациях это действительно более удачная модель.
Но на старте больших проектов, которые представляют из себя уравнение с сотнями
неизвестных - вряд ли.Запись от Убежденный размещена 19.07.2015 в 20:54
-
Я вот тоже применил "снизу-вверх" прочитал с начала комменты, и запись читать не захотелось ))Запись от Avazart размещена 22.03.2016 в 21:48
