Большой проект, как не запутаться?

[grenles]

Слушайте. ну тут можно и поспорить, а можно и так сказать.

Для того, чтобы построить туалет, архитектора звать не надо.

А чтобы построить хотя бы торговый комплетк молотком, пилой и гвоздями с лету не обойдешься, а то так и выйдет тот самый домик неизвестного архитектора.

Собственно так и в программировании. Если твой уровень крут, ты сел и начал писать. А если крут уровень задания, то тут уже ты начинаешь пИсать и писАть ТЗ, доки и еще рыть и копать интерент и библиотеки в поисках нужных вещей, а также искать нужных людей.

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

Вот собственно и все. Я себя сейчас позиционирую как "Профи с бУквой "У"
И, почему-то мне кажется, я прав в своей логике.

Если короче:
пока задания ниже твоего уровня - тебе ничего не надо - пишешь сходу.
как только уровень задания превышает IQ твоих мозгов - ты компенсируешь это другими средствами - ТЗ, привлечение помощников и прочее.

Все сложное просто.

[SunKnight]

как только уровень задания превышает IQ твоих мозгов - ты компенсируешь это другими средствами - ТЗ

Насмешил. Считай что обозвал всех разработчиков "умственно отсталыми".

Не буду утруждать себя и банально представлю вырезку из вики:

Техни́ческое зада́ние (ТЗ, техзада́ние) — исходный документ для проектирования сооружения или промышленного комплекса, конструирования технического устройства (прибора, машины, системы управления и т. д.), разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).
ТЗ содержит основные технические требования, предъявляемые к сооружению, изделию или услуге и исходные данные для разработки; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской (проектной, технологической, программной и т. п.) документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.

Техническое задание — исходный документ определяющий порядок и условия проведения работ по Договору, содержащий цель, задачи, принципы выполнения, ожидаемые результаты и сроки выполнения работ.

пока задания ниже твоего уровня - тебе ничего не надо - пишешь сходу.

Какие же мозги у ребят из Sun, Oracle...

[alexinspir]

Сообщение от grenles

Слушайте. ну тут можно и поспорить, а можно и так сказать.

...

Собственно так и в программировании. Если твой уровень крут, ты сел и начал писать. А если крут уровень задания, то тут уже ты начинаешь пИсать и писАть ТЗ, доки и еще рыть и копать интерент и библиотеки в поисках нужных вещей, а также искать нужных людей.

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

Вот собственно и все. Я себя сейчас позиционирую как "Профи с бУквой "У"
И, почему-то мне кажется, я прав в своей логике.

Если короче:
пока задания ниже твоего уровня - тебе ничего не надо - пишешь сходу.
как только уровень задания превышает IQ твоих мозгов - ты компенсируешь это другими средствами - ТЗ, привлечение помощников и прочее.

Все сложное просто.

Не стоит путать, я четко написал что я имею в виду:

Сообщение от alexinspir

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

