пара тупых вопросов программерам

[senior_pomidor]

Несколько глупых вопросов программистам

1) Как грамотно написать тз (было бы супер, если бы кто-нибудь показал кусок правильно составленного тз), чтобы программер не вьёбывал себе мозги и не тратил своё время на осознание написанного заказчиком?
2) Чем обычно пользуются программеры для контроля версий\тудулистов и контроль за выполнением оных? тхт файл чота не рулит. неудобно, сука. php\mysql\c++
3) Где лучше брать сниппеты\шабоны-заготовки (например голый скрипт админки с авторизацией, не с нуля же всю эту хуету писать +)))
4) в конце концов посоветуйте что-нибудь грамотно написанное или софт по регуляркам )) нихуя не могу в них вьехать. с частности интересует PCRE.

спасибо.

[senior_pomidor]

ах да, ещё:
5) как вообще проектируется\закладывается\реализуется возможность расширения софта потом? в том же пхп на ум приходит только вынесение ядра и ключевых компонентов в отдельные файлы в виде функций, по типу как это делается с dll.
6) как вы себя заставляете сидеть и отлаживать один баг 3 часа ))

[solar]

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

2) svn- контроль версий, wiki- для документирования и общения. Вообще вики очень сильно рулит для разработки.

3) на пхп не знаю, а так вообще django решает (это питон)

4) вот тебе чудо сайт: http://txt2re.com/, а из доков лучшее что есть вот - http://www.ozon.ru/context/detail/id/1379940

5) модульность и достаточный уровень абстракции. Опять же есть такая штука как стоимость разработки и если ты под простой проект собираешься городить код не нужный - остановись. Тебе же будет потом сложнее разобраться в нем. Важен принцип задача-решение, а все что между ними по сути не важно. Лучше написать на коленке десять коротких, но работающих функций, чем один невъебенный класс, который замучаешься отлаживать.

6) заставлять очень просто - кушать то хочется

[senior_pomidor]

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

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

2) svn- контроль версий, wiki- для документирования и общения. Вообще вики очень сильно рулит для разработки.

3) на пхп не знаю, а так вообще django решает (это питон)

4) вот тебе чудо сайт: http://txt2re.com/, а из доков лучшее что есть вот - http://www.ozon.ru/context/detail/id/1379940

5) модульность и достаточный уровень абстракции. Опять же есть такая штука как стоимость разработки и если ты под простой проект собираешься городить код не нужный - остановись. Тебе же будет потом сложнее разобраться в нем. Важен принцип задача-решение, а все что между ними по сути не важно. Лучше написать на коленке десять коротких, но работающих функций, чем один невъебенный класс, который замучаешься отлаживать.

6) заставлять очень просто - кушать то хочется

спасибо за ответ!

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

и, кстати, по поводу питона. можешь озвучить основные его преимущества перед тем же php?

[solar]

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

спасибо за ответ!

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

и, кстати, по поводу питона. можешь озвучить основные его преимущества перед тем же php?

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

Например, есть задача регистрировать домены. В эту задачу входит проверка входных данных, проверка незанятости домена, проверка баланса у регистратора, регистрация домена, смена ДНС, высылка отчета на твой емайл. Вот тут уже 6 функций между собой не связанных. Можно сделать класс, где эти функции будут методами. Но зачастую даже классы в таком деле это лишний головняк. Это лично мое мнение конечно, но лучший девиз для программера сформулирован гуглом и звучит так: Release often, release fast.
То есть иногда можно самолет дособрать уже в воздухе, если ты меня понимаешь

насчет питона, собственно питон отлично соответствует этому девизу, код получается легим и удобным и вообще язык приятный. Django, это фреймворк для питона, позволяет тебе буквально за полчаса получить готовую базу данных с интерфейсом администратора, авторизацией и т.д. Очень экономит время: http://docs.djangoproject.com/en/dev/intro/tutorial01/
идеально для быстрого написания всяких фронтэндов

[MasterMushi]

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

Далее по ТЗ. вы не поаерите но есть ГОСТ 19.201-78 в котором говорится как писать ТЗ.

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

Что имеем в результате - Юзер стори и ТЗ две разные вещи. первая вещь это просто почитать и выкинуть. а ТЗ это уже документ который можно давать программисту и тестировщику

[senior_pomidor]

о, спасибо большое.

пс. продолжаю ждать ваши мнения +)

[JackL]

насчет контроля разработки посмотри unfuddle.com и basecamp штуки как для этого сделанные

[Farik]

1) Как грамотно написать тз (было бы супер, если бы кто-нибудь показал кусок правильно составленного тз), чтобы программер не вьёбывал себе мозги и не тратил своё время на осознание написанного заказчиком?

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

Смысла придерживаться ГОСТа, ISO, CMMI или PMI особого нету. Все эти стандарты придуманы для налаживания бизнес процессов в больших группах, а не для улучшения понимания ТЗ конкретным программистом.

