Этапы разработки ПО

[maksimdag0]

Доброго дня! Хочу изучить этапы разработки кода, на языке си пишу(или другими словами описание планировки кода) в гугле все размыто, в основном несколько советов от себя и все. В общем путного ничего не нашел, может я плохо искал?
Может кто знает где можно это почитать, книги может какие-то стоит почитать? Буду очень благодарен, и извиняюсь, если написал не туда.

[GARMIN]

1. Бизнес планирование
2. Требования к софту
3. Интерфейс
4. Бизнес логика
5. Тестирование
6. Разворачивание и интеграция
7. Поддержка

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

[VladislavS]

Всё гораздо проще в жизни:
1. Запустить IDE
2. Создать проект
3. Написать код
4. Скомпилировать
5. Исправить ошибки
6. Скомпилировать
7. Протестировать результат
8. Вернуться к 3
9. Прочитать ТЗ

[linkov1959]

VladislavS, А функциональную блок схему уже не рисуют? Меня учили какие-то квадратики, ромбики, кружочки рисовать. Я не рисовал, с ходу писал код.

Последний раз редактировалось linkov1959 Пн ноя 20, 2023 22:02:28, всего редактировалось 1 раз.

[maksimdag0]

VladislavS писал(а):

Всё гораздо проще в жизни:
1. Запустить IDE
2. Создать проект
3. Написать код
4. Скомпилировать
5. Исправить ошибки
6. Скомпилировать
7. Протестировать результат
8. Вернуться к 3
9. Прочитать ТЗ

Эти тапы-то пройдены, опыт есть, но ведь станешь лучше, если изучишь теорию.

Добавлено after 2 minutes 14 seconds:

GARMIN писал(а):

1. Бизнес планирование
2. Требования к софту
3. Интерфейс
4. Бизнес логика
5. Тестирование
6. Разворачивание и интеграция
7. Поддержка

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

Спасибо за развертывание

Добавлено after 1 minute 22 seconds:

linkov1959 писал(а):

VladislavS, А функциональную блок схему уже не рисуют? Меня учили какие-то квадратики, ромбики, кружочки рисовать. Я не рисовал, с ходу писал код.

Я блок-схему тоже не рисую, но вопрос захватывает шире понятия этапы разработки ПО)

Добавлено after 1 minute 43 seconds:
Дело в том что наверняка умные люди уже написали много информации о том как организовывать, планировать, разрабатывать код наиболее эффективнее, быстрее и лучше. Вот хотелось бы прочитать, так как это более рационально.

[linkov1959]

maksimdag0, Ну если шире, то у японцев, к примеру, все пособия начинаются с требованием сначала набраться душевного равновесия.
После прочтения романа "Дзен и искусство ухода за мотоциклом" скорость и качество работы увеличилась на порядок.

[Николай_С]

Как решить сложную задачу на компьютере? Да очень просто:
1. Включить компьютер.
2. Решить задачу.
3. Выключить компьютер.

[Муркиз]

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

(К последнему посту это не относится )

[LastHopeMan]

maksimdag0, дружище, ты сайтом ошибся. Тут научат светодиодом помигать на ардуине.

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

Когда изучишь полностью синтаксис и определишься с компилятором и средой разработки (а заодно поймешь, это все же будет C++ или C#), то изучай типы данных и алгоритмы. Всякие разные, например алгоритмы сортировки, алгоритмы шифрования, сжатия данных. Типы данных на примере очередей, стеков, разреженных матриц. Если будет понимание этого всего, то можно приступать к чему-то более серьезному.

Реальные задачи на любом языке решаются практически одинаково с поправкой на сферу деятельности заказчика. Большое значение имеет необходимая степень бюрократии. Чем ее меньше, тем оперативнее решаются вопросы, но при этом хаос может негативно влиять на разработку. В целом все работают примерно по такому плану:
1. Понимание задачи. Если не можешь сформулировать - значит задачи нет, расходимся. Пишется тезисно на бумажке с зарисовками и т.д., обычно в процессе беседы с заказчиком.
2. ТЗ. Это первый этап, положенный на алгоритмы. Часто эту хрень пытаются согласовать с заказчиком, но это не совсем корректно, согласовывать нужно дополненный первый этап, а не этот. Потому что заказчик нормальное ТЗ никогда не поймет =)
А почему нельзя сразу согласоваться с заказчиком до написания ТЗ - это очевидно потому что в процессе написания ТЗ будет куча вопросов, куча промежуточных контактов с заказчиком и некий торг по тем моментам, где "можно сделать лучше" или "невозможно реализовать потому что есть аппаратные ограничения".
3. Кодинг. Просто дается ТЗ кодеру, тупому кодеру, который вообще не бум бум что за заказчик, чем он занимается и для чего вообще его программа будет использована. По-хорошему, ТЗ должно быть именно таким, чтобы кодер просто перевел с русского на сишный. К вопросу про бюрократию, часто ТЗ пишет и кодит один и тот же, поэтому ТЗ пишется спустя рукава без подробностей или вообще не пишется, вот это типа быстрее и без лишней бюрократии, но... уже в процессе разработки могут возникнуть трудности и необходимость пересогласоваться с заказчиком. Ну и сроки реализации без нормального ТЗ оценить трудно. Без ТЗ результат ХЗ.
4. Тестирование. Программист должен проверить, что ТЗ соблюдаются. Часто тесты пишут те, кто и пишет ТЗ (и часто тестят они же), это как кому милее.
5. Бета тест. Заказчику дают попробовать, пощупать.
6. Доработки. По результату бета тестов, всяких хотелки и багфиксы. Иногда бывает, что вообще нужно было не то и поняли это только сейчас, так что начинай сначала в пункт 1 =)
7. Сдача. Подписываются документы, жмут руки, берут деньги, отмечают.


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

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

[maksimdag0]

Понял. Приму к сведению. Спасибо!

[electroget]

linkov1959 писал(а):

VladislavS, А функциональную блок схему уже не рисуют?

Что значит "уже"? Её и раньше никто не рисовал. Программисты считают это совершенно ненужным занятием. В результате никто не может чем они вообще занимаются, да и результата на выходе в большинстве случаев никакого нет.

[Муркиз]

Это изучается на 2-4 курсах факультетов с кафедрами программирования, никем из профессоров на моей памяти, не систематизировано.

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

А ведь иначе всякие там Луны-14 разбиваются от непродуманного и не рассчитанного потока данных на вычислитель.

А водить - это лишь школьников учат.

[linkov1959]

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

[electroget]

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

[alexander.k]

Почитайте про scrum и другие agile методики разработки. Там все хорошо формализировано...но несколько оторвано от реальности. Не разу не видел, чтобы этому следовали 100%. Чаще берут отдельные куски этих методик и лепят свой процесс разработки.

В крупных конторах часто используют "водопад". Годится если есть четкое ТЗ которое менять нельзя.

[LastHopeMan]

electroget, под программистом на рынке труда сейчас подразумевают разработчика и программиста в одном лице, кроме случаев, когда явно пишут "написание кода по ТЗ". Хотя и там лукавят, потому что технолог-аналитик далеко не у всех имеется, а под ТЗ подразумевается пара тезисов, написанных заказчиком на туалетной бумаге.

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

В моих кругах программиста "только по ТЗ" принято называть кодером.

alexander.k, я думаю, ТСу рановато и ни к чему изучать типичную айтишную бюрократию, потому что без профильного образования и приличного опыта, оно не применится. Кроме того, эти методы на практике больше подходят для копошения в дерьме (ну или рутинный процесс выживания) и красивых отчетах перед начальством, типа у нас все под контролем. Прекрасный инструмент, которые позволяют айтишному директору ничего не достигать, но еженедельно отчитываться о куче сделанного Хотя наверное хоть раз одна из них работала, там, где ее придумали и более нигде.

Добавлено after 3 minutes 1 second:

maksimdag0 писал(а):

(или другими словами описание планировки кода)

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

[Муркиз]

LastHopeMan, а вот скажи, сколько лет твоя программа проработала без ошибок при постоянном ежедневном использовании организацией в сетевом варианте ?

[LastHopeMan]

Муркиз, мои разработки работают пожизненно. По сути, пока не потеряют актуальность.
А вот в совместных разработках статистика иная.

Нужно тестировать хорошо свои продукты, изучив процессы, для которых их создаешь. И тогда не придется оглядываться, выходя на улицу.

[Муркиз]

Ну и сколько лет той жизни прошло ?

[LastHopeMan]

Муркиз,
0. На кого отучился? Где? Какие дипломы?
1. Кем работаешь? В какой компании?
2. Какой оклад? Какой дополнительный доход?
3. Где живешь?
4. Какова кадастровая стоимость твоей недвижимости? Какова стоимость ремонта и мебели?
5. Какие достижения по жизни?
6. Чего добился на работе? За сколько лет?
7. Какие планы на оставшиеся годы жизни?