Вопрос был задан также корректно - "Большой проект, как не запутаться?".
Рано или поздно, каждому талантливому разработчику хочется покопаться в чем-нибудь глобальном. Для меня это системы уровня поисковиков, биллингов и т.д.
На практике просто не реально держать в памяти сотни тысяч строк кода(в виде алгоримов) и помнить какая часть за что отвечает. Тот же JavaDoc, на который молится каждый опытный Java-разработчик, помогает понять что делает тот или иной класс/функция, для чего служит то или иное магическое_число/переменная, но он не может детально описать всю структуру в целом.
Очень часто встречаются ситуации когда разработчик(и) уходит из фирмы по некоторым причинам(например, берут выпускника авторитетного вуза в team lead'ы, который ничего не понимая, такую херь творит ...), и на работу берут нового... который без UML диаграмм физически не сможет разобраться в уже написанных массивах кода(в отдельных классах разобраться реально, но как это должно выглядеть в целом - катастрофически трудно).

А задачки студентов... я свою курсовую написал за 2 часа без всякого проектирования(многопоточность, распределенные вычисления, многозвенная структура(3 звена), работа с субд, работа с серверами приложений - Enterprise уровень и т.д.). - такое рассматривать не то что бы не стоит, а стыдно должно быть.

p/s/ IQ 128

[grenles]

Ладно. с Вами связываться, так вы еще сюда БСЭ притащите.
Я смотрю со своих позиций, просто не всегда четко и корректно их выражаю.
Может и насмешил, не спорю. всего текста не читал.

У каждого свой уровень и ребят из SUN, Oracle и прочих я не трогаю, - у них свой путь и свои тараканы.

Я просто говорю свой опыт и свое мнение.А также пытаюсь анализировать.

Просто здешний контингент - это 50% точно - "зеленые студенты". В каком-то смысле я такой же, может поэтому и говорю смешно и ошибаюсь в чем-то.
// пояснение чтобы стало ясно. Я позиционирую себя как не чистого программера, а скорее - программера-одиночку, которые программирует урывками.
// между всем прочим. Мне приходится больше использовать, чем реально программить ввиду некоторых особенностей моей работы.
// в каком-то смысле мне просто физически не хватает времени на изучение многого из того, что тут знают другие, однако это мне не мешает делать и высказываться.
// очень хотелось бы услышать ЧИСТОГО программера, например, раработчика той же фирмы 1С и его мнение о созданиие тех же игра.
// а так - весь здешний разговор - это не системное высказывание личного опыта.

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

Да разве я против этого?!?!? Я другой, - тугодум, в чем-то. Поэтому мне и нужны задания. расшифровки, описания и прочее. МОжет и ушел от заданной темы.

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

1. Изначально понимать общий смысл проекта. Например - Винда - это операционная система, а "сетевое окружение" - это часть ОС, решающей задачи в максимально упрощенной форме для пользователей по работе с сетью

2. Знать чем больш, тем лучше
- разлиные технологии программирования и способы написания кода
- алгоритмы из числа известных (сортировки, поиск, выборки, шифровки, архивироания и прочее)
- структуры данных
и так далее.

2.1. Виртуозно, чем лучше и больше - тем лучше знать тонкости языка, его фишки и особоенности среды программирования и т.п.

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

4. САТОРИ, ОПЫТ, ОЗАРЕНИЕ, ТРИЗ и т.п.- это мышление, это то, что и есть решение задачи и программирование. У каждого это абсолютно индивидуально, хотя и подчиняется общим принципам.

пункт 1 - общее направление
пункт 2. - база, на которой все строится.
пункт 3. - это опыт и интеллект + уже кем-то до тебя придуманные механизмы и твое умение их применить.

пункт 4. - это ТЫ, программист,и то, что ты из себя представляешь.

НО!!!!
При этом не стоит стрелять из "пушки по воробьям" и "плыть на лодке через океан".

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



Вот очередное мое мнение.Коллеги.

[alexinspir]

Написать код, который сразу заработает, почти без отладки и ошибок.

только если код написан за несколько часов.

Если же код разрабатывался несколько дней, и вы в нем вообще не нашли багов при первых тестах - в 90% случаев у вас имеется трудно-уловимый логический баг, либо если использовались unit-тесты, то вероятность наличия багов стремится к нулю. Проверено опытом.

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

[grenles]

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

Пожалуй это лучшая мысль данной темы!!! + 1000 баллов

[Casper-SC]

Чё за Т3 впервые слышу?
Я в шоке, и вправду надо либо сидеть дома целыми днями и некуда не ходить, чтобы выучить что-то, точнее столько! Прикупил себе 4 книжки по Delphi (Програмирование Win32 API в Delphi; Справочник Delphi - Базовые классы; Delphi трюки и эффекты; Rootkits, Spyware/Adware & Backdoors - Обнаружение и защита) + ещё до этого были Программирование в Delphi глазами хакера; Основы программирования в Turbo Delphi; Delphi учимся правильно программировать; Delphi задачи и примеры. Так я не могу до сих пор всё прочитать, а что прочитал и то не полностью и дело не в том, что значит я так хочу учиться, а в том, что я пишу программу и у меня все "силы" уходят на неё, а там уже листаешь справочник, смотришь примеры ищешь в интернете (слава богу, что есть поисковики), потом тут на форуме и если не нашёл, то создаётся тут тема. В общем нету времени, так как работаю с 8 до 17, пн - пт и работа и близко с компьютерами не связана. Плюс ещё все друзья, относятся к моему программированию так скажем не серьёзно, никто не работает с компьютерами и даже в городе негде выучиться, даже на курсах. Ещё помню тут на форуме кто-то говорил, что у меня нету желания...

[ds.Dante]

Сообщение от SunKnight

Насмешил. Считай что обозвал всех разработчиков "умственно отсталыми".

Процитирую книгу Стива Макконнелла - "Совершенный код", посвящённую методам проектирования больших проектов.

Никто не обладает достаточным для программирования уровнем интеллекта. Чтобы полностью охватить и понять сразу все детали даже средней программы, человек должен был бы обладать почти неограниченными возможностями. Способ использования интеллекта важнее, чем его уровень.
...
Самые лучшие программисты — те, кто понимают, насколько ограничены их возможности. Они скромны. ... Чем усерднее вы работаете над компенсацией ограниченных возможностей своего разума, тем лучше будете программировать. Быстрота вашего развития напрямую зависит от вашей скромности.

Сообщение от Casper-SC

Чё за Т3 впервые слышу?

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



Мой порядок действий (не пример для подражания, просто мой текущий уровень):

1) Подробно опрашиваю заказчика/работодателя о всех необходимых функциях, одновременно рисуя в своей рабочей тетради примерный вид программы (так, чтобы клиент видел). Предлагаю свои возможные функции программы.
2) Рисую в тетради подробный вид программы - часто помогает придумать неочевидную функциональность. Т. е. не функциональность определяет интерфейс, а наоборот. Конечно, это не относится к написанию драйверов и прочих системностей.
3) Продумываю структуру классов, по мере необходимости делая наброски в тетради.
4) Пишу отдельные классы, один за другим, каждый - в составе консольной программы (чтобы было легче отлаживать); тщательно отлаживаю класс.
5) Пишу собственно программу, вставляя в неё готовы классы.
6) Когда готова бета - прохожусь по коду (мысленный компилятор :), оптимизирую, удаляю закомментированный код, пишу подробные комментарии на будующее.
7) Оформляю программу - пишу документацию, рисую иконки, и т. д.
8) Тщательно тестирую программу, выдумываю самые невообразимые сочетания конфигурации и действий пользователя.
9) Даю на тестирование своему коллеге.