Методологиии user story XP/Scrum которые уже упомянали - это действительно работает и работает хорошо. Но требует чтобы исполнитель принимал эти условия. Большинство программистов, особенно на ПХП, к сожалению с большим трудом идут на усвоение новых для себя вещей.

2) Чем обычно пользуются программеры для контроля версий\тудулистов и контроль за выполнением оных? тхт файл чота не рулит. неудобно, сука. php\mysql\c++

Конкретно программеры этим занимаются чрезвычайно редко. Обычно по поводу тудулиста им жопу рвут манагеры.
В большинстве IDE есть стандартные средства поиска тегов //TODO:, //XXX: и тд. В эклипсе над этой темой навёрнут ещё плагин Myliar. В качестве тудулиста хватает за глаза и за уши.
Если хочется чего то одельного от IDE(или не привязанного к компу и коду, либо необходима иерархия задач) - есть todoist.com, rememberthemilk.com. Оффлайновый есть программулька mylifeorganized.

Если переходить на уровень команды, то это уже trac.
Он заточен под малые группы разработки. SVN+wiki+tickets+milestones. Вобщем если эти четыре слова знакомы, то маст хев.

3) Где лучше брать сниппеты\шабоны-заготовки (например голый скрипт админки с авторизацией, не с нуля же всю эту хуету писать +)))

На ПХП фреймворки - CakePHP(списан с RubyOnRails), Symfony(наворочан жутко), Zend(без коментариев).
На питоне - Django, Zope
На руби - RubyOnRails понятно 8)

4) в конце концов посоветуйте что-нибудь грамотно написанное или софт по регуляркам )) нихуя не могу в них вьехать. с частности интересует PCRE.

Шота вот скинутый пример на txt2re.com нифига на мой взгляд не тянет на роль "помочь разобраться с регулярками" 8)
Конкретно "упражнений для начинающих" - никогда не видел, тк вроде как это просто будут примеры из документации.
В качестве тестового стенда, не привязанного к IDE могу порекомендовать http://weitz.de/regex-coach/ . Опять же если в эклипсе есть приличный плагин, в комодо он тоже присутсвует.

5) как вообще проектируется\закладывается\реализуется возможность расширения софта потом? в том же пхп на ум приходит только вынесение ядра и ключевых компонентов в отдельные файлы в виде функций, по типу как это делается с dll.

Ваще вопрос глобальный.
Функциональное, структурное, ООП, АОП - все вобщем то только для того и делались, чтобы сделать написание программ проще, а модификацию дешевле 8)
Если будешь использовать фреймворки, то вобщем то писать получается будешь только уникальные для конкретного проекта куски кода. А сам фреймворк будешь использовать во всех проектах неизменным.

А возможность внесения изменений в существующий код - это уже вопрос правильной архитектуры, покрытия кода тестами.
На эту тему Фаулер "Рефакторинг" и Бек "Тест-драйв девелопмент".

Вообще если вопрос стоит так

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

То в первую очередь в обязательном порядке надо ознакомиться с первыми 50-100 страницами "Рефакторинга" Фаулера, после чего должно появиться понимание, почему именно то, что ты считаешь ООП, на самом деле им не является. Если понимание придёт, то нужно раза три прочитать "Паттерны проектирования" четырёх(гамма-хелм-джонсон-влиссидес). После чего можно возвращаться к рефакторингу. Часть проблем с проектированием после прочтения этих двух книг должна уйти в прошлое. В дальнейшем читать положительную литературу по ООП рецептом не возбраняется.

6) как вы себя заставляете сидеть и отлаживать один баг 3 часа ))

Ну как. Тошнит, руки дрожат, все вокруг пидорасы и тд. Но баг то исправить надо 8)

[sandy]

2) cvs или svn для контроля версий. как правило, современные IDE поддерживают или то, или другое (через плагины или даже по дефолту)
3) много где, смотря что конкретно тебе надо. можно заюзать готовые фреймворки в качестве каркаса твоего приложения, можно найти в недрах репозиториев опен сорса что-то похожее и переделать под себя, можно копипастить из гугля по нескольку строк кода сам понимаешь, это все разные уровни code reusing
4) не можешь въехать - не юзай. без регулярок можно обойтись всегда, и они реально упрощают код лишь в отдельных специфичных случаях. зато запросто могу превратить код в нечитабельную кашу, которую потом проще с нуля переписать, чем разобраться. почему многие сеокодеры так любят побольше регулярок вставить в код и сделать из него месиво, для меня остается загадкой. дом парсеры или кастомные функции в большинстве случаев предпочтительнее
5)разбиение на функции, разбиение кода по модулям(модульно-ориентированное программирование), следование стандартам объектно-ориентированного проектирования. еще советую почитать про шаблоны проектирования
6) а я не заставляю