Вход на сайт
Правильно программировать
27.11.05 20:27
Где учат правильно проектировать и программировать <Anwendungen> ...???
Чтобы легко можно было что-то изменить...
можете посоветуйте литературу...
как-то написал для одной фирмы программку небольшую...на 1500 строчек..кода..
теперь попросили кое-что изменить...смотрю в код..и нечего не понимаю...
особенно всю логику ...хотя всё написал от и до сам..но 8-мь месяцев назад...
особенно непонятно зачем мне так много переменных около 50 штук...
начинаю распутывать...натыкаюсь на процедуры..вызывающие другие процедуры..и так далее...
голова кругом идёт...
как правильно оформить код...???
скажу сразу, я не программист...
Чтобы легко можно было что-то изменить...
можете посоветуйте литературу...
как-то написал для одной фирмы программку небольшую...на 1500 строчек..кода..
теперь попросили кое-что изменить...смотрю в код..и нечего не понимаю...
особенно всю логику ...хотя всё написал от и до сам..но 8-мь месяцев назад...
особенно непонятно зачем мне так много переменных около 50 штук...
начинаю распутывать...натыкаюсь на процедуры..вызывающие другие процедуры..и так далее...
голова кругом идёт...
как правильно оформить код...???
скажу сразу, я не программист...
NEW 27.11.05 20:49
в ответ Quo Vadis 27.11.05 20:27
а точных правил и нет...
Есть только спецификации на уровне себя лично, на уровне проекта, на уровне фирмы...
Каждый со временем становится более опытным. В результате чего давно писаный код кажется совсем непонятным и от части бредовым. Через это все проходят.
Я часто ужосаюсь смотря на с свой старый код. Учитывая, что я только в начале карьерного пути, то ужосаться прийдется еще долго...
Про тебя можно писать тоже самое. Ты еще тоже молод и неопытен.
Есть только спецификации на уровне себя лично, на уровне проекта, на уровне фирмы...
Каждый со временем становится более опытным. В результате чего давно писаный код кажется совсем непонятным и от части бредовым. Через это все проходят.
Я часто ужосаюсь смотря на с свой старый код. Учитывая, что я только в начале карьерного пути, то ужосаться прийдется еще долго...
Про тебя можно писать тоже самое. Ты еще тоже молод и неопытен.
NEW 27.11.05 21:00
в ответ Quo Vadis 27.11.05 20:42
есть общие правила, но языки бывают разные, которые то поддерживают, то не поддерживают правила:-)
Ну, начни с основ ООП:
классы, обьекты, полиморфизм, интерфейсы, наследование.
Потом переходи на UML, чтобы ты мог моделировать свои приложения и потом не вспоминать, чего ты там творил.
Вот тебе ссылка на видео-уроки для нового Visual C# 2005 Express Edition:
http://msdn.microsoft.com/vstudio/express/visualcsharp/learning/default.aspx
Так что, начинай сразу с .NET 8-)
Попытайся вникнуть, что и как они создают.
Ну, начни с основ ООП:
классы, обьекты, полиморфизм, интерфейсы, наследование.
Потом переходи на UML, чтобы ты мог моделировать свои приложения и потом не вспоминать, чего ты там творил.
Вот тебе ссылка на видео-уроки для нового Visual C# 2005 Express Edition:
http://msdn.microsoft.com/vstudio/express/visualcsharp/learning/default.aspx
Так что, начинай сразу с .NET 8-)
Попытайся вникнуть, что и как они создают.
NEW 27.11.05 21:27
Если пишешь используя ОО и процедурные парадигмы, то прочитай книгу Мартина Фaулера "Рефакторинг" и книгу "the gangs of four": "Design Patterns". Эти две книги прочесть обязательно.
От себя добaвлю: пиши везде комментарии. Параноидально. Дaже, если они кажутся идиотскими. Второе, всегда, вообще всегда, закладывайся на то, что будешь менять программу потом. Обдумывая функциональность класса / модуля, которыe будешь использовать в программе, начинай с дизайна, т.е. думай о том, как именно клиентская часть будет использовать данныe сущности. Избегай ненужных связанностей. Каждая отдельная сущность должна в минимальной степени зависеть от других. Избегай больших методов. В иедале не более пяти строк на метод. Мозг не в состоянии одновременно концентрировать внимание более, чем на пяти-семи объектах. Избегай ненужных хаков. Признак профессионализма - лёгкое понимание кода.
В общем, вот. Удачи.
От себя добaвлю: пиши везде комментарии. Параноидально. Дaже, если они кажутся идиотскими. Второе, всегда, вообще всегда, закладывайся на то, что будешь менять программу потом. Обдумывая функциональность класса / модуля, которыe будешь использовать в программе, начинай с дизайна, т.е. думай о том, как именно клиентская часть будет использовать данныe сущности. Избегай ненужных связанностей. Каждая отдельная сущность должна в минимальной степени зависеть от других. Избегай больших методов. В иедале не более пяти строк на метод. Мозг не в состоянии одновременно концентрировать внимание более, чем на пяти-семи объектах. Избегай ненужных хаков. Признак профессионализма - лёгкое понимание кода.
В общем, вот. Удачи.
Dropbox - средство синхронизации и бэкапа файлов.
NEW 27.11.05 21:33
в ответ Quo Vadis 27.11.05 20:51
Мурр нормально переписывает чужие программы.
Только вот у Мурр'а своего написанного кода... он и не знает сколько.
И в добавок еще переделанного из-под других и _разных_ наверное не меньше. 
Теперь вопрос об том _как_ это делается.
1. Есть две крайние точки - информация в базе и информация на экране. Чем меньше всяких ненужных вещей между ними - тем лучше.
2. Всегда есть какая-то спецификация/документация
. Что требуется на начальном этапе - определить насколько эта документация соответствует тому что реализовано. Все, что не соответствует идет не как переработка, а как разработка с нуля.
3. Выберается архитектура, которая используется в проекте, а лучше - которая может использоваться и в других проектах. Как результат - получаешь "скелет" приложения - не надо будет думать что и где - оно будет определено выбранной архитектурой, нужно будет только реализовывать то что нужно.
4. Приводишь то, что имеешь, к выбранной архитектуре. Понятное дело, что весь проект сразу ты не поднимешь, но те части, в которых ты что-то меняешь, должны выходить из твоих рук уже полностью соответтвующими выбранной архитектуре.
5. Код, который ты пишешь, должен быть простым и понятным, не должен содержать трюков, не должен использовать ничего, кроме того, что стандартизовано. Сложные, выпадающие из принятой архитектуры, вещи должны быть выделены.
и наконец - нулевое правило - ПРОЕКТ ДОЛЖЕН БЫТЬ ДОКУМЕНТИРОВАН. Кроме того, документация на проек разрабатывается не по факту написанного кода, а поэтапно разрабатывается. Кодинг же входит как составная часть создания проектной документации и на него приходится отнюдь не основная часть работы.
Вроде все.
Только вот у Мурр'а своего написанного кода... он и не знает сколько.
И в добавок еще переделанного из-под других и _разных_ наверное не меньше. Теперь вопрос об том _как_ это делается.
1. Есть две крайние точки - информация в базе и информация на экране. Чем меньше всяких ненужных вещей между ними - тем лучше.
2. Всегда есть какая-то спецификация/документация
. Что требуется на начальном этапе - определить насколько эта документация соответствует тому что реализовано. Все, что не соответствует идет не как переработка, а как разработка с нуля.3. Выберается архитектура, которая используется в проекте, а лучше - которая может использоваться и в других проектах. Как результат - получаешь "скелет" приложения - не надо будет думать что и где - оно будет определено выбранной архитектурой, нужно будет только реализовывать то что нужно.
4. Приводишь то, что имеешь, к выбранной архитектуре. Понятное дело, что весь проект сразу ты не поднимешь, но те части, в которых ты что-то меняешь, должны выходить из твоих рук уже полностью соответтвующими выбранной архитектуре.
5. Код, который ты пишешь, должен быть простым и понятным, не должен содержать трюков, не должен использовать ничего, кроме того, что стандартизовано. Сложные, выпадающие из принятой архитектуры, вещи должны быть выделены.
и наконец - нулевое правило - ПРОЕКТ ДОЛЖЕН БЫТЬ ДОКУМЕНТИРОВАН. Кроме того, документация на проек разрабатывается не по факту написанного кода, а поэтапно разрабатывается. Кодинг же входит как составная часть создания проектной документации и на него приходится отнюдь не основная часть работы.
Вроде все.
NEW 27.11.05 23:20
в ответ voxel3d 27.11.05 21:27
Если пишешь используя ОО и процедурные парадигмы, то прочитай книгу Мартина Фaулера "Рефакторинг" и книгу "the gangs of four": "Design Patterns". Эти две книги прочесть обязательно.
Рано ему ещё об этом.
От себя добaвлю: пиши везде комментарии. Параноидально
Не согласен. В самом коде комментарии практически никогда не нужны. Где они действительно нужны - это описание функции: Vor- und Nachbedingungen, аргументы.
В иедале не более пяти строк на метод.
Да ты экстремал. Функции бывают разные, моё правило - должна помещаться на экран.
Рано ему ещё об этом.
От себя добaвлю: пиши везде комментарии. Параноидально
Не согласен. В самом коде комментарии практически никогда не нужны. Где они действительно нужны - это описание функции: Vor- und Nachbedingungen, аргументы.
В иедале не более пяти строк на метод.
Да ты экстремал.
Функции бывают разные, моё правило - должна помещаться на экран.
NEW 28.11.05 00:36
в ответ scorpi_ 27.11.05 23:20
В самом коде комментарии практически никогда не нужны.
------
Если есть нормальная документация на проект - нужны только ссылки на нее.
Но! В случае автора вопроса - писать коментарии, параноидально, можно даже
без кода. По одной из методик обучения, которую я когда-то практиковал в
той стране где сейчас маршируют СС-овцы и уже ищут как остановить поток
эммигрантов, делалось так:
- в "темную", т.е. так, чтобы не видел "сосед", давалось качественное задание и
время на его изучение и задавание вопросов.
- затем задание отбиралось и требовалось не делая код, написать своими словами
что и как должно считаться (повторить постановку задачи).
- затем эти описания просто передавались "соседу" и уже он должен был делать
код.
Разумеется на певый-второй раз ничего не получалось, но была возможность
в живую выяснить что именно было упущено в описании. По прошествии 3-4
занятий люди уже не имели проблем с написанием качественных комментариев
к своему коду.
------
Если есть нормальная документация на проект - нужны только ссылки на нее.
Но! В случае автора вопроса - писать коментарии, параноидально, можно даже
без кода. По одной из методик обучения, которую я когда-то практиковал в
той стране где сейчас маршируют СС-овцы и уже ищут как остановить поток
эммигрантов, делалось так:
- в "темную", т.е. так, чтобы не видел "сосед", давалось качественное задание и
время на его изучение и задавание вопросов.
- затем задание отбиралось и требовалось не делая код, написать своими словами
что и как должно считаться (повторить постановку задачи).
- затем эти описания просто передавались "соседу" и уже он должен был делать
код.
Разумеется на певый-второй раз ничего не получалось, но была возможность
в живую выяснить что именно было упущено в описании. По прошествии 3-4
занятий люди уже не имели проблем с написанием качественных комментариев
к своему коду.
NEW 28.11.05 10:37
в ответ scorpi_ 27.11.05 23:20
От себя добaвлю: пиши везде комментарии. Параноидально
Не согласен. В самом коде комментарии практически никогда не нужны. Где они действительно нужны - это описание функции: Vor- und Nachbedingungen, аргументы.
А по мне -- так лучше параноидально комментировать, чем уже на следующий день смотреть грустными глазами и ничего не понимать. Есть задачи, которые в принципе нельзя раздробить на маленькие, которые по пять строчек кода. Напишешь, например, восемь вложенных ветвлений, а потом смотришь на них и думаешь "мать моя, где ж какое кончается". И в следующий раз, уже помудревший, начало и конец каждого комментируешь.
Не согласен. В самом коде комментарии практически никогда не нужны. Где они действительно нужны - это описание функции: Vor- und Nachbedingungen, аргументы.
А по мне -- так лучше параноидально комментировать, чем уже на следующий день смотреть грустными глазами и ничего не понимать. Есть задачи, которые в принципе нельзя раздробить на маленькие, которые по пять строчек кода. Напишешь, например, восемь вложенных ветвлений, а потом смотришь на них и думаешь "мать моя, где ж какое кончается". И в следующий раз, уже помудревший, начало и конец каждого комментируешь
.
NEW 28.11.05 22:21
в ответ voxel3d 27.11.05 21:27
о, *Рефакторинг* у меня даже на русском есть:-)
По *Design Patterns'ам* вот ету книгу очень хвалят:
http://www.amazon.com/gp/product/0596007124
По *Design Patterns'ам* вот ету книгу очень хвалят:
http://www.amazon.com/gp/product/0596007124
NEW 29.11.05 10:17
в ответ scorpi_ 28.11.05 23:34
Я конечно не великий профессионал, как некотрые, но считаю, что грамотно откоментированый код ничего не заменит. Особенно для новичков ето оптимальный вариант. С опытом програмирования логически правельная структура кода сама установитса. Тем более, что творческий елемент тоже присудствовать должен...
wd360.com
NEW 29.11.05 14:36
в ответ Tomasson 28.11.05 22:25
Согласен с Вадимом. Если писать код, который сам себя комментирует, проблем не будет. В отличие от этого:
<---
;-)
<---
;-)
Прикреплённые файлы
NEW 29.11.05 15:07
в ответ Simple 29.11.05 14:36
Fowler, "Refactoring"
В ответ на:
Don't worry, we aren't saying that people shouldn't write comments. In our olfactory analogy, comments aren't a bad smell; indeed they are a sweet smell. The reason we mention comments here is that comments often are used as a deodorant. It's surprising how often you look at thickly commented code and notice that the comments are there because the code is bad. Comments lead us to bad code that has all the rotten whiffs we've discussed in the rest of this chapter. Our first action is to remove the bad smells by refactoring. When we're finished, we often find that the comments are superfluous.
If you need a comment to explain what a block of code does, try Extract Method. If the method is already extracted but you still need a comment to explain what it does, use Rename Method. If you need to state some rules about the required state of the system, use Introduce Assertion.
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous. A good time to use a comment is when you don't know what to do. In addition to describing what is going on, comments can indicate areas in which you aren't sure. A comment is a good place to say why you did something. This kind of information helps future modifiers, especially forgetful ones.
Don't worry, we aren't saying that people shouldn't write comments. In our olfactory analogy, comments aren't a bad smell; indeed they are a sweet smell. The reason we mention comments here is that comments often are used as a deodorant. It's surprising how often you look at thickly commented code and notice that the comments are there because the code is bad. Comments lead us to bad code that has all the rotten whiffs we've discussed in the rest of this chapter. Our first action is to remove the bad smells by refactoring. When we're finished, we often find that the comments are superfluous.
If you need a comment to explain what a block of code does, try Extract Method. If the method is already extracted but you still need a comment to explain what it does, use Rename Method. If you need to state some rules about the required state of the system, use Introduce Assertion.
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous. A good time to use a comment is when you don't know what to do. In addition to describing what is going on, comments can indicate areas in which you aren't sure. A comment is a good place to say why you did something. This kind of information helps future modifiers, especially forgetful ones.
I did it
my way.
NEW 29.11.05 15:34
в ответ Murr 29.11.05 15:07
Ты мне лучше растолкуй, о чем тут поется: http://www.seeklyrics.com/lyrics/David-Bowie/The-Bewlay-Brothers.html ;-)
NEW 29.11.05 15:48
в ответ scorpi_ 29.11.05 15:12
Yes, about code production and code quality.
I give a sample of code, which do somthing and do very good, but which is completely nonunderstandible.
Of course such type of code cann't be maded with another way, but this sample show that Comment for a code is a god option and have to be added to code.
I give a sample of code, which do somthing and do very good, but which is completely nonunderstandible.
Of course such type of code cann't be maded with another way, but this sample show that Comment for a code is a god option and have to be added to code.
NEW 29.11.05 23:42
в ответ Quo Vadis 29.11.05 22:46
Построчный комент - писать почти без толку.
Бо, максимум, что ты там напишешь - тоже самое что и в операторе.
Писать надо большую шапку для каждого модуля/класса и каждой функции/метода.
Описывать настолько полно, чтобы писать код мог другой человек. Тогда - есть
смысл все это делать. А коммент типа - здесь мы к А прибавим Б чтобы получить Ц
Нафиг никому не нужен. Через неделю он не нужен будет и тебе...
Бо, максимум, что ты там напишешь - тоже самое что и в операторе.
Писать надо большую шапку для каждого модуля/класса и каждой функции/метода.
Описывать настолько полно, чтобы писать код мог другой человек. Тогда - есть
смысл все это делать. А коммент типа - здесь мы к А прибавим Б чтобы получить Ц
Нафиг никому не нужен. Через неделю он не нужен будет и тебе...