Если пишу для себя - первый и последний пункт отсутствуют.

P. S. Я тоже, пожалуй, буду требовать ТЗ в обязательном порядке.

[Utkin]

Да ладно, вот все тыкают много разработчиков, сторонний код, ТЗ и пр. Да ботва это все и зависит исключительно от личной организации программиста. Вот я пишу на Дельфи 100 строк, так Вы считаете, что это не взаимодействие с многими разработчиками? А VCL по Вашему я сам что ли писал? Или всеми любимый WinApi? Нет здесь четких границ, просто grenles немного неудачно выразился называя это IQ. Также если пишу что-то большое и сложное, я могу обойтись без всяких графиков и таблиц и уж тем более без ТЗ. Мне достаточно знаний интерфейсной части модулей (и так и должно быть). А ошибки и сложность проекта с этим конечно связано, но не так сильно, как считают некоторые. Просто у человека стек маленький и он не помнит кучу всяких мелочей. Но если я придерживаюсь неких строгих принципов и создал четкую и простую организацию, я смогу закончить проект в приемлимые сроки.

Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.

Что и делает его бесполезным. Просто ТЗ это стандарт взаимодействия между разработчиками, заказчиками и т.д.

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

Ну напишите блок-схему Виндовс ХР, или линукса, а то, я все время забиваю голову всякой ерундой .

[Stilet]

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

Вкорне не согласен. Я использовал TListBox для отображения файла метра 2 весом - тормоза были невероятные.
Плюнул "изобрел велик" и не жалею, так что терь меня нельзя назвать разработчиком только потому что я стандартные средства откинул?