tag:blogger.com,1999:blog-8278700074442979782.post5878261486624462418..comments2023-07-12T12:53:44.630+02:00Comments on "Поток сознания" о тестировании и программировании: О коммуникациях и "передаче знаний"Alex W. Lulinhttp://www.blogger.com/profile/08400475846894229767noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-8278700074442979782.post-71702022173650903402014-02-06T18:11:27.171+03:002014-02-06T18:11:27.171+03:00> Если мы говорим не о троллинге, а о дискуссии...> Если мы говорим не о троллинге, а о дискуссии, то желательно иметь обоснование позиции. <br /><br />Моё мнение основанно на личных наблюдениях и собственной практике. Не надо каждый раз пытаться записать меня в тролли. =)<br /><br />Отвечу по пунктам:<br />1. КПД меньше - человек делает работу, которую быстрее бы сделал автор кода.<br />2. Что бы написать документацию, нужно знать код. "Писателю" в любом случае придётся его изучить. К тому же программист лучше знает детали и лучше их опишет. <br />3. Я считаю что квалифицированный инженер должен быть в состоянии написать документацию/описание к своей работе. И, как я писал выше - у "связки" КПД меньше, что, естественно, негативно сказывается на затратах.<br />4. Не надо ложных аналогий - программист в процессе обучения имеет полное право на ошибки, в отличии от приведённых профессий. Этим нужно пользоваться.Son of a gunnoreply@blogger.comtag:blogger.com,1999:blog-8278700074442979782.post-88605665958915767552014-02-04T10:50:27.518+03:002014-02-04T10:50:27.518+03:00>>должен писать программист
Должен, но не об...>>должен писать программист<br />Должен, но не обязан (армейская присказка). <br /><br />Если мы говорим не о троллинге, а о дискуссии, то желательно иметь обоснование позиции. <br /><br />Несколько пунктов в поддержку позиции "почему писать документацию должен ДРУГОЙ человек".<br />1. Своего рода "парное программирование" - если я пишу код под то, что другой будет писать доку, я не буду халявить не только на архитектуре, но и даже на именовании.<br />2. Когда я пишу "о своём", я уже знаю про код/систему. А читать будет тот, кто НЕ знает, но хочет узнать. Поэтому и писать должен тот, кто на одной и той же позиции с целевой аудиторией.<br />3. Писание кода и документирование - суть разные вещи. По компетенции. И по оплате. Ладно, не будем про бабки. Но чисто личностные качества "писателя кода" и "описателя кода" разные. Островский-Белинский. Программист более креативен, писатель более критичен. Все-таки про компетенцию и стоимость таковой. Я бы не стал "Люлина тратить" на доки.<br />4.<br />>>Единственный способ научиться программировать - это писать код, больше никак<br />Типично заблуждение. В классике инженера разработчик винтовок никогда не проектирует свою винтовку с нуля. Инженер по кондиционерам не делает Form1->Button1. Даже врачи никогда не делают первую операцию по книгам. Нужно сначала разобраться с типовыми ГОТОВЫМИ эталонными конструкциями. Посмотреть ОШИБКИ, допущенные предшественниками. И только потом более менее можно приступать к созданию своей системы. <br /><br />Давай, контр-аргументируй. Назвался "son" доставай свой "gun" :)<br />Всеволод Леоновhttp://blogs.embarcadero.com/vsevolodleonovnoreply@blogger.comtag:blogger.com,1999:blog-8278700074442979782.post-16780371539848698962014-02-03T00:30:26.835+03:002014-02-03T00:30:26.835+03:00Намёк оценил :-)Намёк оценил :-)Alex W. Lulinhttps://www.blogger.com/profile/08400475846894229767noreply@blogger.comtag:blogger.com,1999:blog-8278700074442979782.post-21996761908322030322014-02-02T09:32:32.046+03:002014-02-02T09:32:32.046+03:00Моё мнение: документацию к своему коду должен писа...Моё мнение: документацию к своему коду должен писать программист. Комментарии и документация разные вещи. Документация обязательна, несмотря ни на какие UML(грубо говоря схема это часть документации, но одной этой части недостаточно). Комментарии - опционально. Человеку, не понимающему код, сложнее написать правильную документацию. <br />Единственный способ научиться программировать - это писать код, больше никак. Чтение чужого кода - только небольшие отрывки, примеры для переписывания. В написании документации для чужого кода полезного ничего не вижу.Son of a gunnoreply@blogger.comtag:blogger.com,1999:blog-8278700074442979782.post-69124579634045926972014-02-01T20:20:28.196+03:002014-02-01T20:20:28.196+03:00https://d262ilb51hltx0.cloudfront.net/max/900/1*Ds...https://d262ilb51hltx0.cloudfront.net/max/900/1*DsEH7PLPuom0DFHro7CwZg.jpeg<br />:)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8278700074442979782.post-44307828296033454652014-01-31T18:26:01.681+03:002014-01-31T18:26:01.681+03:00>>Вот тут - когда "объясняет он тебе&qu...>>Вот тут - когда "объясняет он тебе", а не "ты ему" - всё становится на свои места. По ходу "его объяснений" - ты начинаешь понимать - как он ТЕБЯ ПОНЯЛ.<br /><br />+100500<br /><br />>>комментировать мой код<br /><br />Вообще, идеальный путь программиста. Начать с "чтения чужих кодов". Вдумчиво. Самое вдумчивое чтение - писать на них доку.<br /><br />+100500<br /><br />И никаких икскьюзов типа "не я пишу доки". Самому доки писать нельзя.<br />Это будет "самодокументирование". А нужно "документ для тех, кто видит код в первый раз". И это должно быть правдой. <br /><br />Так что некоторым начинающим нужно позавидовать, что "не под Вас попали".Всеволод Леоновhttp://blogs.embarcadero.com/vsevolodleonovnoreply@blogger